AWS Production Security Checklist: 10 Controls Before Go-Live

Simple explanation

AWS gives you powerful tools but does not configure them for you. The default state of a new AWS account is more permissive than most teams expect: the root account has no MFA, CloudTrail is not enabled, GuardDuty is off, and EBS encryption is not enforced by default.

A security checklist is a list of the controls you need to deliberately turn on before traffic reaches production. It is not about building an impenetrable system. It is about closing the gaps that attackers routinely exploit.

Work from the top of this page down. The controls are ordered by impact. Fixing identity before encryption, and detection before patching, reflects the actual order attackers work through your attack surface.

When to use this checklist

• Launching a new AWS workload. Run through this before the first users hit production.
• Promoting staging to production. Staging environments often have relaxed settings that should not carry over.
• Auditing an existing account. Use each section as an audit prompt to find gaps in a running system.
• Preparing for a security review or compliance conversation. This covers the controls most reviewers check first.

How to use this checklist

Work through the sections in this order. Each area is a dependency for the next.

1. Identity first. A compromised AWS identity can undo every other control.
2. Network second. Limit what is reachable before worrying about what is encrypted.
3. Encryption. Protect data in transit and at rest.
4. Secrets. Ensure credentials are not leaking through environment variables or config files.
5. Detection. Turn on the logging and alerting you need to know when something goes wrong.
6. Patching. Keep the software running your workloads free of known vulnerabilities.
7. Deployments and operational access. Secure the pipeline and the humans who operate the system.
8. Recovery. Verify you can restore from backup before you need to.

AWS production security checklist

1. Secure the account and identities

IAM is the first thing to lock down because a compromised AWS identity can bypass every other control on this page.

Root account. The root account has unrestricted access to everything and cannot be constrained by IAM policies or Service Control Policies. Lock it down before anything else:

• Enable MFA on the root account
• Remove any access keys (they almost never should exist)
• Store root credentials in a password manager as a break-glass emergency credential
• After initial account setup, never use the root account again for day-to-day work

Human access. For new accounts, AWS IAM Identity Center (formerly SSO) is the recommended approach rather than individual IAM users. Identity Center assigns permission sets to people and connects to identity providers your team already uses (Google Workspace, Okta, Active Directory). Users get short-lived credentials via the AWS access portal. No long-lived IAM user credentials to rotate or leak.

If you are using IAM users in a smaller setup, enforce MFA for all users with console access. An IAM policy condition denying all actions when aws:MultiFactorAuthPresent is false handles this cleanly.

Least privilege for service roles. Every Lambda function, EC2 instance, ECS task, and EKS pod should have an IAM role scoped to the minimum permissions it actually uses. An API that reads from one DynamoDB table should allow exactly dynamodb:GetItem and dynamodb:Query on exactly that table, not dynamodb:* on *.

Write policies with specific resource ARNs rather than wildcards. Review roles quarterly. Permission creep is common and goes unnoticed until a breach.

Temporary credentials via STS. Services should use IAM roles that issue short-lived credentials automatically. Avoid distributing long-lived access keys to applications. If a key leaks, it remains valid until someone manually rotates it.

Multi-account guardrails. If you run more than one AWS account, use AWS Organizations with Service Control Policies to set boundaries no account can override. Common SCPs prevent disabling CloudTrail, restrict which regions workloads can run in, and block creation of public S3 buckets. SCPs apply to all identities in the account, including root users within the Organization.

2. Lock down the network

A well-designed VPC keeps backend resources in private subnets where they are not directly reachable from the internet.

Subnet architecture. Use at least two subnet tiers:

• Public subnets. Only resources that must be internet-accessible, specifically Application Load Balancers and NAT Gateways. Even EC2 instances serving web traffic should sit in private subnets behind an ALB, not in public subnets with direct internet exposure.
• Private subnets. Application servers, RDS databases, ElastiCache, Lambda functions in a VPC, ECS tasks. No inbound internet access; outbound through a NAT Gateway if needed.
• Database subnets (recommended). A dedicated tier for RDS and ElastiCache with no internet route. Only the application subnet should reach it.

Admin access. Replace SSH over port 22 with AWS Systems Manager Session Manager. Session Manager requires no open inbound port. Instances connect outbound to the Systems Manager service endpoint. There is no bastion host to maintain, no SSH keys to distribute, and every session is logged in CloudTrail.

Security groups are stateful and default-deny. They are the primary network control at the resource level:

• Database security groups should reference the application security group as the allowed source, not a CIDR range. This ensures only instances in the application tier can reach the database, regardless of IP changes.
• Never use 0.0.0.0/0 as a source except for the ALB’s HTTP/HTTPS inbound rule.
• Tighten outbound rules where possible. Most backend services do not need unrestricted outbound access.

Security Groups vs NACLs:

For most workloads, well-configured security groups are sufficient. Network ACLs add value as a secondary layer to block known-bad IP ranges or as a defence-in-depth measure.

3. Encrypt data in transit and at rest

In transit. All external traffic should use TLS 1.2 or higher. AWS Certificate Manager (ACM) provides free TLS certificates for Application Load Balancers and CloudFront distributions. Configure your ALB to redirect HTTP to HTTPS automatically. For internal service-to-service traffic that crosses network or process boundaries, use TLS where practical.

At rest. Most AWS managed services support encryption at rest. Verify these before go-live:

• RDS. Enable encryption at creation time. It cannot be enabled after the fact. You would need to take a snapshot and restore an encrypted copy, which involves downtime.
• S3. SSE-S3 encryption is on by default for all new objects. No action required unless you need customer-managed keys.
• EBS volumes. Enable EBS encryption by default at the region level in the EC2 console so every new volume is automatically encrypted.
• DynamoDB. Encrypted at rest by default using AWS-managed keys.

AWS-managed keys vs customer-managed keys (CMKs). AWS-managed keys are the right default for most workloads. Customer-managed KMS keys give you an audit trail (every encrypt/decrypt logged in CloudTrail) and the ability to revoke access by disabling the key. CMKs add operational overhead, including key rotation policy, access policy management, and key deletion windows. Adopt them when the compliance or control requirement is real, not hypothetical. See Customer-Managed Keys for a practical breakdown.

For a broader view of encryption across AWS services, including how RDS, EBS, and S3 handle keys differently, that page covers the full picture.

4. Manage secrets safely

Database passwords, API keys, OAuth client secrets, and private certificates should never appear in:

• Lambda environment variables
• ECS task definition environment variables
• EC2 user data scripts
• Application config files committed to Git
• Hardcoded in source code

The correct approach is AWS Secrets Manager. Store the secret there, grant the Lambda execution role or ECS task role permission to read it, and retrieve it at runtime. The plaintext value never touches environment configuration.

const { SecretsManagerClient, GetSecretValueCommand } = require('@aws-sdk/client-secrets-manager');
const client = new SecretsManagerClient({ region: 'us-east-1' });

async function getDatabaseCredentials() {
  const response = await client.send(new GetSecretValueCommand({
    SecretId: 'prod/myapp/db-credentials'
  }));
  return JSON.parse(response.SecretString);
}

Secrets Manager also handles automatic rotation for RDS credentials. It rotates the password on a schedule and updates the secret value without application downtime.

Secrets Manager vs SSM Parameter Store:

For most production secrets, Secrets Manager is the right choice. For config values that are sensitive but do not rotate, SSM Parameter Store is lighter and cheaper.

For CI/CD pipelines, see Secrets in CI/CD Pipelines. Build systems have different exposure surfaces than application runtime environments.

5. Turn on logging, detection, and posture checks

Securing infrastructure is necessary but not sufficient. You also need to know when something goes wrong.

CloudTrail records every API call made in your AWS account: who made it, when, from where, with what parameters, and whether it succeeded. Enable a multi-region trail so activity in every region is captured from day one. Send logs to an S3 bucket in a dedicated logging account. That way, even if an attacker compromises your main account, the audit trail is intact. Enable log file validation to detect tampering.

CloudTrail is the foundation of every incident investigation: “who created this resource?”, “when were these credentials used?”, “who changed this policy?” Without it, you are reconstructing events from memory. See CloudTrail log types for the difference between management events and data events.

GuardDuty uses machine learning to detect suspicious activity by analysing CloudTrail, VPC Flow Logs, and DNS query logs. It generates findings for events like an EC2 instance communicating with a known command-and-control server, unusual API calls from a new geographic location, or cryptocurrency mining activity. Enable GuardDuty in every region, every account. It costs a few dollars per month for most accounts, which is small relative to what it detects.

Route high-severity GuardDuty findings to an SNS topic connected to your on-call alerting channel. A finding that sits unreviewed for weeks provides no protection at all.

Security Hub aggregates findings from GuardDuty, AWS Inspector, IAM Access Analyzer, and other services into one view. It also runs the AWS Foundational Security Best Practices standard, which checks your account for misconfigurations like public S3 buckets, unencrypted RDS instances, or IAM access keys that have not been rotated. Use Security Hub findings as a prioritised remediation list. Review it weekly during the first months after launch.

AWS Inspector scans your EC2 instances and ECR container images continuously for known CVEs. Enable it for both EC2 and ECR. It runs in the background and surfaces vulnerabilities in your deployed software without requiring manual scans.

6. Patch, scan, and rebuild workloads

Unpatched software is one of the most common attack paths after credential compromise.

Managed services (RDS, ElastiCache, ECS Fargate, Lambda). AWS patches the underlying infrastructure. For RDS, enable auto minor version upgrades so security patches apply automatically. Have a tested plan for major version upgrades. They require manual scheduling but carry security fixes that do not reach minor versions.

EC2 instances. Use AWS Systems Manager Patch Manager to automate patching. Define a patch baseline (which patches to apply), a maintenance window (when to apply them), and patch groups (which instances are in scope). Test patches in staging before production.

Container images. When Inspector’s ECR scanning finds a CVE in a deployed image, rebuild the image from an updated base and redeploy. Do not patch running containers in place. Rebuild from source so the image stays reproducible and every instance starts from a known state.

Immutable infrastructure. For EC2, the cleaner approach is immutable replacement: build a new AMI with the patch applied, deploy new instances from it, and terminate the old ones. This eliminates configuration drift and removes the “what did someone change on this running instance” problem. It costs more to automate up front but is operationally simpler over time.

7. Secure deployments and operational access

A CI/CD pipeline with excessive permissions is a privileged path straight into your production account.

CI/CD roles. The IAM role your pipeline uses to deploy should have only the permissions that deployment actually requires, not AdministratorAccess. Use a dedicated role for each pipeline stage (build, test, deploy to staging, deploy to production), scoped to the minimum. See Secure CI/CD Pipelines for scoping patterns.

No long-lived access keys in pipelines. If your CI/CD platform supports OIDC federation, use it. The pipeline exchanges an OIDC token for temporary credentials from STS. No stored access keys to rotate or accidentally leak in build logs.

Operational access via Session Manager. For production debugging, use Session Manager rather than SSH. It requires no inbound port 22, no bastion host, and no SSH key distribution. Every session is logged to CloudTrail and optionally to S3 and CloudWatch Logs. Access is controlled by IAM, so you can scope who can start a session on which instances.

Break-glass access. Define and document a procedure for emergency access when normal controls are unavailable. This typically means a dedicated break-glass IAM role in each account with broad emergency permissions, protected by a separate MFA device, with CloudTrail alerts configured for every assumption of that role. The goal is that break-glass use is always detected, reviewed, and time-limited.

8. Backups and recovery readiness

A backup you have never restored is an untested assumption.

What to back up. At minimum: RDS automated snapshots with a retention period that matches your RPO, EBS snapshots for stateful workloads, S3 versioning on buckets where data loss is unacceptable, and DynamoDB with point-in-time recovery (PITR) enabled. AWS Backup can centralise backup policy across services into one place.

Test a restore before go-live. Before production launch, restore at least one backup into a test environment and verify both the data is intact and the application works against it. This sounds obvious, but most teams skip it until after an incident forces it.

Recovery objectives. Document your RTO (how long you can tolerate being down) and RPO (how much data loss is acceptable). These numbers drive decisions about backup frequency, cross-region replication, and whether you need a warm standby or active/active setup. See Disaster Recovery Strategies for the four DR patterns and when each makes sense.

Cross-region backups. For workloads where a regional failure would be unacceptable, copy snapshots to a second region. RDS snapshots can be copied cross-region manually or via Lambda automation. S3 Cross-Region Replication handles objects automatically. The goal is that a region going down does not also destroy your most recent recovery point.