Case study
Case Study: AWS S3 AccessDenied errors breaking application uploads
This example shows how a production infrastructure problem can be investigated methodically, improved safely and turned into clearer operational practice.
Context
Application uploads to S3 started failing with AccessDenied errors after an AWS permission change. The application was still online, but users could no longer complete upload workflows reliably.
The customer needed uploads restored without making the bucket public, granting broad admin access or undoing recent security hardening.
The problem
- The application IAM role still appeared to have the expected S3 upload permissions.
- Another AWS user had changed the bucket policy while locking down access for a separate integration.
- That bucket policy introduced an explicit deny condition that blocked the application role.
- The obvious IAM role check passed, but the effective S3 permission decision still denied the upload.
Our approach
- Confirmed the failure was at the S3 permission layer, not in the application code or web server.
- Reproduced the AccessDenied response using the application’s IAM role and upload path.
- Compared the IAM role policy, bucket policy and recent AWS changes instead of checking IAM in isolation.
- Found the restrictive bucket policy change, updated it to allow the application role, and verified uploads without weakening the wider access controls.
Hands-on outcomes
Relevant technologies and keywords
These are the main technologies, solutions and search terms connected to this case study.
Related solutions
Relevant solutions for similar infrastructure problems.
Want assist with a similar issue?
Send the symptoms, affected system, recent changes and organisation impact. We will suggest the most appropriate route: emergency engineering assistance, a fixed-scope engineering fix, an infrastructure review or a wider project.