How We Automated 80+ Hours of AWS Security Hardening into a Single Terraform Module

If you’ve ever prepared an AWS infrastructure for a SOC 2 Type II or GDPR compliance audit, you know the drill.

What starts as a clean cloud architecture quickly devolves into 80+ hours of tedious manual hardening: stitching together KMS keys, locking down IAM boundary policies, configuring S3 block public access, routing CloudTrail log delivery, and ensuring zero 0.0.0.0/0 ingress rules in your VPC security groups.

And the worst part? Manual hardening creates configuration drift. Two months after the audit, someone opens a temporary SSH port or forgets to encrypt an EBS volume, and your compliance posture crumbles.

We got tired of re-inventing the same security wheel across every deployment. So we engineered a battle-tested approach to collapse those 80+ manual hours into a single, automated, production-ready IaC? baseline.

Here is the exact framework we used, the architectural decisions behind it, and how you can automate security gating in your own CI/CD pipeline.
The 5 Core Compliance Pillars Most AWS Setups Miss

When auditing standard Terraform setups, we consistently find the same 5 critical security gaps that auditors flag instantly:

1. Default VPC Left Intact

Leaving the default AWS VPC enabled in any active region is an immediate audit penalty. Default VPCs have public subnets and internet gateways pre-configured, making it trivial for a developer to launch an exposed resource by accident.

1. Missing S3 Public Access Block at Account Level

Encrypting an S3 bucket isn't enough if someone can override bucket policies. Security baselines require account-level S3 Public Access Block enforcement alongside mandatory Customer Managed Keys (CMK) via KMS.

1. Loose IAM Boundary Policies

Granting AdministratorAccess or loose wildcard * actions during early development usually bleeds into production. Baseline architectures require strict IAM Permission Boundaries that set maximum allowable permissions regardless of role policies.

1. Unencrypted CloudTrail Logs Without KMS

Default CloudTrail logs use AWS-managed keys. Auditors require logs encrypted with dedicated KMS keys with key rotation enabled, paired with S3 bucket object-locking to prevent log tampering.

1. Open Ingress on Security Groups

Security groups allowing ingress from 0.0.0.0/0 on management ports (22, 3389, 5432) are the #1 source of automated cloud exploits.
Architectural Deep Dive: Automating Hardening in Terraform

Instead of applying security rules piecemeal, we structured our baseline module to enforce security properties by default upon instantiation.

Here is a simplified pattern showing how we enforce zero-trust S3 encryption and public access lockdown natively within our IaC baseline:

main.tf - Hardened S3 Bucket Pattern

resource "aws_kms_key" "baseline_kms" {
description = "Dedicated KMS key for S3 bucket encryption"
deletion_window_in_days = 30
enable_key_rotation = true

tags = {
Environment = var.environment
ManagedBy = "Terraform"
}
}

resource "aws_s3_bucket" "audit_logs" {
bucket = "${var.prefix}-${var.environment}-audit-logs"
force_destroy = false
}

resource "aws_s3_bucket_server_side_encryption_configuration" "audit_logs" {
bucket = aws_s3_bucket.audit_logs.id

rule {
apply_server_side_encryption_by_default {
kms_master_key_id = aws_kms_key.baseline_kms.arn
sse_algorithm = "aws:kms"
}
}
}

resource "aws_s3_bucket_public_access_block" "audit_logs" {
bucket = aws_s3_bucket.audit_logs.id

block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}

By abstracting these compliance rules into reusable module defaults, developers cannot provision resources that violate organizational security policies.
Shift-Left: Catching Security Drift in CI/CD

Writing secure Terraform is only half the battle. You also need an automated gate in your CI/CD pipeline to reject pull requests that introduce compliance drift or insecure configurations.

We built a lightweight static analysis runner that integrates directly into GitHub Actions to scan your IaC before any terraform apply touches production.
Step-by-Step CI/CD Gating Workflow

Pull Request Trigger: Developer opens a PR modifying Terraform files.

Automated Static Analysis: CI runner evaluates HCL code against SOC 2 and GDPR control maps.

Inline PR Feedback: Violations (e.g., missing KMS key rotation or open security group rules) are flagged directly in the PR diff.

Merge Block: PR cannot be merged until all baseline violations are resolved.

How to Check Your AWS IaC Baseline for Free

If you want to test your current Terraform codebase against standard SOC 2 and GDPR security baselines without spending hours digging through AWS documentation, we open-sourced our checking tool.

You can drop the Vancer Baseline Checker directly into your GitHub Actions workflow:

name: "AWS Infrastructure Security Check"

on:
pull_request:
branches: [ main ]

jobs:
security-check:
runs-on: ubuntu-latest
steps:
- name: Checkout Code
uses: actions/checkout@v4

  - name: Run Vancer Baseline Checker
    uses: vancer-systems/baseline-checker-action@v1
    with:
      terraform_dir: './infrastructure'

It scans your HCL files and gives you instant visibility into security gaps before an auditor does.
Wrapping Up

Hardening AWS infrastructure doesn't have to consume weeks of high-value engineering time. By combining module-level defaults in Terraform/OpenTofu with automated CI/CD security gating, you turn compliance from a chaotic audit rush into a quiet, continuous background process.

How is your team currently handling AWS IaC compliance? Do you manage hardening rules manually, or have you automated your security gating? Let's discuss in the comments below!