AWS Security & Compliance Best Practices

Summary:

• AWS compliance in 2025-2026 demands a multi-layered approach combining Control Tower guardrails, Service Control Policies, and continuous monitoring through AWS Config conformance packs.
• The shared responsibility model requires organizations to understand precisely which compliance controls AWS manages versus customer-owned obligations across frameworks like SOC2, HIPAA, PCI DSS, and FedRAMP.
• Compliance as code transforms manual audit preparation into automated evidence collection using AWS Audit Manager, Config rules, and policy-as-code workflows that scale across multi-account architectures.
• Encryption strategies must address both data at rest through AWS KMS customer-managed keys and data in transit via TLS enforcement, VPC encryption controls, and certificate management.

When your organization faces its next compliance audit, the difference between a three-week scramble and a three-hour evidence export comes down to architectural decisions made months earlier. AWS compliance has evolved dramatically through 2025 and into 2026. Control Tower added new compliance frameworks, and AWS Config introduced dozens of managed rules that automate what previously required manual attestation.

Security teams that treat compliance as an afterthought find themselves retrofitting controls into production environments. Those who embed AWS security best practices from day one transform regulatory requirements into competitive advantages. This guide bridges the gap between understanding compliance frameworks theoretically and implementing enforceable, auditable controls across your entire AWS organization.

The following diagram illustrates how compliance controls flow from organizational policies down through individual accounts. This creates layered enforcement that auditors can trace from policy definition to resource configuration.

Overview of AWS compliance frameworks in 2025-2026

AWS compliance frameworks have undergone significant expansion since late 2024. Control Tower added support for new compliance frameworks and introduced additional AWS Config rules that map directly to regulatory requirements. These updates reflect AWS’s recognition that organizations increasingly operate under multiple overlapping compliance mandates. Healthcare providers navigate HIPAA alongside SOC2, while financial institutions balance PCI DSS with regional data residency laws.

The 2025-2026 landscape introduces more granular controls, particularly around data sovereignty and cross-border data transfer restrictions that emerged from evolving privacy regulations. Understanding which frameworks AWS supports natively versus those requiring custom implementation determines your compliance architecture strategy.

AWS maintains compliance certifications and attestations that customers inherit for the infrastructure layer. However, the shared responsibility model places application-level controls firmly in customer hands. Consider the following framework categories and their AWS support status:

• Fully supported with managed controls: SOC1, SOC2, SOC3, PCI DSS, HIPAA, ISO 27001, ISO 27017, ISO 27018
• Supported with Control Tower frameworks: NIST 800-53, NIST Cybersecurity Framework, CIS AWS Foundations Benchmark
• Requires custom implementation: FedRAMP (High baseline requires GovCloud, while the Moderate baseline is supported in standard US Commercial regions), GDPR (data residency controls), industry-specific regulations

The shared responsibility model for compliance

The shared responsibility model fundamentally shapes how organizations approach AWS compliance, yet many teams misunderstand where AWS’s obligations end and customer responsibilities begin. AWS secures the infrastructure layer, including physical data centers, hypervisors, and the global network backbone. Customers own everything deployed on that infrastructure.

This includes operating system configurations, application code, data classification, identity management, and network access controls. This division means that while AWS maintains PCI DSS certification for its infrastructure, a customer processing credit card data must still implement their own cardholder data environment controls.

Compliance inheritance works differently across service models. Infrastructure services like EC2 require customers to manage operating system patches, while managed services like RDS shift database engine patching to AWS. Serverless offerings like Lambda further reduce customer scope but introduce new considerations around function-level permissions and execution role policies. The following table maps common compliance requirements to responsibility ownership across service models:

Senior engineers and architects must internalize this model when designing compliant systems because auditors will probe exactly where responsibility boundaries lie. Moving from understanding framework requirements to implementing enforceable controls requires a robust multi-account governance strategy.

Multi-account governance and guardrail architecture

Enterprise AWS environments demand multi-account architectures that isolate workloads while maintaining centralized compliance oversight. AWS Control Tower provides the foundational structure for this approach. It establishes a landing zone with built-in guardrails that prevent non-compliant configurations before they reach production.

The 2025-2026 Control Tower updates expanded the Control Catalog with preventive and detective controls mapped to specific compliance frameworks. This allows organizations to activate framework-aligned guardrails with minimal custom development.

Service Control Policies form the backbone of preventive compliance controls. They operate at the AWS Organizations level to establish permission boundaries that even account administrators cannot override. Unlike IAM policies that grant permissions, SCPs restrict what actions are possible within member accounts.

This distinction matters critically for compliance because SCPs create hard boundaries that survive IAM policy misconfigurations. A well-designed SCP strategy addresses several compliance requirements simultaneously:

• Region restriction: Prevent resource creation outside approved regions to satisfy data residency requirements
• Service limitation: Block access to services not approved for your compliance scope
• Encryption enforcement: Deny creation of unencrypted storage resources
• Root account protection: Prevent root user actions except for specific break-glass scenarios

Control Tower and the control catalog

AWS Control Tower’s Control Catalog represents a significant evolution in how organizations implement compliance guardrails. Rather than building custom Config rules and SCPs from scratch, teams can now browse pre-built controls organized by compliance framework and enable them across organizational units with a few clicks.

The catalog distinguishes between preventive controls that block non-compliant actions and detective controls that identify existing violations. This allows organizations to implement defense-in-depth compliance strategies.

The 2025 updates introduced controls specifically mapped to NIST 800-53 revision 5, CIS AWS Foundations Benchmark v3.0, and expanded PCI DSS coverage. Each control includes metadata describing which compliance requirements it addresses. This enables compliance teams to generate framework coverage reports directly from Control Tower. For organizations pursuing multiple certifications, this mapping eliminates the manual crosswalk exercises that previously consumed weeks of audit preparation time.

Implementing Control Tower effectively requires understanding the relationship between organizational units, account enrollment, and control inheritance. Controls applied to a parent OU automatically apply to all child OUs and accounts, creating a hierarchical enforcement model.

This inheritance pattern enables tiered compliance strategies where baseline controls apply organization-wide while stricter controls target specific OUs containing regulated workloads. The architectural decisions made at this layer directly impact how compliance as code implementations function across your environment.

Compliance as code implementation strategies

Compliance as code transforms regulatory requirements from periodic audit exercises into continuously enforced technical controls. This approach embeds compliance logic directly into infrastructure provisioning pipelines, configuration management systems, and runtime monitoring tools. AWS Config conformance packs serve as the primary mechanism for implementing compliance as code. They bundle related Config rules into deployable packages that evaluate resource configurations against defined standards.

AWS provides managed conformance packs aligned with major compliance frameworks, including operational best practices packs for HIPAA, PCI DSS, NIST 800-53, and CIS benchmarks. These packs contain pre-configured rules that evaluate resources against framework-specific requirements. They generate compliance scores and identify non-compliant resources automatically. Organizations can deploy these packs across their entire AWS Organization using AWS Config aggregators, creating a unified compliance dashboard that spans hundreds of accounts.

Policy-as-code workflows with AWS Config rules

AWS Config rules evaluate resource configurations against desired states, flagging deviations as non-compliant. Managed rules cover common compliance scenarios like ensuring S3 buckets block public access or verifying EBS volumes use encryption. Custom rules extend this capability to organization-specific requirements using AWS Lambda functions that implement evaluation logic. The combination of managed and custom rules creates comprehensive compliance coverage tailored to your regulatory environment.

Effective policy-as-code implementations follow a consistent workflow pattern. First, define the desired configuration state based on compliance requirements. Second, implement Config rules that evaluate resources against that state. Third, configure remediation actions that automatically correct non-compliant configurations or alert responsible teams. Fourth, aggregate compliance data across accounts for centralized reporting. This workflow transforms compliance from a point-in-time assessment into continuous assurance.

1. Rule definition: Specify the resource types and configuration attributes the rule evaluates
2. Evaluation trigger: Configure whether rules evaluate on configuration changes, periodic schedules, or both
3. Remediation association: Link rules to Systems Manager Automation documents that correct violations
4. Aggregation setup: Deploy aggregators that collect compliance data from member accounts into a central view
5. Dashboard creation: Build compliance dashboards using Config’s built-in visualizations or export data to custom solutions

Tagging governance and attribute-based access control

Tags serve dual purposes in compliance architectures. They enable resource organization for cost allocation and audit scoping, and they power attribute-based access control policies that enforce least privilege dynamically. AWS’s 2025-2026 tagging capabilities introduced tag policies through AWS Organizations that enforce consistent tagging across accounts. This prevents the tag sprawl that undermines compliance reporting accuracy.

Attribute-based access control extends IAM beyond static role assignments by incorporating resource tags into authorization decisions. Rather than creating separate roles for each project or environment, ABAC policies grant access based on matching tags between principals and resources. A developer tagged with Project:Alpha gains access to resources tagged identically, while resources tagged Project:Beta remain inaccessible. This approach scales elegantly as organizations grow, reducing the IAM policy proliferation that creates audit complexity.

Implementing ABAC for compliance requires careful tag taxonomy design and enforcement mechanisms. Tag policies prevent users from creating resources with unauthorized tag values, while SCPs can require specific tags on resource creation. These controls ensure the tag data driving access decisions remains trustworthy. This is a critical requirement for auditors evaluating your access control implementation. The intersection of tagging governance and encryption controls creates the foundation for comprehensive data protection strategies.

Encryption and data protection controls

Encryption requirements appear in virtually every compliance framework, mandating protection for data at rest and data in transit. AWS provides encryption capabilities across its service portfolio, but enabling and managing these capabilities remains a customer responsibility under the shared responsibility model. AWS Key Management Service serves as the central control point for encryption key lifecycle management. It offers both AWS-managed keys and customer-managed keys with different compliance implications.

Customer-managed keys in AWS KMS provide the control and auditability that compliance frameworks typically require. Unlike AWS-managed keys where AWS controls the key material, customer-managed keys allow organizations to define key policies, enable automatic rotation, and maintain complete CloudTrail audit logs of key usage. For frameworks like PCI DSS that require demonstrable key management procedures, customer-managed keys provide the evidence trail auditors expect.

Encryption in transit and VPC security controls

Data in transit protection requires TLS enforcement across all network communications, both between users and AWS services and between services within your architecture. AWS services support TLS 1.2 and 1.3, with many services now defaulting to TLS 1.3 for improved security and performance. Compliance implementations must verify that older TLS versions are disabled and that certificate management processes ensure continuous coverage without expiration gaps.

VPC encryption controls have expanded significantly in recent updates. AWS introduced encryption options for VPC traffic that previously traversed networks unencrypted. VPC Flow Logs capture comprehensive routing and traffic metadata, while VPC Traffic Mirroring enables deep packet inspection to definitively verify encryption protocols for your security teams. For organizations subject to data sovereignty requirements, VPC configurations must also address cross-region traffic patterns and ensure data remains within approved geographic boundaries.

The encryption controls established at the infrastructure layer must be complemented by comprehensive logging and monitoring capabilities that provide the audit evidence compliance frameworks require.

Audit logging and continuous compliance monitoring

Compliance frameworks universally require audit logging that captures who did what, when, and to which resources. AWS provides multiple logging services that together create comprehensive audit trails. These include CloudTrail for API activity, VPC Flow Logs for network traffic, Config for configuration changes, and service-specific logs like S3 access logs and RDS audit logs. Architecting these logging streams for compliance requires centralization, immutability, and retention policies aligned with regulatory requirements.

CloudTrail serves as the foundational audit log for AWS environments, capturing every API call made against AWS services. Organization trails extend this capability across all accounts in an AWS Organization, ensuring consistent logging without requiring individual account configuration. For compliance purposes, CloudTrail logs must be protected against tampering through S3 bucket policies that prevent deletion, KMS encryption that controls access, and log file validation that detects modifications.

Evidence collection with AWS Audit Manager

AWS Audit Manager automates the evidence collection process that traditionally consumed weeks of audit preparation time. The service continuously collects evidence from AWS services, mapping collected data to specific compliance framework controls. When audit time arrives, compliance teams generate assessment reports that include pre-collected evidence. This dramatically reduces the manual effort required to demonstrate compliance.

Audit Manager supports both AWS-managed frameworks and custom frameworks that address organization-specific requirements. The service integrates with AWS Config, Security Hub, and CloudTrail to gather evidence automatically. It also supports manual evidence uploads for controls that require documentation outside AWS. For organizations pursuing multiple certifications, Audit Manager’s framework mapping capabilities identify where single pieces of evidence satisfy requirements across multiple frameworks.

IAM least privilege and Identity Center enhancements

Least privilege access represents one of the most challenging compliance requirements to implement and maintain. AWS IAM Access Analyzer helps identify overly permissive policies by analyzing resource policies and IAM policies for public or cross-account access. The 2025 enhancements to Access Analyzer introduced policy generation capabilities that create least privilege policies based on actual CloudTrail activity. This transforms historical access patterns into right-sized permissions.

AWS IAM Identity Center, formerly AWS SSO, provides centralized identity management across AWS accounts and applications. Recent improvements include enhanced integration with external identity providers, more granular permission set configurations, and improved audit logging of authentication events. For compliance purposes, Identity Center creates a single control point for access management. This simplifies the demonstration of access review processes and termination procedures that frameworks require.

Conclusion

AWS compliance in 2025-2026 demands architectural thinking that embeds regulatory requirements into infrastructure design rather than treating compliance as a periodic checkbox exercise. The combination of Control Tower guardrails, Service Control Policies, and AWS Config conformance packs creates layered enforcement that prevents non-compliant configurations while generating continuous audit evidence. Organizations that master the shared responsibility model understand precisely which controls they inherit from AWS versus those requiring customer implementation. This enables focused investment in the controls that matter for their specific regulatory environment.

The shift toward compliance as code represents the most significant evolution in how organizations approach AWS security best practices. Automated evidence collection through Audit Manager, policy-as-code implementations through Config rules, and attribute-based access control through ABAC-enabled IAM policies transform compliance from a cost center into an operational capability that scales with your AWS footprint. As regulatory requirements continue expanding and audit scrutiny intensifies, organizations with mature compliance automation will maintain their certifications efficiently while competitors struggle with manual processes that cannot keep pace with cloud-native development velocity.

Start by assessing your current compliance architecture against the multi-account governance patterns and encryption controls outlined in this guide. Identify gaps in your logging coverage, evaluate your Config rule coverage against target frameworks, and implement Audit Manager assessments that run continuously. The organizations that thrive in regulated industries are those that treat AWS compliance as a competitive differentiator that enables faster innovation within well-defined guardrails.