AWS Fargate EU Alternative 2026: Serverless Containers, CLOUD Act Exposure, and EU-Sovereign PaaS

Post #694 in the sota.io EU Compliance Series

AWS Fargate was released in 2017 as Amazon's answer to one of the most persistent complaints about containerized deployments: developers did not want to manage EC2 instances, patch operating systems, or right-size Auto Scaling groups just to run containers. Fargate delivers on that promise by abstracting the underlying compute infrastructure entirely. You define a task — a container specification with CPU, memory, networking, and IAM role requirements — and Fargate schedules it on managed infrastructure that AWS controls, patches, and maintains invisibly.

Fargate operates as the execution engine for both Amazon ECS (Elastic Container Service) and Amazon EKS (Elastic Kubernetes Service). When you launch ECS tasks with the FARGATE launch type, or configure EKS node groups to use Fargate profiles, your containers run on Fargate's managed compute substrate rather than EC2 instances that appear in your AWS account. The operational simplicity is genuine: no AMI maintenance, no node group upgrades, no capacity reservation complexity. Fargate handles all of that.

For EU organizations processing personal data, Fargate's serverless abstraction does not change the jurisdictional analysis: Amazon Web Services, Inc. — a US corporation — controls the infrastructure on which every Fargate task runs. Task definitions, container images, environment variables, CloudWatch log streams, CloudWatch Container Insights telemetry, and all IAM configurations are stored and managed under US-entity jurisdiction, subject to CLOUD Act production orders directed at Amazon. The elimination of visible EC2 instances eliminates operational complexity, but it does not eliminate CLOUD Act exposure.

What Fargate Stores and Processes Under US Jurisdiction

Fargate's data surface is distributed across ECS/EKS control planes, ECR, CloudWatch, and Secrets Manager. The serverless model makes this surface less visible — because there are no EC2 instances to examine, the underlying data persistence is easy to overlook in GDPR analysis.

Task definitions and container specifications. Fargate workloads are defined through ECS task definitions or EKS pod specs. Task definitions include: container image URIs (pointing to ECR or external registries), CPU and memory allocations, environment variable specifications, Secrets Manager and Parameter Store references, network mode configurations, IAM task role ARNs, and log routing configurations. Task definitions are versioned and stored in the ECS control plane indefinitely unless explicitly deregistered. Every version of a task definition — including historical versions containing deprecated configuration or old secret references — is retrievable via the AWS API. Task definitions are AWS-managed data under US-entity jurisdiction.

Container images in Amazon ECR. Fargate tasks typically pull container images from Amazon ECR. ECR stores OCI-compliant container images consisting of: the application binary and all compiled dependencies, base OS layer (typically Alpine, Debian, or Amazon Linux), application configuration files baked into the image, and any static data included at build time. ECR stores multiple image versions — each git push that triggers a CI/CD pipeline typically creates a new image tag in ECR. Historical image versions accumulate unless lifecycle policies remove them. ECR's image vulnerability scanning service (basic or enhanced via Inspector) processes the image layers to identify CVEs — this scanning occurs within AWS infrastructure under US-entity jurisdiction.

Environment variables and secrets. Fargate container environment variables are specified in task definitions or injected via Secrets Manager or Systems Manager Parameter Store. Direct environment variable specifications in task definitions are stored in plaintext as part of the task definition and visible via the AWS API. Variables sourced from Secrets Manager are stored encrypted in Secrets Manager (AWS-managed or customer-managed KMS key) and injected into the Fargate task environment at runtime — the injection mechanism runs within AWS infrastructure. For EU applications, environment variables commonly contain database connection strings (containing host, credentials, and database name), OAuth client secrets, third-party API keys, feature flags controlling data processing behavior, and service discovery endpoints. All of this is stored under AWS's US-entity control.

CloudWatch Logs: container output and platform logs. Fargate containers log via the awslogs driver by default, which streams all container stdout and stderr to CloudWatch Logs. This is the lowest-friction logging configuration and is used by default in most ECS deployments. CloudWatch Logs stores this output in log groups organized by cluster and task family. Container application logs routinely contain: authenticated user identifiers (from JWT claims or session tokens), IP addresses from HTTP request context captured by logging middleware, user-submitted data fragments in error messages, database query results included in debug logging, and behavioral telemetry (page views, feature usage, conversion events) when captured via server-side logging.

For Fargate tasks running EU-facing applications, CloudWatch Logs becomes a secondary personal data store containing real user interaction data. The default retention configuration for CloudWatch Logs is indefinite retention — unless log group retention policies are explicitly configured, application logs accumulate without expiry. GDPR Article 5(1)(e)'s storage limitation principle requires that personal data be retained no longer than necessary; CloudWatch Logs' default indefinite retention is non-compliant for logs containing personal data unless retention policies are configured.

CloudWatch Container Insights. ECS Fargate clusters with Container Insights enabled send additional telemetry to CloudWatch: task-level CPU and memory utilization metrics, network I/O metrics, storage I/O metrics, and cluster-level aggregate metrics. Container Insights metrics are stored in CloudWatch Metrics under AWS management. For applications where task utilization correlates with user activity (an e-commerce application processes more requests at peak shopping hours, a healthcare application shows utilization spikes during appointment windows), Container Insights data can be indirectly linked to user behavioral patterns. All Container Insights data is stored under AWS jurisdiction.

ECS Service Discovery and AWS Cloud Map. Fargate services using ECS Service Discovery register service instances with AWS Cloud Map — Amazon's managed DNS-based service registry. Cloud Map stores service instance records including task IP addresses, ports, and custom attributes. For microservice architectures, the full service dependency map is reconstructed from Cloud Map data. Cloud Map is an AWS service under US-entity control.

Secrets Manager and Parameter Store. Applications running in Fargate commonly use Secrets Manager for credential management. Secrets Manager stores: database credentials (username, password, host), API keys for external services, OAuth secrets, certificate private keys, and application-specific configuration secrets. Secrets Manager stores these values encrypted (AWS-managed or customer-managed KMS key), but the storage, access logging (in CloudTrail), and retrieval mechanisms are all under AWS management. Under CLOUD Act compulsion, both the encrypted values and the KMS decryption keys (if AWS-managed) are accessible.

The ECS and EKS Context

Fargate is not a standalone service — it is the compute substrate for ECS and EKS, and the GDPR analysis of Fargate is inseparable from the analysis of the orchestration layer above it.

ECS + Fargate. In the ECS model, Fargate tasks are launched by ECS services or task schedulers using the FARGATE or FARGATE_SPOT launch type. The ECS control plane (cluster configuration, service definitions, task placement logic, load balancer target group associations) is managed by AWS and stored under AWS jurisdiction. ECS task metadata — including task ARNs, task state transitions, placement history, and network interface assignments — is stored in the ECS control plane.

EKS + Fargate. In the EKS model, Fargate profiles define which Kubernetes pods run on Fargate compute. Kubernetes pod specifications (including init containers, sidecar containers, environment variables, volume mounts, and resource requests) are stored in the EKS cluster's etcd datastore — managed by AWS as part of the EKS control plane. The EKS cluster etcd is not directly accessible to customers and is managed by Amazon under US-entity control. Kubernetes events, pod logs (routed via Fluent Bit to CloudWatch), and cluster audit logs are all stored under AWS management.

Fargate Spot. Fargate Spot provides up to 70% cost reduction for interrupt-tolerant workloads by running tasks on spare AWS capacity that can be reclaimed with a 2-minute warning. The data surface for Fargate Spot is identical to standard Fargate — the only difference is task interruption behavior. Fargate Spot tasks process the same data in the same AWS-managed environment as standard Fargate tasks.

The GDPR and CLOUD Act Analysis

CLOUD Act and Fargate's invisible infrastructure. The CLOUD Act grants US law enforcement agencies the authority to compel US-incorporated entities to produce data they store, control, or have access to, regardless of where that data is physically located. Amazon Web Services, Inc. is the contracting entity for AWS services including Fargate, ECS, EKS, ECR, CloudWatch, Secrets Manager, and Cloud Map. A CLOUD Act production order directed at Amazon can compel production of: the container images your Fargate tasks run, the task definitions specifying your application configuration and secrets references, the CloudWatch Logs containing your application output and user data, the Secrets Manager values containing your database credentials and API keys, and the Container Insights telemetry from your cluster.

The elimination of visible EC2 infrastructure does not create any CLOUD Act exemption. Fargate's managed infrastructure model means AWS has deeper access to the execution environment than in an EC2 model where the customer controls the OS — the hypervisor layer, the container runtime, and the task execution environment are all under AWS's management.

Personal data in Fargate deployments. For EU organizations, the relevant assessment is: what personal data flows through the Fargate execution environment? The answer depends on the application but typically includes:

• HTTP request processing: User-authenticated requests handled by the containerized application include user identifiers, session tokens, submitted form data, and behavioral telemetry
• Application logging: CloudWatch Logs receive structured log output containing request context (IP addresses, authenticated user IDs, device identifiers)
• Secrets and credentials: Database connection strings contain infrastructure details; secrets themselves may include cryptographic material derived from user data
• Metrics correlation: CloudWatch Container Insights metrics correlate task load with time periods, which for single-tenant or identifiable workloads can be correlated with individual user activity

Each category requires GDPR Article 30 (Records of Processing Activities) documentation and Article 13/14 data subject notification if the processing involves personal data.

Article 28 DPA with AWS. AWS's Data Processing Agreement covers all Fargate-related services. The DPA provides Standard Contractual Clauses (Module 2: controller-to-processor) as the legal transfer mechanism for GDPR Chapter V compliance. The DPA specifies that AWS acts as a processor for the customer's data — but the DPA cannot commit AWS to refusing CLOUD Act production orders. CLOUD Act obligations supersede commercial commitments, and AWS's DPA explicitly notes that AWS will comply with binding legal process.

Transfer Impact Assessment. Post-Schrems-II, organizations transferring personal data to AWS Fargate infrastructure must conduct Transfer Impact Assessments. The TIA for Fargate must assess: (1) the probability of CLOUD Act compulsion being directed at the specific data in the Fargate environment, (2) the sensitivity of the data at risk, (3) available supplementary measures (customer-managed KMS encryption, VPC endpoint configurations, log encryption), and (4) residual risk after supplementary measures.

Customer-managed KMS keys for CloudWatch Logs encryption and Secrets Manager provide a meaningful supplementary measure — compelled production of encrypted log data is less useful to law enforcement if the decryption key is customer-managed and can be subject to separate legal challenge. However, the task execution metadata (task ARNs, IP assignments, service discovery records, Container Insights metrics) is not customer-encryptable and remains accessible under compulsion regardless of KMS configuration.

NIS2 Article 21(2)(e) and container vulnerability management. NIS2 Article 21(2)(e) requires essential and important entities to implement vulnerability management covering the full ICT supply chain. For Fargate deployments, this means:

• Container base images must be regularly scanned and updated (ECR image scanning or external tools)
• Application dependencies must be patched promptly when CVEs are published
• Fargate task definitions must be updated when base image CVEs are remediated
• ECR lifecycle policies should remove vulnerable historical image versions

AWS manages the Fargate compute layer itself (OS patching, hypervisor updates, container runtime security) — this NIS2 obligation is fulfilled by AWS contractually via the shared responsibility model. The application layer (container image content, application dependencies) remains the customer's NIS2 responsibility.

DORA Article 28 and exit planning for Fargate-dependent financial entities. DORA Article 28 requires that financial entities document and test exit strategies for critical ICT third-party dependencies. For financial entities running customer-facing or core banking applications on ECS Fargate, the DORA exit plan must specify how those workloads would be migrated under adverse conditions — Fargate service disruption, pricing changes, regulatory direction, or CLOUD Act compulsion scenarios affecting the data in Fargate-managed storage.

A concrete DORA exit plan for Fargate includes: confirmation that container images are OCI-compliant and deployable on any compatible runtime, documentation of the Fargate-specific configurations (task IAM roles, VPC networking) and their equivalents on alternative platforms, and a tested runbook for deploying the containerized application to an EU-sovereign PaaS or self-managed container platform. DORA supervisory authorities expect exit plans to be executable within 30 days for critical functions.

EU-Native Alternatives to AWS Fargate

For EU organizations seeking serverless container execution without CLOUD Act exposure, the alternatives divide into EU-sovereign managed PaaS and self-managed options.

sota.io — EU-native managed PaaS. sota.io provides Fargate-equivalent functionality — deploy-from-image or deploy-from-Git container workloads with automatic scaling, managed TLS, custom domains, and environment variable management — built on Hetzner infrastructure in EU data centers (Germany, Finland) with no US-entity parent in the operational chain. The critical structural difference from Fargate: the control plane, container execution environment, log storage, and all operational metadata remain under EU legal entity control throughout. There is no CLOUD Act hook in the stack. For teams that want the Fargate developer experience (no instance management, automatic scaling, Git-integrated deployments) without the jurisdictional exposure, sota.io provides the equivalent value proposition from a structurally EU-sovereign foundation.

Scaleway Serverless Containers. Scaleway (Iliad Group subsidiary, French entity) provides a serverless container offering with automatic scaling semantics similar to Fargate. Container images are pulled from Scaleway Container Registry or external registries, and the execution infrastructure operates under French/EU legal entity jurisdiction. Scaleway's serverless containers support custom domains, environment variables, and secrets management. For organizations requiring provable EU legal entity control throughout the compute and storage stack, Scaleway is the closest public cloud analogue to Fargate's operational model.

OVHcloud — Managed Kubernetes with Fargate-like scheduling. OVHcloud (OVH SAS, French entity) provides managed Kubernetes (MKS) with EU-jurisdictioned control planes. OVHcloud does not offer a direct Fargate equivalent (serverless compute without node management), but managed Kubernetes with Karpenter-style node autoprovisioning achieves similar operational outcomes — minimal node management with container-level resource abstraction. OVHcloud infrastructure operates under French commercial law with no US parent.

Hetzner Cloud with Kubernetes (k3s, k0s, or kubeadm). Organizations with the operational capacity to manage a Kubernetes control plane can achieve Fargate-equivalent container scheduling on Hetzner Cloud infrastructure (Hetzner Online GmbH, German company). k3s (lightweight Kubernetes) deployed on Hetzner provides the container scheduling and scaling capabilities of Fargate without AWS infrastructure. The operational overhead compared to Fargate is real — node management, control plane maintenance, and cluster upgrades become internal responsibilities — but the jurisdictional outcome is EU-sovereign infrastructure with no CLOUD Act exposure.

Fly.io and Render with EU regions. Fly.io and Render both offer containerized application deployment with EU region selection. Both are US-incorporated entities (Fly.io, Inc. and Render, Inc.), which means CLOUD Act jurisdiction applies regardless of EU region selection for task execution. Application logs, service configurations, and control plane metadata are accessible to CLOUD Act production orders directed at the US parent. These options address data residency requirements but do not address CLOUD Act jurisdiction. Teams with EU residency requirements but no strict legal entity requirements may find them acceptable with documented TIA.

Migration Assessment: Fargate to EU-Native Container Execution

Container image portability. OCI-compliant container images built for Fargate run on any compatible container runtime without modification. If the application container image does not depend on Fargate-specific execution context (instance metadata service endpoints, ECS task metadata endpoint, Fargate-injected environment variables), it is directly portable to EU-sovereign container platforms.

Task definition to platform configuration translation. Fargate task definitions specify CPU/memory, network mode, log routing, IAM role, and environment configuration. The equivalent configuration in sota.io or Scaleway is a service definition or container app configuration — structurally parallel but platform-specific. The translation is mechanical: CPU/memory resource requests, environment variables, secrets references, and custom domain configuration map directly to equivalent fields in EU-sovereign platform APIs.

IAM task roles and permissions. Fargate tasks often rely on IAM task roles for AWS service access — reading from S3, writing to DynamoDB, sending to SQS. Migrating away from Fargate means migrating away from the AWS services these roles access. If the application uses AWS-native services (S3, DynamoDB, SQS) that do not have direct EU-sovereign equivalents in the migration target, the migration scope expands beyond the compute layer to include storage and messaging layer replacement. For applications already using database-centric architectures (PostgreSQL, Redis, application-level message queues), the IAM dependency surface is typically limited to S3 and secrets access — both of which have EU-sovereign equivalents.

CloudWatch log migration. Applications using awslogs driver to stream to CloudWatch require a log routing change when migrating from Fargate. EU-sovereign platforms route container logs to platform-managed log storage. For teams running custom observability (Grafana, OpenSearch, Loki), the migration typically involves pointing the application's logging driver at the existing observability infrastructure rather than CloudWatch.

The Compliance Summary

AWS Fargate delivers genuine operational value: no EC2 instance management, automatic scaling, and tight integration with AWS's container ecosystem. For EU organizations processing personal data, Fargate's serverless model does not reduce CLOUD Act exposure — it increases AWS's depth of access to the execution environment relative to EC2, because the Fargate compute substrate is entirely under Amazon's management.

The GDPR and CLOUD Act profile of Fargate is substantively identical to ECS with EC2 launch type, EKS with managed node groups, and App Runner: Amazon Web Services, Inc. controls the infrastructure, stores the task definitions and container images, receives the CloudWatch log streams, and manages the Secrets Manager values. CLOUD Act compulsion orders directed at Amazon reach the full Fargate data surface.

For organizations whose GDPR compliance posture requires EU-sovereign infrastructure — eliminating CLOUD Act exposure rather than documenting and accepting it — Fargate is not a compliant foundation for EU personal data workloads. sota.io provides the Fargate developer experience — serverless container deployment, automatic scaling, Git-integrated workflows, managed TLS and domains — built on Hetzner's EU-sovereign infrastructure with no US-entity parent. No task definition stored under US-entity control. No CloudWatch log streams under CLOUD Act jurisdiction. Move once, solve the problem at the infrastructure layer.