AWS & DevOps consulting
Infrastructure your team can change on a Tuesday afternoon without a war room: defined in Terraform, shipped through one pipeline, and locked down by default.
Sound familiar?
- Infrastructure built by hand in the console, so nobody is sure what is running or why.
- Deployments that work differently for every service, and only one person knows all the variations.
- IAM policies and security groups that grew by exception until “allow everything” became the easy choice.
- Environments that can’t be reproduced, so testing happens in production by accident.
- A platform that worked for the first ten services and is starting to creak under the next ten.
How I approach it
I start with what is actually running, not what the diagram says. Most cloud estates have drifted from their documentation, and the useful decisions come from the real account: its networks, its roles, its bill, and the pipelines that change it.
From there the work usually has the same shape. Codify what exists in Terraform, give deployments one well-lit path, and tighten access so the secure option is also the convenient one. I prefer well-understood AWS building blocks over clever ones, because your team will be operating this long after the engagement ends.
What you get
- 01
Architecture review
A written assessment of account structure, networking, IAM, and the delivery path, with prioritized recommendations.
- 02
Infrastructure as code
Terraform for the infrastructure you run, so changes are reviewed, repeatable, and reversible.
- 03
CI/CD
One deployment path per kind of workload, on GitHub Actions or GitLab CI, with the checks your team actually needs.
- 04
Security baseline
Least-privilege IAM, private networking, secrets in KMS and SSM rather than environment files, and isolation where it matters.
- 05
Handover
Documentation and walkthroughs so your engineers own what was built.
What I work with
Where I’ve done this
- Case study · SaaS · AIBuilding an isolated sandbox for autonomous remediationA disposable, Terraform-built AWS environment: 250 tables validated, and a validation cycle cut from about a week to under two hours.
- Case study · SaaS · SecurityHardening contractor WorkSpaces against data exfiltration20 contractor WorkSpaces hardened against data exfiltration, with the first verified WorkSpace delivered in about a week.
- Case study · Enterprise PlatformOperationalizing an enterprise Kubernetes platformCentralized CI/CD templates, Helm, and Terraform turned into a repeatable path to production.
How an engagement runs
- Discovery call. We talk through your environment, what is hurting, and whether I am the right person to help.
- Assessment. I review the systems involved and write down what I find, with recommendations in priority order.
- Plan. We agree what changes first, what it should achieve, and how we will know it worked.
- Implementation. Hands-on work alongside your team, through code and review rather than console clicks.
- Handover. Documentation and walkthroughs so your engineers own the result, with ongoing support if you want it.
Questions
Do you only work with AWS?
No. AWS and Google Cloud are where most of my production work has been, and the case studies cover both. Infrastructure as code, one delivery path, and least privilege carry across providers.
Can you work with our existing Terraform and pipelines?
That is the usual starting point. Replacing working tooling for its own sake is rarely the right first move, so the first job is understanding what is already there.
What does it cost?
It depends on whether you need a focused review or hands-on engineering. Current starting rates for both are published on the consulting page.