Sign in Subscribe
Concepts

Enforcing Read-Only AWS S3 Access in Microservices with an Access Proxy

Andrios Robert

• 1 min read

A microservices access proxy solves this by acting as a single controlled gateway between your services and S3. Instead of handing out AWS credentials to every microservice, the proxy uses a tightly scoped AWS IAM role. This role has read-only permissions to the specific buckets or paths you define. No other actions allowed.

Here’s the flow:

  1. Client calls your microservice.
  2. Microservice calls the access proxy.
  3. Proxy assumes the read-only IAM role to request data from S3.
  4. Object is returned to the microservice, and no write privileges are ever exposed.

Use AWS IAM policy syntax to allow only s3:GetObject actions, scoped by resource ARN. Attach this policy to the proxy’s role. Block s3:PutObject, s3:DeleteObject, and anything else. In AWS terms, this is least privilege with surgical precision.

The benefits stack up fast:

  • Centralized control over S3 access.
  • Simplified credential management for microservices.
  • Reduced risk of data corruption.
  • Clear audit trails via AWS CloudTrail.

Deploying the access proxy as a container or Lambda lets you manage scaling independently of your services. Combine it with AWS API Gateway for external endpoints, or keep it internal over VPC. In multi-team setups, it becomes the single enforcement point for read-only S3 roles across environments.

If you need to enforce strict and fast read-only S3 access in microservices without exposing raw AWS keys, build the proxy. Grant it nothing beyond the GET permission. Test with buckets locked to the correct role ARN. Sleep knowing no code path can overwrite your data.

Want to see this pattern work in real time? Spin it up using hoop.dev and watch secure, read-only AWS S3 access flow through your microservices in minutes.