Compliance

Compliance in cloud security means meeting the requirements defined by regulatory bodies, industry standards, and internal policies. AWS provides the infrastructure compliance (SOC reports, ISO certifications), but customers must implement compliant configurations.

Common Frameworks

• SOC 2 Type II: trust service criteria for security, availability, processing integrity
• HIPAA: health information protection (requires BAA with AWS)
• GDPR: EU data protection and privacy
• PCI DSS v4.0.1: payment card data security
• CIS AWS Foundations Benchmark: prescriptive security configuration checklist (v7.0 is latest)
• ISO 27001: information security management system

AWS Compliance Tools

• AWS Config: continuous configuration compliance monitoring
• Security Hub: automated compliance scoring against CIS, FSBP, PCI DSS
• AWS Audit Manager: automated evidence collection for audits
• AWS Artifact: access AWS compliance reports and agreements

How It Goes Wrong in Practice

The most persistent compliance failure in AWS environments is inherited-compliance confusion: a team downloads the AWS SOC 2 report or ISO certificate from AWS Artifact, attaches it to a customer questionnaire, and concludes the platform's compliance covers their workload. It does not. Those documents attest to AWS's side of the shared responsibility model, the physical facilities, hypervisors, and managed service infrastructure; everything you configure, your IAM policies, encryption settings, network exposure, and logging, sits on your side and is audited separately. Auditors and enterprise customers know the difference even when internal teams do not. The second recurring failure is point-in-time compliance: the environment is groomed for the audit window, passes, and then drifts for eleven months, so each annual audit becomes an archaeology project rediscovering the same classes of finding. This is the specific problem continuous tooling solves: Config rules evaluate resources against policy as they change, Security Hub scores accounts against standards on an ongoing schedule, and Audit Manager accumulates evidence continuously instead of in a panicked quarter-end sprint. The third failure is scope mismatch: compliance tooling enabled in the flagship production account and flagship region while workloads quietly run in a dozen other accounts and regions that no rule evaluates. Compliance posture is only as good as its coverage, which is why organization-wide deployment of Config, Security Hub, and CloudTrail through AWS Organizations is the foundation move, not an optimization.

Practical Check: Find What Is Failing Now

If AWS Config is recording and rules are deployed, one command surfaces your current non-compliance:

aws configservice describe-compliance-by-config-rule --compliance-types NON_COMPLIANT

The --compliance-types filter accepts COMPLIANT, NON_COMPLIANT, NOT_APPLICABLE, and INSUFFICIENT_DATA, and you can narrow to specific rules with --config-rule-names. Treat INSUFFICIENT_DATA results with suspicion: they often mean the rule's scope matches nothing or the recorder is off in that region, which is a coverage gap dressed up as a neutral status. Run the check in every region where you operate, or centralize with a Config aggregator so one query covers the organization.

Frequently Asked Questions

If AWS is certified for a framework, am I compliant with it?
No. AWS certifications cover the infrastructure AWS operates; your configurations, data handling, and processes are assessed separately. The practical use of AWS's certifications is that they let you inherit the infrastructure portion of a framework's controls, shrinking your audit scope to what you actually control.

Where do I get AWS's compliance reports for my auditor?
AWS Artifact, in the console. It provides on-demand access to AWS's audit reports (SOC, ISO, PCI attestations) and to agreements such as the Business Associate Addendum required for HIPAA workloads. Auditors routinely accept these as evidence for the AWS-managed layers.

What is the difference between Config, Security Hub, and Audit Manager for compliance?
Config is the evaluation engine: rules that judge individual resource configurations continuously. Security Hub packages controls into named standards (CIS, FSBP, PCI DSS) and scores your accounts against them, largely on top of Config. Audit Manager maps evidence from Config, CloudTrail, and Security Hub onto the control structure of an audit framework and produces assessment reports. Detection, scoring, and evidence: you generally want all three.

Is compliance the same thing as security?
No, and confusing them fails in both directions. Compliance is proof against a defined standard at a defined scope; security is resistance to actual attack. Compliant environments get breached through things no framework asked about, and secure environments fail audits over documentation. Use frameworks as a floor and an evidence discipline, not as the definition of done.