AWS publishes an Operational Best Practices conformance pack for APRA CPG 234 — a bundle of AWS Config rules pre-mapped to APRA's guidance. AWS has mapped roughly 130 technical controls to the 48 control objectives in CPG 234. Deploying it is a ten-minute job. The work that matters is reading the wall of failures it hands back and knowing which ones are real.
Practitioner guidance, not legal or audit advice. The conformance pack reflects AWS's mapping to CPG 234 (the guidance); your obligations sit under CPS 234 (the standard). Validate against both.
Deploy it
Conformance packs deploy per-account or org-wide via the Config console, CLI, or a CloudFormation template. The fastest path:
aws configservice put-conformance-pack \
--conformance-pack-name apra-cpg-234 \
--template-s3-uri s3://<your-bucket>/Operational-Best-Practices-for-APRA-CPG-234.yamlPrerequisite: AWS Config must already be recording in the account and region. If it isn't, the pack deploys but evaluates nothing — the single most common reason people think they "passed."
Deploy it org-wide through a delegated administrator, not account-by-account. CPS 234 is an estate-level obligation; evaluating one account tells you almost nothing.
Now read the failures
A first deployment against a real environment typically returns dozens of non-compliant rules. They are not equal. Sort them into three buckets.
Bucket 1 — Fix today (genuine exposure)
These are real risk, and an auditor will flag them immediately:
s3-bucket-public-read-prohibited/s3-bucket-public-write-prohibited— how to fix public S3restricted-ssh,restricted-common-ports— security groups open to the world (how to fix)iam-root-access-key-check,root-account-mfa-enabled— how to fix the root accountcloud-trail-encryption-enabled,multi-region-cloud-trail-enabled— how to fix CloudTrail
Bucket 2 — Fix this quarter (hygiene, not emergency)
access-keys-rotated,iam-password-policyencrypted-volumes,rds-storage-encryptedon non-production data — how to fix encryption at restvpc-flow-logs-enabledon lower environments
Bucket 3 — Noise and false positives (the trap)
Some failures are artifacts of how the rule evaluates, not real gaps:
- Rules flagging resources that are intentionally public (a static marketing site bucket).
required-tagsfailing because the rule's expected tag keys don't match your tagging standard — fix the rule parameters, not the resources.- Rules evaluating decommissioned resources Config hasn't aged out yet.
Don't blindly remediate Bucket 3. Auto-remediating a "public" S3 bucket that's meant to be public will break production and teach your team to distrust the whole exercise.
Turn failures into evidence
The conformance pack's real value to a CPS 234 audit isn't the score — it's the compliance-over-time view. Each rule carries a timeline. When the auditor asks whether a control held across the period, the conformance-pack history is the answer. Pair it with Audit Manager so the evidence collects continuously instead of being reconstructed under pressure.
Where this fits
The conformance pack tells you which controls fail. It doesn't tell you which CPS 234 clause each maps to in plain English, or what evidence to hand the auditor — that's what the CPS 234 → AWS Controls cheatsheet and the full control mapping are for.
For when to use the conformance pack versus Prowler versus Security Hub, see this comparison. Drowning in failures with no idea which are real? That triage — across the conformance pack and a Prowler scan — is the first thing a readiness assessment sorts out.
Primary sources: AWS APRA guidance (conformance pack) · AWS Config conformance packs · CIS in Security Hub