AWS Well-Architected Security pillar review for Terraform
5+ years AWS engineering · Open-source contributor
Last reviewed: 2026-05-27
The AWS Well-Architected Security pillar covers five design areas: identity and access management, detection, infrastructure protection, data protection, and incident response. For Terraform-managed infrastructure, each design principle translates to specific resource configurations — some caught by linters, many not. This guide covers the Terraform-aware interpretation of each principle, with HCL examples and a practitioner’s view of what ArchGuard flags most often.
The five Security pillar design principles, as Terraform-aware checks
1. Implement a strong identity foundation
Every AWS access should be governed by IAM roles, not users with long-lived credentials. The root account should have MFA enabled and no active access keys. Break-glass roles should exist for emergency access, with auditing of their use.
In Terraform: avoid aws_iam_user with programmatic access. Use aws_iam_role with aws_iam_policy_document for every principal. Root MFA is enforced via aws_organizations_account policy settings; verify your org SCP enforces it.
2. Enable traceability
CloudTrail must be enabled in all regions, not just the primary region. An organisation trail captures API calls from all accounts in the org. CloudWatch Logs integration enables metric alarms on suspicious API patterns.
In Terraform: aws_cloudtrail with is_multi_region_trail = true, enable_log_file_validation = true, and cloud_watch_logs_group_arn.
3. Apply security at all layers
VPC security groups, NACLs, WAF for internet-facing workloads, Shield Standard for DDoS protection, S3 bucket policies, and per-account public access blocks. Defense-in-depth means no single control failure exposes the workload.
In Terraform: use aws_security_group_rule instead of inline rules (allows Terraform state management of individual rules), aws_s3_bucket_public_access_block on every bucket, and aws_wafv2_web_acl for ALBs and CloudFront distributions.
4. Automate security best practices
AWS Config rules, GuardDuty, Security Hub, and Inspector automate continuous assessment of the environment. These should be deployed via Terraform alongside the workload infrastructure — not as manual one-time setups.
In Terraform: aws_guardduty_detector with enable = true, aws_securityhub_account, and aws_config_config_rule for the highest-impact CIS controls.
5. Protect data in transit and at rest
KMS keys with rotation enabled, S3 default encryption, RDS storage encryption, ACM certificates for TLS termination, and S3 bucket policies that deny non-TLS requests are the core data protection controls for most Terraform workloads.
In Terraform: aws_kms_key with enable_key_rotation = true, aws_s3_bucket_server_side_encryption_configuration on every bucket.
Five things ArchGuard flags most often in the Security pillar
IAM roles with overly broad permissions
Not wildcards — but more actions than the principal needs. Blast radius analysis requires workload context; linters cannot evaluate it.
No CloudTrail organisation trail
Single-account CloudTrail misses API calls from sub-accounts in an AWS Organisation. Multi-account workloads need aws_cloudtrail with is_organization_trail = true.
S3 buckets without TLS-required bucket policy
SSE-KMS encryption is not sufficient — objects can still be transmitted over HTTP. A bucket policy with aws:SecureTransport = false Deny closes this gap.
Security groups with /8 or /16 CIDR ingress
Passes Checkov's 0.0.0.0/0 check but violates defense-in-depth. /8 CIDRs cover entire internal networks. Security groups should reference specific service CIDRs or security group IDs.
KMS keys without rotation enabled
The AWS default is enable_key_rotation = false. Key rotation is a CIS 3.5 control and a WAFR SEC 8 requirement. Every customer-managed KMS key should have rotation enabled.
How this maps to NIS2 and DORA evidence
NIS2 Article 21(2)(e) and (h) address configuration management and technical security measures. DORA Article 9 addresses ICT change management. Security pillar review produces documented evidence of infrastructure configuration practices. ArchGuard does not claim that using it alone satisfies NIS2 or DORA, and we make no compliance certification claim for either regulation.
Further reading
IAM least-privilege in Terraform
aws_iam_policy_document, condition blocks, IAM Access Analyzer, anti-patterns.
S3 encryption best practices in Terraform
Default encryption, KMS vs S3-managed keys, TLS-required bucket policy, public access blocks.
VPC security groups audit in Terraform
aws_security_group_rule over inline rules, deny-by-default, 0.0.0.0/0 anti-patterns, egress filtering.
KMS key rotation in Terraform
aws_kms_key with enable_key_rotation, key policy patterns, multi-region keys.
CloudTrail account-wide trail in Terraform
Multi-region trail, organisation trail, S3 bucket policy, CloudWatch Logs delivery.
AWS Well-Architected Security Pillar whitepaper
docs.aws.amazon.com — primary source
Frequently asked questions
What does the AWS Well-Architected Security pillar cover?↓
The Security pillar covers five design principles: implement a strong identity foundation, enable traceability, apply security at all layers, automate security best practices, and protect data in transit and at rest. It also covers preparing for security events. For Terraform, these translate to specific resource configurations across IAM, CloudTrail, VPC, KMS, and S3.
Which Terraform resources are most important for the Security pillar?↓
aws_iam_role (least-privilege), aws_cloudtrail (multi-region, org trail), aws_guardduty_detector, aws_securityhub_account, aws_kms_key (with rotation), aws_s3_bucket_server_side_encryption_configuration, aws_s3_bucket_public_access_block, and aws_security_group_rule. These cover the most common Security pillar findings.
Does Checkov cover the AWS Well-Architected Security pillar?↓
Checkov has strong coverage of Security pillar rule-level checks — S3 encryption, security group rules, IAM wildcard policies. It has gaps in architecture-level concerns: IAM blast radius, workload context, absent monitoring resources. Use Checkov in CI and complement with an architecture review.
How does the Security pillar relate to NIS2 and DORA?↓
NIS2 Article 21(2)(e) and (h) address configuration management and technical security measures. DORA Article 9 addresses ICT change management. Security pillar compliance produces evidence relevant to both. ArchGuard does not claim that using it satisfies either regulation.