Forem: Danny Steenman

10 AWS Security Misconfigurations Found in 90% of Accounts

Danny Steenman — Thu, 02 Apr 2026 17:30:07 +0000

import { FaqSection } from "@/components/mdx/faq-section";
import { CtaCard } from "@/components/mdx/cta-card";

I've reviewed over 200 AWS accounts across startups and enterprises. These 10 security misconfigurations appear in more than 90% of them, and most teams don't know they exist until something goes wrong. The difference between a good review and a great one is how findings are prioritized and presented so you can actually act on them. For a complete breakdown of the review process, see our AWS security review process guide.

AWS security misconfigurations are incorrect settings in cloud infrastructure that expose resources to unauthorized access, data breaches, or service disruption. Unlike software vulnerabilities requiring patches, misconfigurations result from human error, default settings that aren't secured, or operational shortcuts that become permanent. Cloud misconfigurations cause over 80% of security breaches, making this the most impactful security work you can do.

The good news? Every issue I'll cover is detectable using native AWS tools, and most fixes take minutes to implement. By the end of this guide, you'll know exactly how to detect each issue using AWS Security Hub, Config rules, and CLI commands, plus the specific steps to fix them.

Here's a quick reference of all 10 misconfigurations with severity ratings and detection methods:

Misconfiguration	Severity	Primary Detection Method
Public S3 Buckets	Critical	Security Hub S3.1, S3.8
Overly Permissive IAM Policies	Critical	Security Hub IAM.1, IAM.21
Missing MFA on Root Account	Critical	Security Hub IAM.6, IAM.9
Unencrypted EBS Volumes	High	Security Hub EC2.7, EC2.3
Security Groups with 0.0.0.0/0	High	Security Hub EC2.18, EC2.19
Missing CloudTrail Logging	High	Security Hub CloudTrail.1
Unused IAM Credentials	Medium	Security Hub IAM.3, IAM.8
Default VPC Usage	Medium	Security Hub EC2.2
Missing Encryption in Transit	Medium	Security Hub S3.5, CloudFront.3
No AWS Config Rules	Medium	Config recorder status

Let me walk through each one, including why it matters, how to detect it, and exactly how to fix it.

1. Public S3 Buckets

Severity: Critical

Public S3 buckets remain the most common and dangerous misconfiguration in AWS environments. Despite AWS making Block Public Access the default for new buckets as of April 2023, legacy buckets and misconfigurations continue to expose sensitive data.

Why It's Still the Number One Issue

AWS considers a bucket public when Access Control Lists (ACLs) grant permissions to the AllUsers or AuthenticatedUsers groups, or when bucket policies grant access to principals outside your zone of trust. The challenge is that buckets created before April 2023 don't have Block Public Access enabled by default, and a single misconfigured policy can override account-level protections.

Block Public Access provides four settings that work together:

BlockPublicAcls: Prevents accepting public ACLs for buckets and objects
IgnorePublicAcls: Ignores all public ACLs on buckets and objects
BlockPublicPolicy: Rejects bucket policies that grant public access
RestrictPublicBuckets: Restricts access to AWS service principals and authorized users only

How to Detect Public Buckets

Security Hub Controls: S3.1 (account-level), S3.8 (bucket-level), S3.2 (public read), S3.3 (public write)

Config Rules: s3-account-level-public-access-blocks, s3-bucket-public-read-prohibited

CLI Detection:

# Check account-level Block Public Access settings
aws s3control get-public-access-block --account-id <account-id>

# Check bucket-level settings
aws s3api get-public-access-block --bucket <bucket-name>

# Check bucket ACLs for public grants
aws s3api get-bucket-acl --bucket <bucket-name>

IAM Access Analyzer also automatically flags cross-account and public access, generating findings with details about the access level and external principal.

How to Fix and Prevent

Enable Block Public Access at the account level first, then verify bucket-level settings:

# Enable at account level (protects all buckets)
aws s3control put-public-access-block \
    --account-id <account-id> \
    --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# Enable at bucket level
aws s3api put-public-access-block \
    --bucket <bucket-name> \
    --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

For legitimate public access needs, use CloudFront with Origin Access Control (OAC), presigned URLs with expiration times, or VPC endpoints for private access.

While S3 exposure is visible, IAM policy issues hide in plain sight, making them equally dangerous but harder to spot.

2. Overly Permissive IAM Policies

Severity: Critical

Overly permissive IAM policies violate the principle of least privilege and create the largest attack surface in most AWS accounts. When credentials are compromised, the damage is limited only by what those credentials can access.

Common Anti-Patterns

In my reviews, I consistently find these patterns:

Full administrator permissions (*:*) granted to IAM users or roles
Wildcard service actions like s3:* or ec2:* instead of specific operations
Policies attached directly to users rather than groups or roles
Missing condition keys that would restrict access by IP, organization, or MFA status
No permissions boundaries for delegated administration

IAM users and roles have no permissions by default, which is the right starting point. The problem is that teams add permissions incrementally and rarely remove them.

How to Detect Overpermissioned Policies

Security Hub Controls: IAM.1 (admin privileges), IAM.2 (user-attached policies), IAM.21 (wildcard actions)

Config Rules: iam-policy-no-statements-with-admin-access, iam-user-no-policies-check

CLI Detection with IAM Access Analyzer:

# Validate a policy against best practices
aws accessanalyzer validate-policy \
    --policy-document file://policy.json \
    --policy-type IDENTITY_POLICY

# List policies attached to a user (should be empty - use groups)
aws iam list-attached-user-policies --user-name <user-name>

How to Implement Least Privilege

Start with AWS managed policies for job functions like ViewOnlyAccess, PowerUserAccess, or SecurityAudit. Then use IAM Access Analyzer's policy generation feature, which creates least-privilege policies based on actual CloudTrail access activity.

Here's an example of a properly scoped policy with condition keys:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::my-bucket/my-prefix/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        },
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

Use aws:PrincipalOrgID condition keys to ensure access only comes from within your AWS Organization, and review permissions every 90 days to identify and remove unused access.

For broader governance, consider using Service Control Policies to prevent misconfigurations before they happen.

Even perfect IAM policies mean nothing if your root account lacks MFA.

3. Missing MFA on Root Account

Severity: Critical

The root user has unrestricted access to everything in your AWS account, including the ability to close it entirely. Compromise of root credentials without MFA protection leads to complete account takeover, data destruction, and significant financial impact through unauthorized resource provisioning.

The Risk of Unprotected Root

As of 2025, AWS now enforces MFA for root users across all account types, including member accounts in AWS Organizations. But enforcement doesn't mean configuration. Many accounts I review have MFA enabled with a single device that's lost or inaccessible, which creates operational risk without the security benefit.

How to Detect Missing MFA

Security Hub Controls: IAM.6 (hardware MFA), IAM.9 (virtual MFA)

Config Rules: root-account-mfa-enabled, root-account-hardware-mfa-enabled

CLI Detection:

# Check if root account has MFA enabled
aws iam get-account-summary | grep "AccountMFAEnabled"

# List MFA devices for root user
aws iam list-mfa-devices

How to Enable MFA

AWS supports three MFA types, and I recommend using the strongest option your team can manage:

Passkeys and FIDO Security Keys (strongest): Physical devices like YubiKeys that use public key cryptography. These are phishing-resistant and provide the strongest authentication.
Virtual Authenticator Apps: Software applications like Google Authenticator, Microsoft Authenticator, or Authy that generate time-based codes.
Hardware TOTP Tokens: Physical devices generating six-digit codes. AWS recommends FIDO security keys over these due to their stronger security properties.

Best practices:

Register multiple MFA devices (up to 8 supported) for redundancy
Store MFA recovery information with multi-person approval
Use a group email address for root user, not an individual's email
Document and test root access procedures annually

With authentication secured, let's ensure your data at rest is encrypted.

4. Unencrypted EBS Volumes

Severity: High

EBS volumes are not encrypted by default unless you explicitly enable encryption by default at the Region level. Unencrypted volumes expose data at rest to unauthorized access if snapshots are shared, volumes are attached to compromised instances, or physical hardware is accessed.

Why Default Encryption Matters

When you enable encryption by default, EBS automatically encrypts new volumes, new volumes created from unencrypted snapshots, and snapshot copies. The encryption happens on the servers hosting EC2 instances, protecting both data at rest and data in transit between instances and volumes.

You have two key options:

AWS managed key (aws/ebs): No configuration required, AWS handles everything
Customer managed key: Provides control over key policies, rotation, and cross-account snapshot sharing

How to Find Unencrypted Volumes

Security Hub Controls: EC2.7 (encryption by default), EC2.3 (attached volumes encrypted)

Config Rules: ec2-ebs-encryption-by-default, encrypted-volumes

CLI Detection:

# Check if encryption by default is enabled
aws ec2 get-ebs-encryption-by-default --region <region>

# List unencrypted volumes
aws ec2 describe-volumes \
    --filters Name=encrypted,Values=false \
    --query 'Volumes[*].[VolumeId,State,Size]' \
    --output table

How to Enable Encryption

Enable encryption by default in each Region where you operate (this is Region-specific):

# Enable encryption by default
aws ec2 enable-ebs-encryption-by-default --region <region-name>

# Optionally set a customer managed key as default
aws ec2 modify-ebs-default-kms-key-id \
    --kms-key-id <kms-key-id> \
    --region <region-name>

For existing unencrypted volumes, you'll need to migrate via snapshots:

Create a snapshot of the unencrypted volume
Copy the snapshot with encryption enabled
Create a new encrypted volume from the encrypted snapshot
Stop the instance, detach old volume, attach new volume, restart

Encryption protects data at rest, but open security groups expose it to the network.

5. Security Groups with 0.0.0.0/0

Severity: High

Security groups with rules allowing ingress from 0.0.0.0/0 permit traffic from any IP address on the internet. While acceptable for ports 80 and 443 on public-facing load balancers, opening administrative or database ports to the world creates significant attack surface.

High-Risk Ports That Should Never Be Open

These ports should never be accessible from 0.0.0.0/0:

22 (SSH): Remote command-line access to Linux instances
3389 (RDP): Remote Desktop access to Windows instances
3306 (MySQL), 5432 (PostgreSQL), 1433 (MS SQL): Database access
27017 (MongoDB), 6379 (Redis): NoSQL and cache access
9200/9300 (Elasticsearch): Search engine access

How to Find Overly Permissive Rules

Security Hub Controls: EC2.18 (unrestricted traffic for authorized ports), EC2.19 (unrestricted high-risk ports)

Config Rules: restricted-ssh, restricted-common-ports, vpc-sg-open-only-to-authorized-ports

CLI Detection:

# List security groups with 0.0.0.0/0 rules
aws ec2 describe-security-groups \
    --query 'SecurityGroups[?IpPermissions[?IpRanges[?CidrIp==`0.0.0.0/0`]]].{GroupId:GroupId,GroupName:GroupName,VpcId:VpcId}' \
    --output table

# Find security groups with SSH open to the world
aws ec2 describe-security-groups \
    --filters Name=ip-permission.from-port,Values=22 \
              Name=ip-permission.to-port,Values=22 \
              Name=ip-permission.cidr,Values='0.0.0.0/0' \
    --query 'SecurityGroups[*].[GroupId,GroupName,VpcId]'

While you're auditing security groups, you might also want to find unused security groups in your account to reduce unnecessary attack surface.

Secure Alternatives to Open Ports

AWS Systems Manager Session Manager (Recommended): Eliminates the need for SSH or RDP ports entirely. Sessions are fully auditable via CloudTrail, controlled by IAM policies, and logged to S3 or CloudWatch Logs.

Security group references: Instead of IP ranges, reference other security groups for internal communication:

aws ec2 authorize-security-group-ingress \
    --group-id <target-security-group-id> \
    --protocol tcp \
    --port 3306 \
    --source-group <source-security-group-id>

Specific IP ranges: For legacy requirements, restrict to known office or VPN IP ranges rather than 0.0.0.0/0.

Even with tight network security, you need visibility into what's happening. That's where logging comes in.

6. Missing CloudTrail Logging

Severity: High

Without CloudTrail enabled, you have no record of who did what, when, and from where in your AWS account. This makes incident investigation impossible, compliance audits difficult, and unauthorized activity undetectable.

What Should Be Logged

CloudTrail captures four types of events:

Management Events (default, free): Control plane operations like creating instances, modifying security groups, and IAM changes
Data Events (additional charges): Data plane operations like S3 GetObject/PutObject and Lambda invocations
Network Activity Events: VPC Flow Logs metadata
Insights Events: Anomalous API call patterns detected by machine learning

CloudTrail Event History provides 90 days of management event retention for free, but you need a trail configured to retain logs longer or send them to CloudWatch Logs for alerting.

How to Detect Logging Gaps

Security Hub Controls: CloudTrail.1 (multi-Region trail), CloudTrail.2 (encryption), CloudTrail.4 (log validation), CloudTrail.5 (CloudWatch integration)

Config Rules: cloud-trail-enabled, multi-region-cloud-trail-enabled, cloud-trail-encryption-enabled

CLI Detection:

# List all trails
aws cloudtrail list-trails

# Check if trail is logging
aws cloudtrail get-trail-status --name my-trail

# Find trails that aren't multi-region (a gap)
aws cloudtrail describe-trails --query 'trailList[?IsMultiRegionTrail==`false`]'

How to Configure Proper Logging

Always create multi-Region trails. Single-Region trails miss activity in other Regions, including new Regions AWS adds over time.

# Create a multi-region trail with best practices enabled
aws cloudtrail create-trail \
    --name organization-trail \
    --s3-bucket-name cloudtrail-logs-bucket \
    --is-multi-region-trail \
    --enable-log-file-validation

# Start logging
aws cloudtrail start-logging --name organization-trail

For AWS Organizations, create an organization trail that automatically covers all member accounts. This is essential for AWS Organizations governance patterns.

Essential configuration checklist:

Enable log file validation (detects tampering)
Encrypt log files using KMS
Configure S3 bucket policies to prevent unauthorized access
Set up CloudWatch Logs for real-time alerting
Enable CloudTrail Insights for anomaly detection

With logging in place, let's address the credentials that could be used against you.

7. Unused IAM Credentials

Severity: Medium

Unused credentials (access keys, passwords, roles, users) create significant risk. Forgotten credentials can be compromised without detection, used by former employees, or discovered in code repositories and configuration files by attackers.

The Hidden Risk of Stale Credentials

I regularly find access keys that haven't been used in over a year but remain active. These are prime targets: they have permissions, no one monitors them, and if compromised, no legitimate use would be disrupted to trigger an alert.

Types of unused credentials to track:

Unused access keys: Not used for API calls within 90 days
Unused passwords: Not used for console sign-in within 45-90 days
Unused IAM roles: Not assumed within 90 days
Unused IAM users: No activity (console or API) for extended periods

How to Find Unused Credentials

Security Hub Controls: IAM.3 (key rotation), IAM.8 (unused credentials), IAM.22 (credentials unused 45+ days)

Config Rules: iam-user-unused-credentials-check, access-keys-rotated

IAM Access Analyzer: Continuously monitors and generates findings for unused roles, access keys, and passwords over 90 days.

CLI Detection using Credential Report:

# Generate credential report
aws iam generate-credential-report

# Download and analyze
aws iam get-credential-report --output text --query Content | base64 --decode > credential-report.csv

# Get access key last used information
aws iam get-access-key-last-used --access-key-id <access-key-id>

The credential report includes user creation date, password last used, access key last used dates, and MFA status for every user.

How to Clean Up and Rotate

Disable before deleting: Always disable unused keys first and wait a period to ensure nothing breaks:

# Disable unused access key
aws iam update-access-key \
    --access-key-id <access-key-id> \
    --status Inactive \
    --user-name <user-name>

# After confirming no impact, delete
aws iam delete-access-key \
    --access-key-id <access-key-id> \
    --user-name <user-name>

Best practices:

Rotate access keys every 90 days maximum
Create a second access key before disabling the first (zero-downtime rotation)
Remove credentials for users inactive over 45 days
Use AWS Secrets Manager for automated rotation of database credentials
Replace long-term credentials with IAM roles wherever possible

Credential hygiene matters, but so does your network architecture.

8. Default VPC Usage

Severity: Medium

Every AWS account comes with a default VPC in each Region. While convenient for getting started, default VPCs have security and operational limitations that make them unsuitable for production workloads.

Why Default VPCs Are Problematic

Security issues:

Predictable CIDR block (172.31.0.0/16) makes network scanning easier
Internet Gateway attached by default with public routes
Default security group allows all inbound traffic from itself
Public subnets by default with automatic public IP assignment
No network segmentation or isolation

Operational limitations:

Cannot customize CIDR block (always 172.31.0.0/16)
Limited subnet sizing control
Difficult to integrate with VPC peering or Transit Gateway systematically
Cannot enforce organizational network standards

How to Identify Default VPC Resources

Security Hub Control: EC2.2 (default security group should not allow traffic)

Config Rule: vpc-default-security-group-closed

CLI Detection:

# List default VPCs across all regions
for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  echo "Region: $region"
  aws ec2 describe-vpcs \
    --region $region \
    --filters Name=isDefault,Values=true \
    --query 'Vpcs[*].[VpcId,CidrBlock]' \
    --output table
done

# Find instances in default VPC
aws ec2 describe-instances \
    --query 'Reservations[*].Instances[?VpcId==`<default-vpc-id>`].[InstanceId,InstanceType,State.Name]'

How to Migrate to Custom VPCs

Create custom VPCs with proper network segmentation:

# Create VPC with appropriate CIDR
aws ec2 create-vpc \
    --cidr-block 10.0.0.0/16 \
    --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=Production-VPC}]'

# Create public and private subnets
aws ec2 create-subnet \
    --vpc-id <vpc-id> \
    --cidr-block 10.0.1.0/24 \
    --availability-zone us-east-1a \
    --tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=Public-Subnet-1A}]'

Best practices for custom VPCs:

Deploy across at least 2 Availability Zones
Create public, private, and data subnet tiers
Use NAT Gateways for private subnet outbound access
Enable VPC Flow Logs for traffic monitoring
Use VPC endpoints for private connectivity to AWS services

Consider deleting default VPCs after migration to prevent accidental deployments. Note that AWS doesn't allow recreating them in the same Region once deleted.

With proper network architecture, ensure all traffic is encrypted.

9. Missing Encryption in Transit

Severity: Medium

Encryption in transit protects data as it travels over untrusted networks. Without it, traffic can be intercepted, modified, or analyzed through man-in-the-middle attacks.

TLS Requirements and Modern Standards

Minimum TLS version: TLS 1.2 (TLS 1.0 and 1.1 are deprecated)
TLS 1.3: Available across most AWS services for enhanced security and performance
Cipher suites: Use strong, modern ciphers; avoid weak ones like RC4 or DES

How to Detect Unencrypted Traffic

Security Hub Controls: S3.5 (S3 SSL requests only), CloudFront.3 (encryption in transit)

Config Rules: alb-http-to-https-redirection-check, cloudfront-viewer-policy-https, s3-bucket-ssl-requests-only

CLI Detection:

# Check ALB listener security policy
aws elbv2 describe-listeners \
    --load-balancer-arn <alb-arn> \
    --query 'Listeners[?Protocol==`HTTPS`].[ListenerArn,SslPolicy]'

# Check CloudFront distribution TLS settings
aws cloudfront get-distribution-config --id <distribution-id>

How to Enforce HTTPS Everywhere

ALB Configuration: Use modern security policies and configure HTTP to HTTPS redirect:

# Create HTTPS listener with TLS 1.2/1.3
aws elbv2 create-listener \
    --load-balancer-arn <alb-arn> \
    --protocol HTTPS \
    --port 443 \
    --certificates CertificateArn=<certificate-arn> \
    --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06 \
    --default-actions Type=forward,TargetGroupArn=<target-group-arn>

# Configure HTTP to HTTPS redirect
aws elbv2 create-listener \
    --load-balancer-arn <alb-arn> \
    --protocol HTTP \
    --port 80 \
    --default-actions Type=redirect,RedirectConfig='{Protocol=HTTPS,Port=443,StatusCode=HTTP_301}'

S3 Bucket Policy: Enforce HTTPS and minimum TLS version:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::my-bucket", "arn:aws:s3:::my-bucket/*"],
      "Condition": {
        "Bool": {"aws:SecureTransport": "false"}
      }
    },
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": ["arn:aws:s3:::my-bucket/*"],
      "Condition": {
        "NumericLessThan": {"s3:TlsVersion": "1.2"}
      }
    }
  ]
}

CloudFront: Set ViewerProtocolPolicy to redirect-to-https and use TLSv1.2_2021 as minimum security policy.

Finally, let's ensure you have continuous compliance monitoring.

10. No AWS Config Rules

Severity: Medium

AWS Config continuously monitors and records resource configurations, evaluating them against rules that define desired states. Without Config rules enabled, you lack automated compliance checking and configuration drift detection. This is the meta-problem: having no system to catch the other nine issues.

Essential Config Rules for Security

AWS provides managed rules for common security requirements. Here are the essential categories:

Identity and Access Management:

iam-password-policy
iam-user-mfa-enabled
root-account-mfa-enabled
iam-policy-no-statements-with-admin-access
access-keys-rotated

Encryption:

encrypted-volumes
ec2-ebs-encryption-by-default
s3-bucket-server-side-encryption-enabled
s3-bucket-ssl-requests-only

Network Security:

restricted-ssh
vpc-sg-open-only-to-authorized-ports
vpc-default-security-group-closed

Logging:

cloud-trail-enabled
multi-region-cloud-trail-enabled

Public Access:

s3-bucket-public-read-prohibited
s3-bucket-public-write-prohibited
rds-snapshots-public-prohibited

How to Check Config Status

# Check if Config recorder is running
aws configservice describe-configuration-recorders

# Get recorder status
aws configservice describe-configuration-recorder-status

# List existing rules
aws configservice describe-config-rules

How to Deploy Critical Rules

Start by enabling the Config recorder, then deploy rules:

# Enable Config recorder
aws configservice start-configuration-recorder \
    --configuration-recorder-name default

# Deploy encrypted-volumes rule
aws configservice put-config-rule \
    --config-rule '{
      "ConfigRuleName": "encrypted-volumes",
      "Source": {
        "Owner": "AWS",
        "SourceIdentifier": "ENCRYPTED_VOLUMES"
      }
    }'

# Deploy restricted-ssh rule
aws configservice put-config-rule \
    --config-rule '{
      "ConfigRuleName": "restricted-ssh",
      "Source": {
        "Owner": "AWS",
        "SourceIdentifier": "INCOMING_SSH_DISABLED"
      }
    }'

Conformance packs bundle multiple rules for compliance frameworks. AWS provides sample packs for PCI DSS, HIPAA, NIST 800-53, and CIS Benchmarks.

For multi-account deployments, use organization Config rules to deploy consistently across all accounts, which integrates well with AWS Organizations governance patterns.

Now that we've covered individual issues, let's look at tools that catch them all.

How to Detect All 10 Issues at Once

You don't need to run CLI commands for each misconfiguration individually. AWS provides tools that aggregate findings across multiple categories, giving you a single view of your security posture. For a comprehensive approach covering 55+ security checks across IAM, network, data, and logging domains, see our AWS security review checklist.

AWS Security Hub

Security Hub is your central aggregation point. It collects findings from AWS Config, GuardDuty, Inspector, IAM Access Analyzer, Firewall Manager, and Macie. The AWS Foundational Security Best Practices standard covers most of the misconfigurations in this guide and provides automated security checks with severity ratings.

# Enable Security Hub with default standards
aws securityhub enable-security-hub --enable-default-standards

Security Hub calculates security scores based on passed vs. enabled controls, making it easy to track improvement over time. It also supports cross-Region aggregation for a unified view across your entire AWS footprint.

IAM Access Analyzer

Access Analyzer focuses specifically on access issues using automated reasoning to identify external access. It performs three types of analysis:

External access: Resources accessible outside your zone of trust
Internal access: Which principals within your organization can access specific resources
Unused access: Unused roles, access keys, passwords, and permissions

It also validates policies against IAM grammar and best practices before deployment, helping prevent misconfigurations proactively.

AWS Trusted Advisor

Trusted Advisor provides security checks including S3 bucket permissions, security group rules, IAM policies, MFA status, exposed access keys, and CloudTrail logging. Full security checks require Business or Enterprise Support plans.

Start with Security Hub. Enable it with the Foundational Security Best Practices standard, then layer on Access Analyzer for deeper IAM analysis and Trusted Advisor for broader operational recommendations.

Conclusion

These 10 misconfigurations appear repeatedly because they're easy to create accidentally and hard to spot without systematic monitoring. The good news is that AWS provides the tools to detect and fix all of them.

Start with the Critical items today: Enable S3 Block Public Access at the account level, verify root MFA, and audit your IAM policies for wildcards.

Enable Security Hub with the Foundational Security Best Practices standard for continuous monitoring of all 10 issues across your accounts.

Most fixes take minutes but prevent catastrophic breaches. A single public S3 bucket or overly permissive IAM policy can undo months of security work.

For a deeper understanding of AWS security fundamentals, check out AWS account security fundamentals and comprehensive AWS security best practices.

Quarterly security reviews catch drift before it becomes a problem. The misconfigurations I've covered aren't one-time fixes; they require ongoing vigilance as teams add resources, change configurations, and onboard new services.

Choosing an AWS Security Partner: The Honest Framework

Danny Steenman — Thu, 02 Apr 2026 17:30:04 +0000

You've decided you need help with AWS security. That decision alone puts you ahead of most organizations who wait until after a breach. But here's the harder question: how do you pick the right AWS security partner without wasting months on the wrong one?

The challenge is that everyone selling AWS security services sounds the same. They all claim "deep expertise," "proven experience," and "comprehensive solutions." Badges get thrown around. Logos get displayed. But how do you actually verify any of it?

I've been on both sides of this conversation. As a boutique AWS partner ourselves, I've seen how the partner selection process works from the inside. And I'll be honest upfront: this guide will help you evaluate us against our own criteria. If we're not the right fit, I'd rather you know that now than waste both our time.

What you'll get from this guide: A structured evaluation framework including a 10-point checklist, red flags to avoid, specific questions to ask in discovery calls (with guidance on what good answers look like), and transparent positioning on where different provider types, including us, fit best. For the technical foundation of what security partners actually implement, review our AWS security best practices guide.

Signs You Actually Need an AWS Security Partner

Before evaluating partners, let's confirm you're in the right place. Not every organization needs external security help. Here's how to know if you do.

When Internal Teams Hit Their Limits

The trigger isn't usually capacity. It's expertise. Your team might be excellent at building applications but lack deep security knowledge. AWS has 30+ security services, and understanding when to use Amazon GuardDuty vs AWS Security Hub vs Amazon Inspector (vs all three together) requires specialized experience.

Security misconfigurations are the leading cause of AWS breaches, ranging from IAM policies with wildcard actions allowing overly broad permissions to security groups allowing unrestricted access on critical ports. Your team might not have the visibility to catch these issues before they become incidents. Common AWS security misconfigurations often hide in plain sight because teams don't know what to look for.

The Compliance Trigger

Compliance deadlines create urgency that makes partner engagement obvious. SOC 2 audits, HIPAA assessments, PCI DSS certifications, and FedRAMP authorizations all require controls mapped to specific frameworks. AWS supports over 143 security standards and compliance certifications, but implementing the right controls for your specific requirements takes experience.

Partners who've guided organizations through these audits know where teams typically struggle and how to avoid common pitfalls. They've seen what auditors actually focus on, not just what the frameworks say.

Post-Incident Reality Check

After a security event, rapid response requires expertise you may not have. Incident response readiness gaps are common: no defined IR plan, lack of forensic readiness, and unclear escalation paths. AWS Security Incident Response Specialization Partners provide 24/7 monitoring, access to the AWS Customer Incident Response Team (CIRT), and pre-built runbooks for common scenarios.

If you're dealing with the aftermath of a security incident, professional help isn't optional. It's essential for root cause analysis, remediation validation, and preventing recurrence.

The Shared Responsibility Reality

AWS operates under a Shared Responsibility Model. AWS secures the infrastructure (security OF the cloud), but you're responsible for everything you deploy on it (security IN the cloud). This includes your IAM policies, security group configurations, S3 bucket settings, encryption choices, and application security.

Partners add value specifically in your responsibility domain. They help you implement least-privilege access, configure proper detection and response, protect data, and maintain compliance. This is where most organizations struggle, and where experienced partners deliver real value.

Types of AWS Security Providers (And Who They're Really For)

Not all AWS security providers are the same. Understanding the categories helps you narrow your search to providers that actually match your situation.

Big 4 and Large System Integrators

Deloitte, Accenture, PwC, EY, and large SIs bring global scale and deep benches. They can staff large teams across time zones and have established relationships with enterprise compliance and procurement processes.

Best for: Large enterprises with complex multi-year transformations, global compliance requirements across multiple jurisdictions, and organizations where procurement mandates large vendor relationships.

Trade-offs: Higher cost (often $300+/hour), junior staff frequently doing the actual work while seniors handle sales and oversight, longer engagement start times due to contracting complexity, and less flexibility for scope changes.

Boutique AWS Specialists

Smaller firms (typically 10-100 people) with deep AWS focus. These partners often have senior engineers on every engagement because they don't have layers of junior staff to deploy.

Best for: Mid-market companies needing specific AWS expertise, organizations wanting direct access to senior practitioners, faster engagement timelines, and teams that value knowledge transfer over dependency.

Trade-offs: Limited capacity for very large engagements, may not cover every possible specialization, and availability can be constrained during busy periods.

Transparent note: This is our category. We'll address our specific fit honestly in the final section.

Independent Consultants

Individual experts or very small teams (1-5 people) who work directly with clients. Often former Big Tech or enterprise security architects.

Best for: Specific projects with well-defined scope, organizations with budget constraints, short engagements where a single expert is sufficient, and technical advisory roles.

Trade-offs: Availability risk (one person can only do so much), limited capacity for ongoing work, no backup coverage if the consultant is unavailable, and less formal structure for compliance evidence.

AWS Professional Services

AWS's own consulting arm. They have unique access to internal AWS methodologies based on Amazon's internal practices and direct connection to AWS service teams.

Best for: Complex migrations requiring direct AWS involvement, organizations that need AWS's endorsement for stakeholder confidence, and largest enterprises with budget for premium rates.

Trade-offs: $300+/hour pricing puts it out of reach for most organizations, availability can be constrained by demand, and they may still recommend partners for implementation work. Read more about AWS Professional Services pricing and alternatives.

Provider Type	Typical Size	Cost Range	Best For	Key Trade-off
Big 4/SI	Global	$250-400+/hr	Large enterprise, global compliance	Junior staff, slow start
Boutique	10-100 people	$150-250/hr	Mid-market, AWS depth	Limited capacity
Independent	1-5 people	$100-200/hr	Specific projects	Availability risk
AWS ProServe	AWS	$300+/hr	Complex migrations	Premium pricing

10-Point Evaluation Checklist for AWS Security Partners

With provider types understood, here's how to evaluate specific partners. These criteria separate qualified partners from those who just claim expertise.

AWS Credentials That Actually Matter

AWS Partner Network validations aren't marketing fluff. They represent genuine technical assessment by AWS. Here's what to verify.

1. AWS Security Competency or MSSP Competency

The AWS Security Competency validates partners with deep expertise in securing AWS environments. The reimagined AWS MSSP Competency (updated in 2025) covers seven categories: Infrastructure Security, Workload Security, Application Security, Data Protection, Identity & Access Management, Incident Response, and Cyber Recovery. Verify claims directly on the AWS Partner Solutions page.

2. Partner tier level (Select, Advanced, or Premier)

Higher tiers require more customer success evidence and technical validation. Select tier is minimum for Security Hub integration and competency eligibility. Advanced and Premier indicate deeper AWS investment and proven customer outcomes.

3. Foundational Technical Review (FTR) completed

Partners with the "Reviewed by AWS" badge have passed AWS's technical validation process. FTR is required for access to AWS Partner Network programs, funding programs, and the AWS Competency Program. Partners without it haven't met AWS's technical bar.

4. AWS Certified Security - Specialty holders on team

The AWS Certified Security - Specialty (SCS-C03, updated December 2025 with enhanced AI/ML security focus) validates deep security knowledge. Ask how many team members hold this certification and whether certified individuals will work on your project.

5. Service Delivery designations for relevant services

AWS validates partners with deep experience in specific services. Security-relevant Service Delivery designations include AWS WAF, AWS Config, AWS Control Tower, AWS Security Hub, and Amazon GuardDuty. These indicate proven implementation experience.

Technical Depth Indicators

Credentials establish eligibility. These criteria verify actual technical capability.

6. AWS Well-Architected Review capability

Partners should be trained to conduct AWS Well-Architected Reviews, specifically the Security Pillar with its seven design principles and seven best practice areas. Ask for examples of Security Pillar findings they've remediated for clients.

7. Multi-account and multi-region expertise

Real AWS security requires understanding AWS Organizations, Control Tower, centralized logging, cross-account IAM, and Service Control Policies. If your environment spans multiple accounts, partners must demonstrate this expertise. Review AWS multi-account security architecture to understand what to look for.

8. Automation capabilities

Security that depends on manual processes fails at scale. Partners should demonstrate infrastructure as code experience (CDK, Terraform, CloudFormation), AWS Config rules for automated compliance, and Security Hub automation for response orchestration.

Delivery Model Fit

Technical skills matter, but so does how the engagement actually works.

9. Engagement model matches your needs

Consulting (project-based), retainer (ongoing advisory), or managed services (they operate it for you) represent different engagement models. Choose based on your internal capabilities and preferences. If you want to build internal capability, pure managed services might create dependency rather than growth.

10. Knowledge transfer included as explicit deliverable

Good partners make you more capable, not more dependent. Documentation, training sessions, and enablement should be explicit deliverables, not afterthoughts. If knowledge transfer isn't mentioned in the proposal, ask about it directly.

Red Flags When Evaluating Security Partners

Knowing what to look for is half the equation. Here's what should make you walk away.

Cannot verify AWS credentials on the AWS Partner Solutions page. Every competency, specialization, and Service Delivery designation is publicly verifiable. If a partner claims credentials that don't appear on AWS's site, that's a major red flag.

Senior staff sells, junior staff delivers. The architect who impresses you in the sales presentation should be the one working on your project. Ask specifically: "Who will be doing the actual work on our engagement?" If the answer is vague or references "our team," dig deeper.

No customer references in your industry or scale. Partners should be able to provide references from similar organizations. "Trust us, we're great" isn't evidence. No references means no proven track record you can validate.

Overpromising on compliance outcomes. No partner can guarantee you'll pass an audit. They can improve your chances significantly, but compliance ultimately depends on your organization's implementation and evidence. Guarantees indicate either dishonesty or lack of compliance experience.

Lock-in through complexity. Good partners simplify your environment and make it more maintainable. If a proposed solution creates dependencies you can't manage yourself, that's a feature for them and a bug for you.

Zero knowledge transfer in the proposal. If the engagement doesn't explicitly include documentation, training, or enablement, you're being set up for ongoing dependency rather than growing internal capability.

Cookie-cutter solutions without discovery. Your environment isn't identical to everyone else's. Partners who propose solutions before understanding your specific situation are selling a product, not providing expertise.

Questions to Ask in Discovery Calls (And What Good Answers Look Like)

Use these questions to dig beneath surface-level sales pitches. I've included guidance on what good answers actually sound like. For transparency on what our security review process entails, see our AWS security review process guide.

Validation Questions

"Which AWS Security Competency categories are you validated in?"

Good answer: Specific categories with verification instructions. "We hold AWS Security Competency and MSSP Competency in Infrastructure Security and Data Protection. You can verify this on the AWS Partner Solutions page by searching our company name."

Bad answer: Vague references to being an "AWS Partner" without specifics, or inability to point you to verification.

"How many team members hold AWS Certified Security - Specialty?"

Good answer: Specific numbers with context. "We have 4 Security Specialty certified engineers out of our team of 12, and two of them would be assigned to your project."

Bad answer: "Our team is highly certified" without specifics, or deflection to other certifications.

"Can you share customer references in our industry?"

Good answer: "Yes, we've worked with three SaaS companies similar to your size going through SOC 2. I can connect you with two of them after we sign an NDA."

Bad answer: "We have extensive experience" without specific references, or only references from vastly different industries/scales.

Technical Capability Questions

"Are you trained to conduct AWS Well-Architected Reviews?"

Good answer: "Yes, we're AWS Well-Architected Partners. In Security Pillar reviews, we commonly find issues around unused IAM permissions, missing VPC Flow Logs, and encryption gaps. Here's an example of findings we remediated for a client."

Bad answer: Unfamiliarity with the Well-Architected Framework or inability to discuss Security Pillar specifics.

"How do you approach multi-account security management?"

Good answer: References to AWS Organizations governance, Control Tower, centralized logging to a dedicated Security account, cross-account IAM roles, and Service Control Policies. Specific examples of multi-account architectures they've implemented.

Bad answer: Single-account focused answers or unfamiliarity with AWS Organizations features.

"What's your automation approach for security controls?"

Good answer: Specific tools and patterns. "We implement security controls using CDK with cdk-nag for compliance validation, AWS Config rules for continuous monitoring, and Security Hub automation rules for response. Everything is version-controlled and can be reviewed by your team."

Bad answer: Manual processes or vague references to "automation" without specifics.

Engagement Model Questions

"Who specifically will work on our project?"

Good answer: Named individuals with credentials. "John, our principal security architect (Security Specialty certified), will lead the engagement. Sarah, a senior engineer (Solutions Architect Professional), will handle implementation. Both will be on your calls."

Bad answer: "Our team will be assigned" without naming individuals, or names without credentials.

"How do you handle knowledge transfer?"

Good answer: "Knowledge transfer is an explicit deliverable. We provide documentation, two training sessions for your team during the engagement, and a recorded walkthrough of everything we implement. The goal is that your team can maintain and extend the work after we're done."

Bad answer: Knowledge transfer not mentioned, or treated as an afterthought rather than a core deliverable.

"What happens after the initial engagement?"

Good answer: "We provide 30 days of support after engagement completion. For ongoing needs, we offer retainer options, but our goal is that you don't need us for day-to-day operations. The implementation should be self-documenting and maintainable by your team."

Bad answer: Immediately pitching ongoing managed services, or answers that imply you'll always need them.

Price vs Value: Understanding Engagement Models

AWS doesn't publish partner pricing benchmarks, which makes this conversation harder than it should be. Here's what I can share based on market experience.

Common Pricing Structures

Hourly consulting ($100-300+/hour) is typical for advisory work and project-based engagements. Boutique partners usually fall in the $150-250 range, while Big 4 and AWS Professional Services command $250-400+.

Project-based pricing (fixed price for defined scope) works well for assessments, security reviews, and specific remediation projects. This shifts risk to the partner but requires clear scope definition upfront.

Monthly retainer provides ongoing advisory or fractional security leadership. Good for organizations that need regular guidance but can't justify full-time security hires.

Percentage of AWS spend is common for MSSP (managed security) arrangements where partners take operational responsibility for security monitoring and response.

When Premium Makes Sense (And When It Doesn't)

Premium pricing is justified when:

Critical compliance deadlines create urgency (SOC 2 audit in 60 days)
Complex multi-account environments require deep expertise
Active security incidents need immediate response
Your industry requires specific compliance knowledge (healthcare, financial services)

Premium pricing is less justified when:

Standard security assessments with flexible timelines
Well-defined projects with clear scope
Your internal team can handle implementation with advisory guidance
You have time to build internal capability rather than outsource

The value question: Beyond hourly rates, evaluate what capability you build vs. what you outsource. An engagement that costs more but leaves your team more capable may deliver better long-term value than a cheaper engagement that creates dependency.

Our Approach: Transparent Self-Positioning

I promised honesty about where we fit, so here it is.

What We Do Well

Towards the Cloud is a boutique AWS consultancy. Our engagement model means senior engineers on every project, not junior staff doing the work while seniors manage accounts.

Our strengths:

AWS-native architecture using CDK and infrastructure as code
Multi-account security foundations and landing zones
SOC 2 preparation and security review processes
Direct access to decision-makers (you talk to the people doing the work)
Knowledge transfer as explicit focus (we want you to learn, not depend)

For a transparent breakdown of what our security review process looks like from discovery call through deliverables, see our AWS security review process guide.

We've helped organizations establish secure AWS foundations, prepare for compliance audits, and implement the security controls that make auditors happy and keep data protected.

Who We're Not Right For

Here's where honesty matters most.

We're probably not the right fit if:

You need global 24/7 managed security operations (we're a small team in European time zones)
You're a large enterprise requiring Big 4 relationships for procurement or stakeholder confidence
You need purely managed security where someone else operates everything (we're consulting-focused)
Your industry requires specialized certifications we don't hold (FedRAMP, specific government clearances)

If this sounds like you, consider the Big 4 (Deloitte, Accenture, PwC) for enterprise requirements or AWS MSSP Competency partners for managed security operations. These providers exist for good reasons, and they may be better suited to your specific needs.

Making Your Decision

Choosing an AWS security partner isn't about finding the "best" provider. It's about finding the right fit for your specific situation, timeline, and internal capabilities.

Use the 10-point checklist to evaluate any partner you're considering, including us. Verify credentials on AWS's Partner Solutions page. Ask the discovery call questions and listen for specific, evidence-backed answers.

Watch for red flags that indicate a partner might create problems rather than solve them. Trust your instincts when something feels off.

Match provider type to your needs: Big 4 for enterprise complexity, boutique specialists for AWS depth and senior access, independents for specific projects, AWS ProServe for direct AWS involvement.

The right partner will make your AWS environment more secure, more compliant, and more manageable. The wrong partner will create complexity, dependency, and frustration.

If you want to evaluate your current security posture before engaging any partner, start with our AWS security review checklist. It's the same framework we use for paid engagements, and it will help you understand where you stand.

AWS CDK Best Practices: The Complete Guide [2026]

Danny Steenman — Thu, 02 Apr 2026 17:29:00 +0000

Most CDK tutorials teach you how to deploy your first Lambda function. Few prepare you for what happens when your team grows to 10 engineers, your stacks multiply to 50, and a refactoring mistake deletes your production database.

This guide covers the AWS CDK best practices that prevent those disasters. By the end, you'll understand AWS's official best practice categories, know how to structure projects with Projen (yes, it's a necessity, not optional), test your infrastructure code, implement security guardrails with cdk-nag, and avoid the anti-patterns that cause production incidents.

I've based these recommendations on AWS's official documentation, the AWS re:Invent 2023 advanced CDK session (embedded below), and the patterns I've implemented in the aws-cdk-starter-kit that you can use as a reference implementation.

If you're new to CDK, start with our beginner's guide to AWS CDK and install AWS CDK before diving into best practices.

Why CDK Best Practices Matter

Before diving into tactical advice, let me explain why investing time in best practices pays dividends.

The AWS CDK was built around a model where your entire application is defined in code, not just business logic but also infrastructure and configuration. At deployment time, CDK synthesizes a cloud assembly containing CloudFormation templates for all target environments plus file assets like Lambda code and Docker images.

This everything-in-code model is powerful but dangerous without guardrails. Every commit in your main branch represents a complete, deployable version of your application. That's great for automation but means mistakes propagate quickly.

The difference between a working CDK app and a production-ready CDK app comes down to following proven patterns that prevent:

Data loss from logical ID changes that accidentally replace databases
Security incidents from overly permissive IAM policies
Cost explosions from untagged resources and orphaned assets
Deployment failures from circular dependencies and oversized stacks
Team friction from unclear ownership boundaries

The Cost of Ignoring Best Practices

Let me give you some concrete examples of what goes wrong without best practices.

Logical ID changes destroy stateful resources. In CDK, every resource gets a logical ID derived from its construct ID and position in the tree. Change either one, and CloudFormation sees it as a new resource, replacing the old one. For a DynamoDB table or RDS database, "replace" means "delete the old one and create a new empty one." I've seen teams lose production data this way.

Hardcoded names prevent multi-environment deployment. If you hardcode bucketName: 'my-app-assets', you can't deploy the same stack twice in the same account, not for dev/staging/prod environments, not even for testing. Names are precious resources in AWS.

Untested infrastructure breaks production. Without tests asserting your Lambda has the right memory configuration or your security group allows the correct ports, you're deploying blind. CloudFormation will happily deploy misconfigured infrastructure.

AWS's Four Categories of Best Practices

AWS organizes CDK best practices into four broad categories that I'll cover throughout this guide:

Organization best practices: How to structure teams and adoption at the organizational level
Coding best practices: How to organize CDK code, repositories, and packages
Construct best practices: How to develop reusable, composable constructs
Application best practices: How to combine constructs and make architectural decisions

Now that you understand why best practices matter, let's start with the foundation: how you structure your CDK project.

Project Structure and Projen (Essential Tooling)

Project structure might seem like a minor concern, but it determines how maintainable your CDK application becomes as it grows. More importantly, how you manage that structure matters even more than the structure itself.

I'm going to make a strong statement here: Projen is a necessity for CDK projects, not an optional nice-to-have. If you're still manually maintaining package.json, tsconfig.json, and other configuration files, you're creating technical debt that will slow you down.

Why Projen is a Necessity, Not Optional

Let me explain why manual configuration management is an anti-pattern.

When you run cdk init, you get a basic project with configuration files you're expected to maintain by hand. This works fine for a weekend project. But in a team environment, those files drift. Someone updates a dependency in package.json but forgets to update tsconfig.json. Someone else copies configuration from Stack Overflow without understanding it. Six months later, you have a mess of conflicting settings that nobody fully understands.

Projen solves this by treating configuration as code. Instead of editing package.json directly, you define your project in a .projenrc.ts file:

import { awscdk } from 'projen';

const project = new awscdk.AwsCdkTypeScriptApp({
  cdkVersion: '2.175.0',
  defaultReleaseBranch: 'main',
  name: 'my-cdk-app',
  projenrcTs: true,

  // Dependencies
  deps: ['@aws-cdk/aws-lambda-python-alpha'],
  devDeps: ['cdk-nag'],

  // Testing
  jest: true,
  jestOptions: {
    jestConfig: {
      testMatch: ['**/*.test.ts'],
    },
  },

  // Linting
  eslint: true,
  prettier: true,
});

project.synth();

Run npx projen, and Projen generates all your configuration files consistently. The generated files include a warning not to edit them manually, because Projen owns them.

This approach provides several benefits:

No configuration drift: Every team member gets identical configuration
Automated dependency management: Projen keeps dependencies compatible
Built-in best practices: ESLint, Jest, and TypeScript are pre-configured correctly
Easy upgrades: Update the Projen version to get the latest recommended settings

Projen isn't some obscure tool either. It's the underlying technology for blueprint synthesis in Amazon CodeCatalyst. AWS uses it internally because manual configuration doesn't scale.

For a deep dive on project organization patterns, see my detailed guide on structuring your CDK project.

The aws-cdk-starter-kit: Your Reference Implementation

Rather than just telling you what best practices look like, I've created a reference implementation you can clone and study: the aws-cdk-starter-kit.

This repository demonstrates:

Projen configuration for CDK TypeScript projects
Project structure that scales from starter to enterprise
Testing setup with Jest and CDK assertions
Security validation with cdk-nag integration
CI/CD workflows using GitHub Actions with OpenID Connect

You can use it as a starting point for new projects or as a reference when restructuring existing ones. The starter kit implements every best practice covered in this guide.

Repository Organization Patterns

AWS recommends that every CDK application starts with a single package in a single repository. This keeps things simple and avoids premature complexity.

Resist the urge to put multiple applications in the same repository, especially if you're using automated pipelines. Here's why:

Changes to one application trigger deployment of all applications
A broken build in one app prevents deployment of others
The "blast radius" of any change increases dramatically

When you need to share code between applications, move shared constructs to their own repository and publish them as packages via CodeArtifact or npm. Shared packages require their own testing strategy because they must be validated independently from the applications that consume them.

Infrastructure and Runtime Code Colocation

One of CDK's superpowers is bundling runtime code (Lambda functions, Docker images) alongside infrastructure definitions. Embrace this by colocating related code in self-contained constructs.

For example, a construct that creates a Lambda function should include the Lambda's source code in the same directory:

lib/
├── api-handler/
│   ├── api-handler-construct.ts    # CDK construct
│   ├── handler.ts                  # Lambda runtime code
│   └── handler.test.ts             # Lambda unit tests

This colocation enables:

Synchronized versioning: Infrastructure and code evolve together
Isolated testing: Test the construct and its runtime code independently
Easy sharing: Publish the entire construct as a reusable package

With your project properly structured, let's dive into how to design constructs effectively.

Construct Design Best Practices

Constructs are the building blocks of every CDK application. Understanding how to design and use them correctly determines whether your infrastructure code is reusable and maintainable or a tangled mess.

Understanding L1, L2, and L3 Constructs

AWS CDK constructs come in three levels of abstraction, and knowing when to use each is fundamental to CDK development.

L1 Constructs (CFN Resources) map directly to single CloudFormation resources. They're named with a Cfn prefix (like CfnBucket) and offer no abstraction. You get complete control over every property, but you're responsible for all the configuration. New CloudFormation resources become available as L1 constructs within about a week.

L2 Constructs (Curated Constructs) provide a higher-level, intent-based API with sensible defaults. A Bucket (L2) versus CfnBucket (L1) includes best-practice security policies by default, helper methods for permissions (.grantRead()), and generates boilerplate automatically. Most of your CDK code should use L2 constructs.

L3 Constructs (Patterns) combine multiple resources into complete architectures. ApplicationLoadBalancedFargateService creates a Fargate service with a load balancer, target groups, security groups, and IAM roles, all properly configured to work together.

For a comprehensive explanation of construct levels with code examples, see my deep dive on CDK constructs.

Model with Constructs, Deploy with Stacks

This principle from AWS is worth memorizing: Model your application with constructs, but use stacks only for deployment.

Everything in a CDK stack deploys together. If you model your website as a Stack containing S3, API Gateway, Lambda, and RDS, you can't reuse that website in another context without copying code.

Instead, model the website as a Construct containing those resources. Then instantiate that construct in stacks for different deployment scenarios:

// The construct models the application
class WebsiteConstruct extends Construct {
  constructor(scope: Construct, id: string, props: WebsiteProps) {
    super(scope, id);
    // S3, API Gateway, Lambda, RDS defined here
  }
}

// Stacks define deployment boundaries
class DevStack extends Stack {
  constructor(scope: Construct, id: string) {
    super(scope, id);
    new WebsiteConstruct(this, 'Website', { environment: 'dev' });
  }
}

class ProdStack extends Stack {
  constructor(scope: Construct, id: string) {
    super(scope, id);
    new WebsiteConstruct(this, 'Website', { environment: 'prod' });
  }
}

This separation improves reusability, testing, and modularity.

Protecting Logical IDs for Stateful Resources

Every resource in CDK gets a logical ID derived from its construct ID and position in the construct tree. Changing a logical ID causes CloudFormation to replace the resource, which for stateful resources like databases means data loss.

Protect yourself by writing unit tests that assert logical IDs remain stable:

test('database logical ID remains stable', () => {
  const app = new App();
  const stack = new MyStack(app, 'TestStack');
  const template = Template.fromStack(stack);

  // This test fails if you accidentally rename the database construct
  template.hasResource('AWS::DynamoDB::Table', {
    // Asserts the logical ID contains 'UserTable'
  });
});

If you need to rename constructs or move resources between stacks, use the new CDK Refactor feature (available since September 2025) which safely reorganizes infrastructure without replacing resources.

Constructs Aren't Enough for Compliance

Many enterprises create wrapper constructs (sometimes called L2+ constructs) that enforce security policies like encryption or specific IAM configurations. While useful for surfacing guidance early in development, don't rely on wrapper constructs as your sole compliance mechanism.

Developers can bypass your wrappers by using L1 constructs directly or third-party constructs from Construct Hub. Instead, enforce compliance at multiple levels:

Service Control Policies (SCPs) and permission boundaries at the AWS Organizations level
cdk-nag to validate constructs before deployment (covered below)
CloudFormation Guard for template-level validation
Aspects to apply cross-cutting validations to all constructs

Now that you understand construct design, let's look at the coding patterns that keep your CDK code maintainable.

Coding Best Practices

These coding patterns apply to all CDK projects regardless of size. Following them from the start saves significant refactoring later.

Start Simple, Add Complexity Only When Needed

The guiding principle from AWS is simple: keep things as simple as possible, but no simpler. Don't architect for every possible scenario upfront. CDK enables refactoring, so you can add complexity when requirements actually demand it.

If you're building a single Lambda function, don't create an abstract "FunctionFactory" pattern on day one. Start with the simplest thing that works. Add abstraction when you have a second, third, or fourth function that genuinely needs it.

Make Decisions at Synthesis Time

Although CloudFormation supports deploy-time decisions using Conditions, Fn::If, and Parameters, AWS recommends against using them with CDK. The types of values and operations available in CloudFormation conditions are limited compared to TypeScript or Python.

Instead, make all decisions in your CDK code using programming language features:

// Good: Decision at synthesis time
if (props.environment === 'prod') {
  new Alarm(this, 'HighErrorAlarm', {
    threshold: 10,
    evaluationPeriods: 3,
  });
}

// Avoid: CloudFormation conditions
const isProd = new CfnCondition(this, 'IsProd', {
  expression: Fn.conditionEquals(props.environment, 'prod'),
});

Treat CloudFormation as an implementation detail for reliable deployments, not as a programming language.

Use Generated Resource Names

Hardcoding resource names like bucketName: 'my-app-data' creates several problems:

You can't deploy the stack twice in the same account (dev and prod environments)
You can't replace the resource if an immutable property changes
CloudFormation can't safely replace resources (old and new need the same name)

Let CDK generate names instead. Pass generated names to consumers through:

Environment variables for Lambda functions
AWS Systems Manager Parameter Store
References between stacks in the same CDK app
Static from methods like Table.fromTableArn() for cross-app references

Define Removal Policies for Stateful Resources

By default, CloudFormation retains stateful resources when you delete a stack, leaving orphaned S3 buckets and DynamoDB tables in your account. CDK provides explicit removal policies:

const bucket = new Bucket(this, 'DataBucket', {
  removalPolicy: RemovalPolicy.RETAIN, // Default: keeps bucket on stack delete
  // RemovalPolicy.DESTROY, // Deletes bucket when stack is deleted
  // RemovalPolicy.SNAPSHOT, // For databases: snapshot before delete
});

For resources that don't expose a removalPolicy prop, use the escape hatch:

const cfnBucket = bucket.node.findChild('Resource') as CfnBucket;
cfnBucket.applyRemovalPolicy(RemovalPolicy.DESTROY);

Configure with Properties, Not Environment Variables

Environment variable lookups inside constructs are a common anti-pattern:

// Anti-pattern: Creates machine dependency
class MyConstruct extends Construct {
  constructor(scope: Construct, id: string) {
    super(scope, id);
    const env = process.env.ENVIRONMENT; // Don't do this
  }
}

This creates a dependency on the machine where synthesis runs and introduces configuration that lives outside your codebase.

Instead, accept configuration through a properties object:

// Good: Full configurability in code
interface MyConstructProps {
  environment: string;
}

class MyConstruct extends Construct {
  constructor(scope: Construct, id: string, props: MyConstructProps) {
    super(scope, id);
    const env = props.environment; // Configuration explicit in code
  }
}

Environment variables should be limited to the top-level of your CDK app for development convenience, never inside constructs or stacks.

Writing good code is only half the battle. Next, let's ensure your CDK code actually works as expected through testing.

Testing Your CDK Code

Testing infrastructure code might seem unusual if you're used to only testing application logic. But CDK makes infrastructure testable, and you should take advantage of that.

Untested CDK code is a liability. You're trusting that your Lambda has the right memory, your security group allows the correct ports, and your IAM policies follow least privilege, all without verification.

Two Testing Approaches: Assertions vs Snapshots

The CDK assertions module supports two complementary testing approaches:

Fine-grained assertions test specific aspects of your synthesized CloudFormation templates. They're useful for verifying critical properties and catching regressions:

test('Lambda function has correct memory', () => {
  const app = new App();
  const stack = new MyStack(app, 'TestStack');
  const template = Template.fromStack(stack);

  template.hasResourceProperties('AWS::Lambda::Function', {
    MemorySize: 1024,
    Timeout: 30,
  });
});

Snapshot tests compare your entire synthesized template against a stored baseline:

test('stack matches snapshot', () => {
  const app = new App();
  const stack = new MyStack(app, 'TestStack');
  const template = Template.fromStack(stack);

  expect(template.toJSON()).toMatchSnapshot();
});

Snapshots enable confident refactoring because any template change triggers a test failure. However, CDK version upgrades can change generated templates, so don't rely solely on snapshots.

Setting Up Your Testing Framework

For TypeScript projects, CDK uses Jest. If you're using Projen (which you should be), testing is already configured. Otherwise, add these dependencies:

{
  "devDependencies": {
    "jest": "^29.0.0",
    "@types/jest": "^29.0.0",
    "ts-jest": "^29.0.0"
  }
}

Create tests following the naming convention *.test.ts in your test/ directory.

Fine-Grained Assertion Examples

Here are practical examples of assertions you should write:

import { App } from 'aws-cdk-lib';
import { Template, Match } from 'aws-cdk-lib/assertions';
import { MyStack } from '../lib/my-stack';

describe('MyStack', () => {
  let template: Template;

  beforeAll(() => {
    const app = new App();
    const stack = new MyStack(app, 'TestStack');
    template = Template.fromStack(stack);
  });

  test('S3 bucket has encryption enabled', () => {
    template.hasResourceProperties('AWS::S3::Bucket', {
      BucketEncryption: {
        ServerSideEncryptionConfiguration: Match.arrayWith([
          Match.objectLike({
            ServerSideEncryptionByDefault: {
              SSEAlgorithm: 'aws:kms',
            },
          }),
        ]),
      },
    });
  });

  test('Lambda function uses correct runtime', () => {
    template.hasResourceProperties('AWS::Lambda::Function', {
      Runtime: 'nodejs20.x',
    });
  });

  test('IAM role follows least privilege', () => {
    template.hasResourceProperties('AWS::IAM::Policy', {
      PolicyDocument: {
        Statement: Match.arrayWith([
          Match.objectLike({
            Effect: 'Allow',
            Action: Match.arrayWith(['s3:GetObject']),
            // Not s3:* or s3:GetObject*
          }),
        ]),
      },
    });
  });
});

Integration Testing with integ-tests-alpha

For testing that requires actual AWS resources, use the @aws-cdk/integ-tests-alpha module. Integration tests deploy real infrastructure and verify behavior:

import { IntegTest, ExpectedResult } from '@aws-cdk/integ-tests-alpha';

const integ = new IntegTest(app, 'ApiIntegTest', {
  testCases: [stack],
});

// Make assertions against deployed resources
integ.assertions
  .httpApiCall('https://api.example.com/health')
  .expect(ExpectedResult.objectLike({ statusCode: 200 }));

Integration tests are slower and cost money (they deploy real resources), so use them sparingly for critical paths.

With tested infrastructure, let's ensure it's also secure with CDK's security features.

Security and Compliance Best Practices

Security in CDK goes beyond writing secure code. It includes managing permissions for deployments, enforcing least privilege between resources, and validating infrastructure before it reaches production.

IAM Best Practices and Grant Methods

L2 constructs provide grant methods that create least-privilege IAM policies automatically. Always prefer these over manual policy definitions:

// Good: Uses grant method for least privilege
bucket.grantRead(lambdaFunction);

// Also good: Specific permissions when needed
bucket.grantReadWrite(lambdaFunction);

// Avoid: Overly permissive manual policies
lambdaFunction.addToRolePolicy(new PolicyStatement({
  actions: ['s3:*'], // Too permissive
  resources: ['*'],   // Too broad
}));

Each grant method creates a unique IAM role with only the permissions needed. If you need custom permissions, be explicit about actions and resources:

lambdaFunction.addToRolePolicy(new PolicyStatement({
  actions: ['s3:GetObject', 's3:ListBucket'],
  resources: [bucket.bucketArn, bucket.arnForObjects('*')],
}));

Validating with cdk-nag

cdk-nag is an open-source tool that checks your CDK applications against compliance rule packs. It uses CDK Aspects to validate every construct in your application.

Available rule packs include:

AWS Solutions: General AWS best practices
HIPAA Security: Healthcare compliance rules
NIST 800-53 rev 4/5: Government security controls
PCI DSS 3.2.1: Payment card industry standards

Add cdk-nag to your application:

import { AwsSolutionsChecks, HIPAASecurityChecks } from 'cdk-nag';
import { Aspects } from 'aws-cdk-lib';

const app = new App();

// Apply compliance checks to all stacks
Aspects.of(app).add(new AwsSolutionsChecks({ verbose: true }));
Aspects.of(app).add(new HIPAASecurityChecks({ verbose: true }));

cdk-nag reports violations during synthesis, catching issues before deployment:

[Error at /MyStack/Bucket/Resource] AwsSolutions-S1: The S3 Bucket does not have server access logging enabled.

You can suppress specific rules when you have a valid reason:

import { NagSuppressions } from 'cdk-nag';

NagSuppressions.addResourceSuppressions(bucket, [
  {
    id: 'AwsSolutions-S1',
    reason: 'Access logging handled by CloudTrail data events',
  },
]);

For detailed implementation steps, see the AWS Prescriptive Guidance on cdk-nag implementation.

Using Aspects for Cross-Cutting Concerns

Aspects use the visitor pattern to apply operations across all constructs in your application. They're powerful for enforcing standards that apply everywhere.

Read-only aspects validate without modifying:

class BucketVersioningChecker implements IAspect {
  public visit(node: IConstruct): void {
    if (node instanceof Bucket) {
      if (!node.versioned) {
        Annotations.of(node).addError('Bucket must have versioning enabled');
      }
    }
  }
}

Aspects.of(app).add(new BucketVersioningChecker());

Mutating aspects modify constructs during synthesis:

class TaggingAspect implements IAspect {
  public visit(node: IConstruct): void {
    if (Tags.of(node)) {
      Tags.of(node).add('Environment', 'production');
      Tags.of(node).add('ManagedBy', 'CDK');
    }
  }
}

Aspects.of(app).add(new TaggingAspect());

With secure, tested code, let's set up continuous delivery with GitHub Actions.

CI/CD with GitHub Actions

For CDK deployments, I recommend GitHub Actions over CDK Pipelines. While CDK Pipelines is a valid option, GitHub Actions provides a simpler, more widely understood approach that integrates better with existing workflows.

The critical piece is using OpenID Connect (OIDC) for AWS authentication instead of long-lived credentials. Storing AWS access keys in GitHub secrets is a security anti-pattern.

Why GitHub Actions Over CDK Pipelines

CDK Pipelines adds significant complexity to your CDK application. Your pipeline becomes CDK code that deploys itself, which can be confusing to debug and requires understanding both CodePipeline and CDK internals.

GitHub Actions, by contrast, is platform-agnostic and widely understood. Most developers already know how to work with GitHub Actions workflows. When something fails, you're debugging a YAML workflow, not synthesized CodePipeline resources.

Additionally, GitHub Actions with OIDC provides better security than CDK Pipelines' default bootstrap roles. You have explicit control over the IAM trust policy.

Secure AWS Access with OpenID Connect

OpenID Connect (OIDC) lets GitHub Actions assume an IAM role without storing long-lived credentials. GitHub acts as an identity provider, and AWS trusts tokens from specific repositories and branches.

Setting up OIDC requires:

Creating a GitHub OIDC provider in your AWS account
Creating an IAM role with a trust policy for GitHub
Configuring your workflow to use OIDC authentication

For step-by-step instructions, see my detailed guides on setting up OpenID Connect with GitHub or Bitbucket.

GitHub Actions Workflow Structure

Here's a production-ready workflow structure for CDK deployments:

name: CDK Deploy

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions:
  id-token: write
  contents: read

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Run linting
        run: npm run lint

      - name: Run tests
        run: npm test

      - name: Synthesize CDK
        run: npx cdk synth

  deploy-dev:
    needs: build-and-test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    environment: development
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/GitHubDeployRole
          aws-region: us-east-1

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Deploy to dev
        run: npx cdk deploy --all --require-approval never

  deploy-prod:
    needs: deploy-dev
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::987654321098:role/GitHubDeployRole
          aws-region: us-east-1

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Install dependencies
        run: npm ci

      - name: Deploy to production
        run: npx cdk deploy --all --require-approval never

For a complete CI/CD implementation, check the aws-cdk-starter-kit CI/CD documentation.

Multi-Environment Deployment Patterns

For multi-environment deployments, use GitHub environments with protection rules:

Development: Deploys automatically on push to main
Staging: Requires manual approval before deployment
Production: Requires manual approval and passes all staging tests

Configure environment protection in GitHub repository settings. The environment key in your workflow jobs enforces these rules.

Before bootstrapping each environment, ensure you've configured CDK bootstrap with appropriate trust relationships for your GitHub OIDC role.

Now that you know the best practices, let's look at what NOT to do: the anti-patterns that cause production incidents.

Common Anti-Patterns to Avoid

Knowing what to avoid is as important as knowing what to do. These anti-patterns cause real problems in production CDK applications.

Hardcoding Physical Resource Names

// Anti-pattern: Hardcoded names
new Bucket(this, 'DataBucket', {
  bucketName: 'my-company-data-bucket', // Don't do this
});

Consequence: You can't deploy this stack twice in the same account. Want dev and prod in the same account? Want to test a feature branch? Can't do it. The name is taken.

Solution: Let CDK generate names. Pass them to consumers through environment variables, Parameter Store, or stack references.

Environment Variable Lookups in Constructs

// Anti-pattern: Environment variable lookup in construct
class MyConstruct extends Construct {
  constructor(scope: Construct, id: string) {
    super(scope, id);
    const region = process.env.AWS_REGION; // Machine dependency
  }
}

Consequence: Your infrastructure depends on whatever machine runs synthesis. Works on your laptop, fails in CI. Works today, fails tomorrow when someone changes their shell profile.

Solution: Accept all configuration through properties. Environment variables belong only at the top level of your app for development convenience.

Manual Infrastructure Modifications

Anti-pattern: Making changes through the AWS Console or CLI after CDK deployment.

Consequence: Configuration drift. Your CDK code says one thing, AWS has something different. Next deployment either fails mysteriously or overwrites your manual changes.

Solution: All infrastructure changes go through CDK code in version control. If you need a quick fix, make it in code and deploy, even for "temporary" changes.

Bypassing Code Review and Testing

Anti-pattern: Running cdk deploy directly from your laptop to production.

Consequence: Untested, unreviewed changes reach production. No audit trail. When something breaks, nobody knows what changed.

Solution: All production deployments go through CI/CD with pull request reviews and automated tests. No exceptions, not even for "quick fixes."

Multiple Applications in One Repository

Anti-pattern: Multiple CDK apps sharing a single repository with a shared pipeline.

Consequence: Changing one application triggers deployment of all applications. A bug in App A prevents deployment of App B. The blast radius of any change is massive.

Solution: One application per repository. Share code through published packages, not filesystem proximity.

Checking In Secrets

Anti-pattern: Committing credentials, API keys, database passwords, or sensitive configuration to version control.

// Anti-pattern: Secrets in code
new Function(this, 'MyFunction', {
  environment: {
    DB_PASSWORD: 'super-secret-password', // Never do this
    API_KEY: 'sk-1234567890abcdef',        // This either
  },
});

Consequence: Security breach waiting to happen. Secrets in Git history persist even after deletion. Automated scanners constantly search public repositories for exposed credentials. Even in private repositories, anyone with read access sees your secrets.

Solution: Use AWS Secrets Manager or Systems Manager Parameter Store for all secrets:

import { Secret } from 'aws-cdk-lib/aws-secretsmanager';

const dbSecret = Secret.fromSecretNameV2(this, 'DbSecret', 'prod/db/password');

new Function(this, 'MyFunction', {
  environment: {
    DB_SECRET_ARN: dbSecret.secretArn,
  },
});

// Grant the function permission to read the secret
dbSecret.grantRead(fn);

Additionally:

Add secret patterns to .gitignore (.env, *.pem, credentials.json)
Use pre-commit hooks like git-secrets to scan for accidentally committed credentials
Rotate any secrets that were ever committed, even briefly

Beyond avoiding mistakes, there are also optimization opportunities for performance and cost.

Performance and Cost Optimization

CDK applications can accumulate waste over time if you're not proactive about optimization. Here are the key areas to address.

Tagging for Cost Allocation

Tags propagate from parent constructs to all taggable children. Apply tags at the app or stack level to ensure every resource is tagged:

import { Tags } from 'aws-cdk-lib';

const app = new App();
Tags.of(app).add('Project', 'MyProject');
Tags.of(app).add('Environment', 'production');
Tags.of(app).add('CostCenter', 'engineering');

These tags appear in your AWS Cost Explorer, enabling cost allocation by project, environment, or team.

Managing CDK Assets with Garbage Collection

Over time, CDK bootstrap buckets and ECR repositories accumulate old assets from previous deployments. This increases storage costs unnecessarily.

CDK Garbage Collection (currently in preview) cleans up isolated assets:

cdk gc --unstable=gc

This command works at the environment level, identifying and deleting assets that are no longer referenced by any deployed stack. Configure safety buffers to avoid deleting assets needed for rollbacks:

cdk gc --unstable=gc --rollback-buffer-days 14 --created-buffer-days 1

Warning: Don't run garbage collection during active deployments. Wait until all deployments are complete.

Finally, let's look at the newest CDK features you should know about.

Recent CDK Features (2024-2025)

CDK continues to evolve rapidly. These recent features address longstanding pain points and open new possibilities.

CDK Refactor for Safe Infrastructure Changes

Released in September 2025, CDK Refactor enables safe refactoring of infrastructure by renaming constructs, moving resources between stacks, and reorganizing CDK applications without replacing existing resources.

Previously, renaming a construct or moving it to a different stack caused CloudFormation to delete the old resource and create a new one. For stateful resources like databases, this was catastrophic.

CDK Refactor uses CloudFormation's refactor capabilities to compute the mapping between old and new logical IDs automatically:

cdk refactor

Use cases include:

Breaking monolithic stacks into domain-specific stacks
Renaming constructs to follow naming conventions
Reorganizing applications after team structure changes

This feature is available in all AWS Regions where CDK is supported.

CLI and Library Split

Starting February 2025, the CDK CLI and CDK Construct Library have independent release cadences:

CDK CLI versions: 2.1000.0, 2.1001.0, etc.
CDK Construct Library versions: 2.175.0, 2.176.0, etc.

The CLI source code moved to a new GitHub repository: github.com/aws/aws-cdk-cli.

Practical impact: Keep your CDK CLI at the latest version. The CLI is backward-compatible with all Construct Library versions released before it. Update your CI/CD pipelines to install the latest 2.x CLI rather than pinning specific versions.

New L2 Constructs

Several services gained L2 constructs in 2024-2025:

Amazon Data Firehose L2 (February 2025): Define streaming data infrastructure with familiar programming patterns. Programmatically configure delivery streams to S3, Redshift, and other destinations.

AWS AppSync Events L2 (February 2025): Create WebSocket APIs for real-time applications. Define event APIs and channel namespaces, grant access to specific channels, and integrate with Lambda functions.

Amazon EKS v2 L2 (alpha): Uses native CloudFormation resources and modern Access Entry-based authentication. Supports EKS Auto Mode and multiple clusters per stack.

These new L2 constructs replace verbose L1 configurations with intent-based APIs that include sensible defaults.

For even more advanced patterns, check out this AWS re:Invent session from experts with 4+ years of CDK experience.

Advanced Patterns: Learning from 4 Years of CDK (Video)

This AWS re:Invent 2023 session (COM302) covers advanced CDK patterns from engineers who have used CDK in production for over four years. The talk goes deeper into topics like testing strategies, organizational patterns, and lessons learned from large-scale deployments.

Key topics covered include:

Organizational patterns for multi-team CDK adoption
Advanced testing strategies beyond unit tests
Performance optimization for large CDK applications
Governance and compliance at scale
Real-world failure scenarios and how to avoid them

The session complements this guide by providing visual explanations and live demonstrations of advanced patterns.

Your CDK Best Practices Checklist

Here's what to remember from this guide:

Use Projen for project configuration management, not manual file editing
Model with constructs, deploy with stacks to maximize reusability
Test your infrastructure with fine-grained assertions and snapshots
Validate with cdk-nag before deployment to catch compliance issues
Use GitHub Actions with OIDC for secure CI/CD without long-lived credentials
Avoid anti-patterns like hardcoded names, environment variable lookups, and manual changes
Let CDK generate resource names and pass them to consumers explicitly
Define removal policies for all stateful resources
Tag everything for cost allocation and governance
Keep CDK CLI updated to get the latest features and compatibility

Your next step: Clone the aws-cdk-starter-kit and explore how it implements these best practices. Use it as a starting point for your next project or as a reference when restructuring existing applications.

For more detailed guidance on specific topics, check out these related guides:

What is AWS CDK? for a beginner-friendly introduction to CDK fundamentals
AWS CDK Project Structure for deeper project organization patterns
AWS CDK Constructs for mastering L1, L2, and L3 constructs
AWS CDK Stacks for understanding stack lifecycle and patterns
Configure OpenID Connect for GitHub for OIDC setup details

What best practices have made the biggest difference in your CDK projects? I'd love to hear about patterns that have worked well for your team.

AWS CloudOps Engineer Exam Guide: SOA-C03 Prep & Study Plan [2026]

Danny Steenman — Thu, 02 Apr 2026 17:28:56 +0000

The AWS Certified SysOps Administrator exam you might have prepared for no longer exists. As of September 2025, it's the AWS Certified CloudOps Engineer Associate (SOA-C03), a significant update that brings containers, modern operations practices, and multi-account architectures into scope.

This isn't just a name change. The exam content has evolved substantially, and many outdated study guides are still ranking in search results. If you're using SOA-C02 materials, you're studying for the wrong exam.

This guide gives you a complete preparation roadmap: personalized study timelines based on your experience level, domain-by-domain breakdown with service coverage, free and paid resource recommendations, hands-on practice strategies, and exam day tactics. Everything is based on the official SOA-C03 exam guide and AWS Training and Certification resources.

What is the AWS CloudOps Engineer Associate Certification?

The AWS Certified CloudOps Engineer Associate validates your expertise in deploying, operating, and maintaining workloads on AWS. It's designed for system administrators, operations engineers, and DevOps professionals who manage production AWS environments.

This certification sits at the Associate level in AWS's certification hierarchy, which means it expects hands-on implementation skills, not just theoretical knowledge. You'll need to demonstrate practical understanding of monitoring, automation, security, and cost optimization across AWS services.

Key Exam Details (SOA-C03)

Here's what you need to know about the exam itself:

Detail	Specification
Exam Code	SOA-C03
Price	$150 USD
Duration	180 minutes
Format	Multiple-choice, multiple-response, ordering, matching, case study
Delivery	Pearson VUE test center or online proctoring
Passing Score	Scaled scoring (AWS doesn't disclose exact threshold)
Questions	50-65 questions

Note: Follow this advice on getting 30 minutes extra time to permanently receive additional time for all your AWS exams.

What Changed: From SysOps Administrator to CloudOps Engineer

AWS announced the certification rename in July 2025, with registration opening on September 9, 2025. The last day to take the previous SOA-C02 exam was September 29, 2025, meaning only SOA-C03 is available now.

The name change reflects the industry's shift in terminology. "CloudOps" better describes the modern role of cloud operations professionals who manage, monitor, and automate cloud infrastructure. But the changes go deeper than branding:

Key differences in SOA-C03:

Containers are now in-scope: Amazon ECS, EKS, and ECR are testable topics
Greater emphasis on multi-account, multi-Region architectures: Understanding AWS Organizations and multi-account strategy is more important than ever
Increased focus on automation and infrastructure as code: Expect deeper questions on CloudFormation, Systems Manager, and Config
More modern services and features: Updated content reflects AWS services released through 2025
New question types: Ordering, matching, and case study questions test procedural knowledge

No task statements were removed from the previous exam, only additions and reorganization. If you studied for SOA-C02, you have a foundation, but you need to fill the gaps.

Impact on existing certifications: If you already hold the AWS Certified SysOps Administrator Associate, your certification remains valid until its expiration date. It won't automatically rename. You'll only earn the "CloudOps Engineer" title by passing the new SOA-C03 exam.

Who Should Take This Exam?

AWS designed this certification for professionals who manage AWS production environments. You're a good fit if you:

Have at least 1-2 years of hands-on experience operating AWS workloads
Know how to troubleshoot applications using AWS monitoring and logging services
Understand fundamental networking concepts (DNS, TCP/IP, firewalls, VPCs)
Can implement highly available, performant architectures
Work with or aspire to work in cloud operations, DevOps, or platform engineering roles

This isn't an entry-level certification. If you're brand new to AWS, consider starting with the Cloud Practitioner certification to build foundational knowledge first.

Is the CloudOps Exam Right for You?

Before committing weeks or months to exam preparation, make sure CloudOps Engineer aligns with your career goals and current skill level. The wrong certification path wastes time and money.

Prerequisites and Recommended Background

AWS doesn't mandate specific prerequisites, but the Associate level assumes you can do more than recognize service names. You need implementation experience.

Recommended background:

Hands-on experience managing, monitoring, and maintaining cloud infrastructure
Familiarity with AWS core services (EC2, VPC, IAM, S3, CloudWatch)
Understanding of operational concepts like monitoring, logging, backup, and disaster recovery
Experience with at least one infrastructure as code tool (CloudFormation, CDK, Terraform)

Timeline expectations:

If you're transitioning from on-premises infrastructure roles: 3-6 months to master AWS fundamentals before focused exam prep
If you have AWS experience but not in operations: 4-8 weeks of targeted study
If you already work in AWS operations daily: 2-4 weeks of exam-focused preparation

Should You Get Cloud Practitioner First?

The short answer: it depends on your background.

Start with Cloud Practitioner if:

You're completely new to AWS
You don't have hands-on cloud experience
You want to validate foundational knowledge before investing in Associate-level prep
Your organization values or requires foundational certification

Skip to CloudOps Engineer directly if:

You have 6+ months of hands-on AWS experience
You already work with CloudWatch, VPC, IAM, or EC2 regularly
You've built or managed infrastructure on AWS
You hold other cloud certifications

Cloud Practitioner adds 2-3 weeks to your total preparation time but builds a strong conceptual foundation. For complete beginners, it's worth the investment. For working cloud professionals, it's often unnecessary.

Read the AWS Cloud Practitioner exam guide if you decide the foundational path makes sense.

CloudOps vs Solutions Architect vs Developer Associate

AWS offers three Associate-level certifications, each targeting different roles and skill sets. Choosing the right one accelerates your career in the direction you want to go.

Certification	Primary Focus	Best For
Solutions Architect Associate	Designing cost-effective, scalable architectures	Architects who design systems
Developer Associate	Building and deploying applications on AWS	Developers writing code for AWS
CloudOps Engineer Associate	Operating and maintaining production workloads	Operations engineers, SysAdmins, DevOps

CloudOps Engineer focuses on the operational lifecycle: monitoring, logging, remediation, automation, and optimization. You're tested on keeping systems running, not designing them from scratch.

Solutions Architect Associate focuses on architectural decisions: choosing the right services, designing for availability, and optimizing costs at the design phase.

Developer Associate focuses on application development: CI/CD pipelines, serverless applications, SDK usage, and debugging.

Career progression insight: Many professionals earn multiple Associate certifications. CloudOps + Developer leads naturally to the AWS DevOps Engineer Professional certification, which validates expertise in both development and operations.

Study Timeline: Choose Your Path

Generic advice like "study for several weeks to months" isn't helpful. Your optimal timeline depends on your starting point. Here are four concrete paths based on experience level.

The timelines below assume you're dedicating 1-2 hours daily to focused study. Adjust proportionally if you have more or less time available.

Complete Beginner Path (8 Weeks)

This path is for you if you're new to AWS or have minimal cloud experience. You'll build foundational knowledge before diving into operations-specific content.

Week 1-2: AWS Fundamentals

Complete Cloud Practitioner-level content on AWS Skill Builder
Focus on core services: EC2, S3, VPC, IAM
Understand the AWS global infrastructure and pricing model
Goal: Pass a Cloud Practitioner practice assessment

Week 3-4: Core CloudOps Services

Deep dive into CloudWatch (metrics, alarms, logs, dashboards)
Learn IAM policies, roles, and permission boundaries
Study VPC components, security groups, and network ACLs
Hands-on: Set up basic monitoring for an EC2 instance

Week 5-6: Advanced Operations Topics

Systems Manager (Session Manager, Patch Manager, Automation)
CloudFormation fundamentals and stack operations
AWS Config rules and compliance automation
Container basics: ECS task definitions and services

Week 7: Practice Exams and Gap Identification

Take your first full practice exam
Score and categorize weak areas by domain
Create targeted study plan for final week
Review all incorrect answers thoroughly

Week 8: Targeted Review and Exam

Focus 70% of time on weak domains identified
Light review of strong areas to maintain knowledge
Take final practice exam (aim for 80%+)
Schedule and take the exam

Cloud Practitioner Holder Path (6 Weeks)

You've already validated foundational AWS knowledge. Now you'll focus on operational depth.

Week 1-2: Monitoring and Logging Deep Dive

CloudWatch metrics, alarms, and composite alarms
CloudWatch Logs, Logs Insights queries, and log retention management
AWS X-Ray for distributed tracing
CloudTrail for API logging and security analysis
Hands-on: Build a monitoring dashboard and configure alarms

Week 3-4: Automation and Security

Systems Manager capabilities (Automation, Run Command, State Manager)
AWS Config rules and auto-remediation
EventBridge rules and targets for automation
IAM best practices, Organizations, and Service Control Policies (SCPs)
Hands-on: Create an automation runbook

Week 5: Containers and Multi-Account Architecture

ECS vs Fargate and when to use each
ECS task roles vs execution roles
EKS cluster operations basics
AWS Organizations and Control Tower vs Organizations
Hands-on: Deploy a containerized application on ECS

Week 6: Practice Exams and Exam

Take 2-3 practice exams from different sources
Deep review of all incorrect answers
Final review of high-weight domains
Schedule and take the exam

Solutions Architect Associate Holder Path (4 Weeks)

You understand AWS architecture. Now you'll learn to operate and maintain what you've designed.

Week 1: Monitoring Deep Dive

CloudWatch metrics you didn't need for SAA (detailed monitoring, custom metrics)
CloudWatch Logs Insights query syntax
Alarm actions and composite alarms
Container Insights for ECS/EKS monitoring
Testing CloudWatch alarms

Week 2: Automation and Remediation

Systems Manager Automation documents
AWS Config rules with auto-remediation
EventBridge rules for operational automation
Patch management and compliance enforcement
SSM Parameter Store vs Secrets Manager operations

Week 3: New SOA-C03 Content

Container operations: ECS execute command, task definitions
ECS vs EC2 decision framework
Multi-account operations with Organizations
AWS Backup and disaster recovery
Cost optimization with Compute Optimizer and Trusted Advisor

Week 4: Practice Exams and Exam

Focus on operations-specific scenarios
Compare your SAA knowledge to CloudOps requirements
Take 2 full practice exams
Schedule and take the exam

Working Cloud Engineer Path (2 Weeks)

You operate AWS daily. Your goal is validating what you know and filling specific gaps.

Days 1-3: Assessment and Gap Identification

Download and review the official SOA-C03 exam guide
Take a practice assessment on AWS Skill Builder
Identify weak domains from your score report
Create targeted study list

Days 4-7: Fill Knowledge Gaps

Focus on any unfamiliar services or concepts
Containers if you don't use them daily
Multi-account architecture if you work single-account
Cost optimization services (Compute Optimizer, Trusted Advisor)
Review documentation for services you use but don't fully understand

Days 8-10: Practice Exams

Take 2-3 full-length practice exams
Time yourself to simulate exam conditions
Review ALL answer explanations, not just wrong ones
Identify any remaining gaps

Days 11-14: Final Review and Exam

Light review of flagged topics
Quick refresher on exam domains and weightings
Rest the day before the exam
Take the exam

Best CloudOps Exam Study Resources

The right resources make preparation efficient. The wrong ones waste time on outdated content or topics not covered on the exam. Here's what actually works for SOA-C03.

Free Resources: AWS Skill Builder and Documentation

AWS provides substantial free preparation materials. For budget-conscious learners, you can pass using only free resources, though it requires more self-direction.

AWS Skill Builder (Free Tier):

Exam Prep Plan: AWS Certified CloudOps Engineer - Associate (SOA-C03)
Individual courses for each exam domain
Free practice questions to understand exam format
Self-paced digital courses covering core services

AWS Documentation:

Service FAQs (especially CloudWatch, Systems Manager, Config)
Best practices whitepapers (operations, security, cost optimization)
Service user guides for deep technical understanding

AWS Builder Labs (Limited Free):

Hands-on labs in actual AWS environments
Specific labs: "Configuring metrics and alarms in Amazon CloudWatch"
AWS Jam challenges for gamified learning

Solutions-Focused Immersion Days (SFIDs):

Free, live virtual events led by AWS experts
Cover core AWS services with hands-on components
Check the AWS Training site for upcoming sessions

For more options, see 11 best free AWS learning resources.

Paid Resources Worth Considering

Paid resources accelerate learning and provide structured paths. They're not required but often worth the investment for time savings.

AWS Skill Builder Subscription ($29/month):

Full access to all labs and hands-on experiences
AWS SimuLearn for exam-style practice
Additional practice question sets
AWS Cloud Quest gamified learning

Video Courses:

Stephane Maarek's courses (Udemy) are highly regarded in the community
Look for courses explicitly updated for SOA-C03
Avoid any course still referencing SOA-C02

Practice Exams:

Tutorials Dojo practice exams (Jon Bonso) are frequently recommended
Official AWS practice question sets
Look for providers with updated SOA-C03 content

Important: Verify any resource is updated for SOA-C03. Content created before September 2025 is for the retired SOA-C02 exam and missing container coverage.

Recommended Resource Combinations

Not sure how to combine resources? Here are three approaches based on budget and learning style.

Budget Path (Free Only):

AWS Skill Builder free courses
AWS documentation and whitepapers
Official free practice questions
AWS Free Tier for hands-on practice
Timeline: Add 1-2 weeks for self-directed learning

Balanced Path ($50-100):

AWS Skill Builder free tier for courses
One paid video course (Udemy, ~$15-20 on sale)
One practice exam set (Tutorials Dojo, ~$15)
AWS Free Tier for hands-on practice
Best value for most learners

Accelerated Path ($150-200):

AWS Skill Builder subscription for full lab access
Paid video course for structured learning
Multiple practice exam sources for variety
Timeline: Can compress study by 1-2 weeks

By learning style:

Visual learners: Prioritize video courses
Hands-on learners: Invest in Skill Builder subscription for labs
Readers: AWS documentation and whitepapers work well
Test-takers: Multiple practice exam sources reveal gaps faster

SOA-C03 Exam Domains and What to Study

The exam covers five domains. Understanding what each domain tests helps you allocate study time effectively and recognize question patterns during the exam.

Domain	Weight	Focus Areas
Monitoring, Logging, Analysis, Remediation & Performance	22%	CloudWatch, X-Ray, troubleshooting, cost optimization
Reliability and Business Continuity	22%	High availability, Auto Scaling, backup, disaster recovery
Deployment, Provisioning, and Automation	22%	CloudFormation, Systems Manager, IaC, CI/CD basics
Networking and Content Delivery	18%	VPC, Route 53, CloudFront, load balancing
Security and Compliance	16%	IAM, encryption, compliance, Organizations, SCPs

Domain 1: Monitoring, Logging, Analysis, Remediation, and Performance Optimization (22%) is tied for the highest weight. This domain now includes performance and cost optimization that was previously a separate domain in SOA-C02. You'll need deep CloudWatch expertise plus understanding of remediation automation.

Domain 2: Reliability and Business Continuity (22%) tests your ability to implement highly available, scalable systems. Key topics include Auto Scaling, load balancing, backup strategies, and disaster recovery procedures.

Domain 3: Deployment, Provisioning, and Automation (22%) focuses on infrastructure as code and deployment automation. CloudFormation, Systems Manager, and deployment strategies are critical here.

Domain 4: Security and Compliance (16%) covers implementing security controls, managing identities, and ensuring compliance. IAM, encryption, and governance tools like Organizations and SCPs are key.

Domain 5: Networking and Content Delivery (18%) tests VPC configuration, connectivity options, DNS with Route 53, and content delivery with CloudFront.

Domain 1: Monitoring, Logging, Analysis, Remediation, and Performance Optimization

This domain tests your ability to implement metrics, alarms, and log filters, primarily using CloudWatch. You should also know how to remediate issues automatically using EventBridge and Systems Manager. In SOA-C03, this domain now includes cost and performance optimization that was previously a separate domain.

Key services to know deeply:

CloudWatch: Metrics (standard and custom), alarms, composite alarms, dashboards, Logs, Logs Insights, Container Insights
CloudTrail: API logging, log file integrity, integration with CloudWatch
AWS X-Ray: Distributed tracing, service maps, trace analysis
EventBridge: Event patterns, rules, targets, scheduling
Systems Manager: Automation documents, Run Command, remediation actions
Cost Explorer: Cost analysis, forecasting, recommendations
AWS Budgets: Budget alerts, actions, notifications
Trusted Advisor: Checks across cost, security, performance, fault tolerance
Compute Optimizer: EC2 and Lambda right-sizing recommendations

What you should be able to do:

Configure CloudWatch alarms with appropriate statistics and periods
Write CloudWatch Logs Insights queries to analyze log data
Set up automated remediation using Config rules and SSM Automation
Design monitoring dashboards for operational visibility
Analyze costs and identify optimization opportunities
Right-size EC2 instances based on utilization data
Implement S3 lifecycle policies for cost optimization

CloudWatch statistics you must know:

Statistic	Use Case
SampleCount	Number of data points in the period
Sum	Total value (e.g., total requests)
Average	Typical value over time
Minimum	Lowest observed value
Maximum	Highest observed value
Percentile (p99, p95)	Latency analysis

EC2 placement groups:

Strategy	Use Case
Cluster	Low latency, high throughput (HPC)
Partition	Large distributed workloads (Hadoop, Cassandra)
Spread	Critical instances that must avoid correlated failures

Domain 2: Reliability and Business Continuity

This domain focuses on implementing scalability, elasticity, and high availability. You need to understand how to design and operate resilient systems.

Key services to know deeply:

Auto Scaling: Scaling policies, health checks, lifecycle hooks
Elastic Load Balancing: ALB, NLB, target groups, health checks
Route 53: Health checks, routing policies, failover configurations
AWS Backup: Backup plans, retention policies, cross-Region backup
Elastic Disaster Recovery: DR strategies, recovery processes

Route 53 routing policies you must know:

Policy	Use Case
Simple	Single resource, basic routing
Weighted	A/B testing, gradual migrations
Latency	Route to lowest-latency Region
Failover	Active-passive high availability
Geolocation	Region-specific content
Geoproximity	Custom traffic distribution
Multivalue	DNS-level load balancing

What you should be able to do:

Configure Auto Scaling policies (target tracking, step, scheduled)
Set up Route 53 health checks with failover routing
Implement backup strategies with appropriate retention
Design multi-Region architectures for disaster recovery

Domain 3: Deployment, Provisioning, and Automation

This domain tests infrastructure as code and deployment strategies. You need to understand CloudFormation deeply and know various deployment patterns.

Key services to know deeply:

CloudFormation: Template anatomy, stack operations, helper scripts, drift detection
AWS CDK: What is AWS CDK, CDK constructs, synthesizing templates
Systems Manager: State Manager, Automation, Patch Manager, Parameter Store
AWS Config: Rules, conformance packs, remediation actions

CloudFormation helper scripts:

Script	Purpose
cfn-init	Execute metadata configuration
cfn-hup	Monitor and apply metadata changes
cfn-signal	Signal completion of CreationPolicy/WaitCondition
cfn-get-metadata	View stack metadata

Deployment strategies you must understand:

What you should be able to do:

Write and troubleshoot CloudFormation templates
Implement blue/green and rolling deployments
Configure Systems Manager for patching and automation
Use Config rules to enforce compliance

For deeper DevOps content, see the AWS DevOps Engineer Professional exam guide.

Domain 4: Security and Compliance

This domain covers IAM, encryption, and compliance enforcement. You need to understand both preventive and detective security controls.

Key services to know deeply:

IAM: Policies, roles, permission boundaries, identity federation
AWS Organizations: SCPs, SCP examples, organizational structure
KMS: Key management, encryption contexts, key policies
Secrets Manager: Secret rotation, cross-account access
Security Hub: Findings, compliance standards, integrations
AWS Config: Compliance rules, remediation

What you should be able to do:

Write and troubleshoot IAM policies
Implement encryption at rest and in transit
Configure compliance automation with Config rules
Understand multi-account security with Organizations and SCPs

For a deeper dive, read the AWS Security Specialty exam guide.

Domain 5: Networking and Content Delivery

This domain tests VPC configuration, connectivity options, and content delivery. You need to troubleshoot network issues and optimize content delivery.

Key services to know deeply:

VPC: Subnets, route tables, security groups, NACLs, endpoints
Elastic Load Balancing: ALB, NLB, connection draining, sticky sessions
CloudFront: Distributions, origins, caching, Origin Access Control
Route 53: DNS records, routing policies, hosted zones
Direct Connect: Connections, virtual interfaces, redundancy

VPC components table:

Component	Purpose
Subnets	IP address ranges for resources
Route Tables	Traffic routing between subnets
Internet Gateway	Public internet connectivity
NAT Gateway	Outbound internet for private subnets
Virtual Private Gateway	VPN connectivity
Security Groups	Stateful firewall at instance level
NACLs	Stateless firewall at subnet level
VPC Endpoints	Private connectivity to AWS services

What you should be able to do:

Design and troubleshoot VPC architectures
Configure load balancers with appropriate health checks
Set up CloudFront distributions with S3 origins
Troubleshoot connectivity issues using VPC Flow Logs

New in SOA-C03: Container Services

Containers are the most significant addition to SOA-C03. If you haven't worked with ECS or EKS, this section is essential. Even if you have container experience, make sure you understand the operational aspects tested on the exam.

The exam focuses on operating containers, not developing containerized applications. You need to know how to deploy, monitor, and troubleshoot container workloads.

Amazon ECS for CloudOps

Amazon Elastic Container Service (ECS) is AWS's container orchestration service. It's the primary container service covered on the exam due to its AWS-native integration.

Key concepts you must understand:

Task Definitions: The blueprint for your containers. Know the difference between task roles and execution roles, as this is a common exam topic.

Launch Types: Understand when to choose ECS with Fargate vs EC2 and the operational implications of each:

Fargate: AWS manages the infrastructure. Less operational overhead, but less control over the underlying compute.
EC2: You manage the container instances. More control, but more operational responsibility.

For a broader comparison, see Amazon ECS vs Amazon EC2.

ECS Exec: Know how to access containers using ECS execute command for troubleshooting. This requires the SSM agent and appropriate IAM permissions.

Container Insights: CloudWatch Container Insights provides automatic dashboards for ECS metrics. You should know how to enable it and what metrics it collects.

Amazon EKS for CloudOps

Amazon Elastic Kubernetes Service (EKS) is AWS's managed Kubernetes service. The exam tests operational knowledge, not Kubernetes administration depth.

Key concepts for the exam:

Cluster management: Creating, updating, and maintaining EKS clusters
Node groups: Managed and self-managed node groups
Fargate profiles: Running pods on Fargate without managing nodes
IAM integration: IAM roles for service accounts (IRSA)
Logging: Control plane logging to CloudWatch

ECS vs EKS decision criteria:

Choose ECS When	Choose EKS When
AWS-native simplicity	Kubernetes expertise exists
Tight AWS service integration	Multi-cloud portability needed
Smaller operational team	Complex scheduling requirements
New to containers	Existing K8s workloads

Container Monitoring and Operations

Container monitoring integrates with CloudWatch but requires specific configuration. The exam tests your understanding of container-specific observability.

CloudWatch Container Insights:

Automatic collection of CPU, memory, network, and storage metrics
Pre-built dashboards for ECS and EKS
Per-container and per-task metrics
Integration with CloudWatch alarms

Log aggregation:

ECS: Configure the awslogs log driver in task definitions
EKS: Use Fluent Bit or CloudWatch agent for log forwarding
Know how to query container logs with Logs Insights

X-Ray integration:

Trace requests across containerized microservices
Instrument containers with the X-Ray SDK or daemon
Analyze service maps for performance bottlenecks

Common troubleshooting scenarios:

Container health check failures
Task placement failures (insufficient resources)
Networking issues (security groups, service discovery)
IAM permission errors (task role vs execution role)

Hands-On Practice Strategy

Reading about AWS services won't prepare you for scenario-based questions. You need hands-on experience to understand how services behave in practice. This section covers how to practice safely without unexpected AWS bills.

Why Hands-On Experience is Critical

The CloudOps exam includes scenario-based questions that assume practical knowledge. You're not just choosing the correct service; you're choosing the correct configuration, parameter, or troubleshooting step.

Examples of what hands-on teaches you:

CloudWatch alarm states and how they transition
What happens when a Config rule finds non-compliant resources
How Auto Scaling behaves during scale-in events
Why certain IAM policies don't work as expected

The exam may also include lab-style questions where you perform tasks in a simulated AWS environment. Familiarity with the console and CLI gives you an advantage.

Setting Up Your Practice Environment

Create a dedicated AWS account for exam practice. This keeps your practice resources separate and makes cleanup easier.

Initial setup:

Create a new AWS account (or use an existing sandbox account)
Set up billing alerts immediately: Configure Budget alerts at $5, $10, and $20 thresholds
Enable Cost Explorer for spend visibility
Create an IAM user for practice (avoid using root for daily activities)
Tag all resources with Project: CloudOps-Prep for easy cleanup

Cost control practices:

Use t3.micro or t3.small instances (Free Tier eligible)
Stop or terminate resources after each practice session
Set CloudWatch alarms on billing metrics
Avoid services with high hourly costs (large RDS instances, NAT Gateways)
Use AWS Budgets actions to stop resources if budget exceeded

Essential Lab Scenarios

Focus on labs that align with exam domains. Here are priority scenarios to practice:

Monitoring and Logging:

Create custom CloudWatch metrics from an application
Configure CloudWatch alarms with different statistics
Write CloudWatch Logs Insights queries
Set up CloudTrail logging and analyze events
Enable Container Insights for an ECS cluster

Automation:

Create a Systems Manager Automation document
Configure Config rules with auto-remediation
Set up EventBridge rules to trigger Lambda functions
Use Systems Manager Run Command across multiple instances

Deployment:

Deploy a CloudFormation stack with parameters and outputs
Perform a stack update and observe change sets
Create a blue/green deployment using CodeDeploy
Deploy a container application on ECS Fargate

Security:

Write IAM policies and test with IAM Policy Simulator
Configure KMS keys and use them for S3 encryption
Set up Secrets Manager with automatic rotation
Implement Config rules for compliance checking

Networking:

Build a VPC with public and private subnets
Configure VPC endpoints for S3 and DynamoDB
Set up an Application Load Balancer with path-based routing
Troubleshoot connectivity using VPC Flow Logs

Free Tier Optimization and Cost Control

AWS Free Tier includes many services useful for exam preparation. Know the limits to avoid charges.

Free Tier services useful for CloudOps prep:

EC2: 750 hours/month of t2.micro (t3.micro in some Regions)
S3: 5GB storage, 20,000 GET requests, 2,000 PUT requests
Lambda: 1 million requests, 400,000 GB-seconds
CloudWatch: 10 custom metrics, 10 alarms, 5GB log ingestion
DynamoDB: 25GB storage, 25 read/write capacity units

Services to avoid or use carefully:

NAT Gateway: $0.045/hour plus data processing charges
Large RDS instances: Use db.t3.micro for practice
Elastic IPs: Free when attached, charged when not
EKS: $0.10/hour for the control plane

Cleanup automation:

Schedule Lambda functions to stop EC2 instances nightly
Use CloudFormation to deploy and destroy entire environments
Tag resources and use Resource Groups for bulk operations
Review Cost Explorer weekly during preparation

Practice Exams and Self-Assessment

Practice exams are essential for exam readiness, but timing and technique matter. Taking practice exams too early wastes them; taking them wrong reduces their value.

When to Start Taking Practice Exams

Don't burn through practice exams before you've studied the content. They're most valuable for identifying gaps, not learning new material.

Recommended timing:

First practice exam: At 50-60% of your study timeline. Use this to identify major gaps.
Second practice exam: At 75-80% of timeline. Measure improvement and find remaining gaps.
Final practice exam(s): In the last few days. Validate readiness and build confidence.

Save official AWS practice questions for last. Third-party practice exams are good for learning; official questions are best for final validation since they match the actual exam style most closely.

How to Use Practice Exams Effectively

Taking a practice exam and checking your score isn't enough. The real value comes from deep review.

During the practice exam:

Time yourself to simulate real conditions (roughly 2 minutes per question)
Flag questions where you're uncertain
Use process of elimination on difficult questions
Don't look up answers during the exam

After the practice exam:

Review EVERY answer explanation, including questions you got right
For wrong answers, understand why each option is correct or incorrect
Track your performance by domain
Note patterns in question types you struggle with

Process of elimination strategy:

Eliminate obviously wrong answers first
Look for keywords that indicate correct/incorrect (always, never, must)
Consider the scenario carefully; answers often depend on specific details
When stuck between two options, consider which is more operationally sound

Identifying and Addressing Weak Areas

Use practice exam results to create a targeted remediation plan.

Tracking weak areas:

After each practice exam, record your score by domain
Calculate percentage correct per domain
Identify domains below 70% as priorities
Note specific services or concepts you consistently miss

Remediation approach:

Below 60% in a domain: Return to learning resources for that domain
60-70% in a domain: Review specific weak topics, do targeted labs
Above 70% in a domain: Light review to maintain knowledge

When to schedule the exam:

Consistently scoring 80%+ on practice exams
No domain below 70%
Comfortable with question pacing
Feeling confident about container and multi-account content

Exam Day Preparation

Exam day logistics can affect your performance. Knowing what to expect eliminates surprises and lets you focus on the questions.

Online Proctored vs Test Center

Both options are valid. Choose based on your environment and preferences.

Online proctored (at home):

Convenience of taking the exam from your location
Requires private, quiet space
Must complete system test 24 hours before exam
Video scan of room required before starting
Camera and microphone monitored throughout
Risk: Technical issues can disrupt your exam

Test center (Pearson VUE):

Dedicated testing environment
No concerns about home distractions
Technical setup handled by the center
May require travel time
Limited scheduling flexibility

Recommendation: If you have a quiet, private space and reliable internet, online proctoring is convenient. If your home environment is unpredictable, a test center provides a controlled setting.

Technical Requirements and Security Measures

For online proctored exams, technical preparation prevents day-of issues.

24 hours before exam:

Complete the system test on Pearson VUE
Verify webcam and microphone work
Test your internet connection stability
Clear your desk and testing area
Prepare your government-issued ID

Room requirements:

Private room with closed door
Clear desk (only computer and ID allowed)
No notes, phones, or additional monitors
No one else in the room during the exam

Prohibited items:

Cell phones and smart watches
Notes, books, or reference materials
Additional monitors or screens
Headphones or earbuds
Food and drinks (water may be allowed)

ID requirements:

Government-issued ID (passport, driver's license)
Name on ID must exactly match your AWS Certification account
ID must be valid (not expired)

Time Management and Test-Taking Strategies

With 65 questions in 180 minutes, you have approximately 2.5 minutes per question. That's adequate but requires discipline.

Pacing strategy:

First pass: Answer questions you're confident about (mark uncertain ones for review)
Second pass: Return to flagged questions
Final 15 minutes: Review flagged questions, don't second-guess confident answers

Question approach:

Read the entire question, including all answer options
Identify what the question is actually asking (troubleshooting, best practice, most cost-effective)
Eliminate obviously wrong answers
Look for keywords that indicate the correct approach

Common traps:

"Most" questions: Multiple answers may be correct, but one is MOST correct
Scenario details matter: The answer often depends on specific requirements mentioned
Cost questions: "Most cost-effective" isn't always cheapest, it's best value
Time constraints: "Fastest" or "quickest" may override other considerations

Don't change answers: Unless you're certain your first answer was wrong, stick with it. Second-guessing often leads to changing correct answers to incorrect ones.

What If You Don't Pass?

Failing the exam is disappointing but not disqualifying. Many successful certified professionals didn't pass on their first attempt. The key is using the experience to improve.

Understanding Your Score Report

AWS provides a score report after the exam, even for failures. This report is your roadmap for improvement.

What the score report includes:

Overall scaled score (pass threshold is not disclosed)
Performance by domain (meets expectations, needs improvement)
No specific question-level feedback

Interpreting domain scores:

"Meets expectations": You demonstrated competency in this domain
"Needs improvement": This domain contributed to your failure

Note: AWS uses scaled scoring, so raw percentage doesn't directly translate to your score. A 65% raw score might be passing or failing depending on question difficulty weighting.

Creating Your Retake Study Plan

Use your score report to create a targeted study plan for your retake.

Retake rules:

14-day waiting period before retake
Full exam fee required ($150 USD)
No limit on retake attempts

Study plan for retake:

Focus 70% of study time on "needs improvement" domains
Allocate 30% to maintaining strength in passing domains
Use different resources than your first attempt (different perspective helps)
Take practice exams from sources you haven't used before
Increase hands-on practice in weak areas

Typical retake timeline:

Most candidates retake 2-4 weeks after failure
Rushing the retake often leads to similar results
Better to add 1-2 weeks of focused study than fail again

Psychological approach:

One failure doesn't define your capability
Many AWS experts failed certifications before passing
Treat the first attempt as an expensive practice exam
Focus on what you learned, not what you lost

After Passing: Career Benefits and Next Steps

Passing the CloudOps Engineer exam validates your operational expertise. Here's what to do with that achievement.

Certification Validity and Recertification

AWS certifications are valid for three years from your pass date. After that, you must recertify to maintain your status.

Recertification options:

Pass the current version of the CloudOps Engineer exam
Pass the AWS DevOps Engineer Professional exam (recertifies both CloudOps and any Developer Associate)
Pass a higher-level certification that includes CloudOps content

Your certification badge:

Digital badge available through AWS Certification
Shareable on LinkedIn, email signatures, and professional profiles
Verifiable by employers through AWS's verification system

Career Value and Job Opportunities

The CloudOps Engineer certification demonstrates to employers that you can:

Manage production AWS workloads
Implement monitoring and automated remediation
Design resilient and cost-optimized infrastructure
Work with modern container technologies

Roles that value this certification:

Cloud Operations Engineer
DevOps Engineer
Platform Engineer
Site Reliability Engineer (SRE)
Systems Administrator (cloud-focused)

Salary impact: While certification alone doesn't guarantee salary increases, it validates skills that are in demand. Combine certification with demonstrated experience for maximum career impact.

Next Certifications to Consider

CloudOps Engineer positions you well for several certification paths.

Natural progression:

AWS DevOps Engineer Professional: If you have or pursue the Developer Associate, this Professional certification validates combined development and operations expertise. It recertifies both Associate certifications.
AWS Solutions Architect Professional: Broadens your expertise from operations to architecture. Good if you want to move into solution design roles.

Specialty certifications:

AWS Security Specialty: Deep expertise in security architecture and operations
AWS Advanced Networking Specialty: Deep expertise in network design and troubleshooting
AWS Data Engineer Associate: If you work with data pipelines and analytics

Recommended path for operations professionals:

CloudOps Engineer Associate (you are here)
Developer Associate (complements operations with development skills)
DevOps Engineer Professional (validates full DevOps expertise)

AWS Security Review Checklist: Complete Self-Assessment Guide

Danny Steenman — Thu, 02 Apr 2026 17:28:28 +0000

Every AWS breach starts with a misconfiguration someone missed. I've seen it in security reviews: one overly permissive IAM role, one security group with 0.0.0.0/0, one S3 bucket with public access. These aren't sophisticated attacks. They're basic misconfigurations that appear in 90% of accounts and violate AWS security best practices.

This AWS security review checklist is the exact one I use for paid assessments. Now it's yours.

But there's a reason companies still hire me. The checklist identifies problems. Professional experience determines which problems actually matter for your specific environment, how to remediate without breaking things, and what architectural patterns prevent these issues from recurring.

This AWS security review checklist follows the AWS Well-Architected Security Pillar, which organizes security into seven best practice areas: security foundations, identity and access management, detection, infrastructure protection, data protection, incident response, and application security. For the full 57-question checklist across all six pillars, see the AWS Well-Architected Review checklist. I've organized this checklist into the domains that matter most for practical security assessments.

By the end of this guide, you'll be able to systematically assess your AWS security posture, prioritize findings by risk level, and remediate issues with specific steps. Whether you're preparing for a compliance audit, doing proactive security hygiene, or validating your current controls, this checklist gives you a structured approach.

How to Use This Checklist

Before diving into specific checks, let me explain how this assessment is structured. Understanding the approach helps you get maximum value from your time investment.

Each checklist item includes a risk level indicator, specific instructions on what to check, what a "pass" looks like, what a "fail" looks like, and remediation steps. I've organized items by security domain, but you should start with the critical items across all domains before working through high and medium priorities.

Time Estimates by Depth Level

Your time investment depends on what you need to accomplish.

Quick Security Scan (1-2 hours): Critical items only across all domains. This catches the misconfigurations most likely to result in a breach. Good for monthly spot-checks or when you need fast validation.

Standard Security Review (4-8 hours): All checklist items at a reasonable depth. You'll check configurations, review findings, and document issues. Good for quarterly assessments or pre-audit preparation.

Comprehensive Assessment (2-3 days): Full checklist plus remediation implementation. You'll not only identify issues but fix them and verify the fixes. Good for annual deep dives or post-incident hardening.

Multi-account environments multiply these estimates. A standard review of 10 accounts takes 40-80 hours unless you've configured centralized security services with aggregated findings.

Required Tools and Access

Before starting, ensure you have the necessary permissions and tools configured.

IAM Permissions: At minimum, you need the SecurityAudit AWS managed policy attached to your IAM role. This provides read-only access to security configurations across services. For a comprehensive review, ViewOnlyAccess combined with SecurityAudit covers most scenarios.

AWS CLI: Many checks are faster via CLI than console. Configure your CLI with the appropriate profile:

aws sts get-caller-identity

This confirms your identity and permissions before you begin.

Security Services: Several items require specific services to be enabled. If they're not already running, enable them now:

AWS Security Hub (aggregates findings from multiple sources)
AWS Config (tracks configuration compliance)
Amazon GuardDuty (threat detection)
AWS CloudTrail (API activity logging)

For AWS accounts on Business Support or higher, AWS Trusted Advisor provides additional security checks that complement this assessment.

Risk Level Indicators Explained

Each checklist item has a risk indicator that helps you prioritize.

[CRITICAL]: Immediate action required. These represent active security risks that attackers could exploit today. Missing MFA on root, public S3 buckets, security groups with 0.0.0.0/0 for SSH. Fix these before doing anything else.

[HIGH]: Fix within 30 days. Significant exposure that increases your attack surface or violates security best practices. Unencrypted data, missing logging, overly permissive IAM policies.

[MEDIUM]: Address within a quarter. Best practice deviations that improve your security posture but don't represent immediate exploitable risk. Defense-in-depth enhancements, documentation improvements.

[LOW]: Nice to have. Enhancements that provide marginal security improvement. Address these when you have capacity.

Pre-Assessment: Scope and Inventory

You can't assess what you don't know exists. Before running through checklists, document what you're reviewing. This scoping phase ensures nothing falls through the cracks.

Document Your AWS Footprint

Start by mapping your environment. This information shapes how you approach the assessment.

Account Inventory:

How many AWS accounts are you assessing? List account IDs and their purposes.
Are accounts organized under AWS Organizations? Document the OU structure.
Which account is your management account? (It has different security considerations.)

Regional Usage:

Which AWS regions contain active resources?
Do you have resources in regions you don't expect? (This could indicate compromise.)

Key Services in Use:

Compute: EC2, Lambda, ECS, EKS?
Storage: S3, EBS, EFS?
Databases: RDS, DynamoDB, ElastiCache?
Networking: VPC, CloudFront, API Gateway?

Integration Points:

Third-party tools with AWS access
CI/CD pipelines deploying to AWS
SaaS applications with IAM roles

Essential Security Tools to Enable First

Some security tools need to run before the assessment to provide useful data. If these aren't enabled, turn them on now and schedule your assessment for when they've collected baseline data.

AWS Security Hub: Aggregates findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, and Config. Enable with the AWS Foundational Security Best Practices standard at minimum. Security Hub provides a security score and prioritized findings that make assessments dramatically faster.

aws securityhub enable-security-hub \
  --enable-default-standards \
  --region us-east-1

AWS Config: Records configuration changes and evaluates compliance against rules. Enable recording for all resource types in all regions. Without Config, you lose visibility into what changed and when.

Amazon GuardDuty: Continuous threat detection analyzing CloudTrail, VPC Flow Logs, and DNS logs. Enable in all regions. GuardDuty findings often surface issues this checklist helps you investigate.

AWS CloudTrail: Records all AWS API calls. Create an organization trail if using AWS Organizations, or at minimum a multi-region trail in each account. Log file validation must be enabled.

Multi-Account vs Single Account Scope

The assessment approach differs based on your account structure.

Single Account: Apply this checklist directly. All items are relevant.

Multi-Account with Organizations: Centralized controls (SCPs, organization trails, delegated administrators) apply at the organization level. Individual account checks still apply to each member account. Use Security Hub with cross-account aggregation to view findings centrally.

If you're managing multiple accounts, your AWS Organizations best practices configuration directly impacts security. Review organization-level controls in addition to individual account settings.

For guidance on multi-account identity management, see AWS IAM Identity Center.

Identity and Access Management Checklist (15 Items)

IAM misconfigurations cause more breaches than any other category. In security reviews I conduct, IAM issues appear in nearly every environment. One overly permissive policy can expose your entire AWS account.

This section covers root account security, IAM user and role configuration, and credential management. Start here because IAM is where the highest-risk misconfigurations live.

#	Check	Risk	Category
1	Root account has MFA enabled	CRITICAL	Root Account
2	Root account has no access keys	CRITICAL	Root Account
3	Root account not used in last 90 days	HIGH	Root Account
4	Alternate contacts configured	MEDIUM	Root Account
5	All IAM users with console access have MFA	CRITICAL	Users & Roles
6	No IAM users have administrative access	HIGH	Users & Roles
7	IAM password policy meets complexity requirements	HIGH	Users & Roles
8	No inline policies on IAM users	HIGH	Users & Roles
9	IAM Access Analyzer enabled and findings reviewed	MEDIUM	Users & Roles
10	Permissions boundaries for sensitive roles	MEDIUM	Users & Roles
11	Access keys rotated within 90 days	HIGH	Credentials
12	Unused IAM users removed (90+ days inactive)	HIGH	Credentials
13	Unused access keys disabled or deleted	HIGH	Credentials
14	IAM roles used instead of access keys	MEDIUM	Credentials
15	No credentials stored in code or env variables	MEDIUM	Credentials

Root Account Security (4 items)

The root user has unrestricted access to everything in your account. No IAM policy, no SCP, nothing can limit it. Root account compromise means complete account compromise.

[CRITICAL] Root account has MFA enabled

How to check: Console > IAM > Security recommendations, or:

  aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled'

Pass: Returns 1 (MFA enabled)
Fail: Returns 0 (MFA not enabled)
Remediation: Enable hardware MFA (YubiKey or FIDO security key) on the root account immediately. Virtual MFA is acceptable but hardware MFA is strongly preferred for root. AWS offers free MFA security keys to eligible US account owners.

[CRITICAL] Root account has no access keys

How to check: Console > IAM > Security recommendations, or check root user's security credentials
Pass: No access keys exist for root user
Fail: Access keys present (active or inactive)
Remediation: Delete root access keys immediately. There is no legitimate reason for root access keys to exist. Any workload can use IAM roles. If you "need" root keys, you're doing something wrong.

[HIGH] Root account not used in last 90 days

How to check: Console > IAM > Credential report, or:

  aws iam generate-credential-report
  aws iam get-credential-report --query 'Content' --output text | base64 -d | grep '<root_account>'

Pass: password_last_used is older than 90 days or "N/A"
Fail: Recent root usage indicates operational use of root credentials
Remediation: Stop using root for daily operations. Create IAM users or roles for all administrative tasks. Root should only be used for account recovery and specific tasks that require root (like changing support plans or closing the account).

[MEDIUM] Alternate contacts configured

How to check: Console > Account Settings > Alternate contacts
Pass: Billing, Operations, and Security contacts are configured with valid email addresses (not the root email)
Fail: Alternate contacts missing or using root email
Remediation: Configure contacts with group distribution lists (e.g., security@company.com) so AWS notifications reach the right people even when individuals leave the organization.

IAM User and Role Configuration (6 items)

Most environments rely too heavily on IAM users with long-term credentials. Roles with temporary credentials are more secure and should be the default.

[CRITICAL] All IAM users with console access have MFA enabled

How to check: Console > IAM > Users, filter by console access, or:

  aws iam list-users --query 'Users[*].UserName' --output text | xargs -I{} aws iam list-mfa-devices --user-name {}

Pass: Every user with password-enabled login has at least one MFA device
Fail: Users with console access but no MFA
Remediation: Require MFA for all console users. Use IAM policies with aws:MultiFactorAuthPresent conditions for sensitive operations. Better yet, migrate to IAM Identity Center with enforced MFA.

[HIGH] No IAM users have administrative access (use roles instead)

How to check: Console > IAM > Users, check attached policies, or:

  aws iam list-users --query 'Users[*].UserName' --output text | xargs -I{} sh -c 'echo "User: {}"; aws iam list-attached-user-policies --user-name {}'

Pass: No users have AdministratorAccess or equivalent broad policies
Fail: IAM users with admin access for daily operations
Remediation: Create IAM roles for administrative tasks. Use IAM Identity Center permission sets. Humans should assume roles, not have direct admin policies attached. This creates an audit trail and allows MFA enforcement.

[HIGH] IAM password policy meets complexity requirements

How to check: Console > IAM > Account settings, or:

  aws iam get-account-password-policy

Pass: Minimum 14 characters, requires uppercase, lowercase, numbers, symbols, password expiration within 90 days
Fail: Weak password policy or no policy configured
Remediation: Update the password policy:

  aws iam update-account-password-policy \
    --minimum-password-length 14 \
    --require-symbols \
    --require-numbers \
    --require-uppercase-characters \
    --require-lowercase-characters \
    --max-password-age 90 \
    --password-reuse-prevention 24

[HIGH] No inline policies on IAM users (use managed policies)

How to check: Console > IAM > Users > select user > Permissions tab, or:

  aws iam list-users --query 'Users[*].UserName' --output text | xargs -I{} sh -c 'echo "User: {}"; aws iam list-user-policies --user-name {}'

Pass: No inline policies; all permissions via managed policies
Fail: Users with inline policies
Remediation: Convert inline policies to customer managed policies. Managed policies are easier to audit, update, and reuse. Inline policies hide permissions and make reviews harder.

[MEDIUM] IAM Access Analyzer enabled and findings reviewed

How to check: Console > IAM > Access Analyzer, or:

  aws accessanalyzer list-analyzers

Pass: Analyzer exists and active findings have been reviewed
Fail: No analyzer configured or unreviewed findings
Remediation: Create an Access Analyzer:

  aws accessanalyzer create-analyzer --analyzer-name account-analyzer --type ACCOUNT

Review findings weekly. Access Analyzer identifies resources shared with external accounts, unused permissions, and overly broad policies.

[MEDIUM] Permissions boundaries implemented for sensitive roles

How to check: Review IAM roles used by development teams or automation
Pass: Roles that can create other roles have permission boundaries preventing privilege escalation
Fail: Roles can create new roles with any permissions
Remediation: Implement permission boundaries for delegated administration. This prevents teams from granting themselves more access than intended. See AWS documentation on permissions boundaries.

Credential Management (5 items)

Long-term credentials (access keys) are a significant attack surface. Temporary credentials through roles are always preferred.

[HIGH] Access keys rotated within 90 days

How to check: Console > IAM > Credential report, or:

  aws iam generate-credential-report
  aws iam get-credential-report --query 'Content' --output text | base64 -d

Pass: No active access keys older than 90 days
Fail: Keys older than 90 days in use
Remediation: Rotate keys following AWS guidance: create new key, update applications, verify new key works, disable old key, delete old key after grace period. Better: migrate to IAM roles and eliminate access keys entirely.

[HIGH] Unused IAM users removed (no activity in 90+ days)

How to check: Credential report password_last_used and access_key_*_last_used columns
Pass: All users show activity within 90 days
Fail: Users with no activity for 90+ days
Remediation: Disable inactive users first (allows recovery if needed), then delete after confirmation. Implement user lifecycle processes that deactivate accounts when employees leave.

[HIGH] Unused access keys disabled or deleted

How to check: Credential report access_key_*_last_used_date columns
Pass: No active keys unused for 90+ days
Fail: Active keys with no recent usage
Remediation: Deactivate unused keys:

  aws iam update-access-key --user-name USER_NAME --access-key-id ACCESS_KEY_ID --status Inactive

Delete after confirming nothing breaks.

[MEDIUM] IAM roles used instead of access keys for applications

How to check: Review applications and services for credential sources
Pass: EC2 uses instance profiles, Lambda uses execution roles, ECS uses task roles, external services use IAM Roles Anywhere
Fail: Applications using long-term access keys in config files or environment variables
Remediation: Migrate to IAM roles. For workloads outside AWS (CI/CD, on-premises), use IAM Roles Anywhere with X.509 certificates or OIDC federation.

[MEDIUM] No credentials stored in code or environment variables

How to check: Code scanning, environment variable review, Secrets Manager usage
Pass: Credentials retrieved from Secrets Manager or Parameter Store at runtime
Fail: Credentials in source code, config files, or environment variables
Remediation: Use AWS Secrets Manager for database credentials and API keys. Use Parameter Store for non-sensitive configuration. Implement CodeGuru Reviewer or git-secrets to prevent credential commits.

Network Security Checklist (12 Items)

Network security determines what can communicate with what. A single misconfigured security group can expose your database to the entire internet. These checks verify your network perimeter is properly protected.

#	Check	Risk	Category
1	Production workloads in private subnets	HIGH	VPC Config
2	VPC Flow Logs enabled for all VPCs	MEDIUM	VPC Config
3	Multiple Availability Zones used	MEDIUM	VPC Config
4	VPC endpoints configured for AWS service access	LOW	VPC Config
5	No security groups allow SSH (22) from 0.0.0.0/0	CRITICAL	Security Groups
6	No security groups allow RDP (3389) from 0.0.0.0/0	CRITICAL	Security Groups
7	Default security groups have no rules	HIGH	Security Groups
8	Security group rules documented with descriptions	MEDIUM	Security Groups
9	NACLs configured for additional subnet protection	MEDIUM	Security Groups
10	AWS WAF configured for public-facing applications	HIGH	Internet-Facing
11	CloudFront distributions use HTTPS only	MEDIUM	Internet-Facing
12	Shield Advanced considered for critical apps	LOW	Internet-Facing

VPC Configuration (4 items)

Proper VPC design creates layers of defense. Resources should be segmented by security zone with network controls between them.

[HIGH] Production workloads in private subnets

How to check: Console > VPC > Subnets, verify subnet route tables, or identify EC2 instances in subnets with internet gateway routes
Pass: Application servers, databases, and sensitive workloads have no direct internet gateway route
Fail: Production resources in subnets with 0.0.0.0/0 route to internet gateway
Remediation: Move resources to private subnets. Use NAT Gateway for outbound internet access. Use Application Load Balancer in public subnets to route traffic to private resources.

[MEDIUM] VPC Flow Logs enabled for all VPCs

How to check: Console > VPC > Your VPCs > select VPC > Flow Logs tab, or:

  aws ec2 describe-vpcs --query 'Vpcs[*].VpcId' --output text | xargs -I{} aws ec2 describe-flow-logs --filter Name=resource-id,Values={}

Pass: Every VPC has flow logs enabled
Fail: VPCs without flow logs
Remediation: Enable flow logs for each VPC:

  aws ec2 create-flow-logs --resource-type VPC --resource-ids vpc-xxxx --traffic-type ALL --log-destination-type cloud-watch-logs --log-group-name vpc-flow-logs

Flow logs are essential for security investigation and GuardDuty threat detection.

[MEDIUM] Multiple Availability Zones used

How to check: Review subnet configuration across AZs
Pass: Resources distributed across at least 2 AZs
Fail: All resources in single AZ
Remediation: Create subnets in multiple AZs. Configure Auto Scaling groups and load balancers for multi-AZ. This improves both availability and security (limits blast radius).

[LOW] VPC endpoints configured for AWS service access

How to check: Console > VPC > Endpoints
Pass: Gateway endpoints for S3 and DynamoDB; interface endpoints for commonly used services
Fail: All AWS API calls traverse internet gateway
Remediation: Create VPC endpoints for frequently accessed AWS services. This reduces internet exposure and often improves latency. Start with S3 (gateway endpoint, free) and security services like CloudTrail, Security Hub.

Security Groups and NACLs (5 items)

Security groups are your primary network firewall. Misconfigurations here are among the most common and dangerous findings.

[CRITICAL] No security groups allow SSH (22) from 0.0.0.0/0

How to check: Console > EC2 > Security Groups, filter for port 22 rules, or:

  aws ec2 describe-security-groups --filters Name=ip-permission.from-port,Values=22 Name=ip-permission.cidr,Values='0.0.0.0/0' --query 'SecurityGroups[*].[GroupId,GroupName]'

Pass: No results returned
Fail: Security groups with SSH open to internet
Remediation: Remove 0.0.0.0/0 rules for SSH. Use AWS Systems Manager Session Manager instead, which requires no open inbound ports. If SSH must be used, restrict to specific bastion host or VPN IP ranges.

[CRITICAL] No security groups allow RDP (3389) from 0.0.0.0/0

How to check: Same approach as SSH but for port 3389

  aws ec2 describe-security-groups --filters Name=ip-permission.from-port,Values=3389 Name=ip-permission.cidr,Values='0.0.0.0/0' --query 'SecurityGroups[*].[GroupId,GroupName]'

Pass: No results returned
Fail: Security groups with RDP open to internet
Remediation: Remove 0.0.0.0/0 rules for RDP. Use Session Manager for Windows instance access. If RDP is required, use a bastion host in a separate VPC with restricted access.

[HIGH] Default security groups have no inbound or outbound rules

How to check: Console > EC2 > Security Groups, filter for "default", or:

  aws ec2 describe-security-groups --filters Name=group-name,Values=default --query 'SecurityGroups[*].[VpcId,IpPermissions,IpPermissionsEgress]'

Pass: Default security groups have no rules (empty IpPermissions arrays)
Fail: Default security groups with rules (default allows all traffic within the group)
Remediation: Remove all rules from default security groups. Create purpose-specific security groups for resources. Never use default security groups for actual workloads.

[MEDIUM] Security group rules documented with descriptions

How to check: Review security group rules for Description field
Pass: All rules have meaningful descriptions explaining their purpose
Fail: Rules with empty or generic descriptions
Remediation: Add descriptions to all security group rules explaining what traffic they allow and why. This helps during audits and incident investigation.

[MEDIUM] NACLs configured for additional subnet protection

How to check: Console > VPC > Network ACLs
Pass: Custom NACLs with appropriate rules for sensitive subnets
Fail: Using only default NACL (allows all traffic)
Remediation: Create custom NACLs for database and sensitive subnets. NACLs are stateless, so both inbound and outbound rules are needed. They provide defense-in-depth beyond security groups.

Internet-Facing Resources (3 items)

Resources exposed to the internet need additional protection layers.

[HIGH] AWS WAF configured for public-facing applications

How to check: Console > WAF & Shield > Web ACLs, or:

  aws wafv2 list-web-acls --scope REGIONAL
  aws wafv2 list-web-acls --scope CLOUDFRONT

Pass: WAF associated with all public-facing ALBs, API Gateways, and CloudFront distributions
Fail: Internet-facing resources without WAF protection
Remediation: Create WAF web ACLs with AWS Managed Rules (Core Rule Set, Known Bad Inputs). Associate with all public resources. Enable rate limiting to protect against volumetric attacks.

[MEDIUM] CloudFront distributions use HTTPS only

How to check: Console > CloudFront > Distributions, check Viewer Protocol Policy
Pass: All distributions configured for "Redirect HTTP to HTTPS" or "HTTPS Only"
Fail: Distributions allowing HTTP
Remediation: Update viewer protocol policy to redirect HTTP to HTTPS. Ensure custom SSL certificates are configured if using custom domains. Enforce minimum TLS 1.2.

[LOW] Shield Advanced considered for critical applications

How to check: Console > WAF & Shield > AWS Shield
Pass: Shield Advanced enabled for business-critical applications, or documented decision to accept Shield Standard protection
Fail: No consideration of DDoS protection for critical applications
Remediation: Evaluate Shield Advanced for applications where downtime has significant business impact. Shield Standard (free) protects against common attacks. Shield Advanced adds 24/7 DDoS Response Team access and cost protection.

Data Protection Checklist (10 Items)

Encryption is your last line of defense. If other controls fail and attackers access your data, proper encryption ensures they get encrypted garbage instead of readable customer data.

#	Check	Risk	Category
1	EBS encryption enabled by default	HIGH	Encryption at Rest
2	RDS instances encrypted	HIGH	Encryption at Rest
3	S3 default encryption configured on all buckets	HIGH	Encryption at Rest
4	Customer managed KMS keys for sensitive workloads	MEDIUM	Encryption at Rest
5	S3 bucket policies require HTTPS	HIGH	Encryption in Transit
6	RDS connections use SSL/TLS	HIGH	Encryption in Transit
7	Load balancers terminate TLS with modern policies	MEDIUM	Encryption in Transit
8	S3 Block Public Access enabled at account level	CRITICAL	S3 Security
9	No buckets with public access (unless required)	HIGH	S3 Security
10	S3 versioning enabled for critical buckets	MEDIUM	S3 Security

Encryption at Rest (4 items)

All data stored in AWS should be encrypted. Since January 2023, S3 encrypts new objects by default, but other services and legacy data need verification.

[HIGH] EBS encryption enabled by default

How to check: Console > EC2 > Settings > EBS encryption, or:

  aws ec2 get-ebs-encryption-by-default

Pass: EbsEncryptionByDefault: true
Fail: EbsEncryptionByDefault: false
Remediation: Enable account-wide EBS encryption:

  aws ec2 enable-ebs-encryption-by-default

This applies to all new volumes. Existing unencrypted volumes require creating encrypted snapshots and new volumes.

[HIGH] RDS instances encrypted

How to check: Console > RDS > Databases, check Encryption column, or:

  aws rds describe-db-instances --query 'DBInstances[*].[DBInstanceIdentifier,StorageEncrypted]'

Pass: All instances show StorageEncrypted: true
Fail: Unencrypted RDS instances
Remediation: RDS encryption uses AES-256 and cannot be enabled on existing unencrypted instances. Create an encrypted snapshot, then restore to a new encrypted instance. Plan for migration and testing.

[HIGH] S3 default encryption configured on all buckets

How to check: Console > S3 > select bucket > Properties > Default encryption, or:

  aws s3api list-buckets --query 'Buckets[*].Name' --output text | xargs -I{} sh -c 'echo "Bucket: {}"; aws s3api get-bucket-encryption --bucket {} 2>&1'

Pass: All buckets have default encryption configured (SSE-S3 or SSE-KMS)
Fail: Buckets without default encryption (legacy buckets created before January 2023)
Remediation: Enable default encryption:

  aws s3api put-bucket-encryption --bucket BUCKET_NAME --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'

[MEDIUM] Customer managed KMS keys for sensitive workloads

How to check: Review KMS key usage for sensitive data stores
Pass: Sensitive data encrypted with customer managed keys (you control key policy)
Fail: Relying solely on AWS managed keys for data requiring strict access control
Remediation: Create customer managed KMS keys for sensitive workloads. This provides audit trails via CloudTrail, fine-grained access control via key policies, and cross-account sharing capabilities.

Encryption in Transit (3 items)

Data moving between systems needs protection from interception and tampering.

[HIGH] S3 bucket policies require HTTPS (aws:SecureTransport)

How to check: Review bucket policies for SecureTransport condition, or use Config rule s3-bucket-ssl-requests-only
Pass: All buckets have policies denying requests without SecureTransport
Fail: Buckets accessible over HTTP
Remediation: Add this policy to all buckets:

  {
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": ["arn:aws:s3:::BUCKET", "arn:aws:s3:::BUCKET/*"],
    "Condition": {"Bool": {"aws:SecureTransport": "false"}}
  }

[HIGH] RDS connections use SSL/TLS

How to check: Review RDS parameter groups for rds.force_ssl parameter, check application connection strings
Pass: SSL/TLS enforced at database level or all applications use SSL connections
Fail: Unencrypted database connections possible
Remediation: For PostgreSQL, set rds.force_ssl=1 in parameter group. For MySQL, set require_secure_transport=ON. Update application connection strings to use SSL and verify certificates.

[MEDIUM] Load balancers terminate TLS with modern security policies

How to check: Console > EC2 > Load Balancers > select ALB > Listeners, or:

  aws elbv2 describe-listeners --load-balancer-arn ALB_ARN --query 'Listeners[*].[Protocol,SslPolicy]'

Pass: HTTPS listeners using ELBSecurityPolicy-TLS13-1-2-2021-06 or newer
Fail: HTTP only or outdated TLS policies (TLS 1.0, 1.1)
Remediation: Update listener security policy to enforce TLS 1.2 minimum. TLS 1.3 preferred for modern applications. Remove HTTP listeners unless needed for redirect-only.

S3 Bucket Security (3 items)

S3 misconfigurations have caused some of the highest-profile cloud data breaches. These checks are critical.

[CRITICAL] S3 Block Public Access enabled at account level

How to check: Console > S3 > Block Public Access settings for this account, or:

  aws s3control get-public-access-block --account-id $(aws sts get-caller-identity --query Account --output text)

Pass: All four settings enabled (BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, RestrictPublicBuckets)
Fail: Any setting disabled
Remediation: Enable all Block Public Access settings at account level:

  aws s3control put-public-access-block --account-id ACCOUNT_ID --public-access-block-configuration "BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true"

This prevents accidental public bucket creation. For buckets that legitimately need public access, use CloudFront with Origin Access Control instead.

[HIGH] No buckets with public access (unless explicitly required)

How to check: Console > S3, check "Access" column, or use IAM Access Analyzer for S3
Pass: No buckets show "Public" or "Objects can be public" (except documented exceptions)
Fail: Buckets with public access that shouldn't be public
Remediation: Review each public bucket. Most public buckets should use CloudFront instead. If public access is required, document the business justification and ensure Block Public Access is still enabled at account level (bucket-level settings override).

[MEDIUM] S3 versioning enabled for critical buckets

How to check: Console > S3 > select bucket > Properties > Bucket Versioning
Pass: Versioning enabled for buckets containing important data
Fail: Critical data in non-versioned buckets
Remediation: Enable versioning to protect against accidental deletion and ransomware:

  aws s3api put-bucket-versioning --bucket BUCKET_NAME --versioning-configuration Status=Enabled

Consider S3 Object Lock for compliance requirements preventing even root from deleting objects.

Logging and Detection Checklist (8 Items)

Without proper logging, you can't investigate incidents or detect threats. These services form your security visibility foundation.

#	Check	Risk	Category
1	CloudTrail enabled with multi-region trail	CRITICAL	CloudTrail
2	CloudTrail log file validation enabled	HIGH	CloudTrail
3	CloudTrail logs encrypted with KMS	HIGH	CloudTrail
4	GuardDuty enabled in all regions	HIGH	Monitoring
5	Security Hub enabled with FSBP standard	HIGH	Monitoring
6	AWS Config enabled with recording in all regions	MEDIUM	Monitoring
7	CloudWatch alarms for critical security events	HIGH	Alerting
8	GuardDuty findings routed with notifications	MEDIUM	Alerting

CloudTrail Configuration (3 items)

CloudTrail records every AWS API call. It's the foundation of AWS audit trails and essential for security investigation.

[CRITICAL] CloudTrail enabled with multi-region trail

How to check: Console > CloudTrail > Trails, or:

  aws cloudtrail describe-trails --query 'trailList[*].[Name,IsMultiRegionTrail,IsOrganizationTrail]'

Pass: At least one trail with IsMultiRegionTrail: true
Fail: Single-region trails only or no trails
Remediation: Create a multi-region trail:

  aws cloudtrail create-trail --name organization-trail --s3-bucket-name cloudtrail-logs-bucket --is-multi-region-trail --enable-log-file-validation
  aws cloudtrail start-logging --name organization-trail

For AWS Organizations, create an organization trail for all accounts.

[HIGH] CloudTrail log file validation enabled

How to check: Console > CloudTrail > Trails > select trail, check Log file validation
Pass: LogFileValidationEnabled: true
Fail: Log file validation disabled
Remediation: Enable log file validation when creating trail or update existing trail. Validation uses SHA-256 digests to detect log tampering.

[HIGH] CloudTrail logs encrypted with KMS

How to check: Console > CloudTrail > Trails > select trail, check KMS key
Pass: Trail configured with KMS encryption key
Fail: Using S3-managed keys (SSE-S3) or no encryption
Remediation: Update trail to use KMS encryption. This provides additional access control through key policy and audit trail of who accessed logs.

Security Monitoring Services (3 items)

These services analyze logs and configurations to detect threats and misconfigurations automatically.

[HIGH] GuardDuty enabled in all regions

How to check: Console > GuardDuty, check each region, or:

  for region in $(aws ec2 describe-regions --query 'Regions[*].RegionName' --output text); do
    echo "Region: $region"
    aws guardduty list-detectors --region $region
  done

Pass: Detector exists in every region
Fail: GuardDuty disabled in some regions
Remediation: Enable GuardDuty in all regions. Attackers can operate in any region, and disabled regions create blind spots. Enable all protection plans (S3, EKS, Malware, RDS, Lambda).

[HIGH] Security Hub enabled with AWS Foundational Security Best Practices

How to check: Console > Security Hub > Security standards
Pass: Security Hub enabled with FSBP standard active
Fail: Security Hub disabled or no standards enabled
Remediation: Enable Security Hub with default standards:

  aws securityhub enable-security-hub --enable-default-standards

Review your security score weekly and address Critical and High findings.

[MEDIUM] AWS Config enabled with recording in all regions

How to check: Console > Config > Settings, or:

  aws configservice describe-configuration-recorder-status

Pass: Configuration recorder recording in all regions
Fail: Config not enabled or limited regions
Remediation: Enable Config with all resource types. Deploy conformance packs for automated compliance checking against CIS Benchmarks and AWS Foundational Best Practices.

Alerting and Response (2 items)

Detection without alerting is just logging. You need to know when threats are detected.

[HIGH] CloudWatch alarms for critical security events (root login, unauthorized API calls)

How to check: Console > CloudWatch > Alarms, review security-related alarms
Pass: Alarms configured for root login, IAM changes, CloudTrail configuration changes, security group changes
Fail: No security event alarms
Remediation: Create metric filters and alarms for critical events. At minimum: root account usage, IAM policy changes, CloudTrail modifications, failed console logins, security group changes. Route alerts to SNS topics monitored by your security team.

[MEDIUM] GuardDuty findings routed to Security Hub with automated notifications

How to check: Security Hub shows GuardDuty findings, EventBridge rules for findings
Pass: GuardDuty findings appear in Security Hub, high-severity findings trigger notifications
Fail: No integration or alerting for findings
Remediation: GuardDuty integrates with Security Hub automatically when both are enabled. Create EventBridge rules to route high and critical findings to SNS for immediate notification:

  {
    "source": ["aws.securityhub"],
    "detail-type": ["Security Hub Findings - Imported"],
    "detail": {"findings": {"Severity": {"Label": ["CRITICAL", "HIGH"]}}}
  }

Compute Security Checklist (10 Items)

Compute resources, including EC2 instances, Lambda functions, and containers, run your workloads. Misconfigurations here can expose your applications and data.

#	Check	Risk	Category
1	IMDSv2 required on all instances (IMDSv1 disabled)	HIGH	EC2
2	No EC2 instances with administrative IAM roles	HIGH	EC2
3	Systems Manager Session Manager used instead of SSH	MEDIUM	EC2
4	Amazon Inspector scanning enabled	MEDIUM	EC2
5	All Lambda functions using supported runtimes	HIGH	Lambda
6	Lambda functions have least privilege IAM roles	HIGH	Lambda
7	Lambda code scanning enabled in Inspector	MEDIUM	Lambda
8	ECR image scanning enabled	HIGH	Containers
9	EKS clusters using supported Kubernetes versions	HIGH	Containers
10	Container images scanned in CI/CD before deployment	MEDIUM	Containers

EC2 Instance Security (4 items)

EC2 instances require configuration beyond the defaults to be secure.

[HIGH] IMDSv2 required on all instances (IMDSv1 disabled)

How to check: Console > EC2 > Instances > select instance > Actions > Instance settings > Modify instance metadata options, or:

  aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,MetadataOptions.HttpTokens]'

Pass: All instances show HttpTokens: required
Fail: Instances with HttpTokens: optional (allows IMDSv1)
Remediation: IMDSv1 is vulnerable to SSRF attacks. Require IMDSv2:

  aws ec2 modify-instance-metadata-options --instance-id i-xxxx --http-tokens required --http-endpoint enabled

Set account-wide default for new instances via EC2 settings.

[HIGH] No EC2 instances with administrative IAM roles

How to check: Review instance profiles for attached policies

  aws ec2 describe-instances --query 'Reservations[*].Instances[*].[InstanceId,IamInstanceProfile.Arn]' --output text | grep -v None

Then check each role for admin policies.

Pass: No instance roles have AdministratorAccess or equivalent
Fail: Instances with admin IAM roles
Remediation: Replace admin policies with specific permissions needed for the workload. Use IAM Access Analyzer to generate least-privilege policies based on actual usage.

[MEDIUM] Systems Manager Session Manager used instead of SSH keys

How to check: Review how teams access instances, check for SSH key pairs in use
Pass: Session Manager is primary access method, SSH keys eliminated or minimized
Fail: SSH keys distributed to team members for instance access
Remediation: Configure Session Manager for instance access. Install SSM Agent (pre-installed on Amazon Linux 2+). Create IAM policies allowing ssm:StartSession. Session Manager provides audit logging and eliminates exposed SSH ports.

[MEDIUM] Amazon Inspector scanning enabled

How to check: Console > Inspector > Account management
Pass: Inspector enabled for EC2, ECR, and Lambda scanning
Fail: Inspector not enabled or scanning disabled
Remediation: Enable Inspector for continuous vulnerability scanning. Inspector scans for OS vulnerabilities, application dependencies, and network exposure. Integrates with Security Hub for centralized findings.

Lambda Function Security (3 items)

Lambda functions have unique security considerations around runtime versions and IAM permissions.

[HIGH] All functions using supported runtimes

How to check: Console > Lambda > Functions, check Runtime column, or:

  aws lambda list-functions --query 'Functions[*].[FunctionName,Runtime]'

Pass: All functions use runtimes in standard support (not deprecated)
Fail: Functions using deprecated runtimes (Python 3.7, Node.js 14, etc.)
Remediation: Upgrade functions to supported runtimes. Deprecated runtimes receive no security patches. Review AWS Lambda runtime support policy for current deprecation schedule.

[HIGH] Lambda functions have least privilege IAM roles

How to check: Review Lambda execution role policies for each function
Pass: Functions have specific permissions for their needs (e.g., specific DynamoDB tables, specific S3 buckets)
Fail: Functions with * resources or broad service permissions
Remediation: Refine IAM policies to specific resources. Use IAM Access Analyzer to identify unused permissions. Common mistake: dynamodb:* when function only needs GetItem on one table.

[MEDIUM] Lambda code scanning enabled in Inspector

How to check: Console > Inspector > Account management > Lambda scanning
Pass: Lambda standard scanning and Lambda code scanning enabled
Fail: Code scanning not enabled
Remediation: Enable Lambda code scanning to identify vulnerabilities in custom code, not just dependencies. This catches security issues in your application logic.

Container Security (3 items)

Container environments add layers that each need security attention.

[HIGH] ECR image scanning enabled

How to check: Console > ECR > Repositories > select repo > Scan on push
Pass: Scan on push enabled, or Inspector scanning configured for ECR
Fail: No image scanning
Remediation: Enable scan on push for all repositories. Better: enable Inspector enhanced scanning which rescans as new CVEs are published, not just at push time.

[HIGH] EKS clusters using supported Kubernetes versions

How to check: Console > EKS > Clusters, check Kubernetes version
Pass: All clusters on supported versions (check Amazon EKS Kubernetes versions)
Fail: Clusters on deprecated versions
Remediation: Plan cluster upgrades to supported versions. Deprecated versions don't receive security patches. EKS supports versions for approximately 14 months after release.

[MEDIUM] Container images scanned in CI/CD before deployment

How to check: Review CI/CD pipeline configuration
Pass: Pipeline fails on critical vulnerabilities before images reach production
Fail: Images deployed without scanning or without failing on findings
Remediation: Integrate Inspector or ECR scanning into CI/CD. Set thresholds to fail builds on critical vulnerabilities. This shifts security left and catches issues before production.

Prioritizing Your Findings

You've run through the checklist and found issues. Now what? Not everything needs fixing immediately. Risk-based prioritization ensures you address the most dangerous issues first.

The framework below helps you decide what to fix now versus what can wait. This is based on actual risk, not just the severity label I've assigned.

Risk-Based Prioritization Framework

When evaluating each finding, consider four factors:

Severity: How bad is the potential impact if this is exploited? Root account without MFA is severe because it enables complete account takeover. An unused security group is less severe because it's not currently attached to anything.

Exploitability: How easy is this to exploit? A security group allowing SSH from 0.0.0.0/0 is trivially exploitable. An overly permissive IAM policy requires an attacker to already have some access.

Exposure: Is this resource publicly accessible? A misconfigured public S3 bucket is more urgent than a misconfigured internal S3 bucket.

Compliance Impact: Will this fail an audit? If you have SOC 2 certification to maintain, compliance-related findings have business urgency beyond pure security risk.

Critical Items (Fix Immediately)

These findings represent active security risks. Drop everything and fix these today.

Root account without MFA: One password away from complete account compromise
Security groups with 0.0.0.0/0 for SSH (22) or RDP (3389): Brute force attacks begin within minutes of exposure
Publicly accessible S3 buckets with sensitive data: Data breaches happen from exactly this misconfiguration
CloudTrail disabled or single-region only: You can't investigate what you can't see
IAM access keys for root user: Should never exist

High Priority (Fix Within 30 Days)

Significant exposure that increases attack surface or violates critical best practices.

Unencrypted RDS databases or EBS volumes: Data at rest without protection
IAM users without MFA: Credential compromise risk
Access keys not rotated in 90+ days: Increased window of exposure if compromised
GuardDuty not enabled in all regions: Detection blind spots
Default security groups in use: Overly permissive default rules
Unsupported Lambda runtimes: No security patches available

Medium and Low Priority Items

These improve your security posture but don't represent immediate exploitable risk.

VPC endpoints not configured: Defense-in-depth enhancement
Security group rules without descriptions: Documentation improvement
S3 versioning not enabled: Data protection enhancement
Shield Advanced not evaluated: DDoS protection consideration

Resource Constraints Guidance

If you're a small team with limited time, focus exclusively on Critical items first. A single engineer can address critical findings across one account in 2-4 hours.

For larger teams, parallelize: one person on IAM, one on network, one on data protection. Use Security Hub findings to track progress and verify remediation.

Compliance-Specific Items

If you're working toward specific compliance certifications, certain checklist items map directly to compliance requirements. This section helps you prioritize based on your compliance needs.

SOC 2 Alignment

SOC 2 Trust Service Criteria focus on security, availability, processing integrity, confidentiality, and privacy. Key checklist items for SOC 2:

Security: IAM MFA, access key rotation, CloudTrail logging, encryption at rest and in transit
Availability: Multi-AZ deployments, backup configurations
Confidentiality: S3 Block Public Access, KMS encryption, security group restrictions

AWS Audit Manager provides pre-built frameworks for SOC 2 with 15 automated and 46 manual controls. For complete guidance on preparing for SOC 2 audits including evidence collection strategies and common failure patterns, see our AWS SOC 2 compliance guide. Access SOC reports via AWS Artifact to verify AWS's compliance with their portion of shared responsibility.

HIPAA Considerations

If handling Protected Health Information (PHI), additional requirements apply:

Business Associate Agreement (BAA): Must be in place with AWS before processing PHI
HIPAA-eligible services only: Not all AWS services are covered. Use only services listed in AWS HIPAA eligible services
Encryption requirements: PHI must be encrypted at rest and in transit
Access logging: Comprehensive audit trails for all PHI access

AWS Audit Manager includes HIPAA frameworks with automated evidence collection.

PCI DSS Requirements

For payment card data processing:

Network segmentation: Cardholder data environment must be isolated
Encryption: TLS 1.2+ for transmission, encryption at rest for stored card data
Logging: Comprehensive audit trails with tamper protection
Access control: Strict least privilege for cardholder data access

AWS maintains PCI DSS Level 1 Service Provider certification. Access the Attestation of Compliance (AOC) via AWS Artifact.

CIS AWS Foundations Benchmark

The CIS Benchmark provides specific, actionable security recommendations. Security Hub includes the CIS AWS Foundations Benchmark standard with automated checks.

Level 1: Basic security hygiene applicable to all organizations
Level 2: Additional controls for sensitive environments

Enable the CIS standard in Security Hub for automated compliance checking:

aws securityhub batch-enable-standards --standards-subscription-requests '{"StandardsArn":"arn:aws:securityhub:::ruleset/cis-aws-foundations-benchmark/v/1.4.0"}'

When DIY Isn't Enough

I've given you the complete checklist I use for security reviews. You can absolutely run through this yourself and improve your security posture significantly. But let me be honest about when DIY approaches hit their limits.

Signs You Need Professional Help

Complex multi-account environments (10+ accounts): The checklist scales, but the effort multiplies. Aggregating findings, understanding cross-account dependencies, and coordinating remediation across teams requires experience and tooling beyond what most internal teams have.

Compliance audit preparation with tight timelines: If you need SOC 2 certification in 90 days, learning compliance requirements while implementing them is risky. Experienced practitioners know the shortcuts and pitfalls. If you're facing compliance requirements or want an expert assessment of your AWS security posture, consider a professional AWS security audit to understand your options.

Previous security incident requiring forensic analysis: Post-incident analysis requires skills most teams don't maintain. Preserving evidence, building timelines, identifying root cause, and validating remediation completeness benefit from external expertise.

Findings you don't know how to remediate: The checklist tells you what's wrong, but some remediations require architectural changes. Migrating from IAM users to IAM Identity Center, redesigning VPCs for proper segmentation, or implementing least privilege at scale are projects, not tasks.

Lack of internal security expertise: If your team is excellent at development and operations but doesn't have security specialists, external review catches what internal teams miss. Security requires different thinking patterns than building features.

When evaluating AWS security partners, use our partner selection framework with a 10-point checklist, discovery call questions, and guidance on choosing between Big 4, boutique specialists, and AWS Professional Services.

What Professional Reviews Include Beyond This Checklist

This checklist covers configuration-level security. Professional reviews go deeper:

Custom threat modeling for your architecture: Understanding how your specific application architecture creates attack surfaces that generic checklists miss.

Architecture review and recommendations: Not just "is this misconfigured" but "is this the right architecture." Sometimes the right fix is redesign, not reconfiguration.

Compliance gap analysis with remediation roadmap: Mapping your current state to compliance requirements and creating prioritized plans that account for dependencies and effort.

Penetration testing and vulnerability assessment: Actively attempting to exploit vulnerabilities to validate controls work under attack. The checklist finds misconfigurations, pen tests find exploitable vulnerabilities.

Ongoing monitoring and response setup: Moving from point-in-time assessment to continuous security operations.

Next Steps

If you've worked through this checklist and found issues you're confident remediating, that's excellent. Most organizations can handle the foundational items internally.

If you've found findings that concern you, have compliance timelines to meet, or want validation that you haven't missed something, consider a professional AWS security audit to understand your options.

For organizations that want expert assessment of their AWS security posture, I conduct comprehensive security reviews that identify misconfigurations, compliance gaps, and architectural weaknesses this checklist can't catch.

Key Takeaways

You now have the complete checklist I use for professional security reviews. Let me summarize what matters most.

Start with the critical items. Root MFA, no 0.0.0.0/0 for SSH/RDP, S3 Block Public Access at account level, CloudTrail in all regions. These prevent the misconfigurations that cause actual breaches.

Enable the detection foundation. Security Hub, GuardDuty, Config, and CloudTrail form your security visibility layer. Without them, you're flying blind.

Document findings and create a remediation roadmap. Track what you found, prioritize by risk, and schedule fixes. A finding without a remediation plan is just awareness.

Schedule regular reviews. Quarterly for stable environments. After significant infrastructure changes. Before compliance audits. After security incidents. Security posture degrades over time as new resources are created and configurations drift.

Know when to get help. DIY works for many organizations, especially for foundational security. But compliance requirements, complex environments, and post-incident analysis often benefit from experienced practitioners.

Your immediate action: Run through the critical items in the IAM and Network sections today. It takes less than an hour and addresses your highest risks. Then schedule time for the full checklist.

Have questions about specific findings or want to discuss what you discovered? Drop a comment below.

AWS Security Review Process: What Happens Step by Step

Danny Steenman — Thu, 02 Apr 2026 17:28:24 +0000

You've decided your AWS environment needs a professional security review. Maybe you've already booked a call, or maybe you're comparing providers and want to understand the AWS security review process before committing. Either way, here's exactly what happens, step by step, day by day, so there are no surprises.

Whether you call it a security review, a security audit or assessment, the goal is the same: identify what's misconfigured, what's missing, and what needs to change. Having reviewed 200+ AWS accounts, I can tell you that the same misconfigurations appear in 90% of environments. The difference between a good review and a great one is how findings are prioritized and presented so you can actually act on them.

By the end of this guide, you'll know exactly what to prepare, what happens during each phase, what you'll receive, and what your options are afterward.

Before the Review: How to Prepare

Security review preparation on your end is minimal. Most clients spend less than an hour total across the entire engagement. Here's what helps the review go smoothly.

What I Need from You (Access and Documentation)

The most common preparation mistake is granting full admin access. I don't need it and don't want it. Here's what's actually required:

Read-only IAM role: A role with the SecurityAudit AWS managed policy attached. This provides read-only access to security configurations without any ability to modify your environment. I provide a CloudFormation template to set this up in minutes.
Architecture documentation (if available): Diagrams, service maps, or even a rough sketch of how your environment is structured. Helpful but not required.
Compliance requirements: If you need to align with specific frameworks (SOC 2, HIPAA, PCI-DSS, CIS), let me know upfront so the review covers those controls. For SOC 2 specifically, see how AWS SOC 2 compliance requirements map to your controls.
Known concerns: Anything keeping you up at night. Recent incidents, areas you suspect are misconfigured, or services you've outgrown.

Who Should Be Involved

You don't need to assemble a large team. Three people typically cover it:

AWS account owner or administrator - to provision the read-only IAM role
Technical lead or CTO - for 30 minutes of architecture context during the discovery call
Compliance or security lead (if applicable) - to confirm framework alignment requirements

Total time commitment from your team: roughly 30-60 minutes across the entire engagement. The rest happens on my side.

Day 1: Discovery Call and Access Setup

Once you've set up the read-only role, the engagement kicks off with a discovery call. This is where I learn what matters most to you.

What We Cover in the Discovery Call

The discovery call runs 30-45 minutes and covers:

Your environment: How many accounts, which regions, what services you're running, and how your architecture is structured
Business context: What workloads are business-critical, what compliance obligations you have, and what triggered the review
Scope alignment: Confirming which accounts and regions to assess, and which compliance frameworks to evaluate against
Known risk areas: Any services or configurations you're already concerned about

This conversation is important because it determines focus. A startup with a single account running a SaaS application gets a different emphasis than a company with 20 accounts preparing for a SOC 2 audit. The AWS shared responsibility model defines what falls under your responsibility, and the discovery call ensures I'm reviewing the parts that matter most to your business.

Setting Up Secure Read-Only Access

If you haven't provisioned the IAM role beforehand, we handle it during this step. The role uses:

Minimal permissions: The SecurityAudit managed policy, nothing more
No write access: I cannot create, modify, or delete any resources in your environment
Trust relationship scoped: The role is only assumable from a specific external account ID

Access setup takes about 10 minutes using the CloudFormation template I provide. Once confirmed, the analysis begins, typically on the same day.

Days 1-2: The Security Analysis Process

This is the core of the engagement. The assessment combines automated scanning with manual expert review, aligned with the AWS Well-Architected Security Pillar and its seven best practice areas. For the detailed checklist behind this process, see our complete AWS security review checklist.

What I Review (The Seven Security Domains)

Every review covers these seven domains systematically:

Security Domain	What Gets Checked	Key Tools Used
Identity and Access Management	Root account security, MFA enforcement, unused credentials, overly permissive policies, access key rotation	IAM Access Analyzer, Security Hub
Network Security	VPC configuration, security groups (0.0.0.0/0 checks), NACLs, public exposure, VPC endpoints	VPC Flow Logs, Config Rules
Data Protection	Encryption at rest (SSE-S3, SSE-KMS), encryption in transit (TLS 1.2+), S3 public access blocks, KMS key management	Security Hub, S3 policies
Logging and Monitoring	CloudTrail in all regions, VPC Flow Logs, CloudWatch alarms, DNS query logging	CloudTrail, CloudWatch
Infrastructure Protection	EC2 patching, container security, Lambda function configurations, security group segmentation	Inspector, Config
Detection and Threat Monitoring	GuardDuty status, Security Hub findings, Inspector vulnerability scans, alert routing	GuardDuty, Inspector, Security Hub
Compliance Alignment	FSBP controls, CIS Benchmark checks, framework-specific requirements	Security Hub, Audit Manager

Tools and Methodology

I use a combination of native AWS security services and open-source tools:

AWS Security Hub - Centralized security scoring with automated checks against FSBP and CIS benchmarks. Security Hub aggregates findings from multiple sources and provides exposure findings with attack path analysis.
Amazon Inspector - Automated vulnerability scanning of EC2 instances, container images, and Lambda functions, including both package vulnerability and code vulnerability detection
IAM Access Analyzer - Identifies external access to your resources, unused permissions, and validates policies using automated reasoning
AWS Config - Evaluates resource compliance against managed rules and conformance packs
Amazon GuardDuty - Reviews threat detection status across CloudTrail, VPC Flow Logs, and DNS, including Extended Threat Detection for multi-stage attack identification
Prowler - Open-source CIS benchmark assessment that complements native AWS tools
Manual expert review - Architecture analysis, policy review, and business-context evaluation that automated tools cannot perform

The automated tools identify what's misconfigured. The manual review determines what actually matters for your environment and what the tools miss. That combination is the difference between running AWS Security Hub yourself and hiring someone who knows how to interpret the results.

The Deliverable: Your Security Report Walkthrough

Once the analysis is complete, everything gets compiled into a prioritized security posture assessment and report. Here's what that report contains, because "you'll receive a detailed report" tells you nothing.

How Findings Are Classified

Every finding is classified by severity, following the same model used by AWS Security Hub and Inspector:

Critical: Immediate risk to data or operations. Active exposure, public access to sensitive resources, or exploitable vulnerabilities. Fix within days.
High: Significant risk requiring prompt action. Missing MFA on privileged accounts, overly permissive IAM policies, or disabled logging. Fix within 2 weeks.
Medium: Moderate risk to address in normal development cycles. Non-optimal encryption settings, missing tags, or security group refinements. Fix within 1-3 months.
Low: Best practice improvements that strengthen your overall posture. Documentation gaps, minor configuration optimizations. Address during regular maintenance.

Each finding includes: what was found, why it matters (business impact, not just technical risk), how to fix it (specific remediation steps), and estimated effort so you can plan resources. On average, a review identifies 15-30 findings per account, with 2-5 classified as critical or high.

What the Remediation Roadmap Looks Like

The report doesn't just list problems. It organizes them into a prioritized roadmap:

Quick wins (0-30 days): Enabling MFA, removing overly permissive security group rules, enabling CloudTrail across all regions, rotating old access keys
Short-term (1-3 months): Implementing least-privilege IAM policies, deploying GuardDuty, configuring CloudWatch alarms, establishing automated backups
Long-term (3-6 months): Centralizing logging to a dedicated account, implementing automated remediation, completing compliance framework alignment

After the report is ready, I walk you through every finding on a call. You can ask questions, challenge priorities, and discuss remediation approaches. This isn't a document dump. It's a conversation about what to fix and in what order.

After the Review: Your Options

The report walkthrough call is included in every engagement. After that, you have three options. No pressure, no upsell. The report stands on its own regardless of what you choose.

Remediation Support

Option 1: Self-remediation. You take the report and fix findings using the step-by-step guidance included with each finding. Many teams handle quick wins and short-term items internally. The remediation roadmap tells you exactly what to do.

Option 2: Guided remediation. I help you implement the fixes, especially for complex changes like IAM policy refactoring, network segmentation, or multi-account security architecture. This is common for teams that want to move fast without risk of breaking production workloads.

For a broader understanding of what good security looks like, AWS security best practices covers the foundational patterns behind these remediations.

Ongoing Security Monitoring

Option 3: Continuous security partnership. Security isn't a one-time activity. For organizations that want ongoing monitoring, this includes periodic reviews (quarterly is the most common cadence), drift detection, and new-finding triage. AWS recommends a continuous monitoring approach with daily Security Hub reviews, weekly Inspector findings analysis, and quarterly Well-Architected reassessments.

The right option depends on your team's capacity and expertise. Most clients start with guided remediation for critical and high findings, then handle the rest internally.

Sample Timeline: From Booking to Deliverables

The most common question I get is "how long does this take?" Here's the typical timeline for a standard AWS security review.

Total: approximately 1 week from kickoff to deliverables for a standard single-account or small multi-account environment.

Larger environments with 10+ accounts, multiple regions, or complex architectures may take longer. Timelines vary based on organization size and scope, which is exactly why the discovery call happens first. I'll give you a specific estimate after understanding your environment.

Common Questions About the AWS Security Review Process

Ready to Start Your AWS Security Review?

Now you know exactly what the AWS security review process involves: minimal preparation on your end, a focused analysis across seven security domains, a prioritized report with clear remediation steps, and a walkthrough call to discuss every finding.

The entire process takes approximately one week. Your team's time commitment is roughly an hour total. You receive actionable findings, not vague recommendations, and you choose what happens next.

The first step is a discovery call to understand your environment and confirm scope. If you want to self-assess before booking, start with our complete AWS security review checklist. If you're still evaluating providers, here's how to choose an AWS security partner using a structured framework.

AWS Cost Optimization Checklist: The Maturity-Based Framework [2026]

Danny Steenman — Thu, 02 Apr 2026 15:21:39 +0000

You've seen the lists. "30 Ways to Reduce Your AWS Bill." "The Ultimate AWS Cost Optimization Checklist." They dump 40+ items on you and call it a day. But knowing what to optimize and knowing where to start are entirely different problems.

The real challenge is prioritization. When you're staring at a checklist with rightsizing, Savings Plans, Graviton migration, and storage class optimization all competing for attention, how do you know which delivers the biggest impact for your current situation?

This AWS cost optimization checklist takes a different approach. Instead of overwhelming you with a flat list, I've organized optimizations into four maturity levels. You identify where you are today, then work through the checklist items appropriate for your stage. Level 1 quick wins can deliver 10-20% savings in 30 days. Level 2 strategic optimizations add 20-35% with proper planning. By Level 4, you're running automated cost governance that sustains savings without constant manual effort.

Understanding AWS Cost Optimization

Before diving into specific checklist items, let's establish the framework that guides prioritization. The AWS Well-Architected Cost Optimization pillar defines five practice areas that form the foundation of any cost optimization program.

Understanding these areas helps you see how individual checklist items connect to broader capabilities. It also ensures your optimization efforts align with AWS's proven practices rather than random tactical improvements.

The Well-Architected Framework Approach

For the complete set of Cost Optimization questions (COST 1-11) as they appear in the AWS Well-Architected Tool, see the Well-Architected Review checklist.

The Cost Optimization pillar organizes practices into five interconnected areas:

Cloud Financial Management: Implementing tools and processes for clear understanding of costs, including allocation, budgeting, and forecasting
Expenditure and Usage Awareness: Monitoring and analyzing usage patterns to identify cost-saving opportunities through detailed visibility
Cost-Effective Resources: Using the right type and size of AWS resources, considering total cost of ownership including operational overhead
Managing Demand and Supply Resources: Scaling dynamically based on actual demand rather than maintaining fixed capacity
Optimizing Over Time: Continuously evaluating opportunities as AWS releases new services and features

These aren't sequential checkboxes. They're ongoing practices that mature together as your organization grows. A Level 1 team focuses heavily on the first two areas while building capability in the others. A Level 4 team operates effectively across all five.

Cost Optimization Maturity Assessment

The maturity model translates these broad practice areas into concrete organizational capabilities. Here's how the four levels map to real-world states:

Where are you today? Ask yourself these questions:

Level 1 indicators: Can you identify your top 5 spending services in 30 seconds? Do you have budget alerts configured? Have you cleaned up idle resources in the last 90 days?
Level 2 indicators: Do you have Savings Plans or Reserved Instances covering steady-state workloads? Are non-production instances scheduled to stop during off-hours? Have you acted on rightsizing recommendations?
Level 3 indicators: Have you evaluated Graviton migration? Do you understand your data transfer costs? Are your Lambda functions memory-optimized?
Level 4 indicators: Do you have Service Control Policies enforcing cost guardrails? Is cost allocation tagging enforced organization-wide? Do developers consider cost impact during design?

If you answered "no" to any Level 1 question, start there. Don't jump to Graviton migration when you haven't cleaned up your idle resources first.

AWS Cost Management Tools Foundation

Before implementing optimizations, you need visibility into your costs. These five tools form the foundation of AWS cost management. Set them up before tackling the optimization levels since you'll reference their recommendations throughout.

The good news: most of these tools are free or included with your existing support tier. The effort to set them up is minimal compared to the value they provide.

Cost Optimization Hub

Cost Optimization Hub is your central dashboard for optimization opportunities across accounts and regions. It consolidates over 15 types of recommendations including EC2 rightsizing, Graviton migration, idle resource detection, Savings Plans opportunities, and EBS volume optimization.

Key capabilities:

Quantifies and aggregates estimated savings accounting for existing discounts (RIs, Savings Plans)
Automatically groups related recommendations and deduplicates resource optimization strategies
Prioritizes recommendations by highest savings
Free to use with no additional cost

Enable Cost Optimization Hub in your management account to see organization-wide recommendations in a single view.

Cost Explorer

Cost Explorer provides visualization and analysis for AWS costs and usage over time. It's your primary tool for understanding spending patterns before taking optimization action.

Key features:

Custom reports with charts and tabular data at various levels (service, account, tag)
Cost forecasting for up to 12 months based on usage patterns
13 months of historical data for trend analysis
Rightsizing recommendations for EC2 instances
Reserved Instance and Savings Plans recommendations

Data refreshes at least once every 24 hours. Make checking Cost Explorer part of your morning routine to catch anomalies quickly.

Compute Optimizer

AWS Compute Optimizer uses machine learning to recommend optimal AWS resources based on actual usage data. It analyzes 14-32 days of utilization history (varies by resource type) and provides estimated monthly savings.

Supported resources:

Amazon EC2 instances and Auto Scaling groups
EBS volumes (gp2, gp3, io1, io2, io2 Block Express, st1, sc1)
Lambda functions (memory configuration)
RDS databases (MySQL, PostgreSQL, Aurora MySQL, Aurora PostgreSQL)
ECS on Fargate services
Idle resource detection for EC2, ASG, EBS, ECS, RDS, and NAT Gateways

Important: Compute Optimizer requires opt-in activation. Enable it now if you haven't already. You can customize rightsizing preferences including CPU/memory utilization thresholds and preferred instance types.

Trusted Advisor

Trusted Advisor offers real-time guidance across five categories: cost optimization, performance, security, fault tolerance, and service limits. For cost optimization specifically, it checks for over-provisioned resources, idle resources, unattached Elastic IPs, and S3 buckets without lifecycle policies.

Access levels:

Basic Support: 7 checks available
Business/Enterprise Support: All 50+ checks with weekly refresh

If you're on Business or Enterprise Support, leverage the full Trusted Advisor check library. The additional checks surface optimization opportunities that basic checks miss.

AWS Budgets and Cost Anomaly Detection

AWS Budgets lets you set custom budgets for costs, usage, and commitment discounts with alert notifications when exceeding or forecasted to exceed thresholds.

Key capabilities:

Monthly budgets at aggregate or granular level with daily granularity for near-real-time tracking
Alert notifications via email, SNS, Slack, or Teams
Budget actions for automated responses (apply IAM policies, SCPs, stop instances)

Cost Anomaly Detection complements Budgets by using machine learning to identify unusual spending patterns. It runs approximately 3 times per day and provides up to 10 potential root causes with approximate dollar impact per anomaly. Unlike threshold-based Budgets, Anomaly Detection catches unexpected spending patterns you might not have anticipated.

Level 1: Reactive Cost Management (Quick Wins)

Level 1 focuses on eliminating obvious waste and establishing visibility. These optimizations require minimal planning, can be implemented in 0-30 days, and typically deliver 10-20% savings with low effort.

If you haven't done these items yet, don't skip to Level 2. The savings from Level 1 often fund the time investment for more strategic optimizations, and the visibility you establish here guides your Level 2 priorities.

Delete Unused and Idle Resources

Idle resources cost money without delivering value. When your AWS bill keeps growing due to forgotten resources, these deletions provide immediate relief. AWS Compute Optimizer provides specific criteria for identifying idle resources:

EC2 Instances (14-day lookback):

Peak CPU utilization 5% or less AND network I/O less than 5MB/day
Recommendation: Delete instance

EBS Volumes (32-day lookback):

Less than 1 read/write operation per day for non-root volumes OR unattached
Recommendation: Create snapshot, then delete

RDS Databases (14-day lookback):

No database connections, low CPU usage, low read/write activity
Recommendation: Stop (7-day max before auto-restart), snapshot and delete, or convert Aurora to Serverless v2

NAT Gateways:

Available state, not in route tables, no active connections
Recommendation: Verify network architecture role, then delete

Always create snapshots or backups before deleting. The cost of retaining a snapshot is far less than recreating a resource you deleted by mistake. For automation scripts to clean up unused Elastic IPs across all regions, see our dedicated guide.

EBS Volume Cleanup and Migration

EBS volumes continue charging whether attached or not. Unattached volumes are pure waste.

Quick wins:

Delete unattached volumes (same cost as attached, zero value)
Delete old snapshots beyond your retention requirements
Migrate gp2 volumes to gp3 for immediate 20% savings

The gp2 to gp3 migration is particularly compelling. gp3 costs $0.08/GiB-month compared to gp2's $0.10/GiB-month, and gp3 includes a baseline of 3,000 IOPS and 125 MiB/s throughput at no extra cost. Most workloads see better performance at lower cost with no downtime during migration.

Compute Optimizer generates recommendations for EBS volume optimization. Check the console or use AWS CLI to identify migration candidates across your accounts.

To compare costs across all EBS volume types and find the most cost-effective configuration, use our EBS Pricing Calculator with IOPS/throughput modeling.

CloudWatch Logs Retention

Here's a cost driver that most teams overlook: CloudWatch Logs default retention is indefinite. Every log ever written stays forever unless you configure retention policies.

Action items:

Review all log groups and set appropriate retention periods (1 day to 10 years based on compliance requirements)
Export old logs to S3 for cost-effective long-term storage if needed
Use S3 Lifecycle policies to transition exported logs to Glacier classes
Review logging levels and avoid DEBUG in production unless actively troubleshooting

Logs take up to 72 hours to delete after the retention period expires, so don't expect immediate savings. But preventing indefinite accumulation stops costs from growing unbounded.

For automation, see our guide on how to automate CloudWatch Logs retention with Python.

Set Up Budget Alerts

Budget alerts prevent cost surprises before they become disasters. Configure budgets for both actual spend and forecasted spend since forecast alerts give you earlier warning.

Recommended budget structure:

Account-level budget: Set at 110% of expected monthly spend. Alert at 50%, 80%, 100%, and 120% thresholds.
Service-specific budgets: For your top 3 services by spend, set individual budgets to catch service-specific anomalies.
Daily spend budget: Enable daily granularity for faster anomaly detection.

AWS Budgets also supports automated actions when thresholds are exceeded. You can automatically apply IAM policies that restrict launching new resources, giving you a safety net against runaway costs.

Enable Cost Anomaly Detection alongside Budgets. While Budgets trigger on thresholds you define, Anomaly Detection uses ML to identify unusual patterns you might not anticipate.

Activate Cost Allocation Tags

Tags are the foundation of cost allocation. Without them, you can see total spending but can't attribute costs to teams, projects, or environments.

Implement these essential tags:

Environment: production, staging, development
Project: website-redesign, mobile-app
Owner: platform-team, data-engineering
CostCenter: CC-1234, engineering-ops

Critical steps after creating tags:

Activate tags in the Billing Console for cost allocation reports (tags don't appear automatically)
Use AWS Organizations tag policies to standardize tags across accounts
Set up Cost Categories to group costs by business logic beyond simple tags
Document tagging conventions and communicate to all teams

Important: Tags are case-sensitive and aren't retroactive. Establish naming conventions before rolling out, and know that costs from before tag creation won't be categorized.

Level 2: Proactive Cost Optimization (Strategic)

With visibility established and waste eliminated, Level 2 focuses on strategic optimizations that require more planning but deliver greater savings. These items take 30-90 days to implement properly and can add 20-35% savings on top of Level 1 gains.

The key difference from Level 1: these optimizations require understanding your workload patterns before committing. Don't purchase Savings Plans until you've cleaned up idle resources and understand your baseline usage.

Proactive Cost Estimation

Here's a principle most cost optimization guides miss: preventing underutilized resources is always better than reactively optimizing or cleaning them up. If you can estimate costs before deployment, you make informed decisions while developing rather than discovering cost problems months later.

CloudBurn is a Cost Optimization CLI we developed that runs deterministic cost rules against Terraform and CloudFormation in CI, then runs those same rules against live AWS infrastrucute using it's discovery tool.

How proactive cost estimation helps:

Developers see cost implications before merging, enabling informed architecture decisions
Large cost increases trigger discussion during PR review, not after deployment
Teams build cost awareness into their development workflow naturally
Prevents the accumulation of underutilized resources that require reactive cleanup

This shift-left approach to cost management reduces the time and effort spent on optimization since you're preventing waste rather than chasing it. When every infrastructure change includes cost visibility, teams make better decisions by default.

EC2 Rightsizing Strategy

Rightsizing ensures instances are appropriately sized for workloads. AWS Compute Optimizer analyzes 14 days of utilization data and classifies instances into three categories:

Over-provisioned: Specifications can be reduced while meeting performance requirements (typically 25% cost reduction opportunity)
Under-provisioned: At least one specification doesn't meet requirements
Optimized: Current configuration appropriately matches workload needs

Each recommendation includes a Performance Risk Rating from very low to very high. Start with "very low" risk recommendations to build confidence.

Rightsizing process:

Review Compute Optimizer recommendations for your accounts
Validate by checking CloudWatch metrics for CPU, memory, and network utilization
For stateless workloads, resize during a maintenance window
For stateful workloads, create a new instance, migrate data, and decommission the old instance

Pro tip: Compute Optimizer accounts for existing Reserved Instances and Savings Plans discounts in its calculations. Recommendations reflect your actual cost impact, not theoretical On-Demand savings.

To compare pricing across instance types and find cost-effective alternatives, use our EC2 Pricing Calculator which includes smart instance recommendations based on your vCPU and memory requirements.

Savings Plans and Reserved Instances

Commitment-based pricing offers the largest discounts but requires understanding your workload patterns first. Here's how to choose:

Savings Plans offer up to 72% savings through 1 or 3-year commitments:

Plan Type	Max Discount	Flexibility
Compute Savings Plans	Up to 66%	Any instance family, size, Region, OS, or tenancy (EC2, Fargate, Lambda)
EC2 Instance Savings Plans	Up to 72%	Specific instance family in a Region, any size/OS/tenancy
Database Savings Plans	Up to 35%	RDS and Aurora across engine, instance family, size

My recommendation: Start with Compute Savings Plans covering 60-70% of your steady-state On-Demand usage. This leaves room for optimization while capturing significant savings. Increase coverage as you gain confidence in your usage patterns.

Perform pricing model analysis at the management account level using Cost Explorer recommendations to identify opportunities across all linked accounts. Savings Plans apply to usage based on highest discount percentage across accounts when purchased at the management account level.

S3 Storage Class Optimization

S3 Intelligent-Tiering automatically optimizes storage costs for data with unknown or changing access patterns. It moves objects between access tiers based on actual access patterns:

Frequent Access tier: Default, standard pricing
Infrequent Access tier (not accessed 30 days): 40% savings
Archive Instant Access tier (not accessed 90 days): 68% savings
Optional Archive Access and Deep Archive tiers: Up to 95% savings

Key advantage: No retrieval charges for Intelligent-Tiering (except optional archive tiers). A small monthly monitoring fee ($0.0025 per 1,000 objects) is the only additional cost.

For data you know will be accessed infrequently, use explicit storage classes with lifecycle policies:

Transition to Standard-IA after 30 days (minimum required)
Transition to Glacier Instant Retrieval after 90 days
Delete after 365 days if no longer needed

Use S3 Storage Class Analysis to identify access patterns before creating lifecycle policies. It generates reports showing object age and access frequency to guide data-driven decisions.

To estimate costs across different storage classes and see free tier tracking, use our S3 Pricing Calculator with cost optimization recommendations.

Lambda Function Optimization

Lambda charges based on memory allocation and execution time. The key insight: Lambda allocates CPU proportionally to memory. A function with 128 MB gets minimal CPU, while 1,769 MB gets one full vCPU. Sometimes increasing memory actually reduces costs because faster execution offsets higher memory charges.

Optimization strategies:

Use AWS Lambda Power Tuning to find optimal memory configuration
Enable ARM64/Graviton2 architecture for up to 34% better price-performance
Enable SnapStart for Java functions to reduce cold starts
Right-size timeout settings (don't set 15 minutes when 30 seconds is sufficient)
Review logging levels and avoid excessive DEBUG logs in production

Compute Optimizer provides Lambda memory recommendations based on historical performance metrics. Check recommendations before manually tuning.

For detailed cost modeling including Compute Savings Plans and Provisioned Concurrency scenarios, use our Lambda Pricing Calculator to estimate serverless costs across different configurations.

RDS and Aurora Database Optimization

Database costs add up quickly. AWS Compute Optimizer now provides rightsizing recommendations for RDS MySQL, PostgreSQL, and Aurora (both MySQL and PostgreSQL compatible editions).

Idle database criteria (14-day lookback):

No database connections
Low CPU usage
Low read/write activity

Options for idle databases:

Stop database for up to 7 days (automatically restarts after 7 days)
Create snapshot and delete instance
Convert Aurora to Aurora Serverless v2 for automatic scaling to zero

Storage optimization:

Enable storage autoscaling to prevent over-provisioning (scales when free space falls below 10%)
Migrate gp2 to gp3 storage for cost savings
Consider Database Savings Plans for predictable workloads

To compare database instance costs, storage types, and Reserved Instance savings, use our RDS Pricing Calculator for MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server or our Aurora Pricing Calculator for Aurora MySQL and PostgreSQL.

Data Transfer Cost Reduction

Data transfer costs often surprise teams, especially when they're 15-30% of the monthly bill. The biggest lever: VPC Endpoints.

VPC Endpoints eliminate NAT Gateway charges for AWS service traffic:

Gateway Endpoints (S3 and DynamoDB) are free
Interface Endpoints cost $0.01/GB processed (still cheaper than NAT Gateway at $0.045/GB)

Additional strategies:

Review and delete idle NAT Gateways (available state, not in route tables, no active connections)
Use CloudFront CDN to cache content at edge locations, reducing origin data transfer
Keep data transfer within the same Availability Zone when possible (free within AZ)

For multi-account architectures, centralize VPC Endpoints in a shared services account and share them via PrivateLink to maximize efficiency across accounts.

Level 3: Predictive Cost Engineering (Advanced)

Level 2 optimizations work within your existing architecture. Level 3 goes deeper with architectural changes that deliver 35-50% additional savings but require more effort and testing. These typically take 90+ days to implement properly.

Organizations enter Level 3 after capturing Level 1 and Level 2 wins. If you haven't optimized the basics, architectural changes won't deliver their full potential since you're optimizing on top of waste.

AWS Graviton Migration

AWS Graviton processors deliver up to 40% better price-performance compared to x86-based instances. Graviton4 offers 30% better performance than Graviton3, which itself is 60% more energy efficient than comparable EC2 instances.

Customer results are compelling: 20-45% reduction in infrastructure costs across various workloads.

Migration paths by workload type:

Containerized workloads: Build multi-architecture images and deploy to Graviton-based Fargate or EKS. Most containers work without modification.
Lambda functions: Change the architecture setting from x86_64 to arm64. Most functions work immediately.
EC2 instances: Test applications on Graviton instances in staging. Modern frameworks (Python, Node.js, Java, Go, .NET Core) typically run without changes.
Databases: RDS and Aurora offer Graviton-based instance types. Start with read replicas and non-production databases for low-risk migration.

Start with non-critical workloads, validate performance, then expand to production. Cost Optimization Hub includes Graviton migration recommendations to help identify candidates.

Spot Instance Strategy

Spot Instances offer up to 90% savings compared to On-Demand prices by utilizing spare EC2 capacity. The tradeoff: Spot Instances can be interrupted with 2-minute warning when AWS needs capacity back.

Best practices for Spot success:

Be flexible: Use multiple instance types and Availability Zones to increase capacity allocation probability
Use attribute-based instance type selection: Automatically identify instances matching specified attributes rather than hard-coding types
Implement interruption handling: Design applications to handle the 2-minute warning gracefully
Use EC2 Rebalance Recommendations: Proactively replace at-risk Spot Instances before interruption
Leverage price-capacity-optimized allocation: Automatically provision from most-available Spot pools with lowest price

Spot Instance interruption frequency varies by pool: less than 5% to over 20% depending on instance type and Availability Zone. Check Spot Instance Advisor for interruption frequency data before selecting instance types.

Ideal Spot workloads: Batch processing, CI/CD pipelines, data analysis, containerized microservices designed for horizontal scaling, and any fault-tolerant application.

Multi-Account Consolidated Billing

AWS Organizations consolidated billing aggregates usage across accounts for volume discounts and shared reservations. For organizations with multiple accounts, this delivers significant savings without additional optimization effort.

Key benefits:

Combined usage qualifies for volume discounts (S3, EC2, data transfer)
Shared Savings Plans and Reserved Instance benefits across accounts
No additional cost for consolidated billing

Discount sharing options:

Organization-wide sharing (default): Management account benefits first, then shares with all member accounts
Prioritized group sharing: Benefits account owner first, then defined groups, then other accounts
Restricted group sharing: Exclusive sharing within defined groups only

Purchase Savings Plans and Reserved Instances at the management account level for maximum flexibility across the organization. For detailed guidance on multi-account best practices including cost governance, see our dedicated guide.

Advanced Monitoring and Forecasting

Level 3 organizations move beyond reactive monitoring to predictive cost management.

Advanced capabilities:

Use Cost Explorer forecasting for 12-month projections to guide budget planning
Set up custom CloudWatch dashboards combining cost metrics with operational metrics
Implement cost-per-feature or cost-per-customer tracking
Analyze Cost and Usage Reports for granular data
Integrate cost data with business metrics to understand unit economics

Cost Explorer retains 13 months of historical data, giving you enough baseline to identify seasonal patterns and forecast accurately.

Level 4: Automated Cost Governance

Individual optimizations don't scale. Level 4 implements governance frameworks that enforce cost controls automatically across your organization, preventing waste before it occurs. This typically takes 6-12 months to mature and delivers 50%+ sustained savings.

This stage is essential for organizations with multiple teams, multiple accounts, or compliance requirements around cost management. Without automation, optimization becomes an endless manual task that teams eventually deprioritize.

IaC Cost Controls

Infrastructure as Code provides the foundation for automated cost governance. When infrastructure is defined in code, you can implement cost controls before resources exist.

Implementation strategies:

Use Terraform modules or CDK constructs with cost-optimized defaults (right-sized instance types, appropriate storage classes)
Implement pre-deployment cost estimation with CloudBurn to get automatic cost estimates in pull requests for Terraform and AWS CDK
Enforce tagging requirements in IaC templates (resources without required tags fail deployment)
Version control cost decisions alongside infrastructure
Implement CI/CD gates that require approval for changes exceeding cost thresholds

The shift-left philosophy applies to costs just like security: catch problems early when they're cheap to fix, not in production when they're expensive to remediate.

Automated Rightsizing

Manual rightsizing reviews don't scale. Level 4 organizations automate the optimization recommendations from Compute Optimizer:

Automation opportunities:

EBS volume type migrations (gp2 to gp3) via Compute Optimizer automation
Lambda memory optimization recommendations applied automatically
Scheduled scaling for predictable workloads (development environments that don't need 24/7)
Tag-based automation rules (instances tagged "environment:development" automatically stop at 8 PM)

Compute Optimizer refreshes recommendations daily. Set up automation to review new recommendations and apply low-risk changes automatically while escalating higher-risk changes for human review.

Service Control Policies for Cost

Service Control Policies provide organization-wide guardrails that even account administrators can't bypass. For AWS Organizations configuration best practices including detailed SCP guidance, see our dedicated guide.

Common cost-focused SCPs:

Region restrictions: Deny launching resources in regions you don't use
Instance type restrictions: Limit non-production accounts to cost-effective instance families
Service restrictions: Block expensive services in sandbox accounts
Tagging enforcement: Deny resource creation without required cost allocation tags

Important limitation: SCPs don't apply to the management account. Implement additional controls there via IAM policies or keep the management account limited to billing and organization management only.

AWS Budgets automated actions provide another layer. When spending exceeds thresholds, Budgets can automatically apply IAM policies that restrict specific actions like launching new EC2 instances.

Common Pitfalls and What NOT to Optimize

Most cost optimization content tells you what to do. This section covers what not to do, which matters equally. Over-optimization creates technical debt and organizational friction that costs more than the savings you capture.

Understanding these trade-offs prevents the failure modes I've seen repeatedly across organizations that pursued savings too aggressively.

The Cost vs Developer Experience Balance

Not all infrastructure costs should be minimized. Some "waste" is actually investment in developer productivity.

Protect these areas from aggressive optimization:

Development environments: Prioritize speed over cost. A developer waiting 10 minutes for an undersized instance to build costs more than the instance savings.
CI/CD pipelines: Pipeline availability matters more than instance cost. Failed builds block entire teams.
Observability tools: Don't cut monitoring that prevents incidents. The cost of an outage exceeds years of CloudWatch spending.

Establish "safe optimization zones" for your organization. Production infrastructure? Optimize carefully. Shared development tools? Leave headroom for productivity.

Calculate cost per developer alongside infrastructure cost. If cutting $500/month in development environment costs adds 2 hours of friction per developer per week across 10 developers, you've lost money.

Over-Optimization Failure Modes

I've seen these patterns repeatedly:

Spot interruptions causing production outages: Teams deploy Spot for stateful services without proper interruption handling. The 90% discount becomes irrelevant when an outage costs $100K.

Reserved Instance commitments for changing workloads: Organizations commit to 3-year Reserved Instances right before a major architecture change. Now they're paying for capacity they can't use.

Aggressive rightsizing causing performance degradation: Rightsizing to the 95th percentile of utilization leaves no headroom for traffic spikes. Users experience latency during peak periods.

Auto-scaling configured too aggressively: Scale-in policies that terminate instances too quickly cause oscillation. The constant scaling costs more than maintaining slightly higher baseline capacity.

Removing redundancy for cost savings: Single-AZ deployments save money until the AZ has an incident. Multi-AZ costs more but provides the resilience production workloads require.

When to Prioritize Speed Over Savings

Cost optimization isn't always the right priority:

Startups in growth phase: Time-to-market often matters more than infrastructure efficiency. Optimize once you've found product-market fit.
Production incidents: Don't optimize during outages. Throw resources at the problem now, optimize later.
New feature launches: Stability before cost reduction. Launch, validate, then optimize.
When developer time costs more than savings: If a week of engineering time saves $200/month, that's a 2-year payback period. Find better uses for engineering time.
Temporary workloads: Don't over-engineer short-term needs. A 3-month project doesn't need Savings Plans.

Measuring Success and ROI

Tracking the right metrics ensures your optimization efforts deliver value. Total AWS spend isn't the right metric for growing organizations since costs should grow with the business. Focus instead on efficiency metrics that reveal whether costs grow slower than business outcomes.

The metrics you track drive behavior. Choose metrics that encourage sustainable optimization rather than aggressive cost-cutting that creates technical debt.

Key Metrics Beyond Dollar Savings

Unit economics metrics:

Cost per transaction/request
Cost per customer
Cost per developer
Cost per deployment

These metrics normalize for business growth. If costs grow 20% while transactions grow 40%, you're optimizing effectively even though absolute spend increased.

Efficiency metrics:

Savings Plans/RI coverage percentage (target 70-80%)
Savings Plans/RI utilization percentage (target 95%+)
Waste ratio (idle and over-provisioned resources as percentage of total spend)
Time to remediation (how quickly teams act on optimization recommendations)

Operational metrics:

Number of idle resources over time (should trend downward)
Tagging compliance percentage
Budget alert frequency (fewer alerts = better forecasting)

Quarterly Review Cadence

Establish regular review cycles to maintain optimization momentum:

Monthly:

Review Cost Optimization Hub recommendations
Check budget status and anomaly alerts
Track unit economics trending

Quarterly:

Analyze Savings Plans and RI utilization
Review commitment purchase recommendations
Assess architecture optimization pipeline (Graviton, Spot candidates)
Update forecasts based on business plans

Annually:

Review Savings Plans/RI terms approaching renewal
Evaluate multi-year commitment strategies
Align cost optimization priorities with business priorities
Assess team ownership and accountability structure

Integrate cost reviews into existing ceremonies (sprint planning, architecture reviews) rather than creating separate meetings. Cost optimization sustains when it's part of how teams already work.

Conclusion and Next Steps

Cost optimization is a journey organized around maturity levels, not a checklist you complete once. The framework I've presented gives you a roadmap: establish visibility (Level 1), eliminate waste and make strategic commitments (Level 2), implement architectural optimizations (Level 3), and automate governance (Level 4).

Key takeaways:

Start with your current maturity level. Don't jump to Graviton migration when you haven't cleaned up idle resources.
Level 1 quick wins can deliver 10-20% savings in 30 days with minimal effort.
Level 2 strategic optimizations add 20-35% but require understanding your workload patterns first.
Balance cost reduction with developer experience and system reliability. Over-optimization creates technical debt.
Automated governance (Level 4) is how you sustain savings without constant manual effort.

Your next action based on current stage:

Level 1: Enable Cost Optimization Hub today. Set up your first budget alert. Delete one idle resource.
Level 2: Review Compute Optimizer rightsizing recommendations. Calculate your Savings Plans coverage gap.
Level 3: Identify one workload to test on Graviton. Evaluate VPC Endpoints for your highest-volume AWS service calls.
Level 4: Implement one cost-focused SCP. Add cost estimation to your CI/CD pipeline.

For organizations wanting deeper coverage of cost optimization principles and the full maturity model framework, see our comprehensive guide to AWS cost optimization best practices.

What's your current maturity level, and what's the biggest blocker to reaching the next stage? I'd like to hear about your cost optimization journey in the comments.

The AWS Cost Spiral: Why Your Bill Keeps Growing (+ Fix)

Danny Steenman — Thu, 02 Apr 2026 15:21:36 +0000

You open your AWS billing dashboard expecting a modest increase. Instead, you see a number that makes your stomach drop. Last month was $12,000. This month: $19,000. You have no idea why.

If your AWS costs keep increasing, you're in the right place. Small inefficiencies compound as teams scale, and without visibility, costs climb silently until the bill arrives.

This guide covers exactly why your AWS bill keeps growing, how to diagnose the causes in your account, a prioritized action plan to reduce spending, and how to prevent it from happening again.

As an AWS Partner who has helped organizations cut their cloud spend by 30-60%, I've seen every version of this story. Here's what actually works.

You Are Not Alone: The Reality of AWS Cost Shock

Before diving into technical fixes, let's acknowledge something: discovering a spiraling AWS bill is stressful. If your AWS bill is too high and you don't understand why, you're not alone. It creates organizational tension, triggers blame dynamics, and forces reactive decisions. Understanding why this happens to even experienced teams helps you approach the problem with clarity instead of panic.

Why AWS Bills Surprise Even Experienced Teams

"Why is my AWS bill so high?" is one of the most common questions teams ask. AWS's pay-as-you-go model means costs are inherently variable. A misconfigured Auto Scaling group, a forgotten long-running test environment, or an unexpected spike in data transfer can generate thousands of dollars in charges overnight.

The cloud's ease of provisioning also creates a "better safe than sorry" mentality. Traditional on-premises thinking, where capacity must be purchased upfront, carries directly into the cloud. Teams select oversized instances "just in case," and AWS's pay-per-use model makes every hour of that excess capacity a direct line item on the bill.

External factors add pressure too. AWS periodically adjusts pricing across services, and these changes compound on top of internal inefficiencies. When your architecture isn't optimized, even a modest price adjustment amplifies the impact.

Is Your Cost Increase Normal or an Emergency?

Not every cost increase is a crisis. Here's a simple framework to assess your situation:

10-20% month-over-month increase with corresponding business growth = normal scaling. Your costs are growing because your business is growing. Focus on optimizing efficiency, not panicking.
20-50% increase without proportional business growth = investigate within the week. Something changed in your infrastructure, and you need to find it.
50%+ sudden increase = drop everything and diagnose immediately. This likely indicates a misconfiguration, forgotten resource, or security event.

The critical question is: did your usage grow, or did your efficiency drop? A growing startup doubling revenue should expect cost increases. A stable product with flat traffic should not. This distinction determines whether you need to optimize your existing setup or simply scale smarter.

Now that you have a sense of the severity, let's examine the specific reasons AWS costs spiral, so you can identify which ones apply to your situation.

Why Your AWS Bill Keeps Growing

Most AWS cost increases trace back to six root causes. Understanding each one helps you diagnose your specific situation and prioritize fixes that deliver the biggest impact.

Over-Provisioned Resources Burning Money

This is the most common cost driver I see. Teams select larger EC2 instance types than needed, run instances 24/7 when workloads only require compute during business hours, and keep EBS volumes attached to stopped instances long after they're needed.

The root cause is a disconnect between infrastructure teams and actual business requirements. That m5.2xlarge running your staging API at 8% CPU utilization? It doesn't need 8 vCPUs and 32 GB of memory. A t3.medium would handle the workload at a fraction of the cost.

RDS databases are another common culprit. Production-grade instances running continuously even when applications see minimal off-peak traffic generate significant waste.

Zombie Resources You Forgot About

Zombie resources are assets provisioned for testing, proof-of-concepts, or temporary projects that were never decommissioned. The most common types include:

Unattached EBS volumes that remain after EC2 instance termination (they cost the same as attached volumes)
Stopped EC2 instances still incurring EBS storage charges
Unassociated Elastic IPs charged hourly when not attached to running instances
Idle RDS databases with no connections and minimal CPU activity
NAT Gateways sitting in available state with no active connections
Load Balancers with no registered targets or active connections

AWS Compute Optimizer identifies idle resources using specific thresholds: EC2 instances with peak CPU below 5% and network I/O less than 5MB/day over a 14-day period, EBS volumes with less than 1 read/write operation per day or unattached over a 32-day period. These aren't arbitrary numbers; they represent resources doing effectively nothing.

The scale can be staggering. One organization discovered 2,800 zombie assets out of 130,000 total resources. That's a significant amount of wasted spend hiding in plain sight.

Paying Full Price Without Commitment Discounts

If you've been running steady-state workloads on On-Demand pricing for more than a few months, you're leaving serious money on the table:

Compute Savings Plans: Up to 66% savings, the most flexible option. Applies to EC2, Fargate, and Lambda across any instance family, size, OS, or region.
EC2 Instance Savings Plans: Up to 72% savings, locked to a specific instance family in a chosen region.
Reserved Instances: Up to 72% for EC2 and up to 69% for RDS with 1 or 3-year terms.
Spot Instances: Up to 90% discount for fault-tolerant, stateless workloads that can handle interruptions.

Savings Plans are now the recommended approach over Reserved Instances due to their superior flexibility. They automatically apply to usage across regions and instance types without manual configuration.

Many organizations avoid commitments because they fear lock-in or lack visibility into usage patterns. The result: paying full retail for resources they'll clearly need for the next 12 months.

Hidden Data Transfer Charges

Data transfer is often the source of AWS unexpected charges. While data coming into AWS is free, nearly everything else costs money. Here's the breakdown:

Transfer Type	Cost per GB	Common Scenario
Cross-AZ	$0.01 (both directions)	Multi-AZ deployments, load balancers
Inter-Region	$0.02	Cross-region replication, disaster recovery
Internet Egress	$0.05-$0.09	API responses, file downloads
NAT Gateway Processing	$0.045 + hourly fee	Private subnet internet access

Common architectural patterns that drive unexpected data transfer costs include placing resources in different Availability Zones than their data sources, using NAT Gateways when VPC endpoints would eliminate the data processing charge entirely, and replicating large datasets across regions without lifecycle policies.

Storage That Grows Silently

Storage costs creep up because data accumulates without anyone actively managing it. Three areas are particularly problematic.

EBS snapshots are incremental, but the first snapshot captures nearly the full volume. Organizations often retain snapshots indefinitely without retention policies, or maintain daily snapshots when weekly would suffice. Meanwhile, unattached EBS volumes orphaned after instance termination continue incurring charges identical to attached volumes.

S3 objects in the Standard storage class cost more than they should when data is infrequently accessed. Without lifecycle policies, logs, archives, and old data remain in expensive tiers indefinitely. S3 Intelligent-Tiering can automatically move objects to cheaper tiers based on access patterns with no retrieval fees.

RDS backup retention defaults matter too. Setting retention to the maximum 35 days without considering actual recovery requirements doubles backup storage costs in multi-AZ deployments.

The fix is straightforward: Amazon Data Lifecycle Manager automates EBS snapshot retention, S3 Lifecycle policies transition objects to cheaper tiers (Standard-IA after 30 days, Glacier after 90), and reviewing RDS backup settings ensures you're not retaining more than you need.

No Cost Visibility or Accountability

This is often the root cause underneath every other issue. When you can't attribute spending to specific teams, projects, or applications, cost optimization becomes everyone's responsibility but nobody's priority.

Common visibility gaps include untagged resources that prevent cost allocation, missing cost anomaly detection to catch unexpected spikes, and the absence of regular cost reviews.

Teams that can't see their costs can't manage them. Visibility is the foundation that makes every other optimization possible.

Now that you understand what drives costs up, let's walk through how to diagnose which of these issues are affecting your specific AWS account.

How to Diagnose Your AWS Cost Increase

Knowing the common causes is step one. Identifying which ones apply to your account requires a structured diagnostic process. Here's the three-step approach I use.

Step 1: Check AWS Cost Explorer for Trends

Open AWS Cost Explorer and view the last 3-6 months at monthly granularity. This immediately reveals when costs started increasing and whether the trend is gradual or sudden. For longer trend analysis, enable multi-year data access for up to 38 months of historical cost data.

The Cost Comparison feature (released in 2025) is particularly useful here. It automatically detects significant cost variations between two months and identifies the underlying drivers, highlighting specific services, accounts, or regions where changes occurred.

Then switch to daily granularity for the most recent month to pinpoint specific spike dates. A single-day spike often points to a misconfiguration. A gradual daily climb suggests accumulating resources or growing usage.

Step 2: Identify the Top Cost Drivers

Now group your costs by Service to find which services are driving the increase. EC2, RDS, S3, and data transfer are the usual suspects, but the specifics vary by account.

If you're using AWS Organizations, group by Linked Account to identify which team or project is responsible. Then filter by Usage Type to distinguish between compute hours, storage gigabytes, data transfer, and API requests. Compare the current month to the previous month using the same filters to isolate exactly where the delta is.

This step transforms a vague "costs went up" into a specific "EC2 compute hours in the staging account increased 40% because three new m5.xlarge instances were launched and never terminated."

Step 3: Run AWS Compute Optimizer and Trusted Advisor

With the top cost drivers identified, run the tools that provide specific recommendations.

AWS Compute Optimizer analyzes EC2, EBS, Lambda, ECS on Fargate, RDS, Aurora, and NAT Gateways. It uses 14 days of CloudWatch metrics to recommend up to 3 alternative configurations with projected savings.

AWS Trusted Advisor scans for specific waste: low-utilization EC2 instances, underutilized EBS volumes, idle RDS instances, idle load balancers, and unassociated Elastic IPs. In 2025, it integrated 16 new checks from Cost Optimization Hub for improved accuracy. Note: full Trusted Advisor access requires Business Support or higher.

AWS Cost Optimization Hub consolidates recommendations into a single dashboard. Its Cost Efficiency metric calculates the percentage of your spend that can be optimized, refreshed daily, at no additional cost.

Now you know what's driving your costs. Let's start fixing it, beginning with the quick wins you can implement today.

Quick Wins to Reduce Your AWS Bill Today

These optimizations deliver immediate results. Most can be implemented within a day and start saving money right away.

Kill Zombie Resources Immediately

Start with the easiest savings: delete resources that serve no purpose.

Delete unattached EBS volumes. They cost the same as attached volumes for zero value.
Release unassociated Elastic IPs. Every unattached Elastic IP incurs an hourly charge. (We published a script to find and delete unused Elastic IPs across all regions that automates this.)
Terminate or snapshot-and-delete idle EC2 instances. If peak CPU is below 5% and network I/O is less than 5MB/day, it's not doing useful work.
Stop or delete idle RDS instances with no active connections.
Remove unused NAT Gateways and Load Balancers with no active connections or registered targets.

Use AWS Compute Optimizer's idle resource recommendations to find all of these systematically. The automation rules feature (introduced in 2024) can run daily, weekly, or monthly cleanup with the ability to track events and reverse actions if needed.

Schedule Non-Production Environments

Development, staging, and test environments running 24/7 waste roughly 65% of their cost. Your team works 8-10 hours a day, 5 days a week. Those environments sit idle the rest of the time.

AWS Instance Scheduler can automatically stop and start EC2 and RDS instances based on defined schedules. Configure your non-production environments to run 8am-6pm on weekdays, and you'll cut non-production compute costs by 65-75%.

Switch to Savings Plans or Reserved Instances

If you've been running steady-state workloads on On-Demand for 3+ months, this is your highest-impact commitment.

Start with Compute Savings Plans for maximum flexibility. They apply across EC2, Fargate, and Lambda, any instance family, any region. Payment options matter: All Upfront gets the highest discount, while No Upfront requires no capital but offers a lower discount. Check Cost Explorer's Savings Plans recommendations, which analyze your historical usage and suggest optimal commitment amounts.

For databases, RDS Reserved Instances save up to 69% and support instance size flexibility within the same family.

Here's my recommendation: commit to covering 70-80% of your baseline usage. This captures the majority of savings while keeping 20-30% On-Demand for flexibility.

Quick wins stop the immediate bleeding. But for lasting savings, you need to systematically optimize how your infrastructure runs.

Systematic Optimization for Long-Term Savings

These strategies require more planning but deliver sustained cost reductions that compound over time. If you're looking for a comprehensive implementation plan, our AWS cost optimization checklist provides a structured, maturity-based approach.

Right-Size Your Compute Resources

Right-sizing isn't a one-time activity. It's an ongoing process you should perform at least monthly as workloads evolve.

EC2 instances: Analyze CPU, memory, network, and disk I/O over 14-30 days. Compute Optimizer recommends up to 3 alternatives with projected savings. Consider Graviton instances (ARM-based) for up to 40% better price-performance on compatible workloads.

RDS and Aurora databases: Compute Optimizer now provides database recommendations (expanded in 2024), including idle detection and Graviton migration suggestions. For variable workloads, Aurora Serverless v2 auto-scales per Aurora Capacity Unit hour instead of fixed instance pricing.

Lambda functions: Memory allocation determines cost (memory x execution time). CPU scales proportionally with memory, so increasing memory can actually reduce cost for CPU-intensive functions by cutting execution time.

Implement Storage Lifecycle Policies

Storage costs compound month over month. Lifecycle policies automate the optimization so you don't have to think about it.

S3 Lifecycle policies automatically transition objects to cheaper tiers: Standard to Standard-IA after 30 days, to Glacier Flexible Retrieval after 90 days, to Glacier Deep Archive for long-term retention. Transition costs are minimal at $0.01 per 1,000 requests. Alternatively, S3 Intelligent-Tiering automatically moves objects between access tiers based on usage patterns with no retrieval fees.

Amazon Data Lifecycle Manager automates creation, retention, and deletion of EBS snapshots and AMIs. Set a retention policy that matches your actual recovery requirements. Similarly, review RDS backup retention settings: if they're set to the maximum 35 days but you only need 7 days of point-in-time recovery, you're paying for unnecessary backup storage.

Optimize Data Transfer Architecture

Data transfer optimizations require architectural thinking, but the payoff is ongoing.

Co-locate resources in the same Availability Zone when possible to avoid the $0.01/GB cross-AZ charge. This matters most for high-throughput connections between compute and data services.
Replace NAT Gateways with VPC Gateway Endpoints for S3 and DynamoDB access. Gateway Endpoints are free and eliminate the $0.045/GB processing charge. For other AWS services, Interface Endpoints cost less than NAT Gateway data processing.
Use Amazon CloudFront for frequently accessed content to reduce internet egress costs.
Review cross-region data replication and ensure lifecycle policies exist on replicated data.
Use VPC Flow Logs and CloudWatch to identify the largest data transfer sources before optimizing.

Optimization gets your costs under control. But the real question is: how do you make sure costs don't spiral again?

How to Prevent Future AWS Cost Spirals

Moving from reactive firefighting to proactive cost governance is the difference between a one-time cleanup and sustainable cost management. Multi-account architecture delivers 20-40% cost savings through consolidated billing, centralized Savings Plans, and automated governance. For a deeper dive into building a complete cost governance program, see our AWS cost optimization best practices guide.

Set Up AWS Budgets and Cost Anomaly Detection

AWS Budgets is your first line of defense. Set multiple alert thresholds at 80%, 90%, and 100% of your monthly budget with notifications via Amazon SNS, email, or Slack through AWS Chatbot.

But alerts alone aren't enough. Budget Actions automatically execute responses when thresholds are exceeded, like applying IAM policies to restrict new resource creation. This is your automated safety net that catches cost overruns even when nobody's watching.

AWS Cost Anomaly Detection uses machine learning to establish spending baselines and flags unusual patterns with confidence scores and root cause identification. Configure monitors for individual services, specific accounts, and cost allocation tags.

Together, Budgets catches threshold breaches with automated enforcement, while Anomaly Detection catches unexpected spending patterns that represent unusual behavior.

Implement Tagging for Cost Accountability

Without tags, you can't attribute costs to teams, projects, or environments. And what can't be measured can't be managed.

Start with these minimum recommended tags:

Environment: prod, dev, staging
CostCenter: Engineering, Marketing, Finance
Project: The project or product name
Owner: Team email or identifier
Application: The application or service name

Activate cost allocation tags in the AWS Billing and Cost Management console (management account only). Tags take up to 24 hours to appear in cost reports and only track costs from activation forward, not retroactively.

Enforce tagging through AWS Organizations Tag Policies or Service Control Policies to prevent untagged resource creation. Tags are case-sensitive (Environment and environment are different tags), so define a consistent schema and enforce it with AWS Config Rules.

For multi-account strategies, combining account-based cost allocation with resource-level tags provides both high-level visibility and granular attribution. Our AWS cloud foundation guide covers how to design this with built-in cost governance.

Build a Cost-Aware Engineering Culture

Tools and policies only work if people use them. The AWS Well-Architected Framework recommends establishing a dedicated cost optimization function and creating a partnership between finance and technology teams.

Here's what that looks like in practice:

Establish regular cost reviews: Weekly quick checks on anomalies, monthly deep dives into trends, quarterly strategic reviews of commitment coverage and architectural efficiency.
Integrate cost into architectural decisions: Teams should understand cost implications before provisioning, not after the bill arrives.
Stay current with AWS releases: Newer instance generations and services often provide better price-performance. Graviton instances, for example, deliver up to 40% better price-performance for many workloads.
Celebrate optimization wins: Quantify savings in business terms, freed budget for innovation, improved margins, faster product delivery.
Track progress with the Cost Optimization Hub Cost Efficiency metric: This calculates the percentage of your cloud spend that can be optimized, refreshed daily, so you can measure whether the organization is getting more or less efficient over time.

Cost optimization is everyone's responsibility. For practical guidance on embedding this into your AWS account best practices including cost management fundamentals, start with foundational account hygiene and build from there.

Take Control of Your AWS Costs

AWS cost increases come from two sources: external price changes and internal inefficiencies. The path forward is clear:

Start with quick wins: Delete idle resources, schedule non-production environments, and commit to Savings Plans for steady-state workloads.
Build for the long term: Right-size continuously, implement lifecycle policies, and optimize data transfer architecture.
Prevent recurrence: Set up Budgets with automated actions, enable Cost Anomaly Detection, enforce tagging, and build a cost-aware engineering culture.

Your next step: Open AWS Cost Explorer right now and run a month-over-month comparison using the Cost Comparison feature. In 5 minutes, you'll know exactly where your money is going.

You're not alone in dealing with AWS cost shock. With the right approach, it's a solvable problem, and the savings are often much larger than expected.

Outgrowing Your Single AWS Account? The Migration Roadmap

Danny Steenman — Thu, 02 Apr 2026 15:21:09 +0000

Your single AWS account started simple. One team, a few workloads, everything manageable. But now you have production and development colliding, IAM policies that look like spaghetti, and a nagging feeling that one misconfiguration could take everything down.

If that sounds familiar, you're not alone. The AWS single account to multi-account migration is the most common architectural shift I see organizations make once they outgrow their initial setup. AWS itself identifies account-level workload separation as a foundational security best practice (SEC01-BP01), and for good reason.

This guide will help you determine if you've outgrown your single account, understand what multi-account architecture looks like, follow a phased migration roadmap, and avoid the most common pitfalls that derail transitions. Unlike AWS documentation that assumes you've already decided to migrate, I'll start at the beginning: do you actually need to make this move?

Signs You Have Outgrown Your Single AWS Account

Before committing to a migration, you need an honest assessment. Not every organization needs multi-account architecture today, but most will eventually. Here's how to tell if you've reached that point.

The 5 Warning Signs

1. Security incidents have no containment boundaries. In a single-account environment, there are no hard security boundaries between workloads. A misconfiguration or breach in one application can impact everything else in the account. If your production database shares an account with your development sandbox, a compromised dev credential can potentially reach production data.

2. Cost allocation is guesswork. You can't tell your CEO which team, project, or environment is responsible for that cost spike last month. Tracking costs within a single account requires disciplined resource-level tagging across every resource, and few organizations maintain that consistently. Account-level cost separation is far simpler.

3. Compliance requirements are creating audit scope creep. Regulated data (PCI-DSS, HIPAA, SOC 2) sharing an account with general workloads means your entire account falls within audit scope. Sensitive data security requires limiting access to dedicated accounts, reducing the number of people and processes that can interact with it.

4. Service quotas are causing cross-workload contention. Your dev team's load test consumed the API rate limit your production application depends on. AWS Service Quotas and API rate limits apply at the account level. When unrelated workloads share the same account, they compete for the same quota pool.

5. IAM complexity has become unmanageable. Trying to separate teams within a single account leads to increasingly complex IAM policies that are hard to audit and easy to misconfigure. You end up with contractors and vendors who have broader access than necessary because everything lives in one boundary.

Here's a quick self-assessment. Do you recognize any of these?

Accidental production data deletion due to shared environments
Development activities impacting production workloads
Inability to differentiate costs between production and development
Contractors or vendors with broader access than necessary
Complex IAM policies attempting to separate teams within a single boundary
Service quota exhaustion affecting unrelated workloads

If you checked three or more, it's time to plan your migration.

When Multi-Account Might Not Be Necessary Yet

I want to be honest here: multi-account isn't always the answer right now. If you're a very small team (1-3 engineers), running a single workload, have no compliance requirements, and your monthly AWS spend is modest, a single account with good tagging discipline and strong IAM practices can work fine.

The key word is "yet." Most organizations hit the warning signs above within 12-18 months of serious AWS usage. So even if you're not ready today, bookmark this guide. You'll need it.

Why Multi-Account Architecture Matters

Understanding the benefits isn't just academic. You'll need these to justify the migration effort to stakeholders and to stay motivated when the work gets complex. Every benefit here directly addresses the pain points from the previous section.

Security and Blast Radius Containment

AWS accounts act as hard boundaries for identity and access management. Access between accounts must be explicitly granted, unlike IAM policies within a single account where misconfiguration can inadvertently expose resources.

The AWS Well-Architected Security Pillar (SEC01-BP01) rates account-level workload separation as a high-risk item if not implemented. Isolation of workloads in separate accounts limits the scope of impact from adverse events, preventing problems from spreading across your entire infrastructure.

In practical terms: if a production database is compromised in a multi-account setup, only that account's resources are exposed. Your other environments, logging infrastructure, and security tooling remain untouched.

Cost Visibility and Accountability

Costs are naturally tracked at the account level through consolidated billing. You get a single bill covering all member accounts at no additional cost, while maintaining individual account visibility.

Here's a detail that makes cost management significantly easier: account tags applied at the account level in AWS Organizations automatically apply to all metered usage within tagged accounts. This eliminates the need for resource-level tagging for organizational cost allocation. Combined usage also counts toward volume discounts and Savings Plans across all accounts.

Compliance and Regulatory Boundaries

Dedicated accounts for regulated data create clear audit scope, data sovereignty, and regulatory control boundaries. Instead of your entire account falling within PCI-DSS or HIPAA scope, only the specific accounts handling regulated data are in scope. That's a significant reduction in audit effort and exposure.

Operational Independence and Innovation

Service quotas and API rate limits distribute across accounts, eliminating the noisy-neighbor problems that plague single-account setups. Sandbox accounts can give developers wide-ranging access for experimentation without any risk to production. Different environments get security postures that match their needs: strict controls for production, permissive policies for development.

Dimension	Single Account	Multi-Account
Security	Soft IAM boundaries, shared blast radius	Hard account boundaries, isolated blast radius
Cost tracking	Requires resource-level tagging discipline	Automatic account-level tracking
Compliance	Entire account in audit scope	Only relevant accounts in scope
Service quotas	Shared across all workloads	Distributed per account
Innovation	Risk of impacting production	Isolated sandbox environments

Now that you understand why multi-account matters, let's look at what the target architecture actually involves.

What a Multi-Account Architecture Looks Like

Before you can migrate, you need a clear picture of where you're headed. The target state involves three layers: the organizational hierarchy (AWS Organizations), the automated setup mechanism (AWS Control Tower landing zone), and shared infrastructure services that connect everything together.

AWS Organizations and Control Tower

AWS Organizations is the management layer that groups accounts into organizational units (OUs), applies policies centrally, and enables consolidated billing. The management account sits at the top. It pays all charges, manages the organization, and should never host workloads. Use a new dedicated account as your management account, not your existing workload account. This is a critical decision I'll revisit in the pitfalls section.

AWS Control Tower automates the landing zone setup in less than one hour. It creates a Security OU with Log Archive and Audit accounts, deploys baseline controls, and provisions Account Factory for standardized account creation. Controls come in three types:

Preventive controls (SCPs) block actions before they happen
Detective controls (Config rules) identify non-compliant resources
Proactive controls (CloudFormation hooks) scan resources before deployment

For teams wanting more flexibility than Control Tower provides, Control Tower alternatives like IaC-based landing zone options exist.

Organizational Unit (OU) Structure

OU design follows a set of principles: organize by function (not org chart), apply controls to OUs (not individual accounts), keep the structure flat, and start small. Here's the recommended starting structure:

Root
├── Security OU
│   ├── Log Archive (account)
│   └── Audit (account)
├── Infrastructure OU
│   └── Networking (account) ─ Transit Gateway, DNS
├── Workloads OU
│   ├── Prod OU
│   │   ├── App1-Prod (account)
│   │   └── App2-Prod (account)
│   └── NonProd OU
│       ├── App1-Dev (account)
│       └── App2-Staging (account)
├── Sandbox OU
│   └── Developer sandboxes (accounts)
└── Transitional OU
    └── Migration staging (account)

Note the Transitional OU specifically for migration staging. Accounts live here temporarily during migration before moving to their final OU. This lets you test Service Control Policies against migrated workloads without affecting other accounts.

OUs can nest up to 5 levels deep, but resist the urge to go deep. A flat structure is easier to understand, maintain, and troubleshoot. The default account limit is 10 (easily increased to thousands), with a maximum of 5 SCPs per OU and a 5,120-character limit per SCP.

Shared Services: Networking, Identity, and Logging

Three shared service areas form the backbone of multi-account operations:

Networking. AWS Transit Gateway deployed in a centralized networking account acts as the hub for all cross-account connectivity. You share it with member accounts using AWS Resource Access Manager (RAM). Use AWS IPAM (IP Address Manager) to prevent CIDR overlaps across all VPCs from day one.

Identity. AWS IAM Identity Center (formerly AWS SSO) provides single sign-on across all accounts. It integrates with your existing identity provider (Microsoft Entra ID, Okta, etc.) and replaces per-account IAM users with temporary, federated credentials. No more long-lived access keys.

Logging and Security. CloudTrail organization trails log events for all accounts automatically and cannot be disabled by member accounts. Config aggregators collect compliance data organization-wide. GuardDuty and Security Hub, enabled from a delegated administrator account, provide centralized threat detection and security findings.

For a deeper exploration of how these components fit together as a cloud foundation, I've written a dedicated guide.

This is where you're headed. Now let's walk through the phased roadmap to get there without disrupting your existing workloads.

The 5-Phase Migration Roadmap

A phased approach is the single most important decision in this entire process. It minimizes risk, builds team confidence through early wins, and keeps your existing workloads running throughout. Here's the roadmap I recommend based on the AWS Prescriptive Guidance for transitioning to multiple accounts.

Phase 1: Assess and Plan

This phase is about building the map before starting the journey. Skip it and you'll break things during migration that you didn't know were connected.

Inventory all resources: Document every workload, application, and service in your account
Map dependencies: Identify data flows, integration points, and inter-service connections
Catalog IAM: List all users, roles, policies, and permissions
Define target architecture: Design your OU structure and decide which workloads go in which accounts
Plan migration waves: Group workloads by environment and dependency. Non-production goes first
Assess risks: Identify encrypted resources (KMS key sharing is complex), downtime tolerance, and critical dependencies

Phase 2: Establish the Foundation

This is the most important phase. Get the foundation right and workload migration becomes straightforward. Get it wrong and you'll be rebuilding it later.

Set up AWS Organizations with a new dedicated management account (not your existing workload account)
Deploy Control Tower landing zone in your home Region where the majority of workloads reside
Create the OU structure: Security OU (auto-created), Infrastructure OU, Workloads OU (Prod/NonProd), Sandbox OU, Transitional OU
Establish shared services: Transit Gateway for networking, IAM Identity Center for identity, CloudTrail organization trails for logging, GuardDuty and Security Hub for security
Implement baseline SCPs: Region restriction, CloudTrail protection, Config protection, encryption enforcement
Test SCPs in a Policy Staging OU before applying to production OUs

Phase 3: Provision Target Accounts and Networks

With the foundation in place, you create the accounts that will receive your workloads.

Use Account Factory to provision accounts with organizational standards baked in
Configure VPCs with non-overlapping CIDRs (use IPAM to prevent conflicts)
Create Transit Gateway attachments for cross-account connectivity
Set up IAM Identity Center access so teams can reach their new accounts
Deploy account baselines via CloudFormation StackSets (monitoring, patching, backup)

Phase 4: Migrate Workloads in Waves

This is where the actual migration happens. The rehost ("lift and shift") strategy is most common for single-to-multi-account moves. Start with non-production workloads because they carry the lowest risk and the highest learning value.

Service-specific migration patterns:

Resource	Migration Method
EC2 instances	Create AMI, share with destination account, launch in new account
S3 buckets	S3 Replication (SRR/CRR) + Batch Replication for existing objects
RDS databases	Create snapshot, share with destination, restore in new account
EBS volumes	Create snapshot, share, copy to destination account
Lambda functions	Redeploy using IaC in destination account
Containers (ECS/EKS)	Push images to new ECR, redeploy with updated task definitions

For encrypted resources (AMIs, snapshots, backups): share the customer-managed KMS key with the destination account and grant kms:CreateGrant, kms:Decrypt, and kms:DescribeKey permissions. This is one of the most common stumbling blocks in migration, so test it with non-production resources first.

Keep source account resources running during a validation period. Update DNS records, redirect traffic, run functional and performance tests, then only decommission source resources after confirming everything works.

Phase 5: Optimize and Decommission

Migration isn't done when the last workload moves. This phase turns a migrated environment into a well-operating one.

Refine OU structure based on operational experience
Deploy advanced controls beyond the mandatory guardrails
Implement Cost Categories for chargeback and showback
Train teams on multi-account operations, IAM Identity Center access, and account request processes
Decommission the original single account: move it to the Suspended OU or close it after verifying all workloads migrated successfully

Following this phased approach minimizes risk and business disruption. But there are specific mistakes that can still derail your migration if you're not prepared.

Common Pitfalls That Derail Multi-Account Migrations

I've seen organizations make these mistakes repeatedly. Every pitfall here comes from real-world experience, and every one is avoidable with proper planning.

Planning and Design Mistakes

Using your existing workload account as the management account. The management account cannot have SCPs applied to it and should never host business workloads. Create a new, dedicated account as the management account and invite your existing account as a member. This is the single most impactful design decision.

Mirroring your org chart in OUs. OUs should represent security and operational boundaries, not reporting hierarchies. Organize by function (Security, Infrastructure, Workloads) and apply controls accordingly. Two teams with identical policy requirements belong in the same OU, even if they report to different VPs.

Overly complex OU structures. You can nest OUs up to 5 levels deep, but that doesn't mean you should. Start with 2-3 levels and expand as needed. Deep hierarchies are difficult to troubleshoot when SCP evaluation produces unexpected results.

Technical Implementation Mistakes

Overlapping CIDR blocks across VPCs. You cannot route between VPCs with overlapping CIDRs, and fixing this after the fact requires re-creating VPCs. Use AWS IPAM for centralized CIDR allocation and plan non-overlapping address space from the start.

Not planning for encrypted resource migration. Encrypted AMIs, snapshots, and backups require KMS key sharing between accounts. If you don't plan for this, your first production migration attempt will fail. Document all encrypted resources during Phase 1 and test cross-account KMS key sharing in non-production.

Attaching SCPs to production without testing. SCPs can inadvertently block legitimate operations, causing production outages. Always test new or modified SCPs in a Policy Staging OU or against a small subset of accounts before broad deployment.

Forgetting to share Transit Gateway via AWS RAM. Member accounts cannot create Transit Gateway attachments if the Transit Gateway isn't shared. Share it immediately after creation to avoid blocking account provisioning.

Operational and Governance Mistakes

No rollback plan. Keep source account resources running during the validation period. Maintain parallel operation until you're confident the migrated workloads function correctly.

Not training teams on multi-account operations. Teams will struggle with cross-account access, get confused about which account to use, and default to workarounds that undermine your architecture. Document processes and provide hands-on training before completing migration.

No SCP change management process. Ad-hoc SCP changes cause unexpected permission denials that can look like service outages. Establish formal change management: test, review, approve, then deploy.

Hitting the default 10-account Organizations quota. The default limit is 10 accounts (which includes deleted and closed accounts). Request a quota increase early in the migration process. It can be raised to thousands of accounts.

How Long Does Migration Take?

This is the question every decision-maker asks, and no AWS documentation answers it. Here are realistic ranges based on the complexity of each phase.

Timeline by Organization Size

Organization Size	Workloads	Approximate Timeline	Effort Estimate
Small (1-3 teams)	Fewer than 10	4-8 weeks	40-80 hours
Medium (3-10 teams)	10-50	8-16 weeks	160-320 hours
Large (10+ teams)	50+	3-6 months	Dedicated migration team

These estimates assume your team has some AWS experience and existing IaC maturity. Manual, ClickOps-managed infrastructure adds significant time because you'll need to recreate everything programmatically. Encrypted resources, complex network architectures, and multi-region deployments push timelines toward the higher end.

The foundation (Phases 1-3) typically takes 40-60% of total effort. It's tempting to rush through it, but this is where shortcuts cost the most.

Team Roles Required

Cloud/Solutions architect: OU design, SCP strategy, target architecture decisions
Security engineer: Controls, compliance requirements, identity management
DevOps/Platform engineer: IaC, automation, Account Factory configuration, CI/CD pipelines
Network engineer: Transit Gateway, VPC design, CIDR planning, connectivity

In smaller organizations, one person often covers multiple roles. That's fine, but expect longer timelines accordingly.

Next Steps: Start Your Multi-Account Migration

You've seen the warning signs, understood the benefits, mapped the target architecture, and learned the roadmap. Here's how to move forward.

DIY Path

Start with Phase 1: inventory your current workloads, dependencies, and IAM structure. This assessment is the prerequisite for every other step and costs nothing but time. Then:

Set up AWS Organizations and deploy Control Tower
Follow the AWS Prescriptive Guidance for transitioning to multiple accounts
Reference our multi-account best practices guide for operational guidance
Review our SCP implementation guide for governance details
Explore multi-account strategy patterns to find the right architecture for your growth stage

Accelerated Path

The foundation (Organizations, Control Tower, OU design, SCPs, networking, identity, logging, security baselines) is the hardest and most important part. It's also where mistakes are most expensive to fix later.

If you want expert guidance on designing and implementing your multi-account architecture, our AWS Landing Zone service handles the entire foundation so your team can focus on what they do best: building and shipping product.

Conclusion

Migrating from a single AWS account to a multi-account architecture is not optional for growing organizations. It's a foundational best practice that the AWS Well-Architected Framework identifies as high-risk to skip. The AWS single account to multi-account migration doesn't have to be overwhelming if you approach it in phases.

Here's what to remember:

Recognize the warning signs: security gaps, cost allocation struggles, service quota contention, and IAM complexity are your signals
Multi-account is foundational: it's SEC01-BP01, not an optional optimization
Follow the 5-phase roadmap: assess, foundation, accounts, migrate, optimize. Each phase builds on the previous
Plan for common pitfalls: CIDR overlaps, encrypted resources, SCP testing, and team training
The foundation is everything: get Organizations, Control Tower, networking, and identity right, and workload migration becomes the straightforward part

Start with an inventory of your current workloads, dependencies, and IAM structure. That assessment is Phase 1, and it's the prerequisite for everything that follows.

Have questions about planning your migration? Drop them in the comments below, I'm happy to help.

AWS SOC 2 Compliance: What Auditors Actually Look For

Danny Steenman — Thu, 02 Apr 2026 15:21:06 +0000

SOC 2 auditors will ask about your AWS controls. Most teams scramble because they don't know what auditors actually test, or what evidence satisfies their requirements.

Here's the uncomfortable truth about AWS SOC 2 compliance: using AWS does NOT automatically make you compliant. AWS being SOC 2 compliant means their infrastructure is compliant, not your applications running on it. Your auditor will want to see YOUR controls, using AWS SOC reports only as evidence of infrastructure compliance.

This guide shows you exactly what to prepare. By the end, you'll know which controls are your responsibility versus AWS's, what evidence auditors expect for each Trust Service Criteria, common failure patterns to avoid, and a 90-day plan to get audit-ready.

With 185 AWS services now in scope for SOC 2 (as of the Fall 2025 reports), the toolkit is comprehensive. The challenge isn't capability. It's knowing where to focus. Let's start with what auditors actually care about.

What SOC 2 Auditors Expect from Your AWS Environment

SOC 2 auditors evaluate controls across five Trust Service Criteria, with Security being mandatory for all engagements. They want evidence, not promises. Documentation and logs that prove compliance matter far more than verbal assurances about your security posture.

AWS publishes their own SOC 2 reports quarterly, covering 185 services as of the Fall 2025 report. Your job is implementing Complementary User Entity Controls (CUECs) that AWS doesn't cover. These are the specific controls you must implement to complement AWS's infrastructure controls.

Understanding this division is the first step. Let's clarify the most common misconception before diving into the details.

The #1 Misconception: AWS Compliance vs. Your Compliance

The shared responsibility model determines everything. AWS secures "of" the cloud (physical infrastructure, hypervisor, networking). You secure "in" the cloud (IAM, data encryption, application configuration, firewall rules).

When your auditor asks about data encryption, they're asking about YOUR KMS key policies, YOUR S3 bucket configurations, YOUR encryption choices. AWS's infrastructure encryption is documented in their SOC reports, but that's a foundation you build on, not a substitute for your own controls.

This distinction matters because many teams assume "we're on AWS, so we're compliant." That assumption leads to audit failures.

How to Access AWS SOC Reports via AWS Artifact

AWS Artifact is the self-service portal for accessing compliance reports at no cost. Your auditor will expect you to have reviewed these reports to understand which controls AWS handles.

To access AWS SOC reports:

Navigate to AWS Artifact in the console (available in US East N. Virginia and GovCloud US-West)
Accept the NDA if you haven't already
Download the relevant SOC 2 report for your audit period

Required IAM permissions: Your IAM user or role needs artifact:ListReportVersions permission. The AWSArtifactReportsReadOnlyAccess managed policy includes this.

As of December 2025, AWS Artifact now provides access to previous versions of compliance reports, helpful when auditors need historical evidence.

The Shared Responsibility Model for SOC 2

Understanding which SOC 2 controls are AWS's responsibility versus yours is critical. Misunderstanding this split leads to gaps that auditors will find.

The AICPA SOC 2 Compliance Guide on AWS whitepaper (released July 2025) provides official guidance on this mapping. I recommend downloading it as a reference alongside this guide.

What AWS Handles (Security of the Cloud)

AWS manages and secures the infrastructure from the host operating system and virtualization layer down to physical security. This includes:

Physical and environmental controls of data centers
Hardware, software, networking, and facilities that run AWS services
Compute, storage, database, and networking infrastructure
AWS-managed security controls documented in their SOC reports

Your auditor will reference AWS SOC reports as evidence for these controls. You don't need to demonstrate these, just show you're aware of and relying on them appropriately.

What You Must Implement (Security in the Cloud)

You're responsible for everything built on top of AWS infrastructure:

Guest operating system (including updates and security patches)
Application software and utilities you install
Configuration of AWS-provided security groups (firewall rules)
IAM policies and access controls
Data encryption (at rest and in transit choices)
Network traffic protection

These are where auditors focus their attention. Every control discussed in this guide falls into your responsibility domain.

Complementary User Entity Controls (CUECs)

CUECs are the specific controls you implement to complement AWS's controls. The AICPA whitepaper provides detailed CUEC guidance mapped to each Trust Service Criteria.

Your auditor will specifically evaluate CUEC implementation. They're looking for evidence that you understood which controls AWS provides and consciously designed your controls to complement them, not duplicate or miss gaps.

SOC 2 Trust Service Criteria and AWS Mapping

The SOC 2 framework consists of five Trust Service Categories. Security (Common Criteria CC 1-9) is mandatory for all engagements. The other four categories are optional based on your business needs and customer commitments.

Understanding how each category maps to AWS services helps you plan both implementation and evidence collection.

Trust Service Criteria	AWS Services	Evidence Types
Security (Required)	IAM, CloudTrail, Config, Security Hub, GuardDuty	Access policies, audit logs, compliance reports
Availability	Multi-AZ, Auto Scaling, Route 53, CloudWatch	Uptime reports, incident logs, backup verification
Processing Integrity	Step Functions, EventBridge, CloudWatch Logs	Transaction logs, reconciliation reports, validation evidence
Confidentiality	KMS, S3 encryption, RDS encryption, Secrets Manager	Key policies, encryption configs, access logs
Privacy	Macie, S3 lifecycle, Data classification	Data inventory, retention policies, consent records

Security (Common Criteria)

Security is mandatory for all SOC 2 engagements. It covers access control, system operations, change management, and risk mitigation. These are the controls auditors spend the most time examining.

What auditors look for:

IAM policies demonstrating least privilege
CloudTrail logs showing all API activity
Evidence of regular access reviews
MFA enforcement for privileged accounts
Change management procedures with approval workflows

Availability

If you've committed to uptime SLAs with customers, you'll include Availability criteria. This covers system accessibility for operation and use as committed.

What auditors look for:

Multi-AZ deployment evidence
Auto Scaling configurations
CloudWatch monitoring and alerting
Incident response documentation
Backup and recovery test results

Processing Integrity (The Gap AWS Doesn't Cover)

This is critical: AWS explicitly does NOT include Processing Integrity in their SOC 2 scope. You are fully responsible for proving that system processing is complete, valid, accurate, and timely.

No AWS service automatically provides Processing Integrity compliance. You must design and document:

Input validation procedures
Transaction logging and audit trails
Data reconciliation processes
Error handling and correction procedures

AWS services that help (even without explicit coverage): Step Functions for workflow orchestration, EventBridge for event tracking, CloudWatch Logs for processing evidence.

Confidentiality

Confidentiality protects information designated as confidential. If you handle customer data with confidentiality requirements, you'll include this category.

What auditors look for:

KMS key policies with least privilege
S3 bucket encryption configurations
RDS encryption enabled
Secrets Manager for credential storage
Evidence of data classification

Privacy

Privacy addresses personal information handling per your privacy notice. This often overlaps with GDPR or CCPA requirements. If you collect personal data from end users, you likely need this category.

What auditors look for:

Data inventory and classification
Retention policies and enforcement
Consent mechanisms
Data access logs
Deletion procedures

Required AWS Security Controls

Now let's get specific about what you need to implement. Each control section includes what auditors expect to see and the evidence you should collect.

For implementation details on these controls, see our AWS security best practices guide which covers the configurations in depth.

Identity and Access Management (IAM)

IAM misconfigurations cause more audit findings than any other category. Auditors scrutinize access controls closely because they're fundamental to every other Trust Service Criteria.

Required controls:

Least privilege - Grant minimum permissions needed. Use IAM Access Analyzer to generate policies based on actual CloudTrail activity.
No root user operations - Eliminate day-to-day root usage. Enable hardware MFA. Never create access keys for root.
MFA enforcement - Required for all privileged accounts and console access.
Temporary credentials - Use IAM roles instead of long-term access keys wherever possible.
Regular access reviews - Remove unused permissions, users, and roles. Document review cadence.
Conditions in policies - Use conditions like PrincipalOrgID and CalledVia to scope access appropriately.

What auditors look for: IAM Credential Reports showing MFA enabled, CloudTrail logs demonstrating no root activity, sample IAM policies showing least privilege implementation, documentation of access review procedures.

Logging and Monitoring

Without comprehensive logging, you can't prove what happened or didn't happen in your environment. Auditors will verify logging is enabled, protected, and retained appropriately.

Required controls:

CloudTrail multi-region trail - Create a trail that captures events in ALL regions. Single-region trails leave blind spots. Follow CloudTrail security best practices.
Log file validation enabled - This provides integrity checking. Without it, you can't prove logs weren't tampered with.
Log encryption with KMS - Encrypt CloudTrail logs using AWS KMS.
Protected S3 bucket - Enable MFA delete, object lock, and strict access controls on your log bucket.
CloudWatch integration - Integrate CloudTrail with CloudWatch Logs for real-time alerting on security events.
Appropriate retention - Minimum 1 year recommended. Note that CloudTrail console history only shows 90 days.

What auditors look for: Trail configuration showing multi-region enabled, validation status, encryption key ARN, S3 bucket policy restricting access, sample CloudWatch alarms for security events.

Data Protection and Encryption

Encryption at rest and in transit protects data even if other controls fail. Auditors want to see encryption enabled by default with proper key management.

Required controls:

Encryption at rest - Enable default encryption for EBS, S3, RDS using AWS KMS. KMS keys are protected by FIPS 140-3 Level 3 validated HSMs.
Encryption in transit - TLS 1.2+ for all connections. Use AWS Certificate Manager for certificate management.
Customer-managed KMS keys - For fine-grained control and audit trails. Enable automatic key rotation.
Least privilege key policies - Keys should only be accessible by services and users that need them.
Separate keys for different data - Use different keys for different data classifications.

What auditors look for: KMS key policies demonstrating least privilege, encryption configuration screenshots for S3/EBS/RDS, TLS certificate evidence, CloudTrail events showing key usage.

Threat Detection and Response

Detection capabilities demonstrate security maturity. Auditors want to see that you can identify and respond to threats, not just prevent them.

Required controls:

GuardDuty enabled - Enable in all regions. GuardDuty continuously monitors for malicious activity using machine learning and threat intelligence.
Security Hub aggregation - Aggregates findings from GuardDuty, Inspector, Macie, and Config. Provides security posture dashboard.
Amazon Inspector - Vulnerability scanning for EC2, Lambda, and container images. Continuous scanning without standalone agents.
Documented incident response plan - IR plan with AWS-specific runbooks, tested regularly.
Automated response - EventBridge rules to trigger containment actions for critical findings.

What auditors look for: GuardDuty enabled confirmation across accounts/regions, Security Hub dashboard showing compliance scores, IR plan documentation, evidence of IR testing.

Network Security

Network controls determine what can communicate with what. Misconfigured security groups are a leading cause of breaches and audit findings.

Required controls:

VPC isolation - Workloads in dedicated VPCs with proper subnet segmentation (public, private, isolated).
Security group best practices - Stateful firewall rules. Avoid 0.0.0.0/0 on sensitive ports. Create purpose-specific groups.
Network ACLs - Stateless subnet-level protection as additional defense layer.
VPC Flow Logs enabled - Required for network traffic monitoring and forensic capability.
WAF protection - Protect web applications from common exploits using managed rule sets.

What auditors look for: Security group configurations showing restricted access, VPC architecture diagrams, Flow Log configuration evidence, WAF rules documentation.

Multi-Account Governance

For organizations using multiple AWS accounts (recommended), governance controls ensure consistent security across the environment. See AWS multi-account best practices for detailed implementation guidance.

Required controls:

AWS Organizations - Centralized management with OU hierarchy.
Service Control Policies (SCPs) - Define maximum available permissions at organization, OU, or account level. See AWS Organizations best practices for SCP patterns.
Control Tower - Automated landing zone with preventive and detective guardrails.
Centralized logging - Aggregate CloudTrail, Config, and Security Hub findings across all accounts to a dedicated log archive account.

What auditors look for: Organizational structure documentation, SCP examples showing guardrails, centralized logging architecture, Control Tower dashboard.

Evidence Collection Strategy

Knowing what controls you need is step one. Proving them to auditors requires systematic evidence collection. This is where many organizations struggle because they implement controls but don't collect evidence proving they work.

AWS Audit Manager automates much of this process. The prebuilt SOC 2 framework includes 15 automated controls and 46 manual controls across 20 control sets. Understanding what evidence you need helps you configure Audit Manager effectively.

Control Category	Evidence Type	Collection Method	Frequency
IAM	Credential reports, policy documents	API calls, manual upload	Weekly/Monthly
Logging	Trail configs, sample logs	CloudTrail, API calls	Continuous
Encryption	Key policies, encryption configs	Config rules, API calls	Event-driven
Network	Security group rules, Flow Logs	Config rules, API calls	Event-driven
Threat Detection	GuardDuty findings, Security Hub scores	Security Hub integration	Scheduled
Incident Response	IR plans, test results	Manual upload	Quarterly

AWS Audit Manager for SOC 2

AWS Audit Manager provides a prebuilt SSAE-18 SOC 2 framework. The framework includes 20 control sets aligned to SOC 2 requirements.

Setting up Audit Manager for SOC 2:

Enable Security Hub with all standards enabled (prerequisite)
Enable necessary AWS Config rules
Create assessment using the SOC 2 framework
Configure evidence sources for automated collection
Set up manual evidence upload procedures for non-AWS controls

Important clarification: Audit Manager controls don't verify compliance or guarantee you'll pass an audit. They organize evidence collection. You still need to ensure your controls are properly implemented and operating effectively.

Evidence collection should begin 3-6 months before your audit to demonstrate controls operating over time. SOC 2 Type 2 audits examine operating effectiveness over a period (typically 6-12 months), not just point-in-time design.

Evidence Types and Data Sources

AWS Audit Manager collects evidence from four data source types:

User activity (CloudTrail) - Continuous API call tracking. Select specific event names for targeted evidence.
Compliance checks (AWS Config) - Event-driven based on Config rule triggers. Shows resource compliance status.
Security findings (Security Hub) - Scheduled per Security Hub check schedule. Aggregated security posture.
Configuration data (API calls) - Snapshots at daily, weekly, or monthly frequency. Point-in-time resource state.

Manual evidence is still required for:

Physical security documentation (if applicable)
Vendor risk assessments
Policy documents and procedures
Training records
Evidence from non-AWS systems

You can import manual evidence from S3, upload from browser, or enter as text directly in Audit Manager.

Automating Evidence Collection with AWS Config

AWS Config conformance packs bundle multiple Config rules for deployment. AWS provides an "Operational Best Practices for SOC 2" conformance pack template. For a broader look at how conformance packs fit into AWS operational best practices, see our operations guide.

Benefits of conformance packs:

Deploy standard rule sets across accounts and regions
Compliance score showing percentage of compliant rule-resource combinations
Automated remediation with Systems Manager Automation
Configuration aggregators for multi-account visibility

Deploy the SOC 2 conformance pack in all accounts within your audit scope. Configure automated remediation where appropriate, but test remediation actions in non-production first.

5 Common SOC 2 Failures on AWS (And How to Avoid Them)

Learning from others' failures is cheaper than learning from your own. These patterns cause consistent audit findings. Most stem from basic misconfigurations that automated tools can detect.

Failure #1: Root User Misuse and Access Key Sprawl

TSC Mapping: Security (CC6.1 - Logical Access)

The failure: Using root user for daily operations. Root account without MFA. Sharing root credentials. Long-term access keys not rotated. Unused access keys accumulating.

Why auditors care: Root access is unlimited. No IAM policy or SCP can restrict it. Poor root controls indicate poor security culture overall.

The fix:

Eliminate root user for all operations (use IAM users/roles)
Enable hardware MFA on root account immediately
Replace long-term access keys with temporary credentials via IAM roles
Regular access key rotation (90 days maximum) and cleanup of unused keys

Evidence to collect: IAM Credential Report, CloudTrail logs showing no root activity over audit period, MFA device configuration for root.

Failure #2: CloudTrail Gaps and Missing Log Validation

TSC Mapping: Security (CC7.2 - System Monitoring)

The failure: CloudTrail not multi-region. Log validation disabled. Logs not encrypted. S3 bucket publicly accessible or with weak policies.

Why auditors care: Without integrity-validated logs, you can't prove what happened. Gaps in logging mean gaps in accountability.

The fix:

Create multi-region trail capturing events in ALL regions
Enable log file validation (integrity checking)
Encrypt logs with KMS
Protect S3 bucket with MFA delete and object lock
Integrate with CloudWatch for real-time alerting

Evidence to collect: Trail configuration showing multi-region enabled, validation status, encryption key ARN, bucket policy with access restrictions.

Failure #3: Unencrypted Data and Weak Key Management

TSC Mapping: Confidentiality (C1.1 - Confidential Information Protection)

The failure: Data stored unencrypted. Same encryption key for all data. Overly permissive key policies. No key rotation.

Why auditors care: Encryption without proper key management provides false security. Anyone with key access has data access.

The fix:

Enable default encryption for EBS, S3, RDS
Use customer-managed KMS keys (not AWS-managed) for control
Apply least privilege to key policies
Separate keys for different data classifications
Enable automatic key rotation

Evidence to collect: Encryption configuration for all storage services, KMS key policies showing restricted access, CloudTrail key usage events.

Failure #4: Security Group Misconfigurations

TSC Mapping: Security (CC6.6 - Logical Access Security)

The failure: Security groups allowing 0.0.0.0/0 on sensitive ports. Default security groups used without modification. Overly permissive rules for unused ports.

Why auditors care: Overly permissive network access is a leading breach vector. It indicates lack of defense-in-depth.

The fix:

Restrict inbound rules to specific CIDR ranges
Remove rules for unused ports
Never use default security groups without modification
Enable VPC Flow Logs for network monitoring
Regular security group audits (at least quarterly)

Evidence to collect: Security group configurations showing restricted access, VPC Flow Log configuration, documentation of security group review process.

Failure #5: Missing Incident Response Capabilities

TSC Mapping: Security (CC7.3 - Security Incident Management)

The failure: No documented IR plan. GuardDuty not enabled. No automated response capabilities. Team not trained on cloud IR procedures.

Why auditors care: Incidents are inevitable. Response capability demonstrates security maturity and operational readiness.

The fix:

Document incident response plan with AWS-specific runbooks
Enable GuardDuty in all accounts and regions
Configure automated containment actions via EventBridge
Train team on cloud IR procedures
Retain logs for forensic analysis (minimum 1 year)

Evidence to collect: IR plan documentation, GuardDuty enabled confirmation, EventBridge automation rules, training records.

Your 90-Day SOC 2 Readiness Plan

Ninety days is aggressive but achievable for organizations with an existing AWS presence and some security maturity. For organizations starting from scratch, plan 6-12 months instead.

Critical context: SOC 2 Type 2 audits examine controls operating over a period (typically 6-12 months). Even after implementing controls, you need evidence of them working consistently. Start evidence collection as early as possible.

Days 1-30: Assessment and Foundation

Week 1: Determine applicable Trust Service Categories. Review AWS SOC reports via Artifact to understand AWS's control coverage.

Week 2: Conduct gap analysis. Identify which CUECs need implementation. Use our security review checklist as a starting point.

Week 3: Define scope (AWS services and accounts). Establish multi-account strategy using AWS Organizations if not already in place.

Week 4: Enable foundational logging: CloudTrail (multi-region), AWS Config (all regions), VPC Flow Logs everywhere.

Deliverables: Scoping document, gap analysis report, multi-account architecture diagram.

Days 31-60: Control Implementation

Weeks 5-6: IAM hardening. Eliminate root usage. Enforce MFA everywhere. Implement least privilege policies. Set up regular access reviews.

Weeks 7-8: Encryption implementation. Deploy KMS keys for each data classification. Enable default encryption for all storage services.

Weeks 9-10: Threat detection deployment. Enable GuardDuty in all accounts and regions. Configure Security Hub with all relevant standards. Deploy Inspector for vulnerability scanning.

Weeks 11-12: Deploy AWS Config conformance packs for SOC 2. Configure automated remediation where appropriate. Set up configuration aggregators for multi-account visibility.

Deliverables: Implemented controls documentation, conformance pack deployment, Security Hub baseline scores.

Days 61-90: Evidence Collection and Pre-Audit

Week 13: Create AWS Audit Manager assessment using SOC 2 framework. Configure all evidence sources.

Weeks 14-15: Verify automated evidence collection is working. Gather manual evidence: policies, procedures, training records, vendor assessments.

Week 16: Control testing. Validate controls are operating effectively, not just designed correctly.

Weeks 17-18: Remediate any identified gaps. Finalize documentation. Prepare for auditor walkthrough.

Deliverables: Audit Manager assessment with collected evidence, complete documentation package, remediation log.

Preparing for the Audit

With controls implemented and evidence collected, you're approaching audit readiness. Understanding what happens during the audit helps you prepare the right materials and people.

SOC 2 audits come in two types:

Type 1 tests control design at a point in time
Type 2 tests operating effectiveness over a period (typically 6-12 months)

Most customers require Type 2 reports because they demonstrate controls actually work, not just that they exist on paper.

What Auditors Will Test

Auditors evaluate controls across three dimensions:

Control design - Is the control designed to meet the Trust Service Criteria requirements?
Control implementation - Is the control actually in place and configured correctly?
Operating effectiveness (Type 2 only) - Has the control been working consistently throughout the audit period?

They'll sample transactions and configurations across the audit period. Prepare walkthroughs for key controls and have subject matter experts available for questions.

Sample Audit Questions by TSC

Security questions:

"Show me your access review process. Walk me through how an employee gets access and how it's revoked."
"Demonstrate how you enforce least privilege. Show me a sample policy."
"How do you detect unauthorized access attempts?"

Availability questions:

"What's your uptime over the audit period? Show me incident tickets."
"Walk me through your backup and recovery procedures. When did you last test recovery?"

Confidentiality questions:

"How is confidential data classified and encrypted? Who has access to encryption keys?"
"Show me your key management procedures."

Privacy questions:

"Show me your data retention policies. How do you handle deletion requests?"
"Where is personal data stored and who has access?"

Processing Integrity questions:

"How do you validate data accuracy? Show me reconciliation reports."
"What happens when processing errors occur? Walk me through an example."

When to Get Professional Help

Consider external assistance if:

First SOC 2 audit - A readiness assessment from a qualified firm identifies gaps before the real audit
Limited internal expertise - Your team excels at development and operations but security compliance isn't their specialty
Tight timelines - Less than 90 days to audit with significant gaps
Complex environments - Multi-account architectures with sophisticated compliance requirements

AWS Security Assurance Services provides compliance advisory. When selecting AWS security partners for compliance work, use our partner evaluation framework to verify their SOC 2 experience and AWS competencies. To understand what a security review engagement entails, see our AWS security review process guide. Third-party GRC platforms (Vanta, Drata, Secureframe) can accelerate evidence collection. Independent consultancies like ours provide hands-on implementation alongside guidance. See how we helped Accolade achieve SOC 2 compliance with a properly governed AWS foundation.

Conclusion: Your SOC 2 Readiness Checklist

AWS SOC 2 compliance requires understanding two things: which controls AWS provides versus which you must implement, and what evidence proves your controls work.

Key takeaways:

Shared responsibility is critical - AWS handles infrastructure security. You handle everything built on it. Auditors evaluate YOUR controls.
Processing Integrity is entirely your responsibility - AWS explicitly excludes this TSC. Plan accordingly.
Evidence collection takes time - Start AWS Audit Manager 3-6 months before audit to demonstrate controls operating over time.
Common failures are preventable - Root user controls, CloudTrail validation, encryption, security groups, IR capabilities. Address these first.
90 days is achievable - With focused effort, proper tooling, and clear priorities.

Your immediate next step: Access AWS Artifact today to download AWS's SOC reports. Understand their control coverage. Identify gaps in your environment using Security Hub. That baseline tells you exactly where to focus.

For organizations wanting expert guidance, a security review identifies gaps quickly and provides a prioritized remediation roadmap. We've helped teams get audit-ready in weeks instead of months.

AWS Landing Zone Benefits: The ROI That Justifies Your Investment

Danny Steenman — Thu, 02 Apr 2026 15:17:51 +0000

You already know an AWS Landing Zone is best practice. Every AWS whitepaper, every Solutions Architect, every conference talk says the same thing: build a landing zone. But "it's best practice" doesn't get budget approved.

What gets budget approved is concrete evidence. Numbers your CFO can put in a spreadsheet. Risk reduction your CISO can quantify. Time savings your engineering leads can validate. And that's exactly what's missing from every landing zone article out there. They all list the same generic benefits without a single metric to back them up.

Here's what the AWS Landing Zone benefits actually look like in measurable terms: account provisioning drops from days to under 1 hour (95%+ reduction), operational overhead shrinks by 60-80%, compliance shifts from quarterly fire drills to continuous monitoring, and your developers stop waiting days for accounts they can provision themselves in minutes. These aren't aspirational goals. They're the documented outcomes from AWS Control Tower's automated multi-account architecture.

I've implemented landing zones for organizations ranging from Series B startups to regulated enterprises. In this guide, I break down every benefit into the five ROI pillars that matter for your business case: security, compliance, cost optimization, operational efficiency, and developer velocity. Whether you're building a board deck or convincing your CTO, this is the ammunition you need.

What Is an AWS Landing Zone (Brief Refresher)

If you're searching for "AWS Landing Zone benefits," you likely have a baseline understanding of the concept. So I'll keep this brief.

An AWS Landing Zone is a well-architected, multi-account AWS environment with built-in governance, security, and compliance controls. Think of it as the enterprise-wide foundation that holds all your organizational units (OUs), accounts, users, and workloads under a single, centrally managed umbrella.

AWS Control Tower is the managed service that automates landing zone setup in under one hour. It orchestrates AWS Organizations, AWS Service Catalog, and AWS IAM Identity Center to provision everything you need: identity management, policy enforcement, data security, network design, and centralized logging. Control Tower extends AWS Organizations by layering on automated guardrails that prevent drift from best practices.

For a deeper dive into what an AWS Landing Zone is and how multi-account architecture works, I've written a comprehensive guide. What matters for this conversation is understanding that the architecture's structure, account isolation, centralized governance, and automated controls, is what creates the business value we're about to quantify.

Now that the architectural foundation is clear, let's look at the concrete business outcomes this architecture delivers, starting with the most critical: security and risk reduction.

Security and Risk Reduction Benefits

Security is the benefit every competitor article mentions, but none of them quantify what "better security" actually means in operational terms. Here's what it looks like when you move from ad-hoc account management to a landing zone with automated controls.

130+ Automated Security Controls

AWS Control Tower provides three types of controls that work together to create a layered security model:

Preventive controls use Service Control Policies (SCPs) to block violations before they happen. These are organization-wide permission boundaries that prevent actions like creating root access keys, enabling public S3 bucket access, or deleting CloudTrail logs.
Detective controls use AWS Config rules to continuously monitor deployed resources for non-conformance. They catch issues like unrestricted TCP traffic, unencrypted data stores, and unattached EBS volumes.
Proactive controls use CloudFormation hooks to evaluate resources before deployment, shifting security left in the development lifecycle.

With 130+ proactive controls available out of the box (as of Control Tower v3.0+), you get comprehensive security coverage from a central location. Compare that to manually configuring security policies account by account, and the risk reduction becomes obvious.

Blast Radius Containment Through Account Isolation

Each AWS account acts as a hard isolation boundary. A compromise in one account does not automatically provide access to resources in other accounts. This is the Well-Architected Framework's SEC01-BP01 best practice in action.

The practical impact of a multi-account strategy:

Security isolation: credentials compromised in a development account cannot access production data
Data isolation: sensitive data lives in dedicated accounts with stricter access controls
Quota isolation: a runaway workload in one account cannot exhaust service limits in another
Workload separation: different compliance levels (PCI-DSS production vs. development sandbox) get different security postures without complex policy management

Organizations using AWS Control Tower can scale to 10,000 accounts while maintaining consistent security controls through hierarchical policy application. That's not a theoretical limit. It's the documented ceiling.

Centralized Security Visibility

AWS Control Tower automatically creates a Security OU with two specialized accounts:

Log Archive Account: centralized, tamper-proof repository for CloudTrail, AWS Config, VPC Flow Logs, and S3 access logs across all accounts. Logs are encrypted using AWS KMS and stored in a separate account, so even if an attacker compromises a workload account, the audit trail remains intact.
Audit Account: provides cross-account read/write access for security teams, integrates with Security Hub and GuardDuty, and serves as the central point for security monitoring and incident response.

This architecture gives your security team a single pane of glass across the entire organization. No more logging into individual accounts. No more wondering if CloudTrail is actually enabled everywhere.

Automated Threat Detection and Response

The landing zone architecture enables rapid security response through integrated services:

GuardDuty monitors for malicious activity across all accounts
Security Hub aggregates findings and provides compliance scoring
EventBridge triggers automated remediation workflows based on finding severity
Systems Manager Automation executes runbooks to isolate compromised resources

The result: reduced mean-time-to-response (MTTR) for security incidents. Instead of hours spent identifying which account is affected and manually remediating, automated detection and response handles common scenarios in minutes.

Security controls don't just protect your infrastructure. They also create the audit trail and evidence collection that transforms compliance from a quarterly fire drill into an always-on process.

How an AWS Landing Zone Accelerates Compliance

Compliance is where the landing zone ROI often hits hardest, especially for organizations in regulated industries. The shift from periodic, manual compliance checks to continuous, automated monitoring fundamentally changes how audit preparation works.

Continuous Compliance Monitoring

Traditional compliance operates on a point-in-time model: auditors show up, you scramble to collect evidence, gaps are discovered, remediation takes weeks. A landing zone replaces this cycle with continuous monitoring.

Detective controls implemented through AWS Config rules evaluate resource configurations continuously. Compliance status is reported at the organization unit, account, and control levels. The dashboard provides real-time visibility into your compliance posture, so you know the moment something drifts out of compliance, not three months later during an audit.

AWS Control Tower also runs automated drift detection to catch when resources or configurations deviate from your established baseline. Governance drift (changes to Control Tower-managed resources) and resource drift (modifications to deployed configurations) are both detected and surfaced automatically.

Audit-Ready Evidence on Demand

CloudTrail automatically captures all API calls across all accounts. AWS Config continuously records every resource configuration and change. All of this flows into the centralized Log Archive account with encryption and retention policies aligned to compliance periods.

This means audit preparation transforms from a months-long manual process to a continuous, automated activity. When auditors ask "show me all changes to your production databases in the last 90 days," you pull a report instead of starting an investigation.

Framework-Specific Benefits (SOC 2, HIPAA, PCI-DSS)

AWS Control Tower supports compliance with specific regulatory frameworks:

SOC 1/2/3: automated evidence collection, continuous control monitoring, and centralized audit trails directly support SOC 2 Trust Services Criteria. See what SOC 2 auditors look for in your AWS controls for detailed mapping.
HIPAA: data isolation through separate accounts, encryption enforcement via SCPs, and access logging satisfy key HIPAA technical safeguards.
PCI-DSS: network segmentation through account isolation, continuous monitoring of security configurations, and tamper-proof logging address multiple PCI-DSS requirements.
GDPR and FedRAMP: Region deny controls restrict where resources can be created, ensuring data residency requirements are met.

Compliance reports are available through AWS Artifact, and AWS Config Conformance Packs provide pre-configured rules for specific frameworks. EventBridge integration enables automated workflows when compliance violations are detected.

While security and compliance protect your organization, the financial benefits of a landing zone directly impact your bottom line, and they compound over time.

Cost Optimization Benefits That Compound Over Time

Despite "aws landing zone pricing" being a frequent related search, only 2 of the top 8 results even mention cost management. This is a massive gap, because the cost optimization benefits are significant and grow as your organization scales.

Consolidated Billing and Volume Discounts

AWS Organizations provides consolidated billing across all accounts in your organization. Your management account receives a single bill, and usage is aggregated across all accounts for volume pricing tiers.

Here's why this matters financially:

Volume pricing: higher combined usage across accounts leads to lower per-unit costs for services like S3, data transfer, and EC2. Even when usage is distributed across dozens of accounts, you get the aggregate discount.
Shared Savings Plans and Reserved Instances: commitment-based pricing can be purchased centrally and shared across accounts. No more each team buying their own RIs independently and missing organizational optimization.
Simplified accounting: one bill instead of dozens. Reduced administrative overhead for finance teams processing invoices and managing payments.

Cost Visibility and Allocation

A landing zone gives you cost attribution tools that simply don't work well in a single-account environment.

As of December 2025, AWS introduced account tags for cost allocation. Tags applied at the account level in AWS Organizations automatically apply to all usage within tagged accounts. This eliminates the need for manual cost groupings in Cost Explorer and Cost and Usage Reports. Changes propagate automatically across all cost management products.

Combined with OU-based cost allocation and Cost Categories, you get a complete picture:

Account-level tracking: every account's spend attributed to the right business unit
Resource-level tags: granular tracking at the application or workload level within accounts
Automated categorization: costs grouped by OU structure, business unit, or environment
Chargeback and showback: accurate cost allocation for internal billing

Waste Reduction Through Governance

This is the cost benefit most organizations underestimate. Governance controls don't just enforce security. They prevent waste.

Preventive controls restrict provisioning of expensive resources in non-production accounts (no p4d.24xlarge instances in sandbox, thank you)
Detective controls identify unattached EBS volumes, underutilized instances, and other idle resources
Region restrictions prevent accidental resource creation in unintended (often more expensive) Regions
Budget controls: AWS Budgets can be automatically applied to new accounts through Account Factory customization
Instance Scheduler: centrally managed solutions that stop non-production resources during non-business hours

The combination of volume discounts (5-15% through aggregated usage), governance-driven waste reduction, and operational cost reduction (60-80% less time on account management) creates a cost optimization flywheel that compounds as your organization grows.

Cost savings free up budget, but the operational efficiency gains free up something even more valuable: your team's time.

Operational Efficiency Gains

The operational benefits are where the 60-80% reduction in time spent on account management comes from. Let me break down exactly where that time savings originates.

Automated Account Provisioning

Account Factory transforms account creation from a manual, error-prone process into an automated workflow:

Account creation completes in under 30 minutes with full security baseline, network configuration, centralized logging, and IAM Identity Center access configured automatically
Up to 5 accounts can be provisioned concurrently (adjustable quota up to 10), enabling batch provisioning for large organizational changes
Zero manual configuration required for CloudTrail, AWS Config, or centralized logging. It's all automatic.

Compare this to the alternative: days of manual setup per account, ticket queues, approval chains, and the inevitable "we forgot to enable CloudTrail in that new account" discovery three months later.

Automation options scale with your maturity:

Console-based provisioning through Account Factory for occasional use
Service Catalog APIs for programmatic batch account creation
Account Factory for Terraform (AFT) for GitOps-based account management
Customizations for AWS Control Tower (CfCT) for version-controlled infrastructure definitions

Standardization and Drift Prevention

Every account provisioned through Account Factory receives a consistent baseline. Controls applied at the OU level are automatically inherited by all child OUs and accounts. Changes propagate automatically.

AWS Control Tower runs daily automated scans to verify controls are applied correctly. When configurations drift from baseline, the dashboard alerts your team immediately. No more discovering that someone disabled Config in a production account during an incident retrospective.

Reduced Manual Overhead

Here's where the 60-80% reduction in operational time breaks down:

Centralized dashboard for monitoring thousands of accounts, replacing account-by-account login
Automated compliance checks eliminating manual compliance reviews
Batch operations for large-scale changes across up to 300 accounts per OU
Centralized policy management with changes propagating automatically, replacing account-by-account scripts
Automated drift detection running continuously without manual intervention

When operations teams spend 60-80% less time on account management, the downstream effect is faster delivery for your development teams.

Developer Velocity and Time-to-Market

This is the benefit zero competitors mention, and it's the one that resonates most strongly with CTOs. A landing zone doesn't just make operations efficient. It makes your developers faster.

Self-Service Account Provisioning

IAM Identity Center users in the AWSAccountFactory group can provision accounts without IT involvement. Fully configured accounts ready in under an hour. No waiting for manual setup, approval chains, or security reviews.

Think about what that means: a team lead who needs a sandbox environment for a proof-of-concept doesn't file a ticket and wait three days. They provision an account, get a fully configured environment with security baselines baked in, and start building. Same day.

Guardrails That Enable Autonomy

Here's a counterintuitive insight: guardrails don't slow developers down. They speed them up.

Without guardrails, developers wait for security team approval on every account request. The security team becomes a bottleneck because they have to manually verify every configuration. Preventive and detective controls replace that bottleneck with automated policy enforcement. Teams innovate within defined boundaries without security team involvement for standard operations.

The security team shifts from gatekeeper to enabler. They define the guardrails once, and developers operate freely within those boundaries.

Faster Path to Production

The velocity improvement compounds across the development lifecycle:

Time to first deployment in new account: days reduced to under 2 hours. New accounts come with security baselines pre-configured. No waiting for security reviews.
Waiting for security approvals: eliminated for standard configurations. Preventive controls handle compliance automatically.
Environment consistency issues: reduced through standardization. Same security model across dev, staging, and production means fewer "it works in dev" surprises.
Multiple teams work independently in separate accounts. No resource contention, no naming conflicts, blast radius limited to individual accounts.

I've covered what you gain. Now let's look at what you risk losing by NOT implementing a landing zone.

The Real Cost of NOT Having a Landing Zone

No competitor article addresses this, and that's a mistake. Decision-makers need to understand both sides: the upside of investing AND the downside of not investing. The cost of inaction is not zero. It compounds.

Security Risks and Compliance Failures

Without a landing zone:

Security controls are applied inconsistently (or not at all) across accounts
Manual configuration multiplies misconfiguration risk
No centralized logging means security incidents go undetected longer
Cross-account incident response requires logging into individual accounts
Compliance evidence collection is manual and time-consuming, turning every audit into a fire drill

Operational Bottlenecks and Cost Sprawl

Without centralized governance:

Central IT becomes the bottleneck for every new account request
Development teams wait days for infrastructure they could provision in minutes
Policy changes require manual updates in every account
Scaling the account count requires proportional growth in the operations team
Cost allocation is manual, error-prone, and incomplete, making chargeback nearly impossible

With vs Without: A Side-by-Side Comparison

Capability	Without Landing Zone	With Landing Zone
Account provisioning	Days to weeks (manual)	Under 1 hour (automated)
Security baseline deployment	Manual per account, inconsistent	Automatic, consistent across all accounts
Policy deployment	Hours per account, manual scripts	Minutes for all accounts, automatic inheritance
Compliance evidence	Weeks of manual collection	On-demand, continuous
Security incident response	Hours (manual identification and access)	Minutes (automated detection and remediation)
Operational overhead	Baseline (grows linearly with accounts)	60-80% reduction
Cost visibility	Manual tagging, incomplete	Automated allocation, comprehensive
Developer wait time	Days for new accounts	Under 1 hour, self-service
Drift detection	Manual audits, periodic	Automated, daily scans
Scalability	Requires proportional ops team growth	Scales to 10,000 accounts with same tooling

The gap between these two columns widens with every account you add. At 5 accounts, the pain is manageable. At 50, it's significant. At 500, it's unsustainable.

Whether you're managing 10 accounts or planning for 1,000, a landing zone scales with you without requiring architectural redesign.

Built to Scale: From 10 to 10,000 Accounts

A common concern I hear from decision-makers: "We're not enterprise-scale yet. Is a landing zone overkill?" The answer is no, because a landing zone's architecture is designed to grow with you.

Scaling Account Structure

The numbers speak for themselves:

Up to 10,000 accounts in a single landing zone
Up to 1,000 accounts per OU for organizing workloads
Nested OUs up to 5 levels deep for sophisticated organizational hierarchies
Maximum 400 OUs per organization
Up to 5 concurrent account operations (adjustable to 10) for batch provisioning
Up to 100 concurrent control operations for large-scale governance changes
Bulk updates for up to 300 accounts per OU operation

You start with 10 accounts. You grow to 100. Then 1,000. The architecture doesn't change. The governance model scales. You don't need to redesign or migrate.

For organizations planning their growth trajectory, I've written a guide on how to design the right multi-account strategy for your growth stage.

Flexible Governance Models

As your cloud maturity evolves, so can your governance approach:

Centralized: a single cloud platform team manages the landing zone and core policies. Best for organizations starting out.
Federated: business units manage their own OUs within the central framework. Delegated administrators handle service-specific governance.
Hybrid: mandatory central controls plus optional business unit controls. The most common model at scale.

The landing zone supports all three models and lets you transition between them without downtime or migration. Multi-organization support also enables clean separation for acquisitions and divestitures.

Now that you understand the full scope of AWS Landing Zone benefits, how do you know if your organization is ready to invest?

When Your Organization Needs a Landing Zone

Not every organization needs a landing zone today. But most organizations that think they don't, actually do. Here's how to evaluate your situation.

Signals That It Is Time to Invest

You need a landing zone if you match three or more of these signals:

Managing 3+ AWS accounts with manual governance processes
Facing compliance requirements (SOC 2, HIPAA, PCI-DSS) with manual evidence collection
Experiencing security incidents from misconfigured accounts
Development teams waiting for account access or infrastructure setup
Inability to accurately track and allocate AWS costs by team or project
Operations team spending significant time on repetitive account management tasks
Scaling plans that require more accounts in the next 12 months

Choosing Your Implementation Approach

Three paths, each suited to different organizational profiles:

AWS Control Tower (managed): fastest time-to-value, AWS-managed controls, landing zone setup in under 1 hour. Recommended for most organizations and the default starting point.
Infrastructure as Code (CDK, Terraform): maximum flexibility and customization, GitOps workflows, best for engineering-mature organizations with specific requirements. See AWS Control Tower alternatives including IaC-based approaches for a detailed comparison.
AWS Partner-led: expert guidance, faster time-to-value for complex environments, recommended when internal cloud expertise is limited. Particularly valuable for regulated industries where compliance requirements add complexity.

If you'd like expert guidance on your specific situation, understanding how AWS Control Tower builds on AWS Organizations is a solid next step for evaluating your options.

Key Takeaways

The evidence is clear: an AWS Landing Zone is not a cost. It's an investment with measurable returns across five pillars.

AWS Landing Zone benefits in summary:

Security: 130+ automated controls, three-tier security model (preventive, detective, proactive), blast radius containment through account isolation, centralized visibility
Compliance: continuous monitoring replaces periodic audits, on-demand audit evidence, framework-specific support for SOC 2, HIPAA, PCI-DSS, GDPR, and FedRAMP
Cost optimization: consolidated billing with volume discounts, automated cost allocation (including the new 2025 account tags feature), governance-driven waste reduction
Operational efficiency: 60-80% reduction in account management time, automated provisioning in under 30 minutes, daily drift detection
Developer velocity: self-service accounts in under 1 hour (not days), guardrails that enable autonomy instead of creating bottlenecks, faster path to production

The cost of NOT investing compounds: manual overhead grows linearly with accounts, security risk increases, compliance gaps widen, and developers slow down.

Start by evaluating your current setup against the signals in the "When Your Organization Needs a Landing Zone" section. If you match three or more, begin planning your implementation. AWS Control Tower can deliver initial value in under one hour.

For a deeper look at the architecture, read my guide on what an AWS Landing Zone is. For teams already evaluating implementation paths, check the Accolade case study for a practical example of landing zone deployment.

What's your biggest hesitation about investing in a landing zone? I'd be curious to hear what's holding back your business case in the comments below.

How AWS Multi-Account Architecture Cuts Costs by 20-40%

Danny Steenman — Thu, 02 Apr 2026 15:17:48 +0000

Most organizations adopt multi-account architecture for security and governance. What they consistently discover is that it also reduces their AWS bill by 20-40% through six distinct cost mechanisms that compound on top of each other.

I'm not talking about a vague "it might save you money" promise. I'm talking about quantifiable AWS multi-account cost savings you can calculate before committing: consolidated billing volume discounts, centralized Savings Plans, preventive cost controls, shared infrastructure, centralized monitoring, and automated cleanup. Beyond these direct savings mechanisms, landing zones add governance-driven waste reduction and automated budget enforcement that prevent unnecessary spending before it happens.

This guide breaks down each strategy with specific savings percentages and real cost calculations so you can build a business case with actual numbers. The strategies are grounded in the AWS Well-Architected Framework Cost Optimization Pillar and backed by current AWS pricing.

Here is the summary of what each strategy delivers:

Strategy	Typical Savings Impact	Effort Level
Consolidated Billing and Volume Discounts	5-20% through aggregated usage	Low (automatic)
Centralized Savings Plans and RIs	Up to 72% on compute	Medium
Service Control Policies	Preventive (avoids waste)	Medium
Shared Infrastructure	30-50% on networking costs	High
Centralized Monitoring and Budgeting	Detective (catches overruns)	Medium
Automated Idle Resource Cleanup	10-15% of total spend recovered	Medium

If you are still designing your AWS multi-account strategy, start there for the architectural foundation. This post focuses entirely on the cost savings you unlock once the structure is in place.

Why Multi-Account Architecture Reduces AWS Costs

The fundamental cost mechanism is simple: AWS Organizations consolidated billing aggregates usage from all member accounts under a single management account. Instead of each account operating as an isolated billing entity, your entire organization's usage counts toward volume discount tiers together.

This matters because AWS services with tiered pricing, including Data Transfer, Amazon S3, and Amazon EC2, calculate discounts based on total organizational usage rather than individual account usage. Your organization reaches higher discount tiers faster, and the savings apply automatically.

How Consolidated Billing Unlocks Volume Discounts

Tiered pricing works in your favor when usage is aggregated. As your combined usage increases, the per-unit cost decreases across the entire organization.

Here is a practical example: if you have 10 accounts each storing 5 TB in S3, consolidated billing treats that as 50 TB of total storage. That 50 TB hits a higher discount tier than any single 5 TB account would reach on its own. The blended rate distributes cost benefits across all member accounts automatically.

The management account sees total usage and charges for all accounts, while member accounts see their individual (unblended) costs. One thing to note: the free tier applies to total usage across all accounts in the organization, not per account.

The Cumulative Effect: Stacking Six Cost Strategies

No single strategy delivers 20-40% savings on its own. The power comes from stacking them.

Volume discounts provide the automatic foundation at 5-20%. Layer centralized Savings Plans on top for up to 72% off compute. Add SCPs to prevent wasteful spending before it happens. Share infrastructure to eliminate redundant networking costs. Monitor centrally to catch overruns early. Automate cleanup to recover the 10-15% of spend that typically goes to idle resources.

Each strategy addresses a different cost lever. Together, they compound into multi-account cost savings of 20-40% that organizations consistently achieve. The rest of this guide walks through each one.

Centralized Savings Plans and Reserved Instances (Up to 72% Off)

Commitment-based discounts represent the single largest cost reduction lever in a multi-account setup. The discount levels are substantial:

EC2 Instance Savings Plans: Up to 72% savings, locked to a specific instance family in a region but flexible on size, OS, and tenancy
Compute Savings Plans: Up to 66% savings, maximum flexibility across instance family, size, region, and also covers Fargate and Lambda
Standard Reserved Instances: Up to 72% off On-Demand pricing
Convertible Reserved Instances: Up to 66% off, with the ability to exchange across instance families
Database Savings Plans: Up to 35% off various AWS database services

The real advantage in a multi-account environment is that these discounts share across your entire organization automatically.

Cross-Account Discount Sharing: How It Works

When using consolidated billing, discount sharing is enabled by default. Savings Plans and Reserved Instances purchased by any member account automatically apply to other accounts' eligible usage.

AWS provides three sharing configurations to control how benefits distribute:

Organization-wide sharing: Benefits the owning account first, then shares remaining benefits across all other accounts. Maximizes overall utilization.
Prioritized group sharing: Uses AWS Cost Categories to define account groups that receive priority. Maximizes utilization within priority groups first.
Restricted group sharing: Exclusively shares within defined account groups. Each account belongs to only one sharing group.

One important limitation: discounts only apply within a single AWS Organization. If you manage multiple Organizations, Savings Plans purchased in one cannot benefit accounts in another.

Centralized vs. Decentralized Purchasing

This is where many organizations leave money on the table.

Centralized purchasing means the management account buys Savings Plans based on payer-level recommendations that analyze total eligible spend across all accounts. This approach maximizes overall savings because it sees the full picture.

Decentralized purchasing lets each team buy for their own workloads. This preserves budget accountability but fragments your purchasing volume, often resulting in lower total savings.

I recommend a hybrid approach: centralized purchasing for stable baseline commitments that cover predictable organization-wide workloads, combined with decentralized purchasing for specialized or variable workloads where individual teams understand the patterns best.

The common mistake is going fully decentralized. When each team buys independently, they miss cross-account sharing benefits and typically achieve 10-15% lower utilization rates compared to centralized purchasing.

Group Sharing with AWS Cost Categories

If you have distinct business units that need cost separation, group sharing lets you restrict benefits within defined boundaries.

Configuration uses AWS Cost Categories with the Accounts dimension. You define which accounts belong to which group, and sharing stays within those groups. The payer account is not part of any sharing group.

This works well for organizations where business units operate as separate P&L centers and need clear cost attribution without cross-subsidy.

Service Control Policies for Cost Governance

Commitment-based discounts maximize savings on resources you need. But how do you prevent teams from launching resources you do not need? That is where Service Control Policies come in.

SCPs define the maximum available permissions for IAM users and roles in member accounts. They restrict, they do not grant. Most organizations use them for security, but they are equally powerful as preventive cost controls.

The cost-specific use cases are compelling: restricting expensive instance types in non-production accounts, limiting resource creation to approved regions, blocking expensive services in sandbox environments, and enforcing cost allocation tags before resource creation.

Preventing Expensive Resource Launches

The most immediate cost impact comes from blocking expensive resources where they are not needed:

Block GPU and metal instances in non-production OUs: A single p4d.24xlarge instance costs over $32/hour. An SCP preventing its launch in dev/test accounts eliminates accidental bills that can reach thousands of dollars overnight.
Restrict services by OU: Disable SageMaker, Redshift, or other expensive services in sandbox accounts where they are not needed.
Enforce approved instance families: Limit production to current-generation instance types (like Graviton-based instances) that offer better price-performance.

AWS recommends testing SCPs by moving accounts into an OU one at a time to validate the effect before broad rollout.

Enforcing Region and Service Restrictions

Limiting resource creation to 2-3 approved regions delivers a double benefit: it concentrates your usage volume for better discount tiers and reduces cross-region data transfer costs.

Combine region restrictions with tag enforcement. An SCP that denies resource creation without required cost allocation tags ensures every resource can be tracked, attributed, and included in chargeback reporting.

For ready-to-use policy templates, check out my collection of production-ready SCP examples organized by OU. The cost governance policies in that guide complement the strategies covered here.

Shared Infrastructure to Eliminate Redundant Costs

SCPs prevent unnecessary spending. But you can also reduce legitimate infrastructure costs by sharing resources across accounts instead of duplicating them.

Shared networking infrastructure is the biggest multi-account cost savings lever most organizations overlook. According to the Well-Architected Framework guidance on shared resources, centralized networking patterns can reduce costs by 30-50% compared to per-account deployments.

Centralized NAT Gateways

This is the highest-impact shared infrastructure pattern, and the math is straightforward.

A single NAT Gateway costs $0.045 per hour. In a typical multi-account setup with 10 accounts and 3 Availability Zones, each account deploys its own NAT Gateways: 10 accounts x 3 AZs = 30 NAT Gateways at $972/month in hourly charges alone.

Centralize those NAT Gateways in a dedicated egress VPC and route spoke VPC traffic through Transit Gateway: 1 egress VPC x 3 AZs = 3 NAT Gateways at $97/month. That is roughly a 90% reduction in NAT Gateway hourly charges.

A single NAT Gateway supports up to 5 Gbps (scalable to 100 Gbps) and 440,000 simultaneous connections, so capacity is rarely a concern. Keep same-AZ routing to minimize cross-AZ data transfer charges, and use security groups, blackhole routes, and NACLs for traffic control.

Transit Gateway and Shared VPC Endpoints

Beyond NAT Gateway consolidation, Transit Gateway replaces the exponential complexity of VPC peering meshes with a simple hub-and-spoke model. Instead of managing N-squared peering connections, you manage N attachments.

Transit Gateway pricing includes $0.05/hour per attachment and $0.02 per GB of data processed. The new Flexible Cost Allocation feature (2025) lets you automatically allocate Transit Gateway data processing charges to specific accounts, enabling receiver-pay models for shared networking.

Shared VPC endpoints are another quick win. Each VPC endpoint costs approximately $0.01/hour per AZ. Instead of every account provisioning its own endpoints for S3, DynamoDB, or other services, share endpoints from a central networking account using AWS Resource Access Manager (RAM).

Centralized Monitoring and Budgeting

Sharing infrastructure reduces costs structurally. But to keep costs optimized over time, you need centralized monitoring and proactive budgeting across all accounts.

Without organization-wide visibility, cost issues hide in individual accounts until the consolidated bill arrives. AWS provides several tools that work together to give you complete monitoring coverage from a single pane of glass.

Multi-Account Budget Hierarchy with AWS Budgets

AWS Budgets supports six budget types: cost, usage, RI utilization, RI coverage, Savings Plans utilization, and Savings Plans coverage. In a multi-account environment, you build a budget hierarchy:

Organization-wide: Aggregate spending cap across all accounts
OU-level: Budget per business unit (Production OU, Development OU)
Account-level: Individual team budgets within each OU

Configure SNS notifications at threshold levels (80%, 100%, 120%) so teams get alerted before budgets are exceeded, not after. Budgets update up to three times daily, giving you near real-time visibility.

For organizations with many accounts, you can automate budget creation across accounts using Lambda, DynamoDB, and Systems Manager Parameter Store. This eliminates manual budget setup as new accounts are provisioned.

Cost Optimization Hub for Organization-Wide Savings

Cost Optimization Hub is the aggregation layer that ties everything together. When enabled in the management account with Organizations integration, it consolidates over 15 recommendation types across all accounts and regions into a single prioritized view:

EC2 rightsizing and Graviton migration opportunities
Idle resource detection (EC2, EBS, RDS, Lambda, NAT Gateways, ECS on Fargate)
EBS volume type upgrades (gp2 to gp3, io1 to io2)
Savings Plans and Reserved Instance recommendations

You can designate a member account as delegated administrator, allowing your FinOps team to access recommendations without management account credentials.

The Cost efficiency metric (2025) gives you a single benchmark score: (Potential monthly savings / Total optimizable spend) x 100. It refreshes daily and supports analysis across accounts, regions, and organizational hierarchies, making it easy to compare efficiency between business units.

Cost Anomaly Detection for Proactive Alerts

AWS Cost Anomaly Detection uses machine learning to identify anomalous spend patterns across your organization. Configure monitors by AWS service, member account, Cost Category, or cost allocation tag to catch unexpected spending spikes before they become significant budget overruns.

The strength of Cost Anomaly Detection in a multi-account setup is coverage. A single monitor configured at the organization level scans spend across all accounts continuously, surfacing anomalies that account-level monitoring would miss. Combine it with SNS notifications for immediate alerts and integrate with AWS Chatbot for Slack or Teams delivery.

For organizations managing multiple AWS Organizations, the multi-source custom billing views feature (2025) provides a unified cost view across up to 20 separate Organizations from a single account, closing the visibility gap for complex enterprise structures.

Automated Cleanup of Idle Resources

Monitoring identifies cost issues. But the most impactful action is automating the cleanup of resources that no longer serve a purpose.

Industry research consistently shows that 10-15% of total cloud spend goes to idle or unused resources. In a multi-account environment, this waste multiplies because each account can accumulate forgotten proof-of-concept deployments, unattached volumes, and unused Elastic IPs independently.

AWS Compute Optimizer Idle Recommendations

AWS Compute Optimizer detects idle resources using specific criteria per resource type:

Resource Type	Idle Criteria	Lookback Period	Recommended Action
EC2 Instances	Peak CPU below 5% AND network I/O less than 5 MB/day	14 days	Delete
EBS Volumes	Less than 1 read/write per day OR unattached 32+ days	32 days	Snapshot and delete
ECS on Fargate	Peak CPU and memory below 1%	14 days	Delete
RDS Databases	No connections, low CPU, low read/write	14 days	Stop or snapshot and delete
NAT Gateways	No route table association, no active connections	14 days	Verify and delete

Enable Compute Optimizer at the organization level for centralized visibility across all accounts. This surfaces idle resources that individual teams may not even know exist.

Automated EBS Volume Optimization

This 2025 feature is a significant advancement for multi-account environments. You can create automation rules that continuously:

Snapshot and delete unattached volumes older than 32 days
Upgrade gp2 volumes to gp3 for better performance at lower cost

A single automation rule operates globally across all AWS Regions. You can configure it to run daily, weekly, or monthly with filtering by region or resource tags.

Here is why this matters financially: unattached EBS volumes cost the same as attached volumes. Deleting 50 unused 100 GB gp3 volumes saves approximately $400/month ($0.08/GB-month x 100 GB x 50 volumes). Unused Elastic IPs add $3.60/month each. Idle EC2 t3.medium instances waste approximately $30/month each. These small amounts compound fast across dozens of accounts.

Safety mechanisms are built in: eligibility checks run before any action, snapshots are created before deletion, and all automated actions can be reversed through Compute Optimizer.

Best Practices to Maximize Multi-Account Savings

With the six core strategies in place, a few additional best practices help you extract maximum value from your multi-account setup.

Enable Credit Sharing Across the Organization

AWS credits (promotional, support, migration acceleration) are shared across all member accounts by default in consolidated billing. Credits apply in this order: oldest credits expire first, then credits with the most eligible services apply first.

The strategic insight here is tracking and governance. Designate a credit management team, create a centralized tracking dashboard in Cost Explorer, and set up automated alerts for expiration dates. AWS offers several credit programs worth leveraging: Migration Acceleration Program (MAP), Digital Innovation credits, and Cloud Economics programs. Without centralized tracking, credits often expire unused in individual accounts.

Implement a Cost Allocation Tagging Strategy

You cannot optimize what you cannot measure. A consistent tagging strategy makes cost allocation and chargeback possible across your organization.

Start with four essential tags: CostCenter, Environment (prod/dev/test), Project, and Owner. The new account tags feature (2025) simplifies this significantly. Apply tags at the account level, and all resources within that account automatically inherit the tag for cost allocation. This eliminates the need to tag thousands of individual resources and even covers resources that do not support resource-level tags.

Enforce compliance with a three-layer approach:

Tag policies in AWS Organizations define acceptable tag values
SCPs deny resource creation without required cost allocation tags
AWS Config rules detect and report non-compliant resources

View Recommendations at the Payer Account Level

This is a best practice that many organizations miss. Payer-level recommendations analyze total eligible spend across all accounts and capture cross-account sharing benefits that linked-account recommendations miss entirely.

Use the Savings Plans Purchase Analyzer to compare different purchasing scenarios before committing. Choose your lookback period based on workload predictability: 7 days for volatile workloads, 30 days for stable workloads, 60 days for highly predictable patterns. Review and adjust monthly as your organization evolves.

Conclusion

Multi-account architecture delivers 20-40% AWS multi-account cost savings through six complementary strategies that work at different layers of your infrastructure and operations.

Start with the foundations: consolidated billing is automatic once you enable AWS Organizations, and centralized Savings Plans offer the highest individual impact at up to 72% off compute. Then add preventive controls with SCPs and structural savings with shared infrastructure. Implement centralized monitoring with AWS Budgets and Cost Optimization Hub for ongoing visibility. Finally, automate idle resource cleanup to recover the 10-15% of spend that silently drains your budget.

The key is that these strategies stack. Each one addresses a different cost lever, and the combined effect is what produces the 20-40% range. The exact savings depend on your organization's size, workload mix, and current optimization maturity.

Your next step: If you have not already, enable AWS Organizations and consolidated billing. Then open Cost Explorer at the payer level, review the Savings Plans recommendations, and calculate how much you are leaving on the table. For deeper implementation guidance, check out the AWS multi-account best practices and the broader AWS cost optimization best practices guides.

What cost savings strategies have worked best in your multi-account setup? I'd love to hear what you've implemented in the comments below.