Deploying Blazor Server apps on Amazon ECS with AWS Fargate
The AWS .NET blog shows how to run Blazor Server applications on Amazon ECS with AWS Fargate. The post explains how the persistent WebSocket connection and in-memory circuit shape routing, session stickiness and deployment behavior. It walks through a CDK-based sample stack fronted by CloudFront.
Key points
- Blazor Server keeps a circuit per session in memory, so every request from a browser must stick to the same task.
- The app enables ForwardedHeaders for X-Forwarded-For and X-Forwarded-Proto and overrides the scheme to https.
- When several instances run, ASP.NET Core Data Protection keys must go to a shared store, configured with AddDataProtection.
- The Data Protection setup needs Systems Manager permissions on the task role and an SSM interface endpoint in isolated subnets.
- The sample uses a 1 GiB Fargate task on port 8080; measure real memory use under load before setting DesiredCount.
- The sample runs in one Availability Zone to save cost; production should spread tasks and endpoints across several AZs.
Blazor Server keeps state on the server and creates an in-memory circuit for each browser session. That means the infrastructure must send every request from a browser to the same ECS task. If routing breaks, the circuit is lost and the user gets a reconnection error. The post shows how these constraints drive the whole deployment design.
In the sample, traffic enters through CloudFront and reaches an internal Application Load Balancer in private subnets, which forwards it to two Fargate tasks on port 8080. CloudFront connects to the load balancer through a VPC origin, and TLS is handled by the default CloudFront certificate. The app trusts X-Forwarded headers and stores ASP.NET Core Data Protection keys in Systems Manager Parameter Store so instances share them. The example uses a single Availability Zone to cut costs, which production setups should avoid.
Real-world use
- A team migrating legacy ASP.NET Web Forms apps to Blazor Server and hosting them on AWS.
- An internal back-office or form-heavy enterprise app that keeps per-user state on the server.
- A platform team that wants a CDK-managed Blazor Server service behind CloudFront in private subnets.
Why it matters
Moving Blazor Server into containers means handling sticky routing, shared Data Protection keys and circuit loss during deployments as first-class concerns. The post gives a concrete starting point for all three.