Introduction

Moving an application to an AWS production environment requires more than deploying compute, databases, and networking components. Production workloads should be protected against unauthorized access, accidental configuration changes, data exposure, network attacks, and operational security incidents.

AWS recommends applying security across multiple layers, including identity and access management, detection, infrastructure protection, data protection, incident response, and application security. The AWS Well-Architected Security Pillar also emphasizes least privilege, traceability, defense in depth, encryption, automation, and preparation for security events.

This AWS production security checklist provides a practical set of controls to review before and after moving a workload to production.

Note: Security requirements vary based on the application, data classification, compliance requirements, and AWS services being used. This checklist is a practical baseline and should be adapted to the specific environment.

---

Prerequisites

Before reviewing the production security configuration, ensure that you have:

• Access to the AWS account or AWS Organization.
• Appropriate permissions to review IAM, networking, compute, storage, databases, and security services.
• A documented production architecture.
• A list of production AWS resources and services.
• Defined data classification and security requirements.
• Defined backup, recovery, and incident-response requirements.
• A documented list of administrators and operational users.

For larger environments, separating workloads across AWS accounts can help reduce management scope and provide stronger isolation between environments. AWS Well-Architected guidance specifically recommends considering account separation based on workload function, compliance, and data sensitivity.

---

AWS Production Security Checklist

1. AWS Account Security

The AWS account itself should be treated as a critical security boundary.

Checklist

• Secure the AWS root user.
• Enable MFA for the root user.
• Do not use the root user for routine administration.
• Avoid creating unnecessary IAM users.
• Use centralized identity management where appropriate.
• Separate production and non-production workloads.
• Review AWS account contacts and security contacts.
• Review account-level security settings regularly.
• Establish a process for emergency or break-glass access.
• Monitor sensitive account-level activity.

AWS recommends securing the root user and establishing a strong identity foundation rather than relying on long-lived static credentials.

---

2. Identity and Access Management

IAM is one of the most important areas to review before placing a workload into production.

Least Privilege

Grant users, applications, and services only the permissions they require.

Review:

• IAM policies for excessive permissions.
• Wildcard Action permissions.
• Wildcard Resource permissions.
• Unused permissions.
• Unused roles and users.
• Cross-account access.
• Third-party access.
• Administrative permissions.

Avoid giving application workloads full administrative access unless there is a documented requirement.

MFA

Enable MFA for privileged identities and administrative access.

Review:

• Root account MFA.
• Administrative identities.
• Privileged human access.
• Emergency access procedures.

AWS security guidance recommends MFA as part of protecting AWS resources.

IAM Roles

Prefer IAM roles for AWS workloads instead of storing long-term AWS access keys on servers.

For example:

EC2 Instance
     |
     v
IAM Role
     |
     +---- S3
     +---- CloudWatch
     +---- Secrets Manager

This reduces the need to store permanent credentials inside application servers.

Access Key Review

Check for:

• Unused access keys.
• Old access keys.
• Hard-coded AWS credentials.
• Credentials stored in source code.
• Credentials stored in configuration files.
• Credentials exposed in CI/CD systems.
• Credentials accidentally committed to Git repositories.

3. VPC and Network Security

Production workloads should use network segmentation rather than exposing every resource directly to the internet.

A typical architecture can separate public-facing components from private application and database resources.

                    Internet
                       |
                       v
                CloudFront / WAF
                       |
                       v
                Application Load
                   Balancer
                       |
              +--------+--------+
              |                 |
              v                 v
        Private Subnet    Private Subnet
          Application       Application
            Server            Server
              |                 |
              +--------+--------+
                       |
                       v
                Private Database

VPC Checklist

• Use a dedicated VPC for production workloads where appropriate.
• Use separate public and private subnets.
• Keep databases in private subnets.
• Avoid assigning public IP addresses to internal workloads unnecessarily.
• Review route tables.
• Review internet gateways.
• Review NAT gateways.
• Review VPC peering connections.
• Review Transit Gateway connections where applicable.
• Review VPC endpoints where appropriate.

Security Groups

Security groups should allow only required traffic.

For example:

Internet
   |
   | HTTPS :443
   v
Load Balancer
   |
   | Application Port
   v
Application Server
   |
   | Database Port
   v
Database

Avoid configurations such as:

0.0.0.0/0 -> SSH 22

unless there is a specific and controlled requirement.

Instead, restrict administrative access through approved networks, VPN, bastion mechanisms, or other controlled access paths.

Review:

• SSH access.
• RDP access.
• Database ports.
• Application ports.
• Internal service ports.
• Temporary firewall rules.
• Unused security groups.
• Rules allowing unrestricted inbound traffic.

4. Network Access Control

Security groups are stateful controls, while network ACLs can provide an additional subnet-level control layer.

Review:

• Network ACL rules.
• Public subnet routes.
• Private subnet routes.
• Internet gateway access.
• NAT gateway paths.
• VPC endpoint policies.
• Cross-VPC connectivity.
• Cross-account network connectivity.

Use defense in depth rather than relying on a single network security mechanism. AWS recommends applying security controls at multiple layers of the workload.

5. TLS and Encryption in Transit

Production applications should protect sensitive traffic while it is transmitted.

Review:

• HTTPS enabled for public applications.
• Valid TLS certificates.
• HTTP redirected to HTTPS where appropriate.
• Secure TLS configuration.
• Internal service communication requirements.
• Database encryption in transit where supported and required.
• API communication protected using HTTPS.

AWS recommends TLS for communication with AWS resources and currently recommends TLS 1.3 while requiring TLS 1.2 for AWS service connections.

6. Data Encryption at Rest

Sensitive production data should be protected using appropriate encryption mechanisms.

Review encryption for:

• EBS volumes.
• RDS databases.
• S3 buckets.
• EFS file systems.
• Backup data.
• Application secrets.
• Log storage.
• Snapshots.

Where customer-managed KMS keys are required, establish appropriate key policies, rotation requirements, access controls, and recovery procedures.

AWS recommends using AWS encryption solutions together with the security controls provided by AWS services.

7. Amazon S3 Security

S3 buckets frequently contain application data, backups, reports, logs, and other sensitive information.

Review:

• Block Public Access.
• Bucket policies.
• IAM permissions.
• Access Control Lists where applicable.
• Encryption.
• Versioning.
• Lifecycle policies.
• Logging and monitoring.
• Cross-account access.
• Replication permissions.
• Pre-signed URL usage.
• Sensitive data exposure.

Avoid making an S3 bucket publicly accessible unless there is a documented business requirement.

8. EC2 Security

For EC2-based production workloads, review both AWS-level and operating-system-level security.

EC2 Checklist

• Use supported operating system versions.
• Apply security patches regularly.
• Remove unnecessary packages.
• Disable unused services.
• Restrict SSH access.
• Use SSH keys or approved access mechanisms.
• Avoid password-based SSH where possible.
• Avoid direct root login.
• Configure host-based firewalls where appropriate.
• Monitor system logs.
• Monitor CPU, memory, disk, and network activity.
• Encrypt EBS volumes.
• Use IAM roles for EC2.
• Review instance metadata access configuration.
• Remove unused instances.
• Review AMIs used for production deployments.

Use a controlled patching process rather than manually updating production servers without testing.

9. Database Security

Production databases should not normally be directly accessible from the public internet.

Review:

• Database is deployed in an appropriate private network.
• Security groups restrict database access.
• Encryption at rest is enabled where required.
• Encryption in transit is configured where required.
• Database credentials are protected.
• Credentials are not hard-coded into applications.
• Automated backups are enabled.
• Backup retention is appropriate.
• Recovery procedures are documented.
• Database activity is monitored.
• Unused database accounts are removed.
• Administrative access is restricted.

For applications using RDS or another managed database service, review both AWS configuration and database-level security.

10. Secrets Management

Do not store sensitive credentials directly in application source code.

Avoid:

DB_PASSWORD=password123
AWS_SECRET_ACCESS_KEY=xxxxxxxx

inside source code or publicly accessible configuration files.

Use appropriate secret-management mechanisms such as:

• AWS Secrets Manager
• AWS Systems Manager Parameter Store
• IAM roles
• KMS encryption

Review:

• Database passwords.
• API keys.
• Third-party credentials.
• SMTP credentials.
• Application secrets.
• Encryption keys.
• CI/CD credentials.

Also ensure that secrets are not accidentally written to application logs.

11. CloudTrail and Audit Logging

AWS CloudTrail provides an audit record of AWS API activity.

For production environments:

• Enable CloudTrail.
• Record required management events.
• Review data events where required.
• Centralize logs where appropriate.
• Protect the log storage location.
• Encrypt logs.
• Define log retention.
• Monitor suspicious activity.
• Validate log integrity where required.

AWS notes that the 90-day CloudTrail event history available in the console is not a replacement for creating a trail when an ongoing record is required.

For multi-account environments, AWS recommends considering centralized CloudTrail logging into a dedicated log archive account.

12. Amazon GuardDuty

Enable Amazon GuardDuty to detect potential threats and suspicious activity.

Review:

• GuardDuty enabled.
• GuardDuty enabled across required AWS Regions.
• Findings monitored.
• Findings routed to the appropriate security workflow.
• High-severity findings investigated.
• Findings retained according to requirements.

AWS Security Hub includes a control that checks whether GuardDuty is enabled and recommends enabling it in all supported Regions.

13. AWS Security Hub

AWS Security Hub can provide centralized security posture management and security findings.

Use it to review:

• Security control findings.
• AWS Foundational Security Best Practices.
• Security configuration deviations.
• GuardDuty findings.
• AWS Config findings.
• Other integrated security findings.

The AWS Foundational Security Best Practices standard contains controls that continuously evaluate AWS accounts and workloads for deviations from security best practices.

14. AWS Config

AWS Config can be used to monitor resource configuration and identify configuration changes or deviations from defined rules.

Review:

• AWS Config enabled where required.
• Required Regions covered.
• Appropriate configuration rules enabled.
• Compliance status reviewed.
• Configuration history retained.
• Findings integrated with security workflows.

In multi-account environments, AWS Prescriptive Guidance recommends centralized AWS Config administration and aggregation.

15. AWS WAF and Application Protection

For internet-facing applications, consider using AWS WAF with services such as CloudFront or Application Load Balancer.

Review:

• WAF enabled where appropriate.
• Managed rules configured.
• Rate-based protection configured where required.
• Application-specific rules configured.
• WAF logs enabled where required.
• WAF findings reviewed.
• False positives monitored.

AWS Security Hub’s foundational controls include checks for WAF protection on CloudFront distributions.

16. CloudFront Security

If CloudFront is used:

• HTTPS enabled.
• Secure TLS configuration.
• Origin access controls configured where appropriate.
• WAF associated where required.
• Access logging enabled where required.
• Cache behavior reviewed.
• Sensitive content protected.
• Direct origin access restricted where appropriate.

17. Monitoring and Alerting

Security is not complete after configuration. Production environments should continuously monitor security and operational events.

Monitor:

• Unauthorized API calls.
• IAM changes.
• Security group changes.
• Network ACL changes.
• Route table changes.
• CloudTrail activity.
• GuardDuty findings.
• Security Hub findings.
• WAF events.
• EC2 system activity.
• Application errors.
• Database activity.
• Authentication failures.

Configure alerts for high-risk events rather than generating large volumes of unactionable notifications.

18. Backup and Recovery Security

Backups should also be protected from unauthorized access and accidental deletion.

Review:

• Automated backups enabled.
• Backup retention defined.
• Backup data encrypted.
• Backup access restricted.
• Cross-account backup strategy where appropriate.
• Cross-Region recovery requirements evaluated.
• Backup deletion permissions restricted.
• Recovery procedures documented.
• Restore testing performed regularly.

A backup strategy should be tested through actual restoration rather than assuming that successful backup jobs automatically guarantee recoverability.

19. Logging Security

Logs may contain sensitive information and should be treated as production data.

Review:

• Application logs.
• Operating-system logs.
• Load balancer logs.
• CloudTrail logs.
• VPC Flow Logs where required.
• WAF logs.
• Database logs.
• Authentication logs.

Also review whether logs contain:

• Passwords.
• Access tokens.
• API keys.
• Session information.
• Personal information.
• Payment information.
• Other confidential data.

Avoid storing unnecessary sensitive information in logs.

20. CI/CD and Deployment Security

Production deployment pipelines should be treated as privileged systems.

Review:

• CI/CD platform access.
• Repository permissions.
• Deployment credentials.
• AWS IAM roles used by pipelines.
• Secrets stored securely.
• Branch protection.
• Code review requirements.
• Dependency scanning.
• Container image scanning where applicable.
• Infrastructure configuration review.
• Production deployment approvals.
• Deployment audit logs.

Avoid giving CI/CD systems unrestricted AWS administrator access when narrower permissions can be used.

AWS recommends automating security controls and integrating security into the development and deployment lifecycle.

21. Application Security

AWS infrastructure security does not replace application security.

Review:

• Authentication.
• Authorization.
• Session management.
• Input validation.
• Output encoding.
• SQL injection protection.
• Cross-site scripting protection.
• CSRF protection where applicable.
• API authentication.
• API authorization.
• Dependency vulnerabilities.
• Secure headers.
• Error handling.
• Sensitive information exposure.

Application security should be included throughout the software development lifecycle rather than being treated as a final production check.

22. Container and Kubernetes Security

For containerized production workloads, review:

• Container images are from trusted sources.
• Images are scanned for vulnerabilities.
• Images are regularly updated.
• Containers do not run with unnecessary privileges.
• Secrets are managed securely.
• Network policies are configured where applicable.
• IAM permissions are restricted.
• Kubernetes API access is restricted.
• Cluster logging and monitoring are enabled.
• Worker nodes are patched.
• Unused images and resources are removed.

For Amazon EKS, review both AWS-level controls and Kubernetes-level RBAC, network, workload, and secret-management settings.

23. Domain and DNS Security

For production applications using Amazon Route 53:

• Review hosted zones.
• Review DNS records.
• Restrict Route 53 permissions.
• Remove unused records.
• Review public and private hosted zones.
• Protect domain registrar access.
• Enable MFA for privileged access.
• Review DNS changes through audit logs.
• Use DNSSEC where appropriate and supported by the architecture.

24. Security Group Review

Perform a dedicated security-group review before production launch.

Look for rules such as:

0.0.0.0/0 -> 22
0.0.0.0/0 -> 3306
0.0.0.0/0 -> 5432
0.0.0.0/0 -> 3389

These should receive particular attention because SSH, database, and remote-administration ports generally should not be exposed publicly without a documented requirement and appropriate compensating controls.

Also identify:

• Unused security groups.
• Duplicate rules.
• Temporary rules.
• Overly broad source ranges.
• Unused ports.
• Cross-environment access.

25. Vulnerability and Patch Management

Production security requires continuous patching.

Review:

• Operating system patches.
• Application dependencies.
• Container images.
• Database versions.
• Web servers.
• Reverse proxies.
• Load balancers and related configurations.
• Security advisories.
• AWS service announcements.

Establish a documented process for identifying, testing, prioritizing, and deploying security updates.

26. Incident Response

A production environment should have a documented process for handling security incidents.

Define:

1. How an incident is detected.
2. Who receives the alert.
3. Who is authorized to respond.
4. How affected resources are isolated.
5. How credentials are revoked or rotated.
6. How evidence is preserved.
7. How affected systems are recovered.
8. How the incident is documented.
9. How lessons learned are incorporated into future controls.

AWS recommends preparing for security events and testing incident-response processes rather than waiting until an incident occurs.

27. Security Testing

Before production deployment, perform appropriate security testing.

Consider:

• Vulnerability scanning.
• Web application security testing.
• API security testing.
• Network security testing.
• IAM permission review.
• Configuration assessment.
• Dependency scanning.
• Container image scanning.
• Backup restoration testing.
• Incident-response exercises.

Testing should be performed according to the application’s scope, risk profile, and applicable AWS and organizational requirements.

---

28. Compliance and Data Protection

If the application handles regulated or sensitive information, identify the applicable requirements before production deployment.

Depending on the workload, requirements may include:

• Data protection requirements.
• Privacy requirements.
• Industry-specific controls.
• Audit requirements.
• Data retention requirements.
• Data residency requirements.
• Access-control requirements.
• Encryption requirements.

Do not assume that enabling an AWS security service automatically makes an application compliant. Compliance depends on the complete architecture, configuration, operational processes, and applicable requirements.

29. Production Security Review Checklist

Use the following checklist before approving a production workload:

Security Area	Check
AWS Account	☐ Root account secured
MFA	☐ MFA enabled for privileged access
IAM	☐ Least privilege applied
IAM Roles	☐ Workloads use roles where appropriate
Access Keys	☐ Unused/old keys removed
VPC	☐ Network segmentation reviewed
Security Groups	☐ Inbound/outbound rules reviewed
Public Access	☐ Unnecessary public exposure removed
TLS	☐ HTTPS/TLS configured
Encryption	☐ Data encrypted where required
S3	☐ Public access reviewed
EC2	☐ OS patched and hardened
Database	☐ Database access restricted
Secrets	☐ Credentials stored securely
CloudTrail	☐ Audit logging enabled
GuardDuty	☐ Threat detection enabled
Security Hub	☐ Security findings reviewed
AWS Config	☐ Configuration monitoring enabled where required
WAF	☐ Application protection reviewed
Monitoring	☐ Security alerts configured
Backups	☐ Backups enabled and protected
Restore	☐ Recovery tested
CI/CD	☐ Deployment permissions restricted
Application	☐ Security testing completed
Logging	☐ Sensitive data excluded from logs
Incident Response	☐ Response process documented
Vulnerability Management	☐ Patch process established
Compliance	☐ Applicable requirements reviewed

30. Recommended Production Security Architecture

A typical production architecture can combine multiple security layers:

                         Internet
                            |
                            v
                     Route 53 / DNS
                            |
                            v
                    CloudFront / WAF
                            |
                            v
                  Application Load Balancer
                            |
              +-------------+-------------+
              |                           |
              v                           v
       Private App Subnet          Private App Subnet
              |                           |
              +-------------+-------------+
                            |
                            v
                    Private Database
                            |
                            v
                     Encrypted Storage


       Security & Monitoring Layer
       ----------------------------
       CloudTrail
       GuardDuty
       Security Hub
       AWS Config
       CloudWatch
       VPC Flow Logs
       AWS KMS
       AWS Backup

This architecture applies security controls at multiple layers rather than depending on a single security service.

31. Security Review Frequency

Security should be treated as an ongoing operational activity.

Before Production

• Complete architecture review.
• Review IAM.
• Review network exposure.
• Review encryption.
• Review secrets.
• Review logging.
• Review backups.
• Perform security testing.

Monthly

• Review IAM access.
• Review unused resources.
• Review security-group changes.
• Review security findings.
• Review vulnerability reports.
• Review backup status.

Quarterly

• Review the overall security architecture.
• Review privileged access.
• Test backup restoration.
• Review incident-response procedures.
• Review security policies.
• Perform a broader vulnerability/security assessment.

After Major Changes

Perform another security review after:

• Major architecture changes.
• New AWS services.
• New public endpoints.
• New third-party integrations.
• Database migrations.
• Application redesigns.
• New compliance requirements.

AWS recommends continuously evolving security controls as threats, recommendations, and workload requirements change.

Conclusion

Securing an AWS production environment requires multiple layers of protection rather than a single security product. Identity controls, network segmentation, encryption, logging, threat detection, vulnerability management, application security, backups, and incident response should work together as part of the overall security architecture.

The AWS Well-Architected Security Pillar organizes security into areas including security foundations, identity and access management, detection, infrastructure protection, data protection, incident response, and application security.

Use this checklist as a baseline production-readiness review and adapt it to your application’s architecture, data sensitivity, operational requirements, and compliance obligations.

Frequently Asked Questions

1. What should be checked before deploying an AWS workload to production?

At a minimum, review IAM permissions, MFA, network exposure, security groups, encryption, secrets management, CloudTrail, monitoring, backups, vulnerability management, and incident-response procedures.

2. Should AWS production servers have public IP addresses?

Not necessarily. Internal application and database resources can often be placed in private subnets, with only the components that require direct internet exposure placed behind appropriate public-facing services.

3. Is enabling GuardDuty enough to secure an AWS account?

No. GuardDuty provides threat detection, but production security requires multiple controls covering identity, infrastructure, data protection, logging, monitoring, application security, and incident response.

4. How often should an AWS security review be performed?

Security should be monitored continuously, with periodic reviews of IAM, network access, security findings, vulnerabilities, backups, and architecture. A new review should also be performed after significant infrastructure or application changes.

5. Should production data always be encrypted?

Encryption requirements depend on the data and applicable requirements, but encryption at rest and in transit should be evaluated for production workloads, particularly when handling sensitive or regulated information.

6. What AWS services can help with production security?

Depending on the workload, commonly used services include IAM, AWS Organizations, CloudTrail, GuardDuty, Security Hub, AWS Config, AWS WAF, KMS, CloudWatch, Macie, and AWS Backup.

Related Articles

• AWS Cost Optimisation Checklist
• AWS Infrastructure Architecture for Startups
• How to Troubleshoot SSH Connection Issues in AWS EC2

Talk to Our Technology Experts

Planning your AWS infrastructure or looking to improve an existing cloud environment? Our team can help with cloud architecture, infrastructure, DevOps, security, deployment, and ongoing optimization.

Connect with our technology experts.