AWS certified · SOC-audit experience

Infrastructure that passes the audit and the 3am incident.

I design and build AWS platforms as code: networks laid out properly, workloads that scale, pipelines that ship safely, and the evidence trail your auditors will one day ask for — priced for what you actually run.

Everything in TerraformYour account, your keysSOC 1 / SOC 2 ready
production-vpc · ap-south-1 reference layout
CloudFront + WAFedge · TLS · rate limits
Route 53dns · health checks
ALBpublic subnets · 2 AZ
ECS service ×3private subnets · autoscaling
WorkersSQS-driven · spot capacity
RDS Multi-AZencrypted · PITR backups
ElastiCacheredis · private only
deploy #214 — greenbackups verified 04:00CloudTrail → 365dcost −38% vs March
Why this exists

The console got you live. It won't get you further.

Most AWS accounts grow by hand: a resource here, a permission there. It works — until the bill, the audit, or the outage asks questions nobody can answer.

The bill nobody can explain

Spend creeps up month over month, and no one can say which line items are load, which are waste, and which are a NAT gateway quietly moving terabytes.

Click-ops with admin keys

Changes happen in the console, by whoever, with credentials that never rotate. There is no history, no review, and no way to rebuild if it disappears.

The audit is suddenly real

A big client or an investor asks for SOC 2, and the scramble begins: where is the evidence, who has access to what, and when was the last tested backup?

What I do

Architecture, pipelines, and the paper trail

One engineer, senior level, hands on keyboard — from network design to the CI/CD pipeline your team ships through every day.

Architecture as code

VPCs, subnets and routing designed on purpose, workloads on ECS, EKS or plain EC2 — all of it in Terraform, applied through a pipeline, never by hand.

  • Network design: VPC, subnets, NAT, security groups
  • ECS / EKS / EC2 with autoscaling that actually scales
  • IAM with least privilege, no shared credentials
  • Multi-account layouts with SSO where teams need it
  • GCP and Azure too — same approach, different console

CI/CD that ships safely

Pipelines in GitHub Actions or GitLab CI that build, test, and deploy with rollbacks ready — so releases are boring instead of brave.

  • Build → test → staging → production, gated
  • Blue/green or rolling deploys with instant rollback
  • Secrets in a manager, never in the repo
  • Monitoring and alerts wired before go-live, not after

Cost & compliance built in

The same review that finds waste also finds risk: right-sizing and savings plans on one side, audit evidence and encryption on the other.

  • Cost review: right-sizing, storage, transfer traps
  • Spot capacity and savings plans sized to real usage
  • CloudTrail, encryption, tested backups by default
  • SOC 1 / SOC 2 evidence produced by the platform itself
How it works

From read-only review to boring releases

No big-bang migration. The account keeps running while it is understood, codified, and improved in reviewable steps.

1

A call, and an honest answer

Twenty minutes on what you run and what hurts — bill, deploys, audit, outages. If you don't need an architect, I will say so.

Day 0
2

Read-only review

With auditor-style access I map the architecture, security posture and spend, and hand you a written findings report — yours to keep either way.

Week 1
3

Codify and fix, in reviewable steps

Existing infrastructure is imported into Terraform, then improved through pull requests you can read — network, IAM, pipelines, cost, in priority order.

Weeks 2–6
4

Hand over, or stay on watch

Docs, diagrams, runbooks and a recorded walkthrough — then either a clean handover or a monthly arrangement for monitoring, patching and incidents.

Ongoing
Before you ask

The questions every team asks

AWS is home base, but I work in GCP and Azure as well — same discipline, same Terraform-first approach. Multi-cloud setups where, say, workloads run on GCP while identity or data lives in AWS are increasingly normal, and the review covers whichever accounts you actually run.

Both, and existing accounts are the more common case. The first step is a read-only review of what is already running — architecture, security posture and spend — so recommendations are grounded in your reality instead of a blank whiteboard. Nothing is changed until you have seen the plan.

Yes. Infrastructure lives in code (Terraform is my default; CloudFormation and CDK on request), reviewed through pull requests and applied through a pipeline. That means every change is visible, reversible and reproducible — and the setup is not locked to me, because any engineer who reads Terraform can take it over.

Usually, and the review shows exactly where before anything is touched: right-sizing, storage classes, NAT and data-transfer traps, spot capacity where it is safe, and savings plans sized to real usage. Cost work is part of architecture, not an afterthought — the same review covers security and reliability too.

It means the infrastructure produces the evidence auditors ask for without a scramble: IAM with least privilege and no shared credentials, CloudTrail and config history retained, encrypted data at rest and in transit, tested backups, and change management through pull requests. I have prepared teams for SOC 1 and SOC 2 audits and build to that standard by default.

Every engagement ends with the repository, architecture diagrams, runbooks and a recorded walkthrough in your hands. Dependence on one person is an availability risk — the goal is that your team can operate the platform, and you call me back because you want to, not because you have to.

Two options: hand over completely, or keep a monthly arrangement for monitoring, patching, cost reviews and being on call for incidents. Month-to-month, no lock-in — the infrastructure is in your account and your repository either way.

Bring the bill. I'll bring the plan.

Twenty minutes, no slides. Tell me what you run and what worries you — I will tell you straight what I would fix first, and what it would cost.