AWS security best practices: 15 ways to secure your AWS environment

AWS security best practices are the controls that keep your identities, data, networks, workloads and logs under your control. They include MFA and least-privilege IAM, temporary credentials, KMS encryption, private networking, organization-wide logging, managed threat detection, multi-account guardrails and tested backups. Most AWS incidents start with a customer mistake rather than an exploit against AWS itself: a bucket left public, an access key committed to a Git repository, a security group open to 0.0.0.0/0 on port 22, or a role that can do far more than its workload needs. This guide covers 15 AWS security best practices, grouped into identity, data, network and workloads, and detection and governance. For each one, it explains what to configure, which mistakes teams repeat, and how to validate the control. It reflects AWS services and guidance as of October 2026 and ends with a prioritised plan and a checklist you can work through in order.

Why AWS security starts with the shared responsibility model

AWS secures the infrastructure that runs its services, and you secure everything you build and configure on top of it. AWS describes this split as AWS protecting the infrastructure of the cloud while you provide security in the cloud. In practice, AWS handles the data centres, hypervisors, hardware and managed service internals. You own IAM, data classification, encryption choices, network rules, guest operating systems, application code and logging.

That boundary explains why misconfiguration dominates AWS risk. AWS cannot stop you from attaching AdministratorAccess to a Lambda function. The same principle sits at the centre of the broader cloud security best practices that apply across providers. The table below maps the main AWS attack surfaces to the insecure configurations attackers look for and the secure replacement for each.

Identity and access best practices

Identity is the primary perimeter in AWS, so the first four practices control who and what can call AWS APIs.

1. Lock down the root user and require MFA

The root user can change billing, close the account and bypass IAM policies in a standalone account. If an attacker takes it, you lose the account. Delete any root access keys and register a hardware security key or passkey as the root MFA device. Use root only for the few tasks that require it. In AWS Organizations, centralised root access management lets you remove root credentials from member accounts entirely. Require MFA for every human user through IAM Identity Center.

Common mistake: the root MFA device lives on one engineer’s phone, with no documented recovery path.

Validate: generate the IAM credential report and confirm the root row shows mfa_active = true and access_key_1_active = false. Then add an EventBridge rule that alerts on any root ConsoleLogin event.

2. Replace long-term access keys with roles and temporary credentials

Long-lived access keys leak through repositories, laptops and CI logs, and they keep working until someone deactivates them. Use these alternatives instead:

• ✓IAM Identity Center for human users
• ✓Instance profiles for EC2
• ✓Task roles for ECS
• ✓EKS Pod Identity or IAM Roles for Service Accounts for Kubernetes
• ✓Execution roles for Lambda
• ✓OIDC federation for pipelines such as GitHub Actions, so no static keys are stored in CI

Common mistake: one “deploy” IAM user’s keys are shared across every pipeline.

Validate: flag any key older than 90 days in the credential report. Keys starting with AKIA are long-term, while ASIA keys are temporary, so scan code and images for the AKIA prefix.

3. Enforce least privilege with Access Analyzer and permission boundaries

Over-permissive roles turn a small foothold into account takeover. Use IAM Access Analyzer policy generation to build policies from actual CloudTrail activity, and use unused access findings to remove idle roles and permissions. For example, a role unused for 120 days should be deleted rather than kept “just in case”. Attach permission boundaries when you let developers create roles, so they cannot grant more than the boundary allows.

Common mistake: AWS managed policies such as PowerUserAccess are applied as a temporary fix and never replaced.

Validate: run aws iam simulate-principal-policy against sensitive actions such as iam:PassRole or kms:Decrypt and confirm they return implicitDeny. Add Access Analyzer policy validation and custom policy checks to CI so broad grants fail the build.

4. Control cross-account and external access

Resource policies and trust policies can grant access to principals outside your organization without anyone noticing. Use these patterns:

• ✓Require sts:ExternalId in trust policies for third-party roles.
• ✓Add aws:PrincipalOrgID conditions to S3, KMS and SQS resource policies.
• ✓Run an Access Analyzer external access analyzer with your organization as the zone of trust.

Validate: work active Access Analyzer findings down to zero, archiving only access you have documented as intended.

Data protection best practices

Data protection in AWS means encrypting by default, refusing unencrypted and public access, and knowing where sensitive data lives.

5. Encrypt data at rest with KMS and treat key policies as access control

Turn on these controls:

• ✓EBS encryption by default in every region you use
• ✓Encryption at RDS creation time (enabling it later requires a snapshot copy and restore)
• ✓SSE-KMS with customer managed keys for sensitive S3 data
• ✓Automatic key rotation, which defaults to yearly and can be set between 90 and 2,560 days
• ✓S3 Bucket Keys to cut the volume of KMS requests and their cost

Client-side encryption keeps plaintext away from AWS entirely. The tradeoff is that you lose server-side features such as Macie inspection, and you take on key distribution yourself.

Common mistake: a key policy that delegates everything to the account, combined with broad IAM policies, lets any administrator decrypt any data.

Validate: use the AWS Config rules encrypted-volumes, rds-storage-encrypted and s3-default-encryption-kms, and run aws ec2 get-ebs-encryption-by-default per region.

6. Block public access and enforce TLS in transit

Take these steps:

1. Enable S3 Block Public Access at the account level.
2. Set Object Ownership to “bucket owner enforced” to disable ACLs.
3. Serve public content through CloudFront with Origin Access Control instead of public buckets.
4. Use short-lived presigned URLs for direct downloads.
5. Set rds.force_ssl on databases.

The bucket policy below rejects any request that does not use TLS:

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

Validate: send an HTTP (not HTTPS) request to the bucket endpoint and confirm a 403. Then run aws s3control get-public-access-block to confirm all four settings are true.

7. Manage secrets and discover sensitive data

Store credentials in Secrets Manager with automatic rotation, or in Parameter Store as SecureString. Keep them out of user data, AMIs, container images and plaintext Lambda environment variables. Use Amazon Macie automated sensitive data discovery to find PII in S3 buckets you did not know held it.

Validate: run secret scanning on repositories and images, review Macie findings, and alert on GetSecretValue calls from unexpected principals in CloudTrail.

Network and workload security best practices

Network and workload controls limit what an attacker can reach and what they can run once they get in.

8. Build private VPCs with tight security groups and VPC endpoints

Place workloads in private subnets and expose only load balancers publicly. Reference security groups by ID rather than CIDR ranges where possible. Replace bastion hosts and open SSH or RDP with Systems Manager Session Manager, which also logs sessions. Route S3 and DynamoDB traffic through gateway endpoints, and use endpoint policies to restrict access to your own buckets.

Common mistake: port 22 or 3389 is open to 0.0.0.0/0 for “temporary” troubleshooting and never closed.

Validate: use the Config rules restricted-ssh and vpc-sg-open-only-to-authorized-ports. Network Access Analyzer can prove that no internet path reaches your database subnets.

9. Protect internet-facing applications with WAF and Shield

Attach AWS WAF to CloudFront, Application Load Balancers and API Gateway. Start with these rule groups:

• ✓AWS Managed Rules core rule set
• ✓Known bad inputs rule group
• ✓Rate-based rules to slow credential stuffing

Shield Standard applies automatically. Consider Shield Advanced for revenue-critical endpoints.

Common mistake: rules are left in Count mode indefinitely after rollout.

Validate: review sampled requests, then send a burst of requests above the rate-based threshold and confirm they are blocked.

10. Harden compute and prioritise vulnerabilities by real exposure

Require IMDSv2 on every instance so server-side request forgery cannot read role credentials from instance metadata. Build from patched golden AMIs, remove unneeded packages, and use Systems Manager Patch Manager for operating system updates. Enable Amazon Inspector for EC2, ECR images and Lambda.

Ranking by CVSS alone produces an unworkable backlog. Prioritise vulnerabilities that are internet-exposed, sit in packages actually loaded at runtime, and run under privileged roles.

Validate: use the Config rule ec2-imdsv2-check and check the Inspector coverage dashboard for unscanned resources.

Detection, governance and resilience best practices

The last five practices make sure you see attacks, keep every account inside guardrails, prove compliance and recover when prevention fails.

11. Enable organization-wide CloudTrail and centralise logs

Create an organization trail that covers all regions and delivers to a dedicated log archive account. Lock that S3 bucket with Object Lock, encrypt it with KMS and enable log file validation. Add these sources:

• ✓S3 and Lambda data events for sensitive buckets and functions
• ✓VPC Flow Logs
• ✓Route 53 Resolver query logs

Validate: run aws cloudtrail validate-logs to check integrity. Then perform a GetObject on a monitored bucket and confirm the data event appears.

12. Turn on GuardDuty, Security Hub and Detective with delegated administration

GuardDuty provides continuous threat detection across CloudTrail, VPC Flow Logs, DNS and runtime telemetry. Security Hub collects findings from GuardDuty, Inspector, Macie, AWS WAF and supported third-party tools through EventBridge. Detective supports deeper investigation. Assign a security tooling account as delegated administrator for all three so member accounts cannot opt out. Use GuardDuty suppression rules and Security Hub automation rules for approved activity. Most teams then layer specialist AWS security tools on top for runtime and cross-cloud context.

Validate: run aws guardduty create-sample-findings and confirm the finding reaches your SIEM or ticketing queue.

13. Govern with a multi-account landing zone and SCPs

Use AWS Organizations, ideally through Control Tower, with separate organizational units (OUs) for these purposes:

• ✓Security (log archive and security tooling accounts)
• ✓Infrastructure
• ✓Production workloads
• ✓Non-production workloads
• ✓Sandbox

Service control policies set the maximum permissions for each account. Resource control policies cap what resources will accept, regardless of who is calling. The SCP below stops anyone in a member account from disabling logging or threat detection:

{
  "Effect": "Deny",
  "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail",
             "guardduty:DeleteDetector", "config:StopConfigurationRecorder",
             "organizations:LeaveOrganization"],
  "Resource": "*"
}

Validate: attempt cloudtrail:StopLogging from a member account administrator role and confirm AccessDenied.

14. Prove compliance continuously with Config, conformance packs and IaC

Run the AWS Config recorder in every account and region, and deploy conformance packs as audit-ready evidence. Security Hub standards include AWS Foundational Security Best Practices, the CIS AWS Foundations Benchmark, NIST SP 800-53 Rev. 5, NIST SP 800-171 Rev. 2 and PCI DSS. Define infrastructure in CloudFormation or Terraform and scan templates with policy-as-code tools such as cfn-guard or Checkov before deployment. Run drift detection to catch console changes after deployment. Many teams also evaluate cloud security posture management tools for multi-cloud coverage.

Validate: export Config compliance history per rule as audit evidence, and confirm drift detection reports “IN_SYNC” for production stacks.

15. Build ransomware-resistant backups and rehearse incident response

Set up these recovery controls:

• ✓AWS Backup with Vault Lock in compliance mode
• ✓Cross-account and cross-region backup copies
• ✓S3 versioning with Object Lock, and MFA Delete on critical buckets
• ✓RDS point-in-time recovery

Write and rehearse playbooks for these response steps:

1. Isolate an EC2 instance by swapping it to a quarantine security group.
2. Snapshot its EBS volumes for forensics.
3. Revoke active role sessions with a deny on aws:TokenIssueTime.
4. Deactivate compromised keys.

Validate: run quarterly restore tests and record the actual recovery time and data loss against your RTO and RPO targets.

How Upwind supports AWS security best practices

Upwind is a runtime-first CNAPP that combines agentless discovery of your AWS accounts with lightweight eBPF sensors on EC2, containers and Kubernetes. It covers CSPM, CWPP, CIEM, vulnerability management, Kubernetes, API security, DSPM and cloud detection and response in one platform. It earns 4.8/5 from 88 reviews on Gartner Peer Insights as of October 2026, with reviewers singling out its runtime visibility and how easy it is to set up in AWS. A few reviewers note the platform is still maturing compared with larger, longer-established CNAPP vendors.

• ✓Prioritises CVEs that are reachable, in loaded packages and internet-exposed (practice 10)
• ✓Shows which identities and permissions are actually used, to support least privilege (practice 3)
• ✓Correlates kernel-level runtime telemetry with IAM and cloud configuration into Threat Stories with timelines and root cause (practices 12 and 15)
• ✓Maps which APIs and data stores carry sensitive data (practice 7)

AWS security best practices checklist

The best order is to remove account-takeover risk in the first 24 hours, build visibility and guardrails within 30 days, and harden and rehearse within 90 days.

AWS security documentation to keep close

• ✓AWS Security Reference Architecture for account layout and delegated administration
• ✓Security Pillar of the AWS Well-Architected Framework for design reviews
• ✓AWS Security Best Practices whitepaper for control rationale
• ✓CIS AWS Foundations Benchmark for an auditable baseline

Apply these AWS security best practices in the order above and validate each control rather than assuming it works. Combine prevention, detection and tested recovery, and an attacker who gets one foothold in your environment will find very little to build on.

FAQ