S3 Access Control: Bucket Policies and ACLs

S3 offers multiple overlapping access control mechanisms: IAM policies (identity-based, control what principals can do), bucket policies (resource-based JSON policies on the bucket), Access Control Lists (ACLs) (legacy per-object/bucket grants), and S3 Block Public Access (account or bucket-level override that blocks any public access regardless of other policies). For most use cases today, bucket policies plus Block Public Access is the recommended approach—ACLs are considered legacy.

A bucket policy is a JSON document attached directly to the S3 bucket. It specifies which principals (IAM users, roles, AWS accounts, services, or the public) can perform which actions on which resources (the bucket and/or specific key prefixes). Bucket policies support cross-account access without needing IAM roles: you can grant a different AWS account's IAM role read access to specific objects directly in the bucket policy. Each bucket can have one policy, and the maximum size is 20 KB.

To serve public content (e.g., static website assets, public datasets), you can make objects publicly readable via a bucket policy. First, disable Block Public Access at the bucket level, then add a bucket policy statement with Principal: '*' and Action: s3:GetObject. The combination of disabling the Block Public Access setting and the bucket policy Allow is required—enabling one without the other will not work. Always scope the Resource to a specific prefix rather than the entire bucket unless you intentionally want all objects public.

S3 Block Public Access is a safety net with four settings that override bucket policies and ACLs: BlockPublicAcls (rejects requests to set public ACLs), IgnorePublicAcls (ignores existing public ACLs), BlockPublicPolicy (rejects bucket policies that grant public access), and RestrictPublicBuckets (restricts access based on public policy). All four settings are enabled by default. You can also enable Block Public Access at the account level, blocking it for all buckets regardless of individual bucket settings—ideal for preventing accidental public exposure.

S3 ACLs are the original access control mechanism, predating IAM. An ACL grants predefined permissions (READ, WRITE, FULL_CONTROL) to AWS accounts or predefined groups (all users, authenticated AWS users, log delivery). ACLs can be applied at the bucket level or the individual object level. AWS now recommends disabling ACLs (the S3 'Bucket Owner Enforced' setting makes the bucket owner own all objects, disabling ACLs) and using bucket policies and IAM instead. ACLs are still tested on the SAA-C03 exam as a legacy concept.

When serving S3 content through CloudFront, you want the bucket private but CloudFront able to fetch objects. Use Origin Access Control (OAC)—the modern replacement for Origin Access Identity (OAI). OAC creates a CloudFront identity that you grant s3:GetObject permission in the bucket policy, while keeping Block Public Access enabled. This way, users must go through CloudFront (for caching, WAF, HTTPS), and cannot access the bucket directly—a common secure architecture pattern on the SAA-C03 exam.

There are two ways to grant another AWS account access to your S3 bucket. Option 1 — Bucket policy: add a statement with the external account's ARN as the Principal and the desired S3 actions. The external account's IAM users/roles still need IAM permissions to call S3, plus the bucket policy must Allow them. Option 2 — IAM role with trust policy: create a role in your account trusted by the external account; the external account's identities assume the role and get your bucket's permissions. Bucket policy is simpler for read-only scenarios; roles are better for operational access.

Cross-Origin Resource Sharing (CORS) allows a web application hosted on one domain to make JavaScript fetch requests to an S3 bucket on a different domain. Without a CORS configuration, browsers block these requests for security. You add a CORS configuration to the bucket that specifies allowed origins, HTTP methods, and headers. CORS is commonly needed when a React SPA hosted on example.com fetches images or files directly from an S3 bucket URL.

A pre-signed URL grants time-limited access to a private S3 object (for GET or PUT) without changing any bucket or object permissions. The URL embeds your credentials and an expiry time—anyone with the URL can access the object until it expires. Use pre-signed URLs to: let authenticated users in your app download private files, allow clients to upload directly to S3 without going through your backend, or share reports temporarily. The expiry can range from 1 second to 7 days (when using STS temporary credentials the max is 12 hours).

Use bucket policy conditions to add context-based security. Common patterns: aws:SourceIp restricts access to specific IP ranges (e.g., VPC endpoints or corporate networks); aws:SecureTransport: true forces HTTPS by denying requests over HTTP (a best practice for all buckets storing sensitive data); s3:x-amz-server-side-encryption ensures objects must be uploaded with server-side encryption; and aws:PrincipalOrgID restricts access to principals within your AWS Organisation, preventing data exfiltration to external accounts.

By default, EC2 instances in a private subnet access S3 over the internet (via NAT gateway), incurring NAT costs and exposing traffic to the public internet. S3 Gateway Endpoints provide private connectivity to S3 from within a VPC without a NAT gateway, at no extra charge. You add the Gateway Endpoint to your route table; traffic to S3 is automatically routed through AWS's private network. You can also add bucket policy conditions using aws:SourceVpce to restrict access to requests coming through the endpoint only.

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: bucket policies are resource-based JSON documents that control cross-account and service access to S3, S3 Block Public Access is a safety override that prevents accidental public exposure, and pre-signed URLs, VPC endpoints, and CORS configurations address specific access patterns securely. Next up we cover S3 versioning, MFA Delete, and replication.