Half a Day on S3 Permissions, Not on Storage

I have used AWS S3 and not Cloudflare R2 or Backblaze B2, so take this as a report on one of the three. Getting files into a bucket and back out was quick, and that part went about as I expected. The part that cost me was IAM: about half a day, roughly 4 hours, went on permissions before things worked the way I wanted them to. None of that time was spent on storage itself.

Every comparison of these services is about price per gigabyte and egress fees. Those matter at scale. At the scale of a small app, the cost I actually paid was in hours, and it was all in access control.

Why permissions take the time

A storage API has one job and it either works or returns an error you can read. Permissions have two failure modes and only one of them is visible.

If the policy is too narrow, the app breaks and you know immediately. If it is too wide, everything works perfectly and you have given something more access than it needs, which you will not find out from testing. So you cannot tell when you are finished. Working and correct are different states here, which is why half a day goes on it rather than ten minutes.

Add to that the shape of the thing: a policy is JSON with actions, resources and conditions, and the names are not guessable. Knowing you want "let this one app write to this one bucket" does not tell you which actions that needs or how to scope the resource.

The order AWS actually recommends

I tried to write the perfect narrow policy first. AWS's own guidance says not to do that, and reading it earlier would have saved me most of the afternoon.

Their IAM security best practices page, read on 2 October 2026, defines least privilege as granting "only the permissions required to perform a task", and then says this about getting there: "You might start with broad permissions while you explore the permissions that are required for your workload or use case. As your use case matures, you can work to reduce the permissions that you grant to work toward least privilege."

So the recommended path is broad, then narrow, which is the reverse of what I attempted. They also say to begin from the AWS managed policies, while warning that those "might not grant least-privilege permissions for your specific use cases because they are available for use by all AWS customers".

And there is a tool for the narrowing step that I did not know existed: AWS can generate a policy from the access activity logged in CloudTrail, so the policy is derived from what your app actually did rather than from what you guessed it would need. For somebody spending half a day guessing, that is the part worth reading first.

Three other things on that page I had not done

Reading it properly for this article turned up three recommendations I had skipped, all of which take minutes.

AWS says to require multi-factor authentication for any case where you do need an IAM user or the root user. It says to treat root user credentials the way you would other sensitive personal information, and points at a separate page of root user practices. And it says to regularly review and remove unused users, roles, permissions, policies and credentials, using IAM's last accessed information to find them.

That last one is the counterpart to the half day. Permissions accumulate: the broad policy you created while exploring is still attached long after the exploring finished. Nobody ever gets an error from a permission that is too wide, so nothing prompts you to go back. A review you have scheduled is the only thing that does.

What I would do differently

Start from a managed policy, get the app working, and only then tighten. The tightening is a separate task you can do with evidence, and doing it with evidence is both faster and more correct than doing it from imagination.

Use roles rather than long-lived keys where you can. AWS's guidance is explicit that workloads should use temporary credentials with IAM roles, and that long-term access keys are for the cases where a role is not possible.

And budget the permissions work as its own line in the estimate. Adding file storage to an app took minutes. Adding an identity and an access boundary around it took the rest of the day, and that is what the job really was. The same thing happened to me with a GitHub token in being rate limited with a token set: the credential was easy and the behaviour around it was the work.