AWS Security Controls and Configuration Guide

AWS security controls span identity management, network architecture, data protection, logging, and compliance automation across a cloud platform that hosts workloads subject to FISMA, HIPAA, PCI DSS, SOC 2, and dozens of additional regulatory frameworks. This page maps the structure of AWS-native security capabilities, their operational mechanics, classification boundaries, and the tensions practitioners encounter when deploying them at scale. The reference material draws on NIST SP 800-53, FedRAMP authorization requirements, and AWS's own published service documentation to ground every section in verifiable standards.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps (non-advisory)
• Reference table or matrix

Definition and scope

AWS security controls are configuration states, policies, and architectural mechanisms applied to Amazon Web Services infrastructure to enforce confidentiality, integrity, and availability requirements. The term encompasses both preventive controls (blocking unauthorized actions before they occur) and detective controls (identifying policy violations after the fact). The scope extends across 30+ discrete AWS service categories, from compute (EC2, Lambda) to storage (S3, EBS, Glacier), databases (RDS, DynamoDB), networking (VPC, Route 53), and identity (IAM, AWS Organizations).

The shared responsibility model defines the boundary between controls AWS manages (physical data centers, hypervisor layer, managed service patches) and controls the customer configures (IAM policies, security group rules, encryption key management, audit logging). Misunderstanding this boundary is the most documented source of AWS security incidents catalogued by the Cloud Security Alliance (CSA).

Within regulated industries, AWS security controls map directly to control families in NIST SP 800-53 Rev. 5: Access Control (AC), Audit and Accountability (AU), Configuration Management (CM), Identification and Authentication (IA), and System and Communications Protection (SC). FedRAMP High baselines require implementation evidence across 421 controls and control enhancements (per FedRAMP High Baseline), making AWS control documentation a compliance artifact as much as an operational one.

Core mechanics or structure

AWS security controls operate through five structural layers:

1. Identity and Access Management (IAM)
IAM is the authorization foundation for all AWS API calls. Every resource action requires a principal (user, role, or service), an action (API call), a resource (ARN), and an explicit Allow statement in the applicable policy. Deny statements override any Allow, including those in identity-based policies. AWS Organizations Service Control Policies (SCPs) impose guardrails at the account or organizational unit level — SCPs cannot grant permissions, only restrict them. This creates a permission intersection model: effective permissions equal the intersection of SCPs, identity policies, and resource policies.

For deeper context on access architecture, see Identity and Access Management Cloud.

2. Network Controls
VPC Security Groups are stateful, instance-level firewalls; Network ACLs are stateless, subnet-level filters. Security groups evaluate inbound and outbound rules independently, while NACLs apply numbered rules in ascending order and return traffic must be explicitly permitted. AWS PrivateLink, VPC endpoints, and Transit Gateway extend network segmentation across service boundaries and multi-account architectures.

3. Data Protection
AWS Key Management Service (KMS) manages cryptographic keys used for server-side encryption across S3, EBS, RDS, and 100+ other services. Customer-managed keys (CMKs) give audit trails of every cryptographic operation through AWS CloudTrail. S3 Block Public Access is a four-parameter setting that overrides any bucket ACL or policy permitting public access — a single toggle that eliminates one of the most common misconfiguration classes.

4. Logging and Detection
AWS CloudTrail records API calls (management events) and optionally data events (S3 object-level, Lambda invocations). Amazon GuardDuty applies machine learning and threat intelligence to VPC Flow Logs, CloudTrail logs, and DNS query logs to surface anomalous behavior. AWS Security Hub aggregates findings from GuardDuty, Amazon Inspector, AWS Config, IAM Access Analyzer, and third-party tools into a unified finding format aligned to the AWS Security Finding Format (ASFF).

5. Configuration Compliance
AWS Config continuously records resource configuration states and evaluates them against rules. Managed rules (175+ available as of the last AWS documentation update) cover CIS AWS Foundations Benchmark requirements, NIST 800-53 control mappings, and PCI DSS checks. Config Conformance Packs bundle rules and remediation actions into deployable compliance packages.

Causal relationships or drivers

The regulatory expansion of cloud-specific requirements is the primary driver of AWS control adoption at enterprise scale. PCI DSS 4.0, finalized by the PCI Security Standards Council in March 2022, introduced explicit requirements for cloud service provider shared responsibility documentation (Requirement 12.9). HIPAA's Security Rule (45 CFR §164.312) maps to AWS controls through the AWS HIPAA Eligible Services list, which names the specific services whose configurations satisfy addressable and required implementation specifications.

Cloud misconfigurations rather than zero-day exploits account for the dominant category of AWS-related security incidents, according to the CSA's "Top Threats to Cloud Computing" report. Misconfigured S3 bucket policies, overly permissive IAM roles, and disabled CloudTrail logging are the three most cited configuration failures in publicly disclosed cloud breaches. Each maps to a specific preventive control: S3 Block Public Access, IAM Access Analyzer, and CloudTrail multi-region trail enablement.

Cost-of-breach economics also drive adoption. IBM's Cost of a Data Breach Report 2023 measured the average total cost of a data breach at $4.45 million. Organizations with mature security automation (encompassing controls like automated Config remediation and GuardDuty response playbooks) showed a $1.76 million lower average breach cost than those without.

Classification boundaries

AWS security controls divide along three primary axes:

Preventive vs. Detective vs. Responsive
- Preventive: IAM policies, SCPs, security groups, S3 Block Public Access, KMS encryption enforcement via bucket policies
- Detective: CloudTrail, GuardDuty, Config rules, IAM Access Analyzer, Macie (data classification)
- Responsive: Lambda-triggered remediation, AWS Systems Manager automation, Security Hub custom actions

AWS-Managed vs. Customer-Managed
AWS manages controls below the hypervisor and within managed services. Customers manage controls at the application, identity, network configuration, and data classification layer. The delineation varies by service — for Amazon RDS, AWS patches the database engine; for EC2, the customer patches the guest OS.

Account-Level vs. Organization-Level
SCPs and AWS Organizations policies apply across all accounts in an organizational unit. Account-level controls (security groups, IAM policies, Config rules) apply within a single account boundary. AWS Control Tower provides a managed landing zone that deploys guardrails (mandatory and elective) as SCPs and Config rules across a multi-account structure.

For enterprise-scale control architecture, see Cloud Security for Enterprises.

Tradeoffs and tensions

Encryption overhead vs. performance
Enabling KMS encryption on all EBS volumes and S3 objects introduces API call overhead for every cryptographic operation. High-throughput workloads (streaming analytics, HPC) experience measurable latency increases when using CMKs compared to AWS-managed keys or no encryption. The tradeoff is between cryptographic control granularity and operational throughput.

Least privilege vs. operational velocity
IAM least-privilege enforcement requires precise scoping of every resource ARN and condition key. Development teams operating under tight delivery timelines frequently use wildcard resource statements ("Resource": "*") or overprovisioned managed policies (e.g., AdministratorAccess) that violate least-privilege principles. IAM Access Analyzer identifies external access paths but does not flag internally overpermissive policies without custom policy validation rules.

Logging completeness vs. cost
CloudTrail S3 data events, VPC Flow Logs with full metadata, and Config recording for all resource types generate storage and analysis costs that scale with workload size. Organizations subject to FedRAMP authorization must enable comprehensive logging; commercial workloads often disable data events to manage cost, creating detection gaps.

Centralized control vs. account autonomy
AWS Organizations SCPs that enforce maximum permission boundaries can block legitimate workload requirements in member accounts. Balancing organizational guardrails against team-level operational flexibility requires exception processes and tested SCP logic — a governance challenge that zero trust architecture frameworks address through policy-as-code tooling.

Common misconceptions

Misconception: S3 buckets are private by default, so no further action is needed.
Correction: While AWS changed default S3 bucket creation to block public access in April 2023, existing buckets created before that date retain their prior ACL and policy configurations. S3 Block Public Access must be explicitly verified at both the account and bucket level. Bucket policies can still permit cross-account access from specific principals even when public access is blocked.

Misconception: Enabling CloudTrail means all activity is logged.
Correction: A single-region CloudTrail trail logs only management events in one region. Data events (S3 object-level, Lambda invocations, DynamoDB API calls) require explicit enablement and generate separate charges. Global service events (IAM, STS, CloudFront) are only captured in trails configured with the global services option. Without multi-region trails and data event enablement, significant activity gaps exist.

Misconception: AWS Config compliance scores represent security posture.
Correction: AWS Config evaluates configuration state against defined rules, not against a threat model. A resource can be 100% Config-compliant and still be vulnerable to privilege escalation through IAM policy relationships, lateral movement through misconfigured VPC peering, or data exfiltration through permissive KMS key policies — none of which standard Config managed rules detect.

Misconception: Security groups and NACLs are redundant.
Correction: Security groups are stateful and operate at the ENI level; NACLs are stateless and operate at the subnet level. They serve different segmentation purposes. NACLs are effective for blocking known-malicious IP ranges across all resources in a subnet; security groups enforce fine-grained instance-to-instance communication rules. Using both creates defense in depth per NIST SP 800-53 SC-7 (Boundary Protection).

Checklist or steps (non-advisory)

The following represents the standard control configuration sequence documented in the CIS AWS Foundations Benchmark v2.0 and AWS Security Hub Foundational Security Best Practices standard:

1. Enable CloudTrail multi-region trail — single trail with global service events enabled, logs delivered to a dedicated S3 bucket with MFA Delete and versioning.
2. Apply S3 Block Public Access — enable all four parameters at the account level; verify at individual bucket level for any existing buckets.
3. Enable AWS Config recording — all resource types, all regions; link to a conformance pack aligned to the applicable compliance framework (CIS, NIST, PCI).
4. Enable GuardDuty — all accounts in the organization via GuardDuty delegated administrator; enable S3 protection and EKS runtime monitoring.
5. Configure IAM password policy — minimum 14-character passwords, MFA required for all human IAM users; enforce via SCP.
6. Enable IAM Access Analyzer — organization-level analyzer to identify resources accessible from outside the organization boundary.
7. Rotate IAM access keys — disable and delete access keys older than 90 days; verify with Config managed rule access-keys-rotated.
8. Enable Security Hub — aggregate findings from all integrated services; apply the AWS Foundational Security Best Practices standard across the organization.
9. Implement VPC Flow Logs — enable for all VPCs; deliver to CloudWatch Logs or S3 for GuardDuty ingestion.
10. Enforce encryption at rest — CMK encryption for all EBS volumes, RDS instances, and S3 buckets storing sensitive data; verify with Config rule encrypted-volumes and s3-bucket-server-side-encryption-enabled.
11. Apply SCPs for baseline guardrails — deny regions outside approved list, deny disabling GuardDuty and Config, deny deletion of CloudTrail logs.
12. Enable AWS Macie — automated sensitive data discovery across S3; configure findings to flow into Security Hub.

Reference table or matrix

Sources for the above mappings: NIST SP 800-53 Rev. 5 Control Catalog, FedRAMP High Baseline Control Summary, CIS AWS Foundations Benchmark v2.0.

For broader context on cloud compliance frameworks and cloud security auditing processes that use these controls as evidence inputs, those reference pages address the documentation and assessment lifecycle downstream of control implementation.

References

• NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations
• FedRAMP High Baseline Security Controls
• FedRAMP Program Basics
• CIS AWS Foundations Benchmark
• AWS Security Finding Format (ASFF) — AWS Documentation
• [IBM Cost of a Data Breach Report 2023](https://www.ibm.com/reports/data-breach