AWS Security Controls and Best Practices

Amazon Web Services (AWS) provides a layered control environment governed by the shared responsibility model, in which AWS secures the physical infrastructure and hypervisor layer while customers are responsible for configurations, identity policies, data classifications, and workload-level protections. This page covers the structural taxonomy of AWS security controls, their regulatory alignment, the causal factors that drive misconfiguration and breach, the tradeoffs inherent in applying least-privilege at cloud scale, and the classification boundaries that separate native AWS controls from third-party and customer-managed compensating controls.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps
• Reference table or matrix
• References

Definition and scope

AWS security controls are the technical, administrative, and detective mechanisms applied within AWS environments to enforce confidentiality, integrity, and availability of hosted resources. The scope covers all three primary AWS service models — Infrastructure as a Service (IaaS) via Amazon EC2 and VPC, Platform as a Service (PaaS) via services such as AWS Lambda and Amazon RDS, and Software as a Service (SaaS) delivered through managed offerings — across single-account, multi-account, and AWS Organizations topologies.

The foundational governance document for this domain is the AWS Shared Responsibility Model, which distinguishes "security of the cloud" (AWS-managed physical, network, and hypervisor layers) from "security in the cloud" (customer-managed identity, data, application, and operating system configurations). Regulatory frameworks including NIST SP 800-53 Rev 5 and the Cloud Security Alliance Cloud Controls Matrix (CCM) provide control catalogs that map directly onto AWS service capabilities, enabling organizations to demonstrate compliance with HIPAA (45 CFR Part 164), PCI DSS v4.0, FedRAMP, and GDPR (EUR-Lex 2016/679) using native tooling.

The cloud security providers on this site catalogue service providers operating in this domain.

Core mechanics or structure

AWS security controls are organized into five functional layers, each corresponding to a distinct attack surface and a distinct set of AWS native services:

1. Identity and Access Management (IAM)
AWS IAM governs authentication and authorization for all API calls. Policies are written in JSON and attached to IAM users, roles, or groups. IAM supports identity federation via SAML 2.0 and OpenID Connect, enabling integration with enterprise identity providers. AWS IAM Identity Center (formerly AWS SSO) centralizes access management across multi-account AWS Organizations structures.

2. Network Security
Amazon VPC (Virtual Private Cloud) provides network segmentation through subnets, route tables, internet gateways, NAT gateways, and VPC endpoints. Security Groups act as stateful packet filters at the instance level; Network Access Control Lists (NACLs) provide stateless filtering at the subnet level. AWS Shield Standard is included for all customers and provides automatic DDoS mitigation at Layer 3 and Layer 4; AWS Shield Advanced extends protection with financial guarantees and dedicated response support.

3. Data Protection
AWS Key Management Service (KMS) manages cryptographic keys used for server-side encryption across S3, EBS, RDS, DynamoDB, and over 100 additional services. AWS Certificate Manager (ACM) handles TLS certificate provisioning. Amazon Macie applies machine learning to classify and discover sensitive data — including personally identifiable information (PII) — stored in Amazon S3.

4. Detection and Monitoring
AWS CloudTrail records API activity across accounts and regions, producing audit logs that satisfy requirements under NIST SP 800-53 AU-2 and AU-12. Amazon GuardDuty provides continuous threat detection using CloudTrail, VPC Flow Logs, and DNS query logs. AWS Security Hub aggregates findings from GuardDuty, Amazon Inspector, Macie, and third-party integrations into a consolidated security posture dashboard scored against the AWS Foundational Security Best Practices standard and CIS AWS Foundations Benchmark.

5. Governance and Compliance Automation
AWS Config continuously evaluates resource configurations against defined rules and conformance packs. AWS Organizations Service Control Policies (SCPs) enforce preventive guardrails across all member accounts. AWS Control Tower deploys a pre-configured landing zone architecture with baseline guardrails aligned to the AWS Security Reference Architecture (SRA).

Causal relationships or drivers

The primary driver of AWS security incidents is misconfiguration rather than zero-day exploitation. The 2024 Verizon Data Breach Investigations Report identified misconfiguration and human error as a leading cause of cloud-related breaches across the enterprise sector. Three structural factors make misconfiguration endemic to AWS environments:

Permissive default states: Certain AWS services ship with settings that prioritize functionality. Amazon S3 buckets historically defaulted to public access before AWS introduced S3 Block Public Access in 2018 and made account-level blocking the default in April 2023. IAM roles created via the console frequently receive AdministratorAccess policies for developer convenience.

Policy complexity at scale: A moderately complex AWS account may contain hundreds of IAM policies across users, roles, resource-based policies, permission boundaries, and SCPs. The interaction of these policy types — particularly the deny-overrides-allow hierarchy combined with implicit denies — produces access outcomes that are difficult to audit manually.

Velocity of service expansion: AWS releases approximately 200 or more new features and services per year. Each new service introduces new resource types, new APIs, and new default configurations that existing security tooling may not cover without explicit rule updates.

FedRAMP authorization documentation for AWS GovCloud (US) reflects the regulatory burden placed on government customers to validate these controls independently of AWS's own compliance posture.

Classification boundaries

AWS security controls divide into three governance categories that determine accountability:

AWS-owned controls cover physical security of data centers, hypervisor patching, network infrastructure between Availability Zones, and hardware supply chain integrity. Customers have no configuration access to these controls; they are validated through third-party audits (SOC 1/2/3, ISO 27001, FedRAMP).

Shared controls include patch management for managed services (AWS patches RDS database engines; customers patch OS layers on EC2), awareness training, and incident response procedures. AWS and customer responsibilities overlap depending on service model.

Customer-owned controls encompass all IAM configurations, security group rules, encryption key policies, CloudTrail enablement, VPC design, and application-layer security. Failures in this category account for the majority of publicly disclosed AWS breaches.

This tripartite structure aligns directly with the CSA Cloud Controls Matrix v4, which maps 197 control objectives across 17 domains to CSP and customer responsibility assignments. For a broader discussion of how these boundaries are structured across the cloud services sector, the page provides contextual framing.

Tradeoffs and tensions

Least privilege versus operational velocity: Implementing true least-privilege IAM policies requires detailed knowledge of every API call a workload makes. AWS IAM Access Analyzer and IAM policy generation tools partially automate this, but fine-grained policy authoring remains labor-intensive. Organizations routinely accept broader permissions to accelerate deployment, accepting residual privilege escalation risk.

Centralized logging versus cost: CloudTrail data events for S3 and Lambda generate high log volumes. Full data event logging across a large AWS environment can incur costs that organizations manage by selective enabling, which creates audit coverage gaps. The NIST SP 800-92 Guide to Computer Security Log Management identifies completeness as a core logging requirement, creating direct tension with cost controls.

Multi-account isolation versus management overhead: AWS recommends separating workloads into discrete accounts to limit blast radius. AWS Organizations and Control Tower facilitate this, but each additional account multiplies IAM role management, cross-account permission complexity, and tooling configuration overhead.

Encryption key control versus availability: Customer-managed KMS keys (CMKs) provide the strongest key governance but introduce key deletion and key policy misconfiguration as availability risks. Accidental key deletion or overly restrictive key policies can render encrypted data permanently inaccessible; AWS KMS enforces a mandatory 7-day to 30-day waiting period before key deletion to mitigate accidental loss.

Common misconceptions

Misconception: AWS compliance certification transfers to the customer.
AWS holds FedRAMP High authorization, SOC 2 Type II, and PCI DSS compliance for its infrastructure layer. These certifications do not automatically cover customer workloads. Customers must independently configure and document controls for their own FedRAMP or PCI DSS compliance. The FedRAMP PMO provides explicit guidance distinguishing CSP authorization boundaries from agency authorization to operate (ATO).

Misconception: Enabling AWS Security Hub constitutes a complete security posture.
Security Hub aggregates findings but does not remediate them. An account with Security Hub enabled and a low Security Score still requires manual or automated remediation workflows. Security Hub findings require triage, ownership assignment, and documented treatment to satisfy audit requirements under NIST SP 800-53 CA-7 (Continuous Monitoring).

Misconception: VPC security groups replace network firewalls.
Security groups operate at the ENI (Elastic Network Interface) level and are stateful. They do not inspect application-layer traffic, cannot enforce URL filtering or IDS/IPS signatures, and do not log allowed traffic by default. AWS Network Firewall, or third-party virtual appliances, are required for Layer 7 inspection.

Misconception: Root account credentials are only used for initial setup.
AWS root account credentials provide unrestricted access to all services and billing functions and cannot be constrained by IAM policies or SCPs. The CIS AWS Foundations Benchmark v2.0 requires that root account access keys do not exist and that multi-factor authentication (MFA) is enforced on the root account — two controls frequently misconfigured in AWS accounts created by development teams.

Checklist or steps

The following sequence represents the control implementation phases documented across AWS Security Reference Architecture, CIS AWS Foundations Benchmark v2.0, and NIST SP 800-53 Rev 5 control families applicable to AWS environments:

1. Establish account structure: Deploy AWS Organizations with a management account and separate organizational units (OUs) for production, development, sandbox, and security tooling accounts.
2. Apply Service Control Policies: Attach SCPs to OUs to prevent region activation outside approved regions, block disabling of CloudTrail, and deny creation of public S3 ACLs.
3. Enforce root account controls: Confirm no root access keys exist; enable hardware MFA on the root account; document root credential storage procedure.
4. Configure CloudTrail: Enable CloudTrail in all regions, including global service events; configure log file integrity validation; route logs to a centralized S3 bucket in a dedicated logging account with object lock enabled.
5. Enable AWS Config: Activate AWS Config in all regions with a conformance pack aligned to CIS AWS Foundations Benchmark or NIST 800-53.
6. Enable GuardDuty: Activate GuardDuty across all accounts using AWS Organizations delegated administrator; configure findings export to Security Hub and to a SIEM.
7. Implement VPC baseline: Deploy VPCs with private subnets for compute resources; restrict internet gateway usage; enable VPC Flow Logs to CloudWatch or S3; deploy AWS Network Firewall for egress filtering in production accounts.
8. Enforce encryption at rest: Enable default S3 bucket encryption with SSE-KMS; enforce encrypted EBS volumes via SCP; configure RDS encryption at creation.
9. Apply IAM least-privilege: Remove standing AdministratorAccess permissions from human users; implement IAM roles with permission boundaries; enable IAM Access Analyzer; review findings quarterly.
10. Establish patch management: Configure AWS Systems Manager Patch Manager with patch baselines for all managed EC2 instances; enforce patching SLAs within 30 days for critical/high vulnerabilities per NIST SP 800-40 Rev 4.
11. Review Security Hub score: Address findings with Critical or High severity; document accepted risks with business justification.
12. Conduct periodic access reviews: Use IAM Access Analyzer and AWS CloudTrail Insights to identify unused credentials and anomalous API activity; disable or remove unused IAM users and roles.

For context on how cloud security service providers structure these control implementations as professional services, the how to use this cloud security resource page describes the provider network's professional category structure.

Reference table or matrix