AWS Security Controls and Configuration Guide

Amazon Web Services environments operate under a shared responsibility model that distributes security obligations between AWS and the account holder — a boundary that regulatory frameworks including FedRAMP and NIST treat as a primary risk factor. This page covers the definition and scope of AWS security controls, the structural mechanics of AWS's native control plane, the regulatory and architectural drivers that shape control requirements, classification of control categories, and the tradeoffs that practitioners and compliance teams navigate when configuring AWS at scale.

• 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
• References

Definition and scope

AWS security controls are the combination of identity policies, network architecture settings, encryption configurations, logging mechanisms, and governance guardrails applied within an AWS environment to enforce confidentiality, integrity, and availability requirements. The scope spans all interaction layers: the AWS management console, CLI and API access, compute and storage resource configurations, inter-service communications, and the account or organizational hierarchy in which resources are provisioned.

The foundational boundary is defined by the AWS Shared Responsibility Model, which places security of the cloud — physical infrastructure, hypervisor, managed service hardware — with AWS, and security in the cloud — operating systems, application code, IAM policies, data classification, network controls — with the account operator. NIST SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing, maps this division explicitly against traditional enterprise security controls.

For federal and federally-adjacent workloads, AWS operates under the FedRAMP Authorization Program, which grants provisional authority to operate (P-ATO) at impact levels Low, Moderate, and High. As of the FedRAMP Marketplace, AWS GovCloud (US) maintains a High authorization covering over 150 services. Commercial workloads subject to HIPAA are addressed through the AWS Business Associate Agreement (BAA), governed by the HIPAA Security Rule (45 CFR Part 164).

For orientation on how the broader cloud defense service sector is structured, the Cloud Defense Providers index catalogs service providers and tool categories operating across these control domains.

Core mechanics or structure

AWS security controls operate across five structural layers, each with distinct native tooling:

1. Identity and Access Management (IAM). IAM is the central policy engine. It governs authentication (via IAM users, roles, and federated identity providers) and authorization (via policy documents evaluated against a least-privilege deny-by-default model). IAM policies are JSON documents attached to principals, resources, or both, evaluated according to an explicit allow/deny hierarchy defined in AWS IAM Policy Evaluation Logic.

2. Network controls. Virtual Private Cloud (VPC) architecture segments resources at the network layer. Security Groups operate as stateful instance-level firewalls; Network Access Control Lists (NACLs) operate as stateless subnet-level filters. AWS Network Firewall provides centralized deep-packet inspection. VPC Flow Logs feed into SIEM pipelines for anomaly detection.

3. Data protection. AWS Key Management Service (KMS) manages symmetric and asymmetric encryption keys used for server-side encryption of S3 objects, EBS volumes, RDS instances, and Secrets Manager entries. AWS Certificate Manager (ACM) handles TLS certificate provisioning for in-transit encryption.

4. Detection and monitoring. AWS CloudTrail records all API calls across an account or AWS Organization. Amazon GuardDuty applies machine-learning threat detection to CloudTrail, VPC Flow Logs, and DNS logs. AWS Security Hub aggregates findings from GuardDuty, Amazon Inspector, AWS Config, Macie, and third-party tools against the AWS Foundational Security Best Practices standard, which maps to NIST SP 800-53 control families.

5. Governance and compliance posture. AWS Config records resource configuration state and evaluates it against managed or custom rules. AWS Organizations Service Control Policies (SCPs) establish permission guardrails across all member accounts. AWS Control Tower automates multi-account landing zone deployment with built-in guardrails aligned to CIS AWS Foundations Benchmark v1.4.

Causal relationships or drivers

The primary driver of AWS security control complexity is the elasticity and programmatic nature of cloud resource provisioning. Resources can be created, modified, and deleted through APIs, Infrastructure as Code (IaC) pipelines, and third-party automation — each a potential misconfiguration vector. The Cybersecurity and Infrastructure Security Agency (CISA) identifies misconfiguration as one of the leading causes of cloud-environment compromises in its Cloud Security Technical Reference Architecture.

Regulatory mandates create a second layer of drivers. PCI DSS v4.0 (published by the PCI Security Standards Council) requires encrypted cardholder data, network segmentation, and audit logging — all of which map directly to AWS KMS, VPC design, and CloudTrail configuration. NIST SP 800-53 Rev. 5 control families AC (Access Control), AU (Audit and Accountability), SC (System and Communications Protection), and SI (System and Information Integrity) each have direct AWS service equivalents.

A third driver is the multi-account architecture that enterprises adopt for workload isolation. AWS Organizations enables consolidated billing and policy inheritance, but it also introduces cross-account IAM role assumptions and trust relationships that expand the lateral movement surface if not governed by SCPs and permission boundaries.

Classification boundaries

AWS security controls can be classified along three independent axes:

By function: Preventive controls (IAM policies, SCPs, NACLs, KMS key policies), Detective controls (CloudTrail, GuardDuty, Config rules, Security Hub), Corrective controls (AWS Systems Manager Automation runbooks, Lambda-triggered remediation), and Deterrent controls (resource tagging policies, CloudWatch alarms).

By scope: Account-level controls (CloudTrail, Config, Security Hub enabled per account), Organization-level controls (SCPs, Delegated Administrator assignments, AWS Control Tower guardrails), and Resource-level controls (S3 bucket policies, KMS key policies, VPC security groups).

By regulatory mapping: The Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0 maps AWS native controls to ISO/IEC 27001:2022, SOC 2, PCI DSS, HIPAA, and NIST SP 800-53 in a single reference matrix, providing the classification framework most widely used by audit and compliance teams.

Tradeoffs and tensions

Least privilege versus operational velocity. IAM least-privilege policies require granular resource-level permissions. Writing and maintaining these policies at scale introduces development overhead that engineering teams frequently resolve by granting broader permissions — a pattern that widens the blast radius of compromised credentials.

Centralized logging versus cost. CloudTrail data events (object-level S3 and Lambda logging) are billed per 100,000 events. In high-throughput environments, enabling full data event logging can generate costs that organizations weigh against detection completeness. The tradeoff between cost and coverage is a recurring operational decision without a universal answer.

Encryption key management versus recovery risk. Customer-managed KMS keys (CMKs) provide maximum control over encryption but introduce key deletion risk. AWS KMS enforces a mandatory 7-to-30-day waiting period before key deletion (AWS KMS Key Deletion documentation), but accidental deletion of a CMK renders encrypted data permanently inaccessible.

SCPs versus account autonomy. Service Control Policies allow central security teams to prevent high-risk actions (e.g., disabling CloudTrail, creating public S3 buckets) across all accounts. However, overly restrictive SCPs can block legitimate workloads, creating friction between security governance and product delivery timelines.

The page contextualizes how service providers in this sector navigate these competing demands on behalf of enterprise clients.

Common misconceptions

Misconception: IAM MFA is enabled by default.
MFA is not enforced on root or IAM user accounts by default in a new AWS account. The CIS AWS Foundations Benchmark v1.4 lists MFA enforcement for the root account and all IAM users with console access as Requirement 1.1.3 and 1.1.4 — both explicitly requiring manual enablement.

Misconception: S3 Block Public Access eliminates data exposure risk.
S3 Block Public Access settings at the account or bucket level prevent ACL- and policy-based public access, but they do not prevent overly permissive bucket policies granting access to specific AWS accounts or authenticated principals. Cross-account access via resource policies remains a distinct exposure vector.

Misconception: CloudTrail being enabled means all activity is logged.
CloudTrail enables management events by default. Data events — which record object-level operations on S3, Lambda invocations, and DynamoDB operations — are disabled by default and must be explicitly configured. Many breach investigations reveal that data exfiltration activity occurred through paths not covered by default CloudTrail settings.

Misconception: AWS Config rules enforce configuration in real time.
AWS Config evaluates resource configurations on a scheduled or change-triggered basis and records compliance status. It does not block non-compliant configurations at creation time. Prevention requires SCPs, IAM permission boundaries, or AWS Control Tower proactive controls.

Checklist or steps (non-advisory)

The following sequence reflects the standard configuration phases for establishing an AWS security baseline aligned to NIST SP 800-53 Rev. 5 and the CIS AWS Foundations Benchmark:

1. Root account hardening — Enable MFA on root account; create no access keys for root; set account contact and alternate security contact.
2. IAM baseline — Enable IAM password policy meeting minimum complexity requirements; enable MFA for all IAM users with console access; create an IAM admin role for break-glass access.
3. CloudTrail activation — Enable CloudTrail in all regions with log file validation; configure S3 bucket for log storage with server-side encryption (SSE-KMS) and access logging; enable multi-region trail.
4. AWS Config enablement — Enable AWS Config in all in-scope regions; attach managed rule set aligned to chosen compliance framework (CIS, NIST, PCI DSS).
5. GuardDuty activation — Enable GuardDuty in all regions; configure findings export to Security Hub; establish SNS notification for high-severity findings.
6. Security Hub enrollment — Enable Security Hub; activate applicable standards (AWS Foundational Security Best Practices, CIS AWS Foundations Benchmark); assign remediation ownership.
7. VPC network baseline — Remove default VPC or restrict it; configure VPC Flow Logs; restrict security group rules to documented port/protocol requirements; enable DNS query logging.
8. S3 hardening — Enable S3 Block Public Access at account level; enforce bucket-level encryption; enable S3 Object Versioning and MFA Delete for critical data buckets.
9. KMS key governance — Create CMKs for each data classification tier; enforce key rotation (annually by default in AWS KMS); document key policy grants and restrict key administrators.
10. SCP governance — Implement SCPs via AWS Organizations to deny root credential use, deny disabling CloudTrail, deny creating public S3 buckets, and restrict regions to authorized geographies.
11. Incident response preparation — Document IAM role assumptions for forensic access; pre-stage Systems Manager Automation runbooks for isolation and snapshot; configure CloudWatch alarms for IAM anomalies.

For guidance on locating qualified practitioners who implement these baselines at scale, the How to Use This Cloud Defense Resource page describes how the service provider network is organized by specialization and scope.

Reference table or matrix