How would you write an S3 bucket policy that denies every request coming from outside your AWS Organization, and what mistake in that policy can lock you out of your own bucket?

## Why a Deny and not an Allow You can express "only my organisation" two ways. An `Allow` limited by `aws:PrincipalOrgID` grants access to org principals but leaves the door open for someone to add a second, broader statement later. A `Deny` conditioned on *not* being in the organisation is a guardrail: explicit deny beats every allow, in the bucket policy, in identity policies, and anywhere else. For a control you intend to be non-negotiable, write the deny. ```json { "Version": "2012-10-17", "Statement": [{ "Sid": "DenyOutsideMyOrg", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": [ "arn:aws:s3:::regulated-data", "arn:aws:s3:::regulated-data/*" ], "Condition": { "StringNotEquals": {"aws:PrincipalOrgID": "o-abc123example"}, "Bool": {"aws:PrincipalIsAWSService": "false"} } }] } ``` Both condition blocks must be satisfied for the deny to apply, because multiple condition operators in one statement are ANDed. So the statement reads: deny anyone who is neither in my organisation nor an AWS service principal. ## The condition keys, precisely - `aws:PrincipalOrgID` is the organisation ID of the account making the request. It is populated for IAM principals in member accounts of the organisation, and is a global key AWS resolves — you never set it yourself. - `aws:PrincipalIsAWSService` is `true` when an AWS service principal is calling. This is what saves log delivery. - `aws:PrincipalAccount` and `aws:SourceAccount` are for narrower, account-specific rules; `aws:SourceArn` pins the specific resource on whose behalf a service is calling and is the right companion when you do want to allow a service but only for one trail or one distribution. A related fence: `aws:SourceVpce` restricts requests to those arriving through a named VPC endpoint. Combining that with the org deny gives you "my org, and only over the private path" — but be aware you are then also excluding console access from outside that network path. ## The lockouts, in order of how often they happen **1. Service principals.** CloudTrail writing trail files, Config delivering snapshots, ELB or CloudFront writing access logs — these calls are made by an AWS service, not by an org principal, so `aws:PrincipalOrgID` is absent and `StringNotEquals` evaluates true. The deny fires and delivery stops. It fails quietly: nobody notices missing audit logs until an incident. The `aws:PrincipalIsAWSService` exemption is the fix, ideally combined with `aws:SourceArn` so you allow only the specific trail or distribution. **2. Cross-account roles you forgot.** S3 replication uses a role in one account writing to a bucket in another; a data-science account reads exports; a vendor's ingest role writes files. If any of those live outside the organisation, the deny catches them. **3. Denying yourself.** A statement built from `NotPrincipal` — "deny everyone who is not this list" — is the sharpest edge in IAM. `NotPrincipal` with `Deny` matches every principal not enumerated, including your administrators, your CI role, and the console session you are using to fix it. Prefer a `Condition`-based deny over `NotPrincipal`; it expresses the same intent without the trapdoor. ## Recovering S3 leaves a way back: sign in as the bucket-owning account's **root user** and delete the bucket policy with `DeleteBucketPolicy`. That is a genuine break-glass event — it requires the root credentials and MFA that you keep locked away, and it should generate an alarm. Everything about that recovery path is an argument for testing the policy first. ## How to test before you ship it - Apply it in a non-production account against a copy of the bucket, then exercise every consumer: replication, log delivery, batch jobs, the CDN. - Use the IAM policy simulator for the principals you know about, and IAM Access Analyzer's policy validation for the statement itself. - Turn on S3 server access logging or CloudTrail data events *before* the change so you have a baseline of who actually calls the bucket. The consumers you forgot are visible there and nowhere else. - Roll it out to one bucket, watch a full batch cycle including weekly and monthly jobs, then generalise. ## The scaling answer One bucket policy per bucket does not scale as an organisational control. The same condition belongs in a Service Control Policy or a resource control policy at the organisation layer, where it applies to every bucket in every account without anyone having to remember. The per-bucket deny is the right tool for a single high-value bucket, not for the estate.