Yesterday, I had the privilege of speaking at the AWS London Well-Architected User Group July Meetup — Summer Special at the AWS Experience in Holborn. With around 33 engineers, architects, and cloud enthusiasts in the room, the energy was fantastic. There is something uniquely rewarding about standing in front of a community of peers, sharing hard-earned lessons from production, and seeing heads nod when a risky Terraform pattern hits home.
"It was a great event and I really enjoyed your talk. Looking forward to attending future meetups!" — Feedback like this from attendees like Saleh Omar is exactly why we do it.
The Venue: AWS Holborn
First, a quick shout-out to the organizers James Harding and Lorenzo M. for pulling together a brilliant evening. We were hosted at AWS LHR14, 60 Holborn Viaduct, a stunning space that perfectly matched the calibre of the conversations.
Walking in, I was reminded of one of Amazon's Leadership Principles that was displayed prominently in the building — "Bias for Action." It felt like the perfect theme for the evening. When it comes to Infrastructure as Code (IaC), bias for action does not mean skipping reviews; it means automating the guardrails so teams can move fast without breaking things.
My Talk: Terraforming the Well-Architected Way
My session was titled "Terraforming the Well-Architected Way: IaC Reviews That Actually Catch Risks." The core argument was simple: most Terraform "reviews" today are syntax checks and rubber-stamped LGTMs. They catch formatting errors but miss the security-critical patterns that only resolve at plan time — the very patterns that show up in breach reports.
The Stakes
I opened with a reality check: ~65% of cloud breaches stem from misconfiguration, not exploits. Fixing a misconfiguration in CI is 3–5x faster than fixing it in production, and the cost of scanning a PR is essentially $0, while the average breach cost runs well into the tens of thousands.
We looked at real-world incidents — from Capital One's over-permissive IAM roles to the OMIGOD RCE vector — and a 2026 trend that is keeping me up at night: AI-generated Terraform that hallucinates Action: "*" policies. The risk is evolving, and our reviews must evolve with it.
The "Before vs. After" Shift
The talk pivoted to a visual comparison of the old way versus the new way:
| Before: Manual Review | After: Automated Pipeline |
| ------------------------------------------------------- | ----------------------------------------------------- |
| Human reads every `.tf` file | 7-layer scan runs on every PR |
| Misses dynamic values (`cidr_block = var.allowed_cidr`) | Plan-scan catches evaluated values (e.g. `0.0.0.0/0`) |
| 30–60 min per review; rubber-stamped under pressure | < 15 min full pipeline; blocks on policy violation |
| Misconfig found in production → incident response | Issues caught in IDE or PR — never reach prod |
The ROI is clear: one blocked public-S3 or over-permissive-IAM misconfig per quarter avoids roughly 20–40 engineering hours of incident response.
The 7-Layer PR Pipeline
The heart of the talk was a practical, layered pipeline that any team can adopt incrementally:
Layer 0 — TruffleHog: Secret detection in code and Git history. Layer 1 — TFLint: Static linting, naming conventions, and AWS-specific rules. Layer 2 — Trivy + Checkov: Static config scanning plus evaluated plan scanning. This is the "secret sauce" — Checkov scanning the JSON plan output catches dynamic values that static analysis misses. Layer 3 — OPA / Rego: Custom policy-as-code gates for organizational rules. Layer 4 — terraform test: Native Terraform 1.6+ assertions for reliability (e.g., "RDS must be Multi-AZ"). Layer 5 — Infracost: Cost diff and budget gates before merge. Layer 6 — PR Comment: Consolidated summary so developers get one clear signal, not six noisy ones.
Well-Architected Through the IaC Lens I framed the pipeline around the six Well-Architected pillars — yes, including the newest one, Sustainability: Operational Excellence: Mandatory tag validation using Terraform 1.3+ validation blocks. Security: Custom Checkov policies that account for the AWS provider v5+ resource model (e.g., checking for the connected aws_s3_bucket_server_side_encryption_configuration resource rather than a deprecated attribute). Reliability: Native terraform test assertions for backup retention and Multi-AZ. Performance Efficiency: TFLint rules blocking legacy instance families (t2, m4, c4) in favor of Graviton. Cost Optimization: OPA gates blocking PRs that exceed a monthly budget threshold. Sustainability: Cloud Carbon Footprint data fed into the same OPA pattern — a carbon budget gate using the exact same enforcement structure as cost gating. State Security: The Richest Target A section that always gets attention: Terraform state is the single richest target in your pipeline. It contains every secret Terraform has ever managed, often in plaintext. We walked through SSE-KMS encryption, S3 versioning, and DynamoDB locking — not as "nice to haves," but as non-negotiable baseline hygiene. Metrics That Matter I proposed four starting metrics for teams at zero automation: MTTD (Mean Time to Detect): < 15 minutes for the full pipeline. Escape Rate: < 2% of misconfigurations reaching production. Review Coverage: 100% of PRs through all layers (enforced via branch protection). Cost Drift: < 10% variance between Infracost estimate and actual bill. Where to Start: The Priority Matrix Not every team needs all seven layers on Day 1. I shared a prioritization matrix for adoption: 🚨 Do First (High Risk / Low Effort): State encryption (SSE-KMS) + DynamoDB locking Checkov plan scanning in CI TruffleHog secret detection TFLint static linting ✅ Quick Wins (Low Risk / Low Effort): Mandatory tag validation Legacy instance family blocking ⚠️ Do Second (High Risk / High Effort): Full OPA policy suite AWS Config Proactive Compliance 🌱 Mature Teams (Low Risk / High Effort): Cloud Carbon Footprint gating Full terraform test coverage Final Thoughts Speaking at the WAUG was a brilliant reminder that the AWS community in London is as strong as ever. The questions during and after the talk — from OIDC trust policy edge cases to Graviton migration strategies — showed a room full of practitioners who genuinely care about building secure, efficient, and sustainable infrastructure. If you are an engineer still relying on manual Terraform reviews, my challenge to you is this: pick one layer from the pipeline and implement it next week. You do not need perfection on Day 1. You need momentum. Bias for action, automated.
Thank you to everyone who attended, asked questions, and stuck around to chat afterwards. See you at the next one! — Alam Zaib Ahmed AWS Community Builder | Cloud & DevOps Engineer | Managed Services Support Analyst – NOC @boxxe
Originally published on AWS Builder Center. Any opinions are those of the individual author and may not reflect the opinions of AWS.