Terraform, module by module
We import what exists rather than demanding a rewrite. Import, verify a plan that shows no changes, then refactor.
Platform
DevOps and platform
Infrastructure in code, environments that rebuild from that code, and a deploy path a new hire can run in their first week without anyone watching.
TerraformCI/CDRebuildable environments
What does a DevOps engagement on AWS cover?
It covers the path from a commit to production: infrastructure defined in Terraform, a pipeline that builds an artifact once and promotes it through environments, secrets held in AWS rather than in a repository, and a rollback that has been run rather than written down.
The problem
Click-built infrastructure is a bet on one person's memory
It works until the person who built it is on leave and staging needs recreating. Then a two-hour job becomes a two-week archaeology project. Moving things into Terraform as we touch them means the second change is always cheaper than the first.
100%
of new infra in code
min
typical deploy time
0
long-lived CI keys
What you get
Included in the engagement
Pipelines
GitHub Actions, GitLab CI or CodePipeline. Build once, promote the same artifact through environments, no rebuilds between staging and production.
Environments on demand
A branch gets a stack, the merge tears it down. Review stops being an argument about who has staging.
Secrets and access
Secrets Manager or Parameter Store, OIDC into AWS from CI, and no long-lived keys in a repository or a laptop.
Rollback that has been used
A rollback path nobody has run is a hypothesis. We run it during the build so it is a procedure.
How it runs
How the platform work runs
The first Terraform apply should be boring. Getting there is most of the work.
State and modules
Terraform state moved somewhere safe and locked, then the estate split into modules that can be applied independently.
Import what already exists
Running resources imported rather than recreated, so adopting Terraform is not an outage.
Pipelines
Build, test and deploy in CI, with the same path to every environment. No deploys from a laptop.
Environments on demand
A branch gets a full environment and gives it back when it merges, so nobody queues for staging.
Secrets and rollback
Secrets out of the repository and into Secrets Manager or Parameter Store, and a rollback rehearsed before the day it is needed.
Fit
Who this is for
If none of these sound like you, say so on the call and we will tell you honestly whether this is the right piece of work to start with.
- Deploys happen at night because that is when it is safe to break things.
- Staging and production have quietly drifted apart.
- Only one person can release, and they would like a holiday.
Do we have to stop shipping while this happens?
No. The work is incremental by design. We take the noisiest part of the pipeline first, and every step leaves the system deployable.
Will our developers be able to maintain it?
That is the point. We write it to be handed over, document it in the repository rather than a wiki nobody updates, and run the walkthrough with your team before we step back.
Do we have to rewrite our infrastructure to use Terraform?
No. We import what already exists, verify a plan that shows no changes, and only then refactor. Nothing is torn down to be rebuilt, because that is the version of this work that causes an outage.
Terraform, CloudFormation or CDK?
Terraform unless you already run CloudFormation or CDK well, in which case we stay there. The tool matters far less than whether every environment can be rebuilt from what is in the repository.
How do you keep AWS credentials out of CI?
OIDC from the CI provider into an AWS role, scoped per environment. No long-lived access keys in a repository, a laptop or a secrets tab, and nothing to rotate when someone leaves.
Can every branch get its own environment?
Yes, and it removes most arguments about who has staging. A branch brings up a stack, the merge tears it down, and the cost stays sane because nothing outlives the pull request.
How do you handle rollbacks?
The same artifact that went forward goes back, and the path gets exercised during the build rather than during an incident. A rollback nobody has run is a hypothesis, not a plan.
Reference
The AWS documentation we work from
Related
Work that usually comes with this
Modern app development
Containers on EKS or ECS, microservices where they earn their keep, and enough observability to debug the system at three in the morning.
BuildRead more
AWS migration
Data centre, another cloud, or a half-finished migration someone else started. We plan the cutover, rehearse it, and keep the rollback usable.
MigrationRead more
Serverless environments
Lambda, API Gateway, EventBridge and Step Functions built where they pay off, and left alone where a container is simply cheaper to run.
ServerlessRead more
Send us your AWS bill
Thirty minutes with an engineer, no slide deck. We will tell you what we would change first and what it would cost to have us do it.