Public Access

Public Access means a resource is reachable from the internet without authentication. While sometimes intentional (static website hosting on S3), it is frequently accidental and a leading cause of data breaches.

Common Public Access Risks

• S3 buckets: public bucket policies or ACLs exposing sensitive data
• RDS instances: publicly accessible database endpoints
• Security groups: inbound rules allowing 0.0.0.0/0 on sensitive ports
• EBS snapshots: shared publicly with all AWS accounts
• AMIs: shared publicly

Prevention

• S3 Block Public Access (organization, account, bucket, and access point level)
• AWS Config rules to detect public resources
• Security Hub checks (CIS, FSBP)
• SCPs to prevent making resources public

What "Public" Actually Means to S3

S3 has a precise definition worth knowing, because it explains surprising behavior. An ACL is public if it grants any permission to the predefined AllUsers or AuthenticatedUsers groups. Note that AuthenticatedUsers means any AWS account, not any user of yours, which is why that grant is effectively public.

For bucket policies, S3 starts by assuming the policy is public and then tries to prove otherwise. A policy is non-public only if it grants access restricted to fixed (non-wildcard) values of a principal, an aws:SourceIp CIDR range, aws:SourceVpc, aws:SourceVpce, aws:SourceArn, aws:SourceAccount, aws:SourceOwner, aws:userid, or the access point condition keys. A condition like "StringLike": {"aws:SourceVpc": "vpc-*"} still counts as public because the value is a wildcard. Very broad IP ranges are also treated as public: anything wider than a /8 for IPv4 or /32 for IPv6, excluding RFC1918 private ranges.

How It Goes Wrong in Practice

The classic pattern is a bucket that was made public on purpose years ago for one file, and then quietly became the dumping ground for everything. Someone needed to share a logo or a CSV with a partner, could not be bothered with presigned URLs, and set a policy with "Principal": "*". Later, an automated export job started writing database dumps or log archives into the same bucket, because it was already there and already had write access configured. Nobody re-reviewed the policy at that point, and the bucket is now indexed by the scanners that continuously crawl S3 namespaces.

The second pattern is the RDS instance with PubliclyAccessible set to true. This is often not a deliberate decision at all: it is the console default path when a database is created in a VPC with a public subnet, and a developer just clicked through. The security group is what saves you, and it fails the moment someone widens it to 0.0.0.0/0 on port 5432 or 3306 to debug a connectivity problem from home. Combine a public endpoint with a weak or reused master password and you have a database that credential-stuffing bots will find within hours.

The third pattern is worth calling out because Block Public Access does not cover it: publicly shared EBS snapshots and AMIs. Snapshots often contain full root volumes with configuration files, private keys, and application secrets. Sharing one publicly is a single API call, and there is no equivalent to the S3 public access block that stops it by default. Use AWS Config or Security Hub to detect them, and an SCP to deny ec2:ModifySnapshotAttribute with a public group value.

Checking Block Public Access From the CLI

For a specific bucket:

aws s3api get-public-access-block --bucket my-bucket-name

The output returns a PublicAccessBlockConfiguration with four booleans: BlockPublicAcls, IgnorePublicAcls, BlockPublicPolicy, and RestrictPublicBuckets. All four should be true unless you have a documented reason otherwise. For the whole account, use aws s3control get-public-access-block --account-id 123456789012. Account-level settings apply to every bucket owned by the account, and S3 applies the most restrictive combination across organization, account, bucket, and access point settings.

To find security groups open to the world on a specific port:

aws ec2 describe-security-groups --filters Name=ip-permission.from-port,Values=22 Name=ip-permission.to-port,Values=22 Name=ip-permission.cidr,Values=0.0.0.0/0

Frequently Asked Questions

Are new S3 buckets public by default?

No. By default, new buckets, access points, and objects do not allow public access. But users with the right permissions can still modify bucket policies, access point policies, or object permissions to open them up. Block Public Access exists to override those changes so a mistake cannot take effect.

Does turning on Block Public Access change my existing policies?

No. The settings do not alter existing bucket policies or ACLs, they only stop them from taking effect. That is useful for auditing, but it also means that removing a block public access setting later immediately makes a bucket with a public policy publicly accessible again. Clean up the underlying policy, do not just rely on the block.

Can I enforce this across the whole organization?

Yes. S3 Block Public Access can be managed at the organization level through AWS Organizations policies, which propagate to member accounts and override account-level settings. At the organization level, the four settings are applied together as a single all-or-none policy, not individually.