AWS App Runner EU Alternative 2026: Managed Containers, CLOUD Act Exposure, and EU-Sovereign PaaS

Post #693 in the sota.io EU Compliance Series

AWS App Runner launched in 2021 as Amazon's answer to the developer demand for zero-infrastructure container deployment. Where Elastic Beanstalk required understanding EC2 instance types, Auto Scaling groups, and load balancer configurations, App Runner promises simplicity: provide a container image or a source code repository, and App Runner handles everything — container builds, deployment orchestration, automatic scaling, load balancing, TLS certificate management, and custom domain configuration. It scales to zero when idle and scales up under load without developer intervention.

For teams migrating from Elastic Beanstalk — particularly those responding to AWS's 2025 deprecation announcement — App Runner is the natural next step within the AWS ecosystem. It offers equivalent developer ergonomics without the infrastructure management overhead that characterized Beanstalk, and AWS positions it as the modern successor for web application and API container workloads.

The GDPR and CLOUD Act analysis of App Runner follows the same structure as Elastic Beanstalk with a critical addition: App Runner introduces a build service that accesses your application source code directly, creating a source code processing layer under US-entity jurisdiction that didn't exist in Beanstalk's model. For EU organizations processing personal data, every App Runner service configuration, container image, application log, and environment secret lives under the reach of US CLOUD Act compulsion orders directed at Amazon Web Services, Inc.

What App Runner Stores and Processes Under US Jurisdiction

App Runner's data footprint is distributed across several AWS services. The apparent simplicity of the developer experience conceals a significant data persistence surface.

Container images in Amazon ECR. App Runner services sourced from container images pull from Amazon Elastic Container Registry — either a public ECR repository or a private ECR registry in your AWS account. The container images stored in ECR contain your compiled application code, all application dependencies, configuration files baked into the image, and any static assets included at build time. ECR is an AWS service under US-entity jurisdiction. CLOUD Act production orders directed at Amazon would reach private ECR repositories containing your application images.

For App Runner's source-based deployments (where you provide a GitHub repository or CodeStar connection rather than a pre-built image), App Runner's build service clones your repository and builds the container image — meaning AWS infrastructure briefly holds your source code during the build process, and the resulting build artifacts are stored in ECR under AWS's management.

App Runner build service and source code access. The App Runner build pipeline represents the most significant privacy surface that distinguishes App Runner from pure compute services. When you configure a source-based App Runner service, App Runner establishes a connection to your source code repository (GitHub via OAuth, or AWS CodeStar Connections). Each build event causes App Runner to:

1. Clone the specified repository branch from the version control system
2. Execute the configured build commands in a managed build environment
3. Package the resulting application into a container image
4. Push the container image to an ECR repository
5. Deploy the new image to the App Runner service instances

The build environment itself runs on AWS infrastructure under US-entity control. Your source code — including all files in the repository, not just the application files — passes through this managed environment. Repositories containing configuration files, internal documentation, API client libraries, and data models are briefly held in the AWS build infrastructure. The build logs capturing this process are stored in CloudWatch Logs under AWS jurisdiction.

Service configuration and environment variables. App Runner service configurations — including environment variables — are stored in the App Runner control plane. Environment variables in App Runner commonly include database connection strings, API keys for third-party services, feature flags, application secrets, and service discovery endpoints. AWS recommends using AWS Secrets Manager for sensitive values and referencing them by ARN in the App Runner configuration, but direct environment variable configuration is widely used in practice.

Environment variables stored directly in the App Runner service definition are visible in the AWS Console, retrievable via the AWS API, and stored in AWS infrastructure. Under CLOUD Act compulsion, these configuration values — including any secrets stored as plain-text environment variables rather than via Secrets Manager — would be accessible alongside the rest of the service configuration.

CloudWatch Logs: application logs and build logs. App Runner automatically streams two log streams to CloudWatch Logs: application logs (everything your container writes to stdout/stderr) and build logs (the output of the build process for source-based services). Both log streams are stored in CloudWatch under AWS management.

Application logs in container deployments frequently contain richer personal data than developers anticipate. JSON-structured logging libraries capture request context including authenticated user IDs, IP addresses, session identifiers, and request parameters. Error logs include stack traces that may contain database query fragments (potentially including query parameters with user-supplied data). Performance logs capture timing data correlated with request paths that can reveal user behavioral patterns.

CloudWatch Logs retention policies determine how long this data persists. Default configurations retain logs indefinitely. For applications processing EU personal data, CloudWatch Logs represents a secondary personal data store that requires explicit consideration under GDPR Article 30 (Records of Processing Activities) and Article 5(1)(e) (storage limitation principle).

App Runner observability: metrics and traces. App Runner integrates with CloudWatch Metrics for service-level observability: request count, response latency, error rates, active instances, and concurrent requests. For teams using AWS X-Ray integration, App Runner can send distributed traces — including request path data and service dependency maps — to X-Ray's managed tracing service. Both CloudWatch Metrics and X-Ray are AWS services under US-entity jurisdiction.

VPC connector configurations. For App Runner services that require access to private AWS resources (RDS databases, ElastiCache clusters, internal microservices), VPC connector configurations define the network attachment points. VPC connector definitions store VPC IDs, subnet IDs, and security group IDs — effectively a map of your internal network topology. These configurations are stored in the App Runner control plane under AWS management.

Custom domain and certificate management. App Runner supports custom domain configuration with automatic TLS certificate provisioning via AWS Certificate Manager. Domain ownership verification records are managed in Route 53 (or external DNS), and the TLS certificates are stored in ACM. Certificate private keys are managed by AWS KMS under US-entity control.

The Beanstalk Migration Context

For organizations currently migrating from Elastic Beanstalk in response to AWS's 2025 deprecation announcement, App Runner is the migration path AWS explicitly recommends for web application and API workloads. The migration itself is straightforward: containerize the Beanstalk application, push the container image to ECR, and create an App Runner service.

From a GDPR and CLOUD Act perspective, this migration moves the data footprint from one AWS surface to another AWS surface. The Beanstalk-specific data (application versions in S3, Beanstalk saved configurations, .ebextensions artifacts) is replaced by App Runner-specific data (ECR images, App Runner service configurations, CloudWatch build logs). The jurisdictional exposure remains identical: Amazon Web Services, Inc., a US entity, controls the infrastructure throughout.

The compliance consideration for organizations processing EU personal data is explicit: a Beanstalk-to-App-Runner migration does not constitute a compliance improvement from a CLOUD Act or GDPR Transfer Impact Assessment perspective. The TIA for App Runner requires the same CLOUD Act risk assessment as the TIA for Elastic Beanstalk. If the organization's compliance team was examining the Beanstalk TIA as part of the deprecation review, the App Runner TIA must address the same open questions.

The GDPR and CLOUD Act Analysis

Personal data processing categories in App Runner deployments. A web application deployed on App Runner typically processes EU personal data through several channels:

• HTTP request processing: User authentication, form submissions, API calls containing user identifiers — all of this is processed by the application container running on App Runner instances
• Application logging: Log output from the container is automatically captured by App Runner and forwarded to CloudWatch Logs
• Error tracking: Application errors with stack traces are logged to CloudWatch Logs and potentially to third-party error tracking services
• Metrics correlation: CloudWatch Metrics captures request-level performance data that can be correlated with application identifiers

For each of these channels, the relevant GDPR question is whether the processing involves personal data and whether that data flows to a US-jurisdiction storage layer (CloudWatch Logs, CloudWatch Metrics, X-Ray traces).

Article 28 DPA with AWS. AWS's Data Processing Agreement covers App Runner and all underlying services it uses. The DPA provides Standard Contractual Clauses as the legal transfer mechanism for GDPR Chapter V compliance. The CLOUD Act analysis is separate from the DPA: the DPA cannot commit AWS to refusing CLOUD Act production orders, because such orders represent legal obligations that override commercial commitments.

Transfer Impact Assessment requirements. Post-Schrems-II, EU organizations transferring personal data to AWS infrastructure (including via App Runner) must conduct Transfer Impact Assessments for the US data transfer. The TIA for App Runner must assess: the probability of a CLOUD Act production order being directed at the specific data stored in App Runner/ECR/CloudWatch, the sensitivity of that data, and the availability of supplementary measures that would render the data inaccessible to US law enforcement even under compulsion.

For application logs containing EU user behavioral data, encryption of log data with customer-managed KMS keys provides a supplementary measure that limits the usability of compelled data (though the metadata — request counts, IP addresses, timing — remains accessible in CloudWatch Metrics regardless of log encryption).

NIS2 and vulnerability management. NIS2 Article 21(2)(e) requires entities to implement vulnerability management covering the full ICT supply chain, including third-party managed services. For App Runner services, this means assessing whether the App Runner platform itself receives timely security updates (AWS manages this), whether the container images used by App Runner services are based on up-to-date base images (the organization's responsibility), and whether the application code deployed via App Runner incorporates patched dependencies.

App Runner's build service can integrate with container image scanning (ECR image scanning) to identify known vulnerabilities in the container image before deployment. Organizations subject to NIS2 should ensure this scanning is enabled and that build pipelines reject images with critical CVEs.

DORA and exit planning for financial entities. DORA Article 28 requires that ICT risk management include documented operational resilience measures and exit strategies for critical third-party ICT service dependencies. For financial entities deploying customer-facing applications on App Runner, DORA's exit planning requirements mean documenting how the application could be migrated away from App Runner under adverse conditions — platform instability, pricing changes, regulatory direction, or CLOUD Act compulsion scenarios.

The App Runner exit plan must be concrete and tested: can the containerized application be deployed to an alternative managed container service (Scaleway, sota.io, Fly.io) using the existing container image? Is the container image build process documented and reproducible outside the AWS build pipeline? DORA supervisory authorities expect exit plans to be executable, not theoretical.

EU-Native Alternatives to AWS App Runner

For EU organizations that want the App Runner developer experience — zero-infrastructure container deployment with automatic scaling — without the CLOUD Act exposure, the alternatives divide into EU-sovereign and US-entity-with-EU-region categories.

sota.io — EU-native managed PaaS. sota.io provides App Runner-equivalent functionality built on Hetzner infrastructure in EU data centers (Germany, Finland) with no US-entity parent in the operational chain. Container deployments via Git push or container image, automatic TLS, custom domains, environment variable management, and autoscaling — the complete managed container deployment surface. The critical difference from App Runner: the control plane, build pipeline, log storage, metrics, and all operational data remain under EU legal entity control throughout. No CLOUD Act hook exists in the stack.

For organizations migrating from Elastic Beanstalk who were considering App Runner as the next step, sota.io represents the alternative that resolves both the Beanstalk deprecation and the underlying CLOUD Act exposure simultaneously — rather than perpetuating the exposure in a more modern AWS wrapper.

Scaleway Container Registry + Serverless Containers. Scaleway is a French cloud provider (Iliad Group subsidiary) operating as an EU-incorporated entity with no US parent. Scaleway's Serverless Containers provide managed container deployment with automatic scaling, similar to App Runner's operational model. The container registry, build pipeline, and all operational infrastructure run under French/EU legal entity jurisdiction. For EU organizations requiring provable EU legal entity control throughout the stack, Scaleway is the closest public cloud analogue to App Runner's feature set.

Fly.io with EU region selection. Fly.io provides container deployment with EU region options (Amsterdam, Frankfurt, London). The operational entity is Fly.io, Inc., a US corporation, which means CLOUD Act jurisdiction applies regardless of physical EU region selection. Application logs, service configurations, and control plane data are accessible to CLOUD Act production orders directed at the US parent. EU region selection addresses data residency; it does not address CLOUD Act jurisdiction. Teams with EU data residency requirements but no strict legal entity requirements may find Fly.io acceptable with documented TIA.

Render with EU regions. Render provides managed container deployments with Frankfurt region support. Render, Inc. is a US entity. Same jurisdictional analysis as Fly.io applies. Render's April 2026 pricing changes (Pro workspace plans at $25/month, significant bandwidth reductions) affect the cost calculus for teams with moderate traffic volumes.

Hetzner Cloud with Coolify or Dokku (self-managed PaaS). Organizations with the operational capacity to manage a PaaS layer can deploy self-managed App Runner equivalents on Hetzner Cloud infrastructure. Coolify (open-source) provides App Runner-comparable functionality: container deployments, Git-based builds, automatic TLS, environment variable management, and domain management. Dokku provides a Heroku-compatible CLI interface for simpler container deployments. Both run on Hetzner's German and Finnish infrastructure (Hetzner Online GmbH, a German company) with no US-entity dependency. The tradeoff is operational responsibility for the PaaS layer — patches, upgrades, and availability maintenance fall to the organization.

Migration Assessment: App Runner to EU-Native Container PaaS

For organizations evaluating a move from App Runner (or planning to migrate from Beanstalk via a route that avoids App Runner), the migration complexity depends on three variables:

Container image portability. Container images built for App Runner are standard OCI-compliant images and run on any container runtime. If the App Runner service uses a pre-built container image (rather than App Runner's build service), the image can be pushed directly to an EU-sovereign container registry (Scaleway CR, sota.io registry, self-hosted Harbor on Hetzner) and deployed without modification.

Build pipeline migration. If the organization uses App Runner's source-based deployment (GitHub → App Runner build → ECR → App Runner deployment), replacing this with a CI/CD pipeline (GitHub Actions, GitLab CI, or self-hosted) that builds and pushes to an EU-sovereign registry removes the AWS build pipeline from the data flow. The build environment remains under the organization's control rather than AWS's managed build service.

Environment configuration and secrets migration. App Runner environment variables stored directly in the service configuration migrate straightforwardly to the target platform's environment configuration. Secrets referenced via Secrets Manager ARNs require migration to the target platform's secrets management — this is a configuration change, not an application change, assuming the application reads configuration from environment variables (the standard twelve-factor application pattern).

The Compliance Summary

AWS App Runner is a well-engineered managed container service that substantially reduces infrastructure complexity for container-based web applications. For EU organizations processing personal data, App Runner's GDPR and CLOUD Act profile mirrors Elastic Beanstalk's: the entire operational surface — builds, images, configurations, logs, metrics — runs under Amazon Web Services, Inc. jurisdiction, subject to CLOUD Act production orders.

Teams migrating from Elastic Beanstalk who choose App Runner as the migration target resolve the NIS2 platform EOL risk (App Runner is actively maintained) and the DORA exit-planning concern (App Runner has no announced deprecation). But they carry forward the CLOUD Act exposure that existed in Beanstalk. The TIA for App Runner requires the same CLOUD Act risk assessment as the TIA for Beanstalk — there is no compliance dividend from the migration.

For organizations whose GDPR compliance posture requires eliminating CLOUD Act exposure rather than documenting and accepting it, the Beanstalk deprecation is the natural window to migrate to EU-sovereign infrastructure. sota.io provides the App Runner developer experience — zero-infrastructure container deployment, Git-push workflows, managed TLS and domains — built on EU-sovereign infrastructure with no US-entity parent. Move once, solve both problems.