KH.
AWS Cloud Infrastructure with Terraform

Service

AWS Cloud Infrastructure with Terraform

Your AWS estate — reproducible, auditable, and safe to change.

Click-ops infrastructure is technical debt with a production blast radius. When your AWS estate is a mix of manually created resources, one engineer's tribal knowledge, and a bill that surprises you every month, you're one mistake away from a very bad day. I migrate AWS infrastructure to Terraform — properly, not just wrapping existing resources in HCL. That means a modular structure your team can maintain, remote state with locking, CI/CD for infrastructure changes, a security baseline that passes audits, and cost visibility so you know what you're spending and why.

Who this is for

  • Startups with AWS infrastructure that was "just spun up quickly" and never formalised
  • Engineering teams where only one person knows how the infrastructure was set up
  • Companies receiving AWS bills that are higher than expected with no clear breakdown
  • Teams preparing for SOC 2, ISO 27001, or enterprise customer security questionnaires
  • CTOs who want to move faster on infrastructure without breaking production

What you get

Terraform codebase

Modular Terraform code in a structure your team can navigate — environment directories, reusable modules, and clear variable boundaries. No Terraform anti-patterns.

Remote state and locking

S3 backend with DynamoDB locking. State encryption at rest. Separate state files per environment to isolate blast radius.

Infrastructure CI/CD

Atlantis or GitHub Actions workflow for infrastructure PRs: terraform plan on every PR, apply on merge. No manual terraform apply in production.

Security baseline

VPC with private subnets, security groups scoped to minimum required, IAM roles with least-privilege policies, CloudTrail enabled, S3 public access blocked, GuardDuty active.

Cost dashboard

AWS Cost Explorer configured with tags for cost allocation. Budget alerts for unexpected spend spikes. Right-sizing recommendations for over-provisioned resources.

Architecture documentation

Network topology diagram, service dependency map, and runbooks for common operations (scaling, rotating credentials, disaster recovery).

How it works

01

Infrastructure audit

2–4 days

I inventory your existing AWS resources, identify what's manually managed, review IAM policies for over-permissive roles, and produce a risk assessment.

02

Architecture design

3–5 days

VPC design, account structure recommendations, module architecture, and migration strategy — documented before any Terraform is written.

03

Terraform import and codification

1–3 weeks

Existing resources imported into Terraform state. New resources created in code. Drift between code and reality eliminated.

04

Security hardening

3–5 days

IAM policies reviewed and tightened. Security groups audited. Encryption at rest and in transit verified. AWS Config rules deployed for continuous compliance.

05

CI/CD for infrastructure

2–3 days

Terraform workflow automated. Plan on PRs, apply on merge. Notifications for apply failures and drift detection.

06

Cost optimisation

2–3 days

Reserved instances and savings plans analysis. Right-sizing recommendations. Unused resources identified and removed.

Pricing

Infrastructure migrations are scoped per-project: a typical AWS estate codification with security hardening runs £3,500–£9,000. Cost optimisation engagements are often day-rate (2–5 days) since the scope depends heavily on what we find. I provide Infracost estimates so you can see the projected cost impact before committing.

Frequently asked questions

We already have Terraform but it's a mess. Can you fix it?+
Yes, this is most of my work. Common problems: all resources in one flat directory with no modules, state stored locally, no CI/CD for infrastructure changes, and hardcoded values everywhere. I'll refactor incrementally — prioritising the highest-risk areas first — rather than rewriting everything at once.
How do you handle importing existing AWS resources without breaking anything?+
Carefully. I use terraform import to bring existing resources under management, then verify with terraform plan that no changes are proposed before applying. I start with read-only resources (S3 buckets, security groups) and work up to stateful resources (RDS, ElastiCache). Nothing gets deleted or recreated without explicit sign-off.
Terragrunt or vanilla Terraform?+
Vanilla Terraform for most teams — it's simpler to onboard and easier to debug. Terragrunt makes sense when you have a large multi-account, multi-region estate and need to avoid repeating backend and provider configuration across dozens of modules. I'll recommend based on your scale.
Can you help reduce our AWS bill?+
Often, yes. The most common wins: right-sizing over-provisioned EC2 and RDS instances, moving suitable workloads to spot instances or Fargate Spot, purchasing savings plans for predictable baseline compute, and eliminating forgotten resources (old snapshots, idle load balancers, unused Elastic IPs). A cost audit typically pays for itself within 2–3 months.
Do you work with multiple AWS accounts?+
Yes. Multi-account setups via AWS Organizations are the recommended approach for production workloads — separate accounts for production, staging, shared services, and sandbox. I'll design the account structure and set up cross-account IAM roles and resource sharing.