Bunny net S3 compatibility can only be enabled

Not specified by the original author.

TL;DR

Use path-style addressing (endpoint/bucket/key), virtual-hosted style does not work. If you need S3-compatible access, create a fresh zone with S3 Compatibility enabled from the start, do not try to retrofit it.

Steps

1. If you need S3-compatible access, create a fresh zone with S3 Compatibility enabled from the start, do not try to retrofit it. Wire clients with zone name as the access key, zone password as the secret, and the region-specific endpoint. Use path-style addressing (endpoint/bucket/key), virtual-hosted style does not work.

When to use

You are seeing this: Wire clients with zone name as the access key, zone password as the secret, and the region-specific endpoint. Use this skill when you run into "Bunny.net S3 compatibility can only be enabled at zone creation".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Official docs (bunny.net, S3 compatibility): S3 access is a choice you make when you create the storage zone, by enabling the S3 Compatibility option on the creation form. It cannot be switched on for an existing zone afterward. The S3 credentials also surprise people: the Access Key ID is the storage zone name itself and the Secret Access Key is the zone password, with a per-region endpoint like https://YOUR-region-s3.storage.bunnycdn.com and path-style URLs only.

Verified resolution: If you need S3-compatible access, create a fresh zone with S3 Compatibility enabled from the start, do not try to retrofit it. Wire clients with zone name as the access key, zone password as the secret, and the region-specific endpoint. Use path-style addressing (endpoint/bucket/key), virtual-hosted style does not work.

Source URL: https://bunny.net/docs/storage/s3

Not specified by the original author.

TL;DR

Start with the minimum set you actually need, you can add regions later but never remove them. If a zone already carries unwanted replicas, migrate the data to a fresh zone with the right region set and delete the old one.

Steps

1. Pick replication regions deliberately at zone creation and treat them as permanent. Start with the minimum set you actually need, you can add regions later but never remove them. If a zone already carries unwanted replicas, migrate the data to a fresh zone with the right region set and delete the old one.

When to use

You are seeing this: Pick replication regions deliberately at zone creation and treat them as permanent. Use this skill when you run into "Bunny.net storage replication regions are permanent once enabled".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Official docs (bunny.net, Storage replication and pricing): replication regions cannot be removed once they are enabled. Each extra region adds to the per-GB storage bill on top of the default region, and the only way back is deleting the zone and recreating it. Agents provisioning zones in automation that add regions for a test and plan to trim later end up paying for replicas they cannot switch off.

Verified resolution: Pick replication regions deliberately at zone creation and treat them as permanent. Start with the minimum set you actually need, you can add regions later but never remove them. If a zone already carries unwanted replicas, migrate the data to a fresh zone with the right region set and delete the old one.

Source URL: http://bunny.net/docs/storage/replication

Not specified by the original author.

TL;DR

S3 Block Public Access is good, but a bucket policy with an explicit deny on public reads is the belt and suspenders. Add a policy statement that denies s3:GetObject to everyone when the request comes from outside your conditions. Test it from an anonymous session before you call it done.

The query

how to write an S3 bucket policy that blocks public access

Use this when

• You store private data in S3 and want public access impossible, not just unlikely
• An audit requires an explicit deny, not just the absence of an allow
• You want protection that survives someone disabling Block Public Access by mistake
• You are writing a baseline bucket policy for every new bucket

Not for

• Static website hosting or public asset buckets; those need public reads by design
• CloudFront origin access; that uses its own identity mechanism
• Fixing an already-public bucket that leaked data; lock it down and rotate what leaked

Steps

1. Turn on S3 Block Public Access for the bucket first. Set all four block settings to true as the outer guardrail. Expected output: the console or CLI shows all four settings enabled.
2. Write the deny statement. Add a policy statement with Effect Deny, Principal "", Action s3:GetObject (and s3:GetObjectVersion if versioned), on the bucket ARN plus /, with a condition that matches public access (aws:PrincipalIsAWSService false is not the trick; the standard approach is denying when aws:PrincipalType or simply denying all unauthenticated reads via a NotPrincipal scoping to your account). Expected output: a policy document saved in your repo.
3. Apply it with the CLI. Run the put-bucket-policy command with your JSON file and confirm it applies cleanly. Expected output: the command succeeds and get-bucket-policy returns your policy.
4. Test anonymous access. From a session with no AWS credentials, try fetching an object URL; it must be denied. Expected output: AccessDenied on the anonymous request.
5. Test your real consumers still work. Your apps, CI, and data pipelines should read fine through their IAM roles. Expected output: all legitimate reads succeed, only anonymous ones fail.
6. Add it to your bucket baseline. Every new bucket gets this policy via your IaC module so nobody has to remember. Expected output: new buckets created from the module carry the deny policy automatically.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_m4Miz5r-MNHynyreeyaVog

Resolved from the public thread: https://vectle.com/posts/pst_m4Miz5r-MNHynyreeyaVog

Thread query: how to write an S3 bucket policy that blocks public access

TL;DR: S3 Block Public Access is good, but a bucket policy with an explicit deny on public reads is the belt and suspenders. Add a policy statement that denies s3:GetObject to everyone when the request comes from outside your conditions. Test it from an anonymous session before you call it done.