AWS Cloud Security Best Practices: A Defender's Guide

Open the IAM console on an account that has run for two years and read the credential report. You will usually find an access key that has not rotated since the account was created, a few users with AdministratorAccess attached directly, and a root account whose MFA status reads "not enabled." None of that is an AWS bug. Each is a default left unchanged, and each is the kind of setting that turns a stolen key into a full account takeover.

AWS cloud security best practices are the specific, account-level controls that close those gaps: turn on this log, scope that role, block that bucket, encrypt that volume. AWS secures the infrastructure under your account. Everything inside it is yours to configure, and the configuration is where breaches happen.

This guide is the defender's checklist for an AWS account. It covers the shared responsibility model that tells you which controls are yours, then the practices that matter most: hardening the root account, least-privilege IAM, logging and threat detection (CloudTrail, Config, GuardDuty), encryption with KMS, network segmentation with VPCs and security groups, blocking public S3 access, and measuring it all against the CIS AWS Foundations Benchmark. Each practice is one thing to do, why it matters, and how to do it. Written for blue teamers: SOC analysts, incident responders, and students prepping for detection-and-response work who inherit an AWS account and have to make it defensible.

What "AWS cloud security best practices" actually means

AWS cloud security is the set of controls a customer configures to protect the workloads, data, and identities they run in Amazon Web Services. It is the AWS-specific application of cloud security, and best practices are the subset of controls that AWS, the CIS benchmark, and breach post-mortems agree reduce the most risk for the least effort.

Three shifts make this its own discipline rather than data-center security with new logos:

• Identity is the perimeter. Every AWS API call is authenticated by a credential and reachable from anywhere. Steal a key or assume the wrong role and you are inside, no network boundary to cross. IAM, not the firewall, is the first control to get right.
• Configuration is the attack surface. Resources are created by API call in seconds. One wrong setting, a public bucket, a security group open to 0.0.0.0/0, an over-broad policy, exposes data instantly. The most common cause of a cloud data breach is a setting, not an exploit.
• Nothing is logged until you ask for it. An account records almost nothing about control-plane activity until CloudTrail is on. The blind spot is the default state.

These practices exist to close those three gaps, roughly in that order.

Start with the shared responsibility model

Before any specific control, know which controls are yours. The shared responsibility model is AWS's definition of the split: in AWS's own words, "AWS manages security of the cloud, you are responsible for security in the cloud." AWS owns the hardware, hypervisor, facilities, and managed-service internals. You own everything you put on top. Where the line falls depends on the service.

The more managed the service, the more AWS takes on: a managed database means AWS patches the engine; an EC2 instance means you patch the guest OS. But three things never leave the customer, regardless of service: your data, your IAM identities and policies, and your configuration. Every practice below sits on the customer side of that line. "We run on AWS, so we are secure" is a category error: AWS's infrastructure can be hardened while your account sits wide open.

Best practice 1: Lock down the root account

The root user can do anything, including delete the account, and cannot be restricted by IAM policy. It is the single most valuable credential in the environment, and on a neglected account it is often the weakest: no MFA, an active access key, used for daily work.

Why it matters. A compromised root account is game over. No SCP, permission boundary, or deny policy applies to it, so an attacker who reaches root owns everything and can lock you out.

How to do it. AWS's guidance is to lock root credentials away and not use them for routine work:

• Enable MFA on root, ideally a phishing-resistant hardware key or passkey, which AWS now recommends wherever possible.
• Delete any root access keys. Root should have no programmatic credentials at all.
• Use root only for the few tasks that require it; operate day to day as IAM identities or federated roles.
• In a multi-account AWS Organization, protect the management account's root most, since it governs every member account.

The CIS AWS Foundations Benchmark's first controls check exactly these: root MFA and the absence of root access keys.

Best practice 2: Enforce least-privilege IAM and kill long-lived keys

IAM is the perimeter, so most of your security effort belongs here. The two failure modes are over-privileged identities (a role that can do far more than its workload needs) and long-lived static keys (an access key that never expires and leaks into code, an AMI, or a laptop).

Why it matters. Once an attacker holds a valid credential, the control plane sees normal activity, because to AWS it is normal activity. An over-broad policy turns one stolen key into lateral movement and privilege escalation: a role that can pass another role, or edit its own policy, is an admin path waiting to be walked.

How to do it, in AWS's recommended order:

• Prefer temporary credentials over static keys. Human users reach AWS through federation (IAM Identity Center or an external IdP) and assume roles for short-lived credentials. Workloads on EC2, Lambda, or ECS use IAM roles, never embedded keys. Reserve long-term access keys for the narrow cases that cannot use a role, and rotate them.
• Grant least privilege. Grant only the actions and resources a task needs. Use IAM Access Analyzer to generate fine-grained policies from real CloudTrail activity and to validate policies before they ship.
• Remove what is unused. IAM last-accessed information shows which permissions, users, roles, and keys have gone cold. Strip them on a schedule.
• Set guardrails across accounts. In an AWS Organization, use service control policies (SCPs) to cap what any principal in an account can do regardless of their IAM policy.
• Require MFA on every human IAM user, not just root.

The goal: no single credential, if stolen, grants more than the narrow slice of access its owner actually used.

Best practice 3: Turn on CloudTrail, Config, and GuardDuty

An AWS account is blind by default. None of the core security services are on in a way a SOC can use, and an intrusion in an unlogged account leaves nothing to investigate.

Why it matters. Detection and forensics in the cloud run on these logs. The "we did not notice for months" outcome is what an unlogged account guarantees. You cannot detect, alert on, or reconstruct what was never recorded.

How to do it. Enable all three, in every account and region, and centralize the output:

• CloudTrail. Create an organization trail that logs management events across every account and region to a dedicated, locked-down S3 bucket, and forward it to your SIEM. Turn on log-file validation so tampering is detectable. This is the control-plane audit log: every AssumeRole, every PutBucketPolicy, every console login.
• AWS Config. Record resource configuration over time, and attach managed rules that flag drift, an unencrypted volume, a public bucket, an open security group, the moment it appears.
• GuardDuty. Enable this managed threat-detection service org-wide. It analyzes CloudTrail, VPC Flow Logs, and DNS logs for known-bad patterns: crypto-mining, credential exfiltration, reconnaissance, traffic to known-malicious IPs. No agents, runs continuously.

Add VPC Flow Logs for network visibility and route everything to one place. Centralized logging is the precondition for every detection you will ever write.

Best practice 4: Encrypt data at rest and in transit with KMS

Encryption is the control that limits blast radius. When a misconfiguration or a leaked credential exposes a store anyway, encryption decides whether the attacker gets data or ciphertext.

Why it matters. Most AWS data services can encrypt at rest with almost no effort, and several now default to it. Leaving it off, or managing keys carelessly, throws away the one control that contains a breach after other controls have failed.

How to do it.

• At rest: enable encryption on S3 buckets, EBS volumes, RDS databases, and snapshots. Use AWS Key Management Service (KMS) and prefer customer-managed keys (CMKs) for sensitive data, so you control the key policy, rotation, and who can decrypt. Turn on automatic key rotation.
• In transit: require TLS everywhere. Enforce it with bucket and resource policies that deny requests where aws:SecureTransport is false, so an unencrypted connection is rejected, not merely discouraged.
• Manage keys deliberately: the KMS key policy is an access-control decision. Scope who can use and who can administer each key, and log key usage through CloudTrail.

Encryption does not stop the misconfiguration. It makes the misconfiguration survivable.

Best practice 5: Segment the network with VPCs, security groups, and NACLs

Identity is the primary perimeter, but the network still matters. A workload reachable from the whole internet is exposed before any credential is even tried, and flat networks let a single compromised host reach everything.

Why it matters. A security group open to 0.0.0.0/0 on a database or admin port is one of the most common and most exploited AWS misconfigurations. Network segmentation contains a compromise so one foothold does not become the whole account.

How to do it.

• Private by default. Place workloads in private subnets with no direct internet route. Put only what must be public (a load balancer) in a public subnet, and reach private instances through Systems Manager Session Manager or a bastion, not open SSH/RDP.
• Tighten security groups. These are stateful instance-level firewalls. Allow only the ports and source ranges each workload needs. Never leave 0.0.0.0/0 on management ports (22, 3389) or databases.
• Use NACLs as a coarse backstop. Network ACLs are stateless subnet-level filters, useful for broad subnet-wide deny rules beneath the per-instance security groups.
• Restrict egress, not just ingress. Default-deny outbound limits how a compromised host beacons to command-and-control or exfiltrates data.

The principle is the one segmentation always served: shrink what any one compromised component can reach.

Best practice 6: Block public access to S3

Public S3 buckets are the archetypal cloud leak: no exploit, no malware, just storage left readable to the internet. AWS has made this harder, but the responsibility is still yours.

Why it matters. A public bucket exposes its contents to anyone who finds the name, and automated scanners find them fast. Many of the largest "cloud breaches" in the news were exactly this.

How to do it.

• Turn on S3 Block Public Access at the account level. This master switch overrides any bucket policy or ACL that would grant public access. It has four independent settings: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets. AWS recommends enabling all four. Since April 2023, new buckets enable Block Public Access by default, but existing buckets and the account-level setting still need confirming.
• Disable ACLs. Use bucket policies for access control and set object ownership to bucket-owner-enforced so legacy ACLs cannot grant access.
• Audit with IAM Access Analyzer for S3, which surfaces every bucket that allows public or cross-account access.

If a bucket must serve public content, do it through a CloudFront distribution with origin access control, not by opening the bucket.

Best practice 7: Measure against the CIS AWS Foundations Benchmark

Best practices only hold if you can prove they are still in place. The CIS Amazon Web Services Foundations Benchmark is the consensus configuration baseline, and it turns "are we secure?" into a list of pass/fail checks.

Why it matters. Accounts drift. A benchmark gives you an objective, repeatable score across IAM, logging, monitoring, networking, and storage, the same domains the practices above cover, instead of relying on memory or one engineer's habits.

How to do it.

• Use the current benchmark. The CIS AWS Foundations Benchmark is at version 7.0.0. Map your account against it, and treat its IAM, CloudTrail, Config, and S3 controls as the baseline the practices above aim at.
• Automate the check. AWS Security Hub runs the CIS benchmark (and the AWS Foundational Security Best Practices standard) continuously and scores every account, so drift shows up as a failed control rather than a surprise during an incident.
• Close findings as incidents. A failed control, root MFA off, a public bucket, CloudTrail disabled in a region, is an exposure with a clock on it, not a line item to file.

The benchmark is not the whole of AWS security, but an account that passes it has the foundational controls in place, and a documented score is what turns best practices into something you can audit.

AWS cloud security best practices checklist

The practices above, condensed to a working checklist. Each line is a control you can verify in the console or with a script.

Work top to bottom. The order is roughly the order of blast radius: a compromised root or an over-privileged identity loses the whole account, while a single un-encrypted volume loses one store.

The bottom line

AWS cloud security best practices come down to configuring the customer side of the shared responsibility model well: AWS secures the infrastructure, you secure the identities, configuration, and data on top of it. The practices that move the most risk are the unglamorous ones: an MFA token on root, a scoped IAM role instead of a long-lived key, CloudTrail and GuardDuty on in every region, encryption with managed keys, a private subnet, and a bucket that is not public.

None of these are exotic. They are defaults left unchanged on most accounts, which is exactly why getting them right separates a defensible AWS environment from a breached one. Measure the result against the CIS AWS Foundations Benchmark so the controls hold as the account grows.