Using cross origin resource sharing (CORS) in Amazon S3

Author

Govardhana M K
September 23, 2025

TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities and articles.

👋 Before we begin, I’m happy to share a free practical workshop to sharpen your Kubernetes skills.

Kubernetes 1.33 just changed the game. For the first time, you can adjust container requests and limits without restarting pods, unlocking zero-downtime optimization. But beware: in-place resizing isn’t a magic fix. Missteps can lead to instability or wasted resources.

Join Anton Weiss and Arthur Berezin as they break down how to use this new capability effectively and when to avoid it. From traditional services to GPU-backed workloads, this session will show you how to strike the balance between efficiency and reliability.

💡 What you’ll learn:

⤷  Where in-place resizing delivers impact—and where it introduces risk.
⤷  A proven methodology to drive efficiency without hurting SLOs.
⤷  Practical strategies for optimizing GPU workloads.
⤷  Real-world examples of teams cutting costs while boosting resilience.

If you’re not a subscriber, here’s what you missed last week.

To receive all the full articles and support TechOps Examples, consider subscribing:

IN TODAY'S EDITION

🧠 Use Case

  • Using cross origin resource sharing (CORS) in Amazon S3

👀 Remote Jobs

📚️ Resources

🛠️ TOOL OF THE DAY

kconnect - A CLI utility that can be used to discover and securely access Kubernetes clusters across multiple operating environments.

🧠 USE CASE

Using cross origin resource sharing (CORS) in Amazon S3

In modern cloud apps, the frontend and backend rarely sit on the same domain. Your UI may be on your-domain.com, while files, APIs, or services could live on other-domain.com. This split architecture improves scalability but also triggers browser security checks that block requests across domains.

What is CORS?

Cross Origin Resource Sharing (CORS) is the mechanism that lets a browser safely fetch resources from a different origin. It’s essentially a contract: the server explicitly states which external origins are trusted and which request methods are allowed. Without it, cross domain calls fail by default.

Key terms you should know:

  • Origin → The domain where your app runs (e.g., your-domain.com).

  • Cross Origin Server → The domain hosting the resource (e.g., other-domain.com).

  • Access-Control-Allow-Origin → The server response header that decides if the browser can use the resource.

How a Typical CORS Flow Works

Preflight Request

  • The browser first sends an OPTIONS request to the cross-origin server (other-domain.com).

  • This request checks whether the origin (your-domain.com) is allowed to access the resource.

Preflight Response

  • The cross origin server responds with its CORS policy.

  • It specifies which origins and HTTP methods (GET, PUT, POST, etc.) are permitted.

Actual Request

  • If the preflight check passes, the browser makes the real request to the cross origin server.

Response

  • The cross origin server responds with the resource.

  • Since the origin was allowed, the browser accepts the response and delivers it to the app

Without the preflight negotiation, browsers would block the request entirely. This handshake ensures only trusted origins can access sensitive data, keeping cross domain interactions both functional and secure.

Here’s how to enable CORS the right way in S3:

1. Identify the access pattern

  • Frontend reads only → allow GET.

  • File uploads from browser → add PUT or POST.

  • APIs behind S3 static hosting → may require HEAD for checks.

2. Add a CORS configuration to your bucket

Go to your S3 bucket → Permissions → CORS configuration and apply JSON like:

[
  {
    "AllowedHeaders": ["*"],
    "AllowedMethods": ["GET", "PUT"],
    "AllowedOrigins": ["https://app.your-company.com"],
    "ExposeHeaders": ["ETag"],
    "MaxAgeSeconds": 3000
  }
]

  • AllowedOrigins → Don’t use "*" in production. Always specify your real domain.

  • AllowedMethods → Keep it minimal. Avoid DELETE unless absolutely required.

  • ExposeHeaders → Add only headers your frontend really needs (e.g., ETag).

In S3, CORS is not a “set and forget.” It’s is matching the browser’s handshake with the minimal rules your app actually needs. Start with the smallest surface area and expand only if you hit real use cases.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)

Looking to promote your company, product, service, or event to 52,000+ DevOps and Cloud Professionals? Let's work together.