CASE STUDY 03 • INFRASTRUCTURE AS CODE

AWS Cloud Security Engineering

A Terraform-based AWS security reference environment designed around least privilege, network segmentation, auditability, encryption, threat detection and repeatable control validation.

SECURITY PROBLEM

Cloud infrastructure should be secure by design, reproducible and reviewable before deployment.

The project models the security foundations expected in a serious AWS environment: identities should be governable, network paths should be intentional, administrative activity should be logged, security telemetry should be available and sensitive audit data should be protected.

Evidence state: the architecture, Terraform baseline, threat model and CI controls are implemented. AWS runtime controls are only marked validated after observed evidence is captured.

ARCHITECTURE

Separate workload tiers while keeping the baseline cost-conscious.

The design spans two Availability Zones with public and private subnets and explicit web, application and database security boundaries. A NAT Gateway is intentionally excluded from the default baseline to avoid unnecessary recurring lab cost.

NETWORKSegmented VPC

Public and private tiers, scoped routes and security-group boundaries.

AUDITCloudTrail

Multi-region API activity logging with log-file validation.

TELEMETRYVPC Flow Logs

Network-flow evidence delivered to CloudWatch Logs for investigation.

PROTECTIONKMS + S3

Encrypted, versioned audit storage with public access blocked and TLS enforced.

SECURITY CONTROLS

Layer preventive, detective and assurance controls.

  • IAM Access Analyzer: included by default to identify unintended external access paths.
  • GuardDuty: represented as an optional threat-detection control for deliberate lab activation.
  • AWS Config and Security Hub: optional posture controls so cost is not created accidentally.
  • KMS: customer-managed key protection with rotation for security-log storage.
  • S3: versioning, public-access blocking and transport-security enforcement.
  • EventBridge and SNS: detection-routing architecture for GuardDuty findings when enabled.

DEVSECOPS ASSURANCE

The deployment path is part of the security boundary.

GitHub Actions runs Terraform formatting, initialisation, validation and linting. The repository also documents encrypted remote-state design and a future GitHub OIDC deployment model so AWS authentication can move away from long-lived access keys.

VALIDATION PROGRAMME

Move each control from code to evidence.

The engineering backlog separates Terraform existence from runtime proof. Planned validation covers the cost-safe deployment, segmentation, Flow Logs, CloudTrail integrity, IAM Access Analyzer, GuardDuty, AWS Config, Security Hub, OIDC, remote state and controlled teardown.

The first Terraform CI run exposed an unused declaration through TFLint. The issue was corrected and the subsequent quality run passed, providing a visible example of automated assurance improving the code before deployment.

LESSONS

A mature cloud-security portfolio should show both design judgement and verification discipline.

The strongest evidence is not the number of AWS services provisioned. It is the ability to explain why each control exists, how cost and operational risk were considered, what automation checks the configuration and what observed evidence will prove the control behaves as intended.