Serverless and Containers in the AWS European Sovereign Cloud: What Ports Across and What You Have to Build

The question most teams actually have about the AWS European Sovereign Cloud (ESC) is simpler than sovereignty: does an ordinary serverless or container workload move into it? The short answer is yes for the primitives and no for three things that usually sit around them - the edge, the managed shortcuts from a container to a URL and the pipeline that deploys the lot.

What is available is easy to summarise. Lambda, DynamoDB, SQS, SNS, EventBridge, Step Functions, ECS with Fargate, EKS, ECR, Elastic Load Balancing, Cognito and API Gateway are all present and close to complete. CloudFront and Global Accelerator are absent, so there is no edge tier of any kind. ECS Express Mode, AppSync, Amplify and Elastic Beanstalk are absent, so the shortcuts are gone. X-Ray, Synthetics, RUM and the CloudWatch core are present with the newer parts missing. Of AWS’s own CI/CD family only CodeDeploy exists.

What is new since the first two posts is that AWS has published dates. Its Capabilities by Region data on the Builder Center, which AWS describes as carrying “forward-looking roadmap information”, now gives a status for each of these gaps in eusc-de-east-1. HTTP APIs and Lambda durable functions are planned for 2026 Q3, CloudFront for 2026 Q4; CodeBuild, CodePipeline, CodeCommit, CodeArtifact and Elastic Beanstalk for 2027 Q1. Global Accelerator, EventBridge Pipes, CloudFormation Git Sync and EKS on Fargate are being planned with no date. AppSync, Amplify, Lambda Function URLs, Managed Grafana and Managed Service for Prometheus are marked as not expanding to the partition. The data has its limits - it is reliable at service level, its sub-feature rows carry no parent service name and a few rows lag the partition - but it sorts the gaps three ways; a reader plans differently for a gap with a quarter on it than for one AWS says is not coming. Design around what is not coming, wait for what has a date and treat what is merely being planned as absent.

This is the last of three posts on the ESC, verified against eusc-de-east-1 from a real organisation running in the partition. The first covered what the partition is and how much sovereignty it gets you; the second covered AI.

The primitives port across

SQS is at parity, with a differences page that says “There are no differences for this service”. SNS lacks only mobile push. EventBridge has its default bus, Scheduler and archive and replay; Pipes is absent. Step Functions is present including Express workflows. DynamoDB is present with Streams; PartiQL works: the differences page lists it as unavailable; an insert, a select, an update and a batch statement against a test table all ran without complaint. ECS with Fargate, EKS, ECR, the three load balancer types and Cognito are all here.

What changes a design is a shorter list. API Gateway is REST only for now; since HTTP APIs are the cheaper and simpler default for new serverless work, every Lambda-behind-an-API design can only use REST. A WebSocket API, which the same page also lists as unavailable, can be created and returns a wss:// endpoint. Lambda has no Function URLs, which AWS’s data says are not coming, so an HTTP endpoint in front of a function means API Gateway or an Application Load Balancer. Lambda also lacks the Kafka, MQ and DocumentDB event sources and has SnapStart for Java only (Lambda differences); DynamoDB has no DAX and no Global Tables; EKS has no Fargate.

On the container side ECS with Fargate, EKS and ECR are present; ECR lacks enhanced scanning and limits its pull-through cache to the partition. What is missing are the shortcuts. ECS Express Mode, the one-call path to a service on Fargate behind an ALB with auto scaling, returns UnsupportedFeatureException; Elastic Beanstalk is planned for 2027 Q1. So a container reaches a public URL the standard way, ECS or EKS behind an ALB with auto scaling, a certificate and DNS you define yourself. One thing to check before relying on the documentation: the ECS page says only rolling or external deployments are supported, while AWS announced blue/green, linear and canary deployment strategies for ECS services in the ESC in July 2026.

CloudFront is missing and it takes static websites with it

CloudFront is absent; Global Accelerator is absent too, so there is no CDN, no edge compute and no anycast front door in the partition. Three consequences change what you build today, each a documented ESC gap that exists because CloudFront does not. API Gateway endpoints are therefore regional or private. S3 static websites are served over HTTP only; the ESC’s own S3 documentation repeats the commercial advice that “If you want to use HTTPS, you can use Amazon CloudFront”, which in this partition you cannot. Cognito user pools get a prefix domain only, because custom domains are CloudFront-backed.

With no CloudFront and S3 websites on HTTP, there is no managed way to serve a static website or a single-page application over HTTPS.

ALB currently carries the weight as a result. It is the public HTTPS front door for containers, for Lambda and for static content; ALB mTLS and its Trust Store are unavailable, so mutual TLS terminates somewhere else.

AWS’s data puts CloudFront in 2026 Q4; the launch services blog said the same in November 2025, “expected to be available in by the end of 2026”. Whether its points of presence would be EU-only and EU-operated, in line with the rest of the sovereignty model, is unstated anywhere I can find.

Observability is there, minus the newer parts

X-Ray exists in the partition, with the default sampling rule and group in place and a differences page that lists what it lacks: W3C trace IDs, cross-account tracing, the ADOT collector and Transaction Search. What Lambda lacks is the X-Ray integration, so a function cannot be traced natively while a container or an instance can. Synthetics, RUM and Observability Access Manager all answer. Application Signals is the odd one: the CloudWatch page says it is not available and the endpoint table has no row for it, yet its API answers with empty lists; AWS’s data lists it as being planned. Container Insights for ECS is being planned too. Managed Grafana and Managed Service for Prometheus are marked as not expanding, so dashboards are CloudWatch’s own or something you run.

CloudWatch Logs is present with a longer list of gaps than any other service here, per its differences page: no Live Tail, no data protection masking, no log transformation and no regex syntax in filter patterns, among others; transformation is planned for 2026 Q4.

Those are the features that help you make sense of unstructured logs after the fact. Logs written as structured JSON from the start do not need them, because JSON filter patterns for metric filters, Logs Insights, alarms and dashboards are all present. I made the case for structured, contextual logs in 2019 and it applies in this partition with more force rather than less: structure the logs, derive the metrics and alarms from them and treat tracing as the second layer, especially for anything on Lambda.

There is no managed CI/CD pipeline until 2027

CodeDeploy is the whole of AWS’s CI/CD in the partition, present with no differences. CodeBuild, CodePipeline, CodeCommit and CodeArtifact have no endpoints; AWS’s data plans all four for 2027 Q1, with CloudFormation Git Sync being planned. Customizations for Control Tower and Account Factory for Terraform are built on CodePipeline and CodeBuild, which is why the first post found them absent, so customising the landing zone with AWS’s own tooling waits for the same date. Ours went in from the CloudFormation console and, for the development account, from GitHub through CDK.

What sits inside the partition regardless of where the pipeline runs is the deployment identity and the enforcement. The identity is a chain: a GitHub Actions OIDC token is exchanged for a role that holds a single permission, sts:AssumeRole on the CDK deploy role; that role can act on CloudFormation and pass the execution role; and the CloudFormation execution role, the only administrator identity in the chain, is used by CloudFormation and never held by a workflow. The enforcement is a CloudFormation Guard hook. Registered from a stack, it blocks non-compliant stacks.

Since August 2026 IAM in the partition can also mint short-lived tokens for external services, which removes static keys in the other direction for a pipeline that has to call back to its host.

The pipeline itself is then a choice between two shapes. Hosted outside the partition, where GitHub, GitLab and Microsoft each offer EU data residency for their hosted products and each delivers it on a US hyperscaler’s commercial EU region under a US-owned operator: GitHub Enterprise Cloud with data residency on Azure, GitLab Dedicated on AWS, Azure DevOps in an EU geography with tokens stored in the United States. However European the region, source, build logs and often the runners stay with that operator. STACKIT Git from Schwarz Digits, Forgejo-based with managed runners in a German cloud, is the European-owned exception I have found. Or self-managed inside the partition, GitLab, GitHub Enterprise Server, Forgejo, Woodpecker or Jenkins on EC2 or EKS, with the operating cost that implies. GitHub Actions with self-hosted runners in the ESC is the halfway house: build compute and secrets inside, control plane in the United States.

My own view is that the choice is where the control plane lives against how much you want to operate yourself and how much ecosystem you keep; until 2027 it is a decision a sovereign-cloud programme has to make explicitly rather than inherit from whatever the team used last.

What is coming, is planned and not coming

Build event-driven and container workloads in the partition now. The primitives are there, the design changes are known and small; the front door is REST API Gateway or an ALB.

Put an ALB at the front and plan to take it out of that role when CloudFront lands in the fourth quarter; expect HTTP APIs this quarter and design for REST until they arrive. Static websites and single-page applications are the workload with no managed home until then: front them with API Gateway or a container behind an ALB and plan to move them when CloudFront does arrive.

Structure the logs first and add tracing second, for anything on Lambda in particular. The parts of CloudWatch that are missing are the ones you need least if the logs are structured.

Choose the pipeline deliberately. Hosted outside the partition or self-managed inside it is a sovereignty decision with an operating cost attached; It is also a decision worth hedging: with CodeBuild, CodePipeline and CodeArtifact due in 2027 Q1 you can keep the pipeline tactical and deployments in CloudFormation or CDK, so that moving the orchestration into the partition later is a change of runner rather than a complete redesign.

Over three posts the picture has been consistent. The ESC is AWS with a shorter service and feature list, operated in Germany by EU-resident staff; much of what an organisation runs from day to day works in it today. The differences sit at the partition boundary: anything that depends on a second region, on a commercial AWS account or on an edge network is absent. The sovereignty question remains one of ownership, as the first post set out; no roadmap alters that. AI is the thinnest area, with three usable models at the time of writing. For the rest, AWS has now published which gaps close and when, which is considerably more than what was said before; a move into the partition can be planned against quarters rather than against guesswork.

If you are evaluating the AWS European Sovereign Cloud for your organisation, Virtuability can help - or email team@virtuability.com.