AWS Security Guide

Most AWS compromises do not start with a flaw in AWS: they start with a leaked access key, an over-permissive role, a public bucket or an instance metadata endpoint that hands out credentials. AWS's native controls only protect an estate structured to use them: separate accounts, organisation-wide guardrails, central logging and least-privilege identities. This guide covers the multi-account foundation (AWS Organizations, Control Tower and the AWS Security Reference Architecture), service and resource control policies, IAM and IAM Identity Center, root user protection, logging and detection with CloudTrail, GuardDuty, Security Hub CSPM and Config, data protection for S3 and KMS, network and compute hardening, and the AWS Foundational Security Best Practices and CIS benchmarks. It is written for cloud security engineers, platform teams and architects who run or inherit AWS organisations.

Key takeaways

• Accounts are the security boundary. Use AWS Organizations with separate accounts for security tooling, logs, networking and each workload, not one large account with clever IAM policies.
• Guardrails cap permissions, they never grant them. SCPs limit what your principals can do and RCPs limit what any principal can do to your resources; both must be tested on a small OU before they reach the root.
• Identity is the main attack path. Federate people through IAM Identity Center, give workloads IAM roles with temporary credentials, remove long-term access keys and lock away root credentials.
• Turn detection on everywhere at once. An organisation trail, GuardDuty, Security Hub CSPM and AWS Config, each run from a delegated administrator account, give coverage that member accounts cannot switch off.
• Defaults have improved, legacy has not. New S3 buckets block public access and disable ACLs, but older buckets, IMDSv1 instances and access keys created years ago still need finding and fixing.

Build the multi-account foundation first

AWS Control Tower describes a landing zone as "a well-architected, multi-account environment that's based on security and compliance best practices". Control Tower orchestrates AWS Organizations, AWS Service Catalog and IAM Identity Center to build one, and its Account Factory provisions new accounts with pre-approved configuration. The AWS Security Reference Architecture (AWS SRA), described by AWS as "a holistic set of guidelines for deploying the full complement of AWS security services in a multi-account environment", uses the following structure.

AWS notes that "not every workload or environment, based on its unique threat exposure, has to deploy every security service", so tailor the SRA rather than copy it. The Well-Architected Framework security pillar supplies the design principles behind it, starting with a strong identity foundation that avoids reliance on long-term static credentials. Two rules hold in every variant: the management account holds no workloads, and log and tooling accounts are separate from the accounts they watch, so an attacker who owns a workload account cannot erase the evidence.

Guardrails: SCPs, RCPs and Control Tower controls

AWS Organizations offers two permission guardrails. AWS documents the split clearly: "Use an SCP when you need to limit permissions of IAM principals within your organization's member accounts. Use an RCP when you need to restrict IAM principals that are external to your organization accounts making requests to access resources within your organization's member accounts." Effective permissions are the intersection of what SCPs and RCPs allow with what identity-based and resource-based policies allow. Neither grants anything.

For both SCPs and RCPs, AWS "strongly recommends" not attaching to the organisation root without testing: attach to a test account, then a low OU, then work upwards, using IAM last accessed information and CloudTrail to see what a deny would break. Keep a documented exception OU for emergencies.

Identity: people, workloads and root

People

• IAM Identity Center (formerly AWS Single Sign-On): AWS calls the organisation instance "the best practice" and the only instance type that manages access to AWS accounts. Connect your identity provider over SAML 2.0, provision users and groups with SCIM, and define permission sets per job function. Users get short-lived role sessions, not IAM user keys. See the Identity Provider and SSO Security Guide.
• Privileged access: keep administrator permission sets small, time-bound and approved, and require phishing-resistant MFA at the identity provider. See the Cloud PAM and CIEM Guide and the JIT Access Guide.

Root user

• Centralise root access: with "Centrally manage root access for member accounts" you can delete root passwords, access keys and signing certificates from member accounts, and AWS states that "New accounts you create in Organizations have no root user credentials by default." Root-only tasks, such as unlocking a bucket policy that denies all principals, then run as privileged tasks from the management account or a delegated administrator for IAM.
• Management account root: it still has credentials. Protect them with hardware MFA (FSBP control IAM.6 checks this), keep no access keys, and store recovery details under break-glass procedures. See the Break-Glass Account Guide.

Workloads and access keys

• Roles, not keys: EC2 instance profiles, Lambda execution roles, ECS task roles, EKS Pod Identity or IRSA, and OIDC federation for CI/CD all issue temporary credentials. AWS's S3 guidance is blunt: "We recommend not storing AWS credentials directly in the application or Amazon EC2 instance." See the Cloud Workload Identity Guide and the CI/CD Pipeline Identity Security Guide.
• Remaining access keys: inventory them, assign an owner, rotate or replace them, and store any that must exist in Secrets Manager rather than code or .env files. The 230 Million AWS Cloud Environments campaign harvested keys from exposed .env files at scale. See the API Key Management Guide and the Secrets Management Guide.
• Least privilege with IAM Access Analyzer: with the zone of trust set to the organisation, use external access findings, unused access findings ("unused roles, unused access keys for IAM users, and unused passwords for IAM users", plus unused actions), policy validation, custom policy checks in pipelines and policy generation from CloudTrail. Unused access and custom checks are charged.
• Roles are non-human identities: each needs an owner, a purpose and a trust policy naming exactly who can assume it. See the Service Account Security Guide.

Logging and detection services

Enable each service organisation-wide from a delegated administrator in the Security Tooling account, with auto-enable for new accounts, so a new workload account is covered from its first minute.

CloudTrail event history keeps only 90 days of management events, so a trail is not optional. Forward findings and trail events to your SIEM; see the Log Management and Retention Guide and the SIEM Guide.

Data protection: S3 and KMS

• Block Public Access: the four settings are BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy and RestrictPublicBuckets. They can be set at organisation level (all four together, through an Organizations S3 policy, overriding account settings), account, bucket and access point level, and S3 applies "the most restrictive combination". FSBP controls S3.1 and S3.8 check them.
• Current defaults: new buckets and objects do not allow public access, Object Ownership is "bucket owner enforced" with ACLs disabled, and SSE-S3 encryption applies to every bucket. From April 2026 S3 also disables SSE-C (customer-provided keys) by default on new general purpose buckets. That matters because the Codefinger S3 ransomware used stolen keys and SSE-C to encrypt victims' objects. Older buckets keep their old settings, so audit them.
• Transport and network: deny requests where aws:SecureTransport is false, reach S3 through VPC endpoints, and restrict buckets to known endpoints or the organisation with bucket policies and RCPs.
• Recovery: versioning and S3 Object Lock (write once, read many) protect against deletion and encryption; keep backups in a separate account. See the Backup Security and Immutable Backup Guide.
• KMS: use customer managed keys where you need control of the key policy, separation of duties between key administrators and key users, or cross-account restrictions. Enable rotation and alert on ScheduleKeyDeletion and DisableKey. See the Cryptographic Key Management Guide.
• Visibility: IAM Access Analyzer for S3 flags buckets open to the internet or other accounts, and CloudTrail data events record object reads and writes (Config rule cloudtrail-s3-dataevents-enabled checks coverage).

Network and compute hardening

• VPC design: private subnets for compute and data, public subnets only for load balancers and NAT, centralised egress and inspection in the Network account, and gateway or interface endpoints so traffic to AWS services stays off the internet. Enable VPC Flow Logs into the Log Archive account, and never open SSH or RDP to 0.0.0.0/0 (use Session Manager). Security groups are stateful and should reference other security groups rather than wide CIDR ranges; network ACLs are stateless subnet filters for coarse denies. See the Network Segmentation Guide.
• Edge: AWS WAF on internet-facing load balancers, API Gateway and CloudFront, with AWS Shield for DDoS protection.
• IMDSv2: by default an instance accepts IMDSv1 or IMDSv2. IMDSv2 requires a session token from a PUT request, rejects PUT requests that carry an X-Forwarded-For header, and uses a default response hop limit of 1, which blunts server-side request forgery. Set "IMDSv2 only (token required)" as the account default in every Region, register AMIs with imds-support v2.0, and enforce it with SCP condition keys, after finding the IMDSv1 callers that AWS warns "will break". The Capital One breach is the reference case for role credentials taken from the metadata service.
• Vulnerabilities: Inspector findings feed patching SLAs for instances, images and functions. See the Vulnerability Management Guide.

Benchmarks: FSBP and CIS AWS Foundations

Security Hub CSPM runs two benchmarks most organisations need. The AWS Foundational Security Best Practices (FSBP) standard is "a set of controls that detect when AWS accounts and resources deviate from security best practices". For CIS, AWS states that "AWS Security Hub CSPM supports CIS AWS Foundations Benchmark versions 5.0.0, 3.0.0, 1.4.0, and 1.2.0" and recommends v5.0.0 (enable a new version before disabling the old one). CIS itself lists v7.1.0 as its latest AWS Foundations release, so if an auditor requires the newest version, expect to cover the gap with manual checks or AWS Config rules. AWS also notes that many CIS requirements "can be evaluated only by manually reviewing the state of your AWS resources".

Implementation roadmap

1. Inventory and stabilise (weeks 1 to 4): list accounts, Regions in use, IAM users, access keys and their last use, public buckets and IMDSv1 instances. Turn on IAM Access Analyzer at organisation scope.
2. Logging and detection (weeks 2 to 6): create the organisation trail into the Log Archive account, enable GuardDuty, Security Hub CSPM (FSBP and CIS v5.0.0) and Config everywhere with auto-enable. Nothing here blocks workloads, so it can go first.
3. Identity (weeks 4 to 12): move people to IAM Identity Center, centralise root access, delete member account root credentials, and replace access keys with roles, starting with keys that have administrative policies or have not been used in 90 days.
4. Guardrails in audit first (weeks 6 to 12): write SCPs and RCPs, attach them to a sandbox OU, review CloudTrail for AccessDenied errors caused by the new policy, fix, then move up one OU at a time. Roll back by detaching the policy, which takes effect without redeploying workloads.
5. Data and compute defaults (weeks 8 to 16): organisation-level S3 Block Public Access, IMDSv2 account defaults, monitoring for IMDSv1 use, then enforcement. Pilot on non-production accounts first.
6. Operate: tune GuardDuty suppression rules and rehearse playbooks for leaked keys and public buckets. See the Leaked Credential Response Playbook.

Decision guidance: small and large estates

• Control Tower or custom landing zone: Control Tower suits most organisations. Estates with heavy infrastructure-as-code pipelines sometimes build on Organizations directly, but must then rebuild account vending, baselines and drift detection themselves.
• SCP or RCP: choose an SCP to stop your own principals doing something (disable logging, use an unapproved Region). Choose an RCP to stop anyone, including outside accounts, reaching your data (data perimeter). Most mature estates use both.
• Small teams: a minimum viable set is management, security tooling, log archive and separate production and non-production accounts, plus Identity Center, an organisation trail, GuardDuty and Security Hub CSPM. That is achievable in weeks.
• Large or regulated estates: add Config conformance packs mapped to your framework, RCP data perimeters, and checks that track the latest CIS version.

Detection and measurement

Metrics that show the programme is working:

• Long-term access keys: count of active IAM user keys, and the share older than 90 days (target: falling to near zero).
• Posture score: Security Hub CSPM FSBP and CIS pass rate per OU, with production tracked separately.
• Coverage: percentage of accounts and Regions with the organisation trail, GuardDuty, Config and Security Hub CSPM enabled (target 100).
• IMDSv2 adoption: share of running instances with tokens required.
• Unused access: open Access Analyzer unused access and external access findings, and median time to close.

Common failure patterns

• Keys in code and config: long-term keys in repositories, images or .env files. The AWS crypto-mining campaign showed compromised IAM credentials running miners within minutes.
• Guardrails attached untested to the root: an SCP that breaks production gets removed in a hurry and never comes back. Test bottom-up.
• Detection in some Regions only: attackers launch resources in Regions nobody watches. Enable services in all Regions or deny unused Regions.
• Over-broad roles for workloads: AdministratorAccess on a CI role or instance profile turns a small compromise into an organisation-wide one. See the NHI Authentication Guide.

Framework mapping

Practitioner checklist

• Keep the management account free of workloads and users; run security services from a delegated Security Tooling account.
• Create a multi-Region organisation trail to a locked Log Archive bucket with integrity validation.
• Enable GuardDuty, Security Hub CSPM (FSBP and CIS v5.0.0), Config and IAM Access Analyzer in every account and Region, with auto-enable.
• Federate people through IAM Identity Center and remove IAM users with console passwords.
• Centralise root access, delete member account root credentials, and protect the management account root with hardware MFA.
• Replace long-term access keys with roles and federation; vault and rotate any that remain.
• Deploy SCPs that protect security services and deny unused Regions, and RCPs that enforce a data perimeter, tested bottom-up.
• Enforce S3 Block Public Access at organisation level and disable SSE-C where it is not needed.
• Set IMDSv2 required as the account default in every Region and enforce it at launch.
• Report access key age, posture score, IMDSv2 adoption and finding closure time monthly.

Standards and references

• AWS: AWS Security Reference Architecture (AWS SRA)
• AWS: Resource control policies (RCPs)
• AWS: AWS account root user
• AWS: Using AWS IAM Access Analyzer
• AWS: AWS Foundational Security Best Practices standard in Security Hub CSPM
• AWS: CIS AWS Foundations Benchmark in Security Hub CSPM
• AWS: Configure the Instance Metadata Service options
• CIS: Amazon Web Services Benchmarks

Related NHI Mgmt Group resources: Cloud Workload Identity Guide · Cloud PAM and CIEM Guide · Secrets Management Guide · CNAPP Guide · Leaked Credential Response Playbook