wtf( )unctionsystem design, drawn
← all problemsAWS SA ProHard

The guardrail at the root that the billing job ignored

Security attached a deny policy at the root of the organization: every bucket must use a customer-managed KMS key, no public snapshots, no IAM users without MFA. It was tested against three member accounts and it held in all three.

The nightly billing exporter has been writing a bucket with plain S3-managed encryption since before the policy existed. It still is. Nobody has changed its permissions, and the policy is attached to the root, above everything.

Place the account the billing exporter should be running in, so the organization's guardrail actually constrains it.
Components — tap one, then tap a slot on the diagram
!An audit found the bucket outside the key policy. The control that was supposed to make it impossible had been in place, and green, for four months.The policy is correct and it is attached correctly. What it is attached ABOVE is the part that decides whether it applies.

Boundaries, outermost first: The organization: Deny policy (attached at the root), Management account (runs the billing job; FAILED: not constrained) Workloads OU: A member account (constrained, tested), an empty slot for the where the billing job belongs Connections: Deny policy controls A member account — constrains members (step 1) Management account publishes to where the billing job belongs — move the job here (step 2) Deny policy must NOT reach Management account — never applies here

A member accountconstrained, tested
Deny policyattached at the root
Management accountruns the billing jobnot constrained