EngineeringScoreAWS container hosting
The part of AWS we recommend is the plain part: your own container in your own VPC, which is what this frontend was rebuilt to be.
We recommend it because we run it
The deployable artifact in this repository is a container image, and the private network is the entire reason it exists. The API keys its scan rate limiting on a header only the frontend is allowed to set, and that assumption holds only while the API cannot be reached from the internet, so the frontend has to sit inside the same network.
What would show you that
- This repository's Dockerfile and server.js are built on the Node adapter's output, and vite.config.ts records why the automatic and static adapters were each rejected for this app.
- docs/deploy-container.md sets out what an ECS task definition and an App Runner service each need, including the inbound rule on the API security group that the whole move exists to make possible, and the headless-Chromium run used to confirm the container serves the same security headers on prerendered and server-rendered pages alike.
What it doesn't do
- AWS Amplify Hosting, where this app ran first, cannot reach a private VPC from its server-rendering compute. The request for it is open on the Amplify Hosting issue tracker as a feature request, so we moved the frontend into a container rather than design around it.
- Amplify Hosting will not take an ordinary Node build either. AWS documents a deployment specification the output has to match, which for SvelteKit meant a community fork of the Node adapter: a dependency on one person's repository for the thing that makes your app deployable.
- An App Runner VPC connector sends all outbound traffic through the VPC, and AWS says the service then has no access to the public internet, so anything the app calls out to needs a NAT gateway on those subnets.
- We can tell you what we chose on AWS and why. This container is verified locally against real Chromium and is not in production yet, so nothing here is a report on what a year of running it taught us.
What it does
- One image runs on Amazon ECS with Fargate or on App Runner with a VPC connector, and either way it gets a security group that another service can admit by reference rather than by address. That reference is the thing worth having.
- AWS does not make you adopt a framework-shaped hosting product to get any of this. A container, a subnet and a security group are the whole interface, which is why the choice between those two runtimes could be left open without changing a line of the image.
Nothing here is gated behind us. Go straight to AWS container hosting and make your own mind up.
Sources
Every claim about AWS container hosting on this page was read on from the pages below. Products change and this page does not change with them, so treat the date as the claim's expiry rather than its publication.
- The AWS Amplify Hosting issue asking for VPC access from the SSR compute runtime, still open and labelled a feature request
- AWS App Runner's networking documentation: that connecting a service to a VPC directs all outbound traffic through it, leaving the service without access to the public internet
- The Amplify Hosting SSR deployment specification, the output format a build has to match to run there
Ready to see where you stand?
Scan your site and get your Engineering Score with a prioritized roadmap in under a minute, no signup required.