Fargate over self-managed instances
Patching and scaling a fleet is real, recurring work. Fargate trades a slightly higher unit cost for the removal of that work entirely, which is the right trade for teams without a dedicated platform group.
Back to work
Cloud Commerce Infrastructure
A reusable deployment architecture for modern commerce applications using automated infrastructure and containerised services.
- Cloud and platform engineering
- 2024 — Present
- AWSTerraformDockerAmazon ECSFargateGitHub Actions
Context, challenge and the part I played.
Context
Most commerce projects rebuild the same infrastructure from scratch. This is that work done once, as a reusable module set.
Challenge
Infrastructure written for one project tends to encode that project's assumptions. Making it reusable meant separating what genuinely varies between deployments from what should stay fixed.
Goals
- Make a new environment a configuration exercise rather than a build
- Remove manual steps from the path to production
- Keep infrastructure changes reviewable alongside application changes
- Keep running costs proportionate to the size of the project
My role
I designed the module structure, wrote the Terraform, and built the delivery pipeline.
From interface down to infrastructure.
Each layer, and the reasoning that shaped it.
Architecture
Composable Terraform modules — network, data, runtime, delivery — assembled per environment. Each module has a narrow input surface, so a new environment is a short configuration file rather than a copy of the previous one.
Front-end
Static assets are built in the pipeline and served from object storage behind a CDN, keeping the application containers focused on dynamic requests.
Backend
Application containers run on ECS with Fargate. Health checks and rolling updates mean a bad release is replaced rather than absorbed.
Database
Managed PostgreSQL with automated backups, and Redis for caching and sessions. Credentials are issued from a secrets store, never committed.
Cloud & deployment
GitHub Actions builds, tests and publishes images, then triggers the service update. Deployment permissions are scoped to exactly what the pipeline needs.
What the system actually does.
Infrastructure as code
Networking, compute, data services and permissions declared in Terraform and reviewed in pull requests.
Containerised services
Multi-stage Docker builds produce small, reproducible images with no build tooling shipped to production.
Serverless container runtime
ECS on Fargate removes host management while keeping the deployment model familiar.
Automated delivery pipeline
Build, test, image publish and deploy run on every merge, with no manual server access required.
Environment parity
Staging and production share one module, differing only in configuration values.
Interface and system views.
Placeholder frames — swap for real captures once they exist.
Environment topology - admin · orders
Delivery pipeline stages Terraform module composition
The trade-offs worth writing down.
Every architecture is a set of choices. These are the ones that mattered most, and why they went the way they did.
One module set, many environments
Environments that drift apart cause the failures that only appear in production. Sharing one module and varying only configuration keeps staging a genuine rehearsal.
Where it stands.
- Created a maintainable foundation for repeatable deployments
- Improved separation of responsibilities between infrastructure and application code
- Designed for future scaling across additional environments
Want the detail behind any of these decisions?
Start a conversation