Write the bucket policy yourself this time, instead of just reading one someone else wrote.
A hosting-enabled bucket still needs one more thing before city residents can actually reach it: permission. All S3 resources are private by default — only the resource owner has access until an access policy says otherwise.
Bucket has a publicReadAccess shorthand
that generates a bucket policy granting public s3:GetObject on every object in the
bucket — no hand-written JSON required. There's one catch:
S3 blocks public access at the bucket-settings level by default, and a bucket policy
can't override that on its own. CDK enforces this at synth time rather than leaving it to
a setting you might forget — publicReadAccess: true on its own throws unless you also
explicitly relax blockPublicAccess.
Add publicReadAccess: true and
blockPublicAccess: BlockPublicAccess.BLOCK_ACLS
to the bucket from the last lesson, then run the synthesizer. BlockPublicAccess
is a new name the starter doesn't import yet — add it to the existing import
from aws-cdk-lib/aws-s3:
import { Bucket, BlockPublicAccess } from 'aws-cdk-lib/aws-s3';
BlockPublicAccess.BLOCK_ACLS still blocks public ACLs — it only opens
the door for the bucket policy you're about to add, which is the narrower,
more intentional of the two mechanisms.
Heads up: you'll likely see an informational cdk-nag finding about block-public-access here (
AwsSolutions-S2). It's not blocking this lesson's pass/fail — a static website's bucket is supposed to be publicly readable. cdk-nag flagging that isn't a sign your code is wrong; it's the same rule that would (correctly) block public access on almost any other bucket in this platform.
Locked
This exercise builds on Provisioning a bucket for static hosting — run synth & validate there until every assertion passes, then this code will unlock.
Go to Provisioning a bucket for static hosting