AWS Security Best Practices: A 2026 Checklist for Your Account

The AWS security best practices that matter most in 2026 are simple to name: sign in through short-lived credentials instead of long-term keys, grant each person and workload only the permissions it needs, keep data private and encrypted, turn on threat detection and logging in every account, and patch and back up on a schedule. AWS secures the hardware and the services it runs, but how you configure your account is your job. Most cloud incidents come from that second half, not the first.

This guide walks through each practice in the order we would tackle it on a real account, names the AWS service that does the work, and flags what AWS now does for you by default. Service names and defaults are current as of October 2026.

Why AWS security still needs your attention

AWS splits the work under its shared responsibility model. AWS is responsible for the security "of" the cloud: data centres, hardware, networking and the software behind managed services. You are responsible for security "in" the cloud: who can sign in, what they can touch, how your data is stored and who can reach your applications.

Getting that half wrong is expensive. IBM's Cost of a Data Breach Report 2026 puts the global average cost of a breach at $4.99 million, a 12% rise on the year before and a record high. The same report finds that organisations making extensive use of AI and automation in security save $1.93 million compared with those using none.

The good news is that most of the controls below are built into AWS, many cost little or nothing, and several are now switched on by default.

AWS security best practices at a glance

1. Lock down the root user and require MFA

The root user can do anything in an account, including closing it. Use it only for the few tasks that need it, never for daily work, and never create access keys for it.

AWS has made this harder to get wrong. In June 2025 it announced that MFA is enforced for root users across all account types, including member accounts in AWS Organizations. If you run several accounts, AWS recommends going one step further: use centralised root access management so member accounts have no root credentials at all.

For everyone else who signs in, the IAM best practices guide says to require MFA and to prefer phishing-resistant options such as passkeys and hardware security keys.

2. Replace long-term keys with temporary credentials

Leaked access keys are one of the most common ways into an AWS account. They end up in code repositories, laptops and CI logs, and they work until someone deletes them.

AWS's own guidance is to remove them wherever you can:

• People should sign in through an identity provider and receive temporary credentials. AWS recommends IAM Identity Center for this, connected to your existing directory if you have one.
• Workloads on AWS, such as EC2 instances and Lambda functions, should use IAM roles. AWS delivers short-lived credentials to them automatically.
• Workloads outside AWS, including CI/CD pipelines, can use IAM Roles Anywhere or web identity federation instead of stored keys.

Where a tool genuinely cannot use roles, keep the key, scope it tightly and replace it when someone with access leaves. IAM's "last used" data shows which keys are idle and safe to remove.

3. Apply least privilege and review it often

Least privilege means each identity can perform only the actions it needs, on the resources it needs, under the conditions you set. Teams often start with broad AWS managed policies to get moving. That is fine, as long as you narrow them later.

IAM Access Analyzer does most of the heavy lifting here. It can:

• Generate a tight policy based on what a role actually did, using CloudTrail activity.
• Flag resources shared publicly or with other accounts, such as S3 buckets, KMS keys and IAM roles.
• Check new policies against more than 100 rules before you save them.

Add conditions where they help, for example requiring TLS on every request, and remove users, roles and policies that nobody has used in months.

4. Separate accounts and set guardrails

One account for everything means one mistake can reach everything. Split production, staging and development into separate accounts under AWS Organizations, and keep logs and security tooling in their own accounts too.

Then set guardrails at the organisation level. Service control policies (SCPs) cap what any identity in an account can do, and resource control policies (RCPs) cap what can be done to your resources. Neither grants access on its own; they set the outer limit. A common first SCP blocks the use of Regions you never operate in.

5. Keep data private and encrypted

Public S3 buckets caused years of headlines, and AWS has changed the defaults in response:

• Since January 2023, Amazon S3 encrypts every new object by default with SSE-S3 at no extra cost.
• Since April 2023, every new bucket has S3 Block Public Access turned on and ACLs turned off by default.

Two gaps remain. Buckets created before those dates keep their old settings, so audit them. And default encryption uses keys AWS manages; for regulated or sensitive data, use AWS Key Management Service (KMS) with your own customer managed keys, so you control who can decrypt and every use of the key is logged. Turn on Block Public Access at the account level too, so a single bucket setting cannot undo it.

Encrypt data in transit as well: serve your applications over HTTPS with certificates from AWS Certificate Manager, and require TLS for connections to databases.

6. Secure the network edge

Put databases and application servers in private subnets of your Amazon VPC, and expose only load balancers or CloudFront to the internet. Security groups should allow the smallest set of ports and sources possible; an SSH port open to the whole internet is still a common finding. Systems Manager Session Manager lets you reach instances without opening SSH at all.

For web applications, AWS WAF filters requests before they reach your code, with managed rule groups for common attacks such as SQL injection and cross-site scripting. Against denial of service, AWS says all customers get Shield Standard automatically, at no additional charge, with the strongest protection for resources behind CloudFront, Route 53 and Global Accelerator.

On EC2, configure the instance metadata service to accept only IMDSv2. Its session tokens add a layer of defence against server-side request forgery attacks that try to steal instance credentials.

7. Log everything and turn on threat detection

You cannot respond to what you cannot see. CloudTrail is on by default, but its event history keeps only the last 90 days of management events in each Region. Create an organisation trail or a CloudTrail Lake event data store so you have a lasting record, and send it to a separate log archive account that ordinary admins cannot change.

On top of logging, three services do most of the detection work:

• Amazon GuardDuty watches CloudTrail, network and DNS activity for threats such as stolen credentials and crypto mining.
• Amazon Inspector scans EC2 instances, container images and Lambda functions for known vulnerabilities.
• AWS Security Hub brings the findings together. Its December 2025 general availability release added near real-time risk analytics that correlate signals from GuardDuty, Inspector and Security Hub CSPM, so you see which issues combine into a real exposure.

Enable them across every account and Region you use, not just the main one. Attackers often launch resources in Regions nobody is watching.

8. Patch on a schedule

Managed services such as Lambda, RDS and Fargate shift much of the patching to AWS, which is one reason to use them. For EC2 instances, the work is yours. AWS Systems Manager Patch Manager applies operating system patches on a schedule using baselines you define and reports which instances are behind. Pair it with Inspector findings to decide what to patch first.

Keep your application dependencies current too. A fully patched server running an outdated web framework is still exposed.

9. Back up and plan your response

Backups are your answer to ransomware, accidental deletion and bad deployments. AWS Backup sets one policy across services such as EBS, RDS, DynamoDB, EFS and S3. For protection against a compromised admin account, copy backups to a separate account and use AWS Backup Vault Lock so they cannot be deleted early. Test restores regularly; an untested backup is a hope, not a plan.

Write down what happens when GuardDuty raises a serious finding: who is told, how a compromised key is disabled, how an instance is isolated and how evidence is kept. Define your infrastructure as code with AWS CloudFormation or a similar tool, so a clean environment can be rebuilt quickly.

A 30-day AWS security checklist

How Codeeo can help secure your AWS setup

Codeeo builds and maintains web platforms and custom software, and is trusted by 200+ companies. If your application runs on AWS and you are not sure how it measures up against these practices, our custom software team can review the account setup alongside the application code and fix what we find. If you need ongoing hands on an AWS workload, you can add dedicated developers to your team, or contact us to talk it through.