Coder Legion - Recent posts tagged aws-s3

S3 vs Supabase Storage vs Cloudinary (2026 Guide)

Mon, 31 Aug 2026 03:19:01 +0000

You're building a Next.js app that needs to store files — user avatars, product photos, PDFs, whatever — and you hit the same wall every developer hits: where do the actual files go?

For most apps, storing large user-uploaded files directly in Postgres isn't the best fit. Object storage is designed for this workload and keeps your database focused on relational data. So you're left picking between three names that show up in almost every tutorial: AWS S3, Supabase Storage, and Cloudinary. They all "store files," but they solve genuinely different problems, and picking the wrong one means either fighting your tools for months or paying for features you'll never touch.

By the end of this guide, you'll know exactly what each one is actually built for, how to wire up a basic upload with real code for all three, what they cost, and which one fits your specific project — not just whichever one showed up first in your search results.

Quick Answer

Choose AWS S3 if you want inexpensive, highly flexible object storage with a huge ecosystem and full AWS control.
Choose Supabase Storage if you're already using Supabase for your database and auth — it plugs directly into the same Row Level Security model you already know.
Choose Cloudinary if images and videos are a core part of your product and you want transformations (resizing, cropping, format conversion, transcoding) handled automatically, with almost no backend code.

If none of those single-sentence answers settled it, keep reading — the "why" behind each one is where the real decision lives.

Why This Comparison Is Tricky

Most "S3 vs X" posts compare feature checklists side by side and call it a day. The problem is these three tools aren't really competing for the same job:

S3 is raw object storage. It stores bytes under a key. It has no idea what an "image" is — resizing, format conversion, and CDN delivery are all things you have to bolt on separately (usually CloudFront).
Supabase Storage is an object-storage service with an S3-compatible API, wrapped in Supabase's API, authentication, and Postgres RLS model.
Cloudinary is a media pipeline first, storage second. Its actual product is on-the-fly image and video transformation — resize, crop, convert to WebP/AVIF, transcode video, remove backgrounds — all driven by URL parameters, with storage as the thing that makes that possible.

Keep that distinction in mind through the rest of this guide: you're not just picking "where files live," you're picking how much of the surrounding work (delivery, optimization, access control) you want to own yourself.

At a Glance

	AWS S3	Supabase Storage	Cloudinary
What it actually is	Raw object storage	Object storage + Supabase Auth/RLS integration	Media transformation pipeline
Access control model	IAM policies + bucket policies	Row Level Security (SQL policies)	Signed uploads / upload presets
Built-in image transforms	None — add an image-processing/optimization layer separately	Available in Paid Plans	Extensive (resize, crop, AI background removal, format negotiation)
Video handling	None — you'd wire up a separate transcoding service	Not a core feature	First-class — transcoding, adaptive streaming, a built-in video player
CDN included	No — add CloudFront separately	Yes, via the Supabase CDN	Yes, built in
Best paired with	Any stack, especially if you already use AWS	A Supabase-backed app (Postgres + Auth)	Any stack where images/video are core UX
Free tier	12-month intro tier only, otherwise pay-as-you-go	~1 GB storage, 5 GB egress (check current limits)	25 credits/month (1 credit = 1 GB storage, 1 GB bandwidth, or 1K transformations)<br/> credits are shared across these resources
Pricing model	Storage + requests + data transfer, billed separately (see below)	Flat plan tiers + usage overages	Credit-based, fixed tiers

💡 Tip: Pricing on all three changes often enough that any number printed in a blog post is a snapshot, not a promise. Treat the figures above as ballpark, and always check each provider's live pricing page before committing budget to one.

AWS S3: Raw, Cheap, and You Own Everything

Amazon S3 (Simple Storage Service) is the original cloud object store — files go in under a "key" (basically a path string), and you get them back out the same way. No opinions about what the file is.

Where S3 wins:

One of the cheapest raw storage per GB at real scale, especially once you're past a few hundred GB
Full control — bucket policies, lifecycle rules (auto-delete or archive old files), versioning, cross-region replication
The de facto standard — every CDN, backup tool, and CMS speaks S3's API, including S3-compatible alternatives like Cloudflare R2 and Backblaze B2

Where S3 struggles:

Zero built-in image processing. Want a thumbnail? You'll need a separate image-processing layer, such as a Lambda-based workflow, an image optimization service, or a framework-level optimizer.
No CDN out of the box — S3 alone serves from one region. You need CloudFront (or another CDN) in front of it for real-world performance.
More setup: IAM users, bucket policies, CORS config, and (for direct browser uploads) presigned URLs are all things you configure by hand.

S3 Pricing Is More Than "Per GB Stored"

This matters enough for a "which is cheapest" comparison that it deserves its own callout: S3's bill is not just storage. You're billed separately for several things at once:

Storage — per GB-month, and it varies by storage class (Standard, Infrequent Access, Glacier, etc.)
Requests — PUT/COPY/POST/LIST requests cost more per-request than GET requests, and both are metered
Data transfer out — serving files to the internet (not through a CDN) is billed per GB and is usually the line item that surprises people
Retrieval fees — if you move infrequently-accessed files to a cheaper storage class, pulling them back out costs extra
Lifecycle transitions — moving objects between storage classes automatically (e.g. Standard → Glacier after 90 days) also incurs a small per-object request cost

A storage-only comparison (S3 vs. Supabase's per-GB rate vs. Cloudinary's credits) misses this. An app that serves thumbnails directly from S3 with heavy traffic and no CDN in front can rack up request and transfer charges that dwarf the storage bill itself — which is exactly why pairing S3 with CloudFront isn't just a performance decision, it's often a cost one too (CloudFront's cached data transfer is typically cheaper than S3's direct transfer-out rate).

A Minimal S3 Upload in Next.js 16

This uses the presigned URL pattern — your server never touches the file bytes, it just asks S3 for permission and hands the browser a temporary signed URL to upload directly.

npm install @aws-sdk/client-s3 @aws-sdk/s3-request-presigner

// lib/s3-client.ts
import { S3Client } from "@aws-sdk/client-s3";

export const s3Client = new S3Client({
  region: process.env.AWS_REGION!,
  credentials: {
    accessKeyId: process.env.AWS_ACCESS_KEY_ID!,
    secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY!,
  },
});

// app/api/presigned-url/route.ts
import { NextRequest, NextResponse } from "next/server";
import { PutObjectCommand } from "@aws-sdk/client-s3";
import { getSignedUrl } from "@aws-sdk/s3-request-presigner";
import { s3Client } from "@/lib/s3-client";
import { randomUUID } from "crypto";
import { auth } from "@/lib/auth"; // your auth solution of choice

const ALLOWED_TYPES = ["image/jpeg", "image/png", "image/webp"];
const MAX_FILE_SIZE = 5 * 1024 * 1024; // 5MB

export async function POST(request: NextRequest) {
  // 1. Authentication — reject anonymous requests before doing anything else
  const session = await auth();
  if (!session?.user) {
    return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
  }

  const { fileName, fileType, fileSize } = await request.json();

  // 2. MIME allowlist — reject anything you don't explicitly support
  if (!ALLOWED_TYPES.includes(fileType)) {
    return NextResponse.json({ error: "Unsupported file type" }, { status: 400 });
  }

  // 3. Max file size — a best-effort check against the size the client reports.
  // A presigned PUT can't fully enforce this on its own; see the note below.
  if (typeof fileSize !== "number" || fileSize > MAX_FILE_SIZE) {
    return NextResponse.json({ error: "File too large" }, { status: 400 });
  }

  // 4. Filename sanitization — never trust the client's filename for anything
  // beyond picking a safe extension. Strip everything else.
  const safeExtension =
    fileName?.split(".").pop()?.replace(/[^a-z0-9]/gi, "").slice(0, 10) || "bin";

  // 5. Server-generated key — the client never chooses where its file lands.
  // Scoping by the authenticated user's id is also your authorization boundary:
  // even if someone tampers with the request, they can only ever get a
  // presigned URL scoped to their own prefix.
  const key = `uploads/${session.user.id}/${randomUUID()}.${safeExtension}`;

  const command = new PutObjectCommand({
    Bucket: process.env.S3_BUCKET_NAME!,
    Key: key,
    ContentType: fileType,
  });

  const uploadUrl = await getSignedUrl(s3Client, command, { expiresIn: 60 });

  return NextResponse.json({ uploadUrl, key });
}

What's happening here: your server never sees the file bytes — it just signs a temporary permission slip — but it does gate who gets that slip (authentication), what they're allowed to upload (MIME allowlist), roughly how big it can be, and exactly where it lands (a server-generated key under the caller's own user id, never a client-supplied path). The browser then does a plain fetch(uploadUrl, { method: "PUT", body: file }) straight to S3, keeping large files off your server entirely — which matters a lot on serverless platforms with body-size limits.

⚠️ This example is still a demonstration, not a drop-in production upload endpoint. A few things it deliberately leaves out, worth knowing about before you ship:

Authoritative size enforcement — the fileSize check above only validates what the client claims its file is. A presigned PutObjectCommand doesn't enforce a byte limit by itself. For a hard limit, use a presigned POST with a content-length-range condition instead of a presigned PUT, or verify the object's real size after upload (via an S3 event notification or a scheduled cleanup job) and delete anything oversized.

Checksum/content validation — for anything security-sensitive, pass a ChecksumSHA256 to PutObjectCommand so S3 rejects an upload whose bytes don't match what the client claimed, and consider scanning uploaded files (e.g. with a virus-scanning Lambda trigger) before treating them as safe to serve.

Rate limiting — nothing above stops one authenticated user from requesting thousands of presigned URLs per minute. Put a rate limiter (Upstash Ratelimit, a simple sliding-window check in your database, or your edge/CDN's built-in limiting) in front of this route in production.

⚠️ Common Mistake: Making the bucket public "to make things easier." None of the common upload/display patterns need a public bucket — presigned URLs grant scoped, temporary access without exposing the bucket itself. Leave Block all public access on unless you have a specific, narrow reason to open one prefix.

Supabase Storage: S3 Underneath, Postgres on Top

Supabase Storage provides an S3-compatible object-storage interface and integrates it with Supabase Auth and Postgres RLS — every bucket can be protected by Row Level Security policies, the same SQL-based authorization system you're already using for your database tables if you're on Supabase.

Where Supabase Storage wins:

If you're already using Supabase Auth + Postgres, storage access rules live in the same mental model — a policy like "a user can only read their own files" is one create policy statement, not a separate IAM configuration
Simple, batteries-included API (upload, download, createSignedUrl) that works identically from the browser or the server
Offers on-the-fly image transformations included via a query-param API, so you don't always need a separate CDN layer for simple resizing, although availability and usage depend on your plan

Where Supabase Storage struggles:

Currently supports automatic WebP optimization but its transformation system is considerably narrower than Cloudinary's
Free-tier storage and egress are modest — fine for an MVP, tight for a media-heavy app
You're tied to Supabase's infrastructure choices; less low-level control than raw S3

A Minimal Supabase Storage Upload

npm install @supabase/supabase-js @supabase/ssr

// lib/supabase/client.ts
import { createBrowserClient } from "@supabase/ssr";

export function createClient() {
  return createBrowserClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!
  );
}

// components/avatar-uploader.tsx
"use client";

import { createClient } from "@/lib/supabase/client";

export function AvatarUploader() {
  const supabase = createClient();

  const handleUpload = async (e: React.ChangeEvent<HTMLInputElement>) => {
    const file = e.target.files?.[0];
    if (!file) return;

    // Get the current user from the session — never take a userId as a
    // prop or form value. The path below is only as trustworthy as this.
    const {
      data: { user },
    } = await supabase.auth.getUser();

    if (!user) return;

    const filePath = `${user.id}/${Date.now()}-${file.name}`;

    const { error } = await supabase.storage
      .from("avatars")
      .upload(filePath, file, { upsert: false });

    if (error) {
      console.error("Upload failed:", error.message);
      return;
    }

    // For a private bucket, generate a temporary signed URL to display it
    const { data: signed } = await supabase.storage
      .from("avatars")
      .createSignedUrl(filePath, 60 * 60); // 1 hour

    console.log("Signed URL:", signed?.signedUrl);
  };

  return <input type="file" accept="image/*" onChange={handleUpload} />;
}

What's happening here: .storage.from("avatars").upload(...) uploads directly through the Supabase client — no separate presigned-URL round trip needed, because auth and authorization already ride along with the client's session. createSignedUrl mirrors S3's presigned-URL pattern, but scoped through the bucket's own RLS policies instead of IAM.

-- Only let a user manage files inside their own folder
create policy "Users can upload their own avatar"
on storage.objects
for insert
to authenticated
with check (
  bucket_id = 'avatars'
  and (select auth.uid())::text = (storage.foldername(name))[1]
);

What's happening here: storage.foldername(name) splits the object path (e.g. user-id/photo.jpg) into segments, so this policy checks that the folder name matches the uploader's own auth.uid(). The authorization model uses Postgres RLS, just like your database tables.

⚠️ Important — don't mistake a client-supplied path for real security. In the component above, user.id comes from supabase.auth.getUser(), which reads the server-verified session — that part is trustworthy. But the resulting filePath string is still just something the client constructs and sends along with the upload request. What actually makes this safe is the RLS policy, which independently re-checks (select auth.uid()) against the path on Supabase's side, every time, regardless of what the client sends.

This distinction matters: if you ever accept a user id as a raw prop, a hidden form field, or anything else that isn't derived from the verified session — or if RLS on the bucket is ever disabled or misconfigured — nothing stops a client from writing someone-elses-id/file.jpg into the path and having the request succeed. The policy is the actual security boundary here, not the fact that the code "usually" builds the path from the right value.

💡 Tip: Writing RLS policies by hand for every bucket pattern (owner-only, team-shared, admin override) gets repetitive fast. If you're already on Supabase, a Supabase RLS Policy Generator can produce the strict, performance-optimized version of these policies — including the (select auth.uid()) wrapper used above — for your specific access pattern.

Cloudinary: A Media Pipeline for Images and Video

Cloudinary's whole pitch is different from the other two: you're not really buying storage, you're buying transformation-on-delivery — and it's easy to think of Cloudinary as "an image tool," but that undersells it. Video is a first-class part of the product too: transcoding, adaptive bitrate streaming, and a dedicated video player component (CldVideoPlayer) ship alongside the image tooling, not as an afterthought. Upload one asset once, and every size, crop, and format you'll ever need — image or video — gets generated from URL parameters, with no separate resize job and no manual WebP conversion.

Where Cloudinary wins:

Transformations are wildly capable across both media types: resize, crop, auto-format (automatically selects an appropriate optimized format for the requesting browser), AI background removal, text/image overlays for images; transcoding and adaptive streaming for video
The next-cloudinary SDK gives you drop-in components — <CldImage> wraps next/image, <CldVideoPlayer> handles video — with almost no configuration
Built-in CDN delivery for both, so there's no separate CloudFront-equivalent to wire up

Where Cloudinary struggles:

Free tier (25 credits/month, where 1 credit ≈ 1 GB storage, 1 GB bandwidth, or 1,000 transformations) disappears fast on anything with real traffic — video in particular eats through credits quickly since files are larger
Pricing is credit-based across three different resource types at once, which makes forecasting cost harder than a flat per-GB rate
It's optimized for media-heavy applications; if most of your workload is arbitrary documents and backups, general-purpose object storage is usually a more natural fit

A Minimal Cloudinary Upload + Display in Next.js 16

npm install next-cloudinary cloudinary

// app/api/sign-cloudinary-params/route.ts
import { v2 as cloudinary } from "cloudinary";
import { NextResponse } from "next/server";
import { auth } from "@/lib/auth"; // your auth solution of choice

cloudinary.config({
  cloud_name: process.env.NEXT_PUBLIC_CLOUDINARY_CLOUD_NAME,
  api_key: process.env.CLOUDINARY_API_KEY,
  api_secret: process.env.CLOUDINARY_API_SECRET,
});

// The widget generates its own paramsToSign and sends them here — never
// sign that object blindly. Only a small, known set of keys is allowed
// through; anything else gets the whole request rejected.
const ALLOWED_PARAM_KEYS = new Set(["timestamp", "folder", "upload_preset", "source"]);

export async function POST(request: Request) {
  const session = await auth();
  if (!session?.user) {
    return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
  }

  const { paramsToSign } = await request.json();
  const keys = Object.keys(paramsToSign ?? {});
  const unexpectedKeys = keys.filter((key) => !ALLOWED_PARAM_KEYS.has(key));

  if (unexpectedKeys.length > 0) {
    return NextResponse.json(
      { error: `Unexpected upload parameters: ${unexpectedKeys.join(", ")}` },
      { status: 400 }
    );
  }

  const signature = cloudinary.utils.api_sign_request(
    paramsToSign,
    process.env.CLOUDINARY_API_SECRET!
  );

  return NextResponse.json({ signature });
}

What's happening here: the widget builds paramsToSign on its own based on how it's configured, and sends that exact object to your endpoint to be signed — so you can't simply substitute your own parameters the way you might for a normal API request, or the signature won't match what the widget actually uploads with. What you can do, and what this endpoint does, is refuse to sign anything that isn't on a small allowlist of expected keys, and require a logged-in session before generating a signature at all. This stops the endpoint from being used to sign arbitrary transformation instructions, moderation overrides, or unexpected metadata that a modified client request might try to sneak in. Once signed, the upload still goes directly from the browser to Cloudinary — your CLOUDINARY_API_SECRET never reaches the client.

💡 Tip: Signed uploads narrow who can request a signature, but the file itself — its folder, allowed formats, and max size — is still best constrained by an upload preset configured in the Cloudinary dashboard (Settings → Upload → Upload presets), since a preset's restrictions are enforced by Cloudinary itself and can't be bypassed by tampering with the request the way a loosely-validated paramsToSign object could be.

// components/cloudinary-uploader.tsx
"use client";

import { useState } from "react";
import { CldUploadWidget, CldImage } from "next-cloudinary";

export function CloudinaryUploader() {
  const [publicId, setPublicId] = useState<string | null>(null);

  return (
    <div>
      <CldUploadWidget
        signatureEndpoint="/api/sign-cloudinary-params"
        options={{ folder: "uploads" }}
        onSuccess={(result) => {
          if (result.info && typeof result.info === "object") {
            setPublicId(result.info.public_id);
          }
        }}
      >
        {({ open }) => (
          <button onClick={() => open()}>Upload an image</button>
        )}
      </CldUploadWidget>

      {publicId && (
        <CldImage
          src={publicId}
          width={600}
          height={400}
          crop="fill"
          alt="Uploaded image"
        />
      )}
    </div>
  );
}

What's happening here: <CldImage> renders the uploaded asset with a crop="fill" transformation applied automatically, on top of next/image's own optimization. Swap this component for <CldVideoPlayer> and the same signed-upload flow works for video uploads, using the same signing endpoint.

⚠️ Common Mistake: Using an unsigned upload preset (no signatureEndpoint, just a public preset name) for anything beyond a quick prototype. Anyone who knows the preset name can initiate uploads subject to the restrictions configured on that preset — fine for a personal demo, risky for anything public-facing.

Media Optimization: Who Actually Handles It?

This is usually the deciding factor in practice, so it's worth calling out directly:

S3 does nothing for you, for images or video. You either accept unoptimized originals, or build your own pipeline (Lambda@Edge, a CloudFront Function, a dedicated transcoding service, or routing S3 through Cloudinary/imgix as a second layer).
Supabase Storage offers a transformation API (resize + quality via query params) that works with a custom Next.js image loader — available only in Paid Plans, and images only; there's no equivalent video pipeline.
Cloudinary is purpose-built for exactly this, for both media types. Automatic format negotiation (AVIF/WebP per browser), on-the-fly cropping, <CldImage>'s tight next/image integration, and adaptive-bitrate video streaming mean you write the least code here.

If your app's core UX depends on fast, well-optimized media at scale — a marketplace, a photo-heavy blog, a portfolio builder, or a product with video uploads (course platforms, social apps, UGC video) — that alone can justify Cloudinary's cost. If media is incidental — a profile picture here, a document there — S3 or Supabase Storage is plenty.

Security Models Compared

	How access is controlled
S3	IAM policies (who can call the API) + bucket policies (what's publicly readable) + presigned URLs for temporary, scoped access
Supabase Storage	Row Level Security policies written in SQL, evaluated per-request against the logged-in user — the same system protecting your database tables
Cloudinary	Signed uploads (server signs the request, ideally after validating it) or unsigned upload presets (public, rate-limited by preset config)

The practical difference: S3 and Cloudinary both support signed requests for scoped upload/access workflows, while Supabase emphasizes identity-aware RLS policies. Supabase Storage centers on who is asking, evaluated through Postgres RLS policies. If your app already has rich, row-level permission logic in Postgres, Supabase Storage lets you reuse that thinking instead of maintaining a parallel IAM policy language — but in all three, a client-constructed path or parameter is never the actual security boundary on its own; the server-side check (RLS, IAM, or a whitelist) is.

Can You Mix Them?

Yes, and plenty of real apps do. A common pattern:

S3 (or Cloudflare R2, an S3-compatible alternative) for cheap, high-volume storage of originals — documents, raw uploads, backups
Cloudinary in front of just the media subset (images and video), either by uploading directly to Cloudinary or using its remote fetch feature to transform images that already live in S3
Supabase Storage for anything tightly coupled to your Supabase-authenticated user data, where RLS access rules matter more than transformation power

There's no rule that says "pick exactly one." Reach for the tool that fits that specific type of file, not a single storage layer for your entire app by default.

Decision Matrix

Your situation	Pick
Already deep in AWS infrastructure	S3
Need the cheapest storage at real scale, and can account for request/transfer costs	S3 / R2 depending on egress profile
Already using Supabase for auth + database	Supabase Storage
Want row-level access rules without a separate IAM setup	Supabase Storage
Images/video are core to your product's UX	Cloudinary
Want automatic format optimization with near-zero setup	Cloudinary
Storing mostly non-image files (PDFs, CSVs, backups)	S3
Small MVP, want the fastest path to "it works"	Supabase Storage if the app already uses Supabase;<br/>Cloudinary if images or video are central.

Frequently Asked Questions

Is Supabase Storage actually built on S3?

Supabase Storage is S3-compatible and exposes an S3 protocol endpoint, so tools that speak the S3 API can interact with it. The important distinction is that Supabase adds its own API, authentication integration, and Postgres RLS model.

Do I need Cloudinary if I'm already using next/image?

Not necessarily. next/image already handles resizing, format conversion, and lazy loading for images you serve from S3 or Supabase Storage — it just needs the source domain allowlisted in remotePatterns. Reach for Cloudinary specifically when you need transformations next/image doesn't do itself, like AI background removal, video transcoding, or on-the-fly cropping driven by user input.

Which one is cheapest for a small side project?

For a small MVP, Supabase Storage is attractive if you're already using Supabase, while Cloudinary is attractive when image or video transformations are central. S3 can also be inexpensive, but remember it's billed across storage, requests, and data transfer separately — factor in all three before assuming it's the cheapest option for your specific traffic pattern.

Is a presigned S3 upload URL alone enough security?

No. A presigned URL controls whether an upload to a specific key is allowed within its expiry window — it doesn't validate file type, size, or content on its own beyond what you sign into the request. Pair it with server-side checks (auth, MIME allowlist, size limits) before issuing the URL, as shown in this guide's example, and treat anything beyond that (checksums, virus scanning, rate limiting) as genuinely needed for production, not optional polish.

Can I switch between these later without a full rewrite?

Keeping storage access behind a small abstraction makes migration easier. The files themselves may be easy to migrate; the harder part is usually recreating URLs, access-control rules, transformations, and metadata.

Does Cloudinary replace the need for a CDN?

Yes — Cloudinary delivers every asset through its own CDN by default, so you don't need to add CloudFront or another CDN in front of it the way you would with raw S3.

What about Cloudflare R2 as another alternative?

R2's S3-compatible API makes many application patterns—such as presigned URLs and S3 SDK usage—very similar to S3, although its pricing and access-control model differ.

Wrapping Up

None of these three is a universally "better" choice — they're solving different halves of the same problem. S3 gives you the cheapest, most flexible raw storage and expects you to build the rest, including the parts of its own billing model (requests, transfer, retrieval) that are easy to overlook. Supabase Storage trades some of that flexibility for tight integration with the auth and database system you're probably already using — just remember that a client-supplied path is never the actual security boundary; the RLS policy is. Cloudinary trades storage cost for a transformation pipeline — for images and video — that would otherwise take real engineering time to build yourself.

Start by asking what you're actually storing and who needs to see it — that answer usually points to one of these three faster than a feature-by-feature comparison ever will.

Continue Learning

Free Developer Tools

Supabase RLS Policy Generator — generate strict, pattern-specific Row Level Security policies for your storage buckets, including the owner-only pattern shown in this guide.

How to Display Images from S3 in Next.js 16 (2026 Guide)

Sun, 02 Aug 2026 06:14:55 +0000

Getting a file into S3 is only half the job. Sooner or later you need to actually show that image back to the user — on a profile page, in a gallery, inside a product card — and that's where a second wave of questions shows up. Do you just paste the S3 URL into an <img> tag? Does next/image even work with S3? What if the file is private and shouldn't be reachable by just anyone with the link?

If you followed our guide on uploading files to S3 with Next.js 16, you already have files living in one of three ways — proxied through your server, uploaded directly via a presigned URL, or pushed up in multipart chunks. The good news: how you display an image doesn't depend on how it was uploaded. It depends on one thing only — is the object public or private?

In this guide, you'll learn all three real-world patterns for displaying S3 images in Next.js 16:

Public bucket URLs — the simplest option, for non-sensitive assets
Presigned GET URLs — for private files that only the right user should see
CloudFront CDN delivery — for performance and scale, with both public and signed variants

By the end, you'll know exactly which pattern fits your use case and have working code for each.

Why This Is Tricky

It's tempting to think "S3 has a URL, I'll just use that." Sometimes that's genuinely fine. But most real apps hit one of these problems fast:

Not everything should be public. A user's private document or someone else's uploaded receipt shouldn't be reachable by anyone who guesses or copies the URL.
next/image doesn't know about S3 by default. Next.js's image optimizer blocks external domains until you explicitly allow them — skip this step and your images silently fail to load.
Raw S3 isn't a CDN. Every request hits the bucket directly, in one region, with no edge caching — fine for a side project, not great once you have real traffic.

So the real question for every image you display is: "Who is allowed to see this, and does it need to be fast at scale?" That answer picks your pattern.

💡 Tip: If you're unsure whether something should be public, default to private. It's much easier to make a private file public later than to discover a "public" file leaked something sensitive.

Prerequisites & Setup

This guide continues directly from our S3 upload guide and assumes:

Next.js 16 with the App Router
TypeScript in strict mode
Tailwind CSS for the UI examples
The same S3 bucket and s3Client from the upload guide's lib/s3-client.ts

If you haven't set up the S3 client yet, go set that up first — every pattern below reuses it.

Allow S3 (and CloudFront) in next.config

next/image refuses to optimize images from a domain it doesn't recognize — this is a security default, not a bug. Add your bucket's hostname to remotePatterns:

// next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  images: {
    remotePatterns: [
      {
        protocol: "https",
        hostname: "devstacked-uploads-demo.s3.us-east-1.amazonaws.com",
      },
      {
        protocol: "https",
        hostname: "*.cloudfront.net", // for Pattern 3 later in this guide
      },
    ],
  },
};

export default nextConfig;

⚠️ Common Mistake: Forgetting this step and assuming next/image is broken. The error Next.js throws ("hostname is not configured") is exactly this — it's not a bug, it's the optimizer refusing to fetch from an unlisted domain.

💡 Tip: If you're serving stable public URLs (Pattern 1 or the public side of Pattern 3), also tune minimumCacheTTL:
images: {
  minimumCacheTTL: 60 * 60 * 24 * 30, // cache optimized output for 30 days
  remotePatterns: [/* ... */],
},
By default, Next.js only caches an optimized image for 4 hours before re-checking the source. For images that never change once uploaded (like avatars or product photos with unique keys), a much longer TTL avoids repeated, unnecessary re-optimization of the same file.

Pattern 1: Public Bucket URLs

How it works: the object is publicly readable, so its S3 URL works for anyone, forever — no signing, no expiry, no server involvement at all.

Browser → S3 object URL directly (no server request needed)

This is the right call for genuinely non-sensitive assets: blog cover images, public product photos, avatars a user chose to make visible. It's also the fastest pattern to build, since there's no backend logic involved in displaying the image at all.

Step 1: Allow Public Reads on Specific Objects

Rather than making the whole bucket public (don't do that), scope a bucket policy to just the folder holding public assets:

// s3-public-read-policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadForPublicFolder",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::devstacked-uploads-demo/public/*"
    }
  ]
}

What's happening here: this policy only opens read access to objects under the public/ prefix — everything else in the bucket (like uploads/ or large-uploads/ from the upload guide) stays private by default.

⚠️ Important: If your bucket still has Block all public access fully enabled (from the upload guide's setup), AWS will reject this policy outright with an "access denied" error, even though the policy itself is valid. Go to your bucket → Permissions → Block public access and uncheck the two bucket policy Block Public Access settings while leaving the ACL-related settings enabled. This allows a scoped public bucket policy without relying on public ACLs.

⚠️ Common Mistake: Applying a public-read policy to the entire bucket instead of a scoped prefix. If your upload code ever writes a sensitive file without thinking to change the key, it becomes silently public the moment it lands.

Step 2: Store the Public URL Format

// lib/s3-urls.ts
const BUCKET_NAME = process.env.S3_BUCKET_NAME!;
const REGION = process.env.AWS_REGION!;

export function getPublicUrl(key: string): string {
  // encodeURIComponent handles spaces and special characters in the key —
  // a raw key like "public/my photo.jpg" produces an invalid URL without it
  const encodedKey = key.split("/").map(encodeURIComponent).join("/");
  return `https://${BUCKET_NAME}.s3.${REGION}.amazonaws.com/${encodedKey}`;
}

Since public URLs never expire and never need signing, you can build this string anywhere — no API call needed, not even to your own server.

⚠️ Common Mistake: Encoding the whole key with a single encodeURIComponent(key) call. That also escapes the / characters in the path, turning public/avatars/photo.jpg into a single garbled segment instead of a valid nested path. Encode each path segment individually, as shown above.

Step 3: Render It with next/image

// components/public-avatar.tsx
import Image from "next/image";
import { getPublicUrl } from "@/lib/s3-urls";

interface Props {
  objectKey: string; // e.g. "public/avatars/uuid-photo.jpg"
  alt: string;
}

export function PublicAvatar({ objectKey, alt }: Props) {
  return (
    <Image
      src={getPublicUrl(objectKey)}
      alt={alt}
      width={96}
      height={96}
      className="rounded-full object-cover"
    />
  );
}

Because we added the S3 hostname to remotePatterns earlier, Next.js is happy to optimize this image — resizing, format conversion (like WebP), and lazy loading all work exactly like they would with a local image.

Pattern 2: Presigned GET URLs for Private Files

How it works: the object stays fully private in S3. When a user is allowed to view it, your server generates a short-lived, signed URL — just like the presigned upload URLs from the upload guide, but for reading instead of writing.

Browser → Next.js (ask "can I see this file?") → gets presigned GET URL
Browser → S3 directly, using that URL, before it expires

This is the mirror image of the presigned upload pattern: same idea, opposite direction. Use it for anything user-specific — private documents, someone's uploaded ID photo, a paid course's video thumbnail.

Step 1: Generate the Presigned GET URL

// app/api/image-url/route.ts
import { NextRequest, NextResponse } from "next/server";
import { GetObjectCommand } from "@aws-sdk/client-s3";
import { getSignedUrl } from "@aws-sdk/s3-request-presigner";
import { s3Client } from "@/lib/s3-client";
import { auth } from "@/lib/auth"; // your auth solution of choice

const URL_EXPIRY_SECONDS = 300; // 5 minutes

export async function GET(request: NextRequest) {
  const key = request.nextUrl.searchParams.get("key");
  const session = await auth();

  if (!session?.userId) {
    return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
  }

  if (!key || !key.startsWith(`private/${session.userId}/`)) {
    return NextResponse.json({ error: "Forbidden" }, { status: 403 });
  }

  const command = new GetObjectCommand({
    Bucket: process.env.S3_BUCKET_NAME!,
    Key: key,
  });

  const url = await getSignedUrl(s3Client, command, {
    expiresIn: URL_EXPIRY_SECONDS,
  });

  return NextResponse.json({ url });
}

What's happening here:

We check the user is authenticated before doing anything else — a presigned URL is only as safe as the check that generates it
The key check (key.startsWith('private/${session.userId}/')) makes sure a user can only ever get a signed URL for their own files, not someone else's, even if they know another user's exact key
expiresIn: 300 means the link works for 5 minutes — long enough to load the image, short enough that a copied link goes stale quickly

⚠️ Common Mistake: Generating a presigned GET URL without checking who's asking. It's easy to think "it expires, so it's safe" — but a 5-minute window is still plenty of time for a leaked link to be misused if you skip the ownership check.

Step 2: Fetch and Display It Client-Side

// components/private-image.tsx
"use client";

import { useEffect, useState } from "react";
import Image from "next/image";

interface Props {
  objectKey: string;
  alt: string;
}

export function PrivateImage({ objectKey, alt }: Props) {
  const [url, setUrl] = useState<string | null>(null);

  useEffect(() => {
    let cancelled = false;

    fetch(`/api/image-url?key=${encodeURIComponent(objectKey)}`)
      .then((res) => res.json())
      .then((data) => {
        if (!cancelled) setUrl(data.url ?? null);
      });

    return () => {
      cancelled = true;
    };
  }, [objectKey]);

  if (!url) {
    return <div className="h-24 w-24 rounded-lg bg-muted animate-pulse" />;
  }

  return (
    <Image
      src={url}
      alt={alt}
      width={96}
      height={96}
      unoptimized // presigned URLs change every load, so caching them via the optimizer adds little value
      className="rounded-lg object-cover"
    />
  );
}

Why unoptimized? Next.js's image optimizer caches the optimized result by URL. Since a presigned URL is different every single time it's generated, the optimizer would just be doing wasted work re-processing an image that's already the right size coming out of S3. Skipping optimization here is the correct call, not a shortcut.

This flag only bypasses Next.js's own optimization pipeline — it doesn't disable the browser's normal HTTP caching. The browser can still cache the actual image bytes according to whatever Cache-Control header S3 returns on the object itself. Many developers assume unoptimized means "never cached at all," which isn't true — it just means Next.js won't resize, re-encode, or store its own separate optimized copy of this particular image.

💡 Tip: For a server component instead of a client component, you can generate the presigned URL directly during the render on the server — no useEffect, no loading flicker, no extra round trip. Reach for the client-side version above only when the key isn't known until after the page has already loaded.

Pattern 3: CloudFront CDN Delivery

How it works: instead of the browser talking to S3 directly, it talks to a CloudFront distribution — a CDN that sits in front of your bucket, caches responses at edge locations close to your users, and can serve either public or signed content.

Browser → CloudFront (edge location near the user) → S3 (only on a cache miss)

Think of it like the difference between calling a single warehouse for every order versus having regional distribution centers — most requests get served from somewhere nearby instead of the original source every time.

This pattern matters once you have real traffic: it cuts latency, reduces direct load (and cost) on your S3 bucket, and gives you one clean domain to serve images from instead of raw S3 hostnames.

Step 1: Create a CloudFront Distribution

This is the part most tutorials gloss over, so let's walk through it fully — this guide is meant to get you a working setup, not just a conceptual overview.

a) Create the distribution

In the AWS Console under CloudFront → Distributions → Create distribution:

Under Origin domain, click into the field and select your S3 bucket from the dropdown (it appears automatically once you start typing the bucket name)
Leave Origin path empty unless you want CloudFront to only serve a subfolder of your bucket
Under Viewer protocol policy, choose Redirect HTTP to HTTPS
Leave the rest of the defaults for now and click Create distribution

Creation takes a few minutes to fully deploy — CloudFront needs to propagate your distribution to edge locations worldwide before it's live everywhere.

b) Attach Origin Access Control (for private objects)

If your bucket (or the folder you're serving) is private, you need CloudFront to be the only thing allowed to read from it directly:

Open your distribution → go to the Origins tab → select your origin → click Edit
Under Origin access control settings, choose Origin access control settings (recommended)
Click Create control setting, give it a name, and leave "Sign requests" as the default
Save — CloudFront will show a banner warning that the bucket policy still needs updating. That's expected; that's the next step.

c) Update the bucket policy to allow CloudFront

AWS actually generates the exact policy JSON for you at the end of step (b) — look for a "Copy policy" button in that same banner. It looks like this:

// s3-cloudfront-oac-policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCloudFrontServicePrincipal",
      "Effect": "Allow",
      "Principal": { "Service": "cloudfront.amazonaws.com" },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::devstacked-uploads-demo/*",
      "Condition": {
        "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/EXAMPLE_ID"
        }
      }
    }
  ]
}

Paste this into your bucket → Permissions → Bucket policy. If you also have the public-read policy from Pattern 1, both statements can coexist in the same policy's Statement array — one scopes access to CloudFront's service principal, the other to Principal: "*" under the public/ prefix.

⚠️ Common Mistake: Copying an OAC policy example from an older tutorial that references the deprecated Origin Access Identity (OAI) instead of OAC. AWS now recommends OAC for all new distributions — OAI still works but lacks OAC's support for all S3 request types and encryption options.

d) Get your CloudFront domain

Once the distribution's status shows Enabled (back on the distributions list), copy the value under Domain name — it looks like d111111abcdef8.cloudfront.net. That's the CLOUDFRONT_DOMAIN value you'll use in the code below. If you own a custom domain, you can also attach it under Alternate domain names (CNAMEs) with a matching ACM certificate, but the default .cloudfront.net domain works fine to get started.

⚠️ Common Mistake: Setting up CloudFront in front of a bucket but forgetting to update the bucket policy to allow the CloudFront OAC principal. Without it, CloudFront gets a 403 from S3 on every request, which looks like a CloudFront bug but is actually a permissions gap between the two services.

Step 2: Serve Public Assets Through CloudFront

For public assets, this is a one-line change from Pattern 1 — swap the S3 hostname for your CloudFront domain:

// lib/s3-urls.ts
const CLOUDFRONT_DOMAIN = process.env.CLOUDFRONT_DOMAIN!; // e.g. "d111111abcdef8.cloudfront.net"

export function getPublicUrl(key: string): string {
  return `https://${CLOUDFRONT_DOMAIN}/${key}`;
}

Nothing else about Pattern 1's code changes — same next/image component, same remotePatterns entry (already added in setup), just a faster, cached path to the same file.

Step 3: Serve Private Assets with Signed CloudFront URLs

For private files behind CloudFront, you sign the CloudFront URL itself instead of the S3 URL. This needs a CloudFront key pair rather than your IAM credentials:

// lib/cloudfront-signer.ts
import { getSignedUrl } from "@aws-sdk/cloudfront-signer";

const CLOUDFRONT_DOMAIN = process.env.CLOUDFRONT_DOMAIN!;
const PRIVATE_KEY = process.env.CLOUDFRONT_PRIVATE_KEY!;
const KEY_PAIR_ID = process.env.CLOUDFRONT_KEY_PAIR_ID!;

export function getSignedCloudFrontUrl(key: string): string {
  return getSignedUrl({
    url: `https://${CLOUDFRONT_DOMAIN}/${key}`,
    keyPairId: KEY_PAIR_ID,
    privateKey: PRIVATE_KEY,
    dateLessThan: new Date(Date.now() + 5 * 60 * 1000).toISOString(), // 5 minutes
  });
}

Install the extra package this needs:

npm install @aws-sdk/cloudfront-signer

What's happening here: getSignedUrl from the CloudFront signer package works conceptually the same as the S3 presigner from Pattern 2 — it appends signed query parameters that CloudFront checks before serving the file — but it's signed with a dedicated CloudFront key pair, not your regular IAM credentials.

Where to create that key pair:

In the AWS Console, go to CloudFront → Key management → Public keys → Create public key

This requires an RSA key pair. Generate one locally first:

openssl genrsa -out private_key.pem 2048
openssl rsa -pubout -in private_key.pem -out public_key.pem

Paste the contents of public_key.pem into the Create public key form and save
Go to Key management → Key groups → Create key group, and add the public key you just created to it
Back in your distribution's Behaviors tab, edit the relevant behavior and set Restrict viewer access to Yes, then select your key group under Trusted key groups
Note the Key ID shown after creating the public key — that's your CLOUDFRONT_KEY_PAIR_ID. The contents of private_key.pem (never the public key) go into CLOUDFRONT_PRIVATE_KEY

⚠️ Common Mistake: Adding the public key to CloudFront but forgetting step 5 — setting Restrict viewer access on the actual behavior. Without that, CloudFront still serves the file to anyone, signed URL or not, because nothing told it signing was required in the first place.

You'd call this the same way as Pattern 2's route handler — check the requesting user owns the file, then return the signed CloudFront URL instead of a signed S3 URL.

💡 Tip: If most of your private files belong to logged-in users viewing many images per page (a dashboard, a gallery), look into signed cookies instead of signed URLs. One signed cookie can authorize access to many files at once, instead of generating and re-fetching a fresh signed URL per image.

Which Pattern Should You Actually Use?

	Public Bucket URLs	Presigned GET URLs	CloudFront CDN
Setup complexity	Low — one bucket policy	Medium — auth check + route handler	Higher — distribution, OAC, key pairs
Latency	Depends on bucket region	Depends on bucket region	Low — served from nearby edge locations
Caching	Browser cache only	Effectively none (URL changes each time)	Edge-cached, huge win at scale
Access control	None — anyone with the URL	Per-request, ownership-checked	Optional — public or signed
Best for	Non-sensitive, low-to-medium traffic assets	Private, user-specific files	Any file type at real scale

Situation	Pattern
Blog covers, public product photos, anything anyone can see	Public bucket URLs
Small app, low traffic, simplicity matters more than speed	Public bucket URLs
Private user documents, receipts, anything tied to one account	Presigned GET URLs
You need an ownership check before showing the file	Presigned GET URLs
Public images at real scale — you want edge caching and lower latency	CloudFront (public)
Private files at scale, or many private images per page	CloudFront (signed URLs or cookies)

A common real-world setup uses all three at once: public marketing assets served through CloudFront for speed, private user uploads gated by presigned URLs (or signed CloudFront URLs once traffic grows), all coming from the same bucket you set up in the upload guide.

Frequently Asked Questions

Can I just use a plain `<img>` tag instead of next/image?

Yes, especially for presigned URLs that change on every load, where next/image's optimization caching adds little value anyway. next/image is worth it for public, stable URLs where resizing and format conversion (WebP/AVIF) genuinely save bandwidth.

Do I need CloudFront if I'm only using presigned URLs?

Not necessarily. Presigned URLs work fine served directly from S3. CloudFront becomes worth the setup once you care about latency at scale or want to reduce direct requests hitting your bucket — it's a performance and cost optimization, not a requirement for private files to work.

Why does my S3 image 403 even though I set a bucket policy?

Usually one of two things: the object key in your policy's Resource doesn't actually match where the file lives, or — if you're using CloudFront with Origin Access Control — the bucket policy hasn't been updated to allow the CloudFront principal specifically, separate from any public-read policy.

Should I store the S3 key or the full URL in my database?

Store the key (e.g. public/avatars/uuid.jpg), not the full URL. Keys never change even if you switch from raw S3 URLs to CloudFront later, rename your bucket, or move regions — you'd just update the URL-building function, not every database row.

Can I resize images on the fly instead of storing multiple sizes?

Yes — a common pattern is a CloudFront distribution with a Lambda@Edge or CloudFront Function that resizes images based on query parameters the first time they're requested, then caches the result. That's a bigger setup than this guide covers, but it's the natural next step once next/image's built-in optimization isn't enough for your use case.

Why does my image download instead of render in the browser?

This happens when the object's Content-Disposition header is set to attachment instead of inline — usually because it was uploaded with that metadata set explicitly, or a client library defaulted to it. Fix it by setting the header correctly at upload time:

new PutObjectCommand({
  Bucket: process.env.S3_BUCKET_NAME!,
  Key: key,
  Body: buffer,
  ContentType: file.type,
  ContentDisposition: "inline", // ensures browsers render it instead of downloading it
})

If files are already uploaded with the wrong header, you can fix them without re-uploading by copying the object onto itself with CopyObjectCommand and the corrected ContentDisposition and MetadataDirective: "REPLACE".

Wrapping Up

You now have three complete patterns for displaying S3 images in Next.js 16 — plain public URLs for anything non-sensitive, presigned GET URLs for anything private and user-specific, and CloudFront for when performance and scale start to matter. Paired with the upload guide, you've got the full loop covered: getting files into S3 the right way, and getting them back out safely and fast.

From here, natural next steps include adding on-the-fly image resizing at the CDN layer, setting up signed cookies for pages with many private images, or wiring up automatic thumbnail generation with S3 Event Notifications when a file finishes uploading.

📦 Source Code: View on GitHub

Continue Learning

Next.js 16 AWS S3 File Upload Guide: Presigned URLs, Proxy & Multipart

Sat, 01 Aug 2026 19:00:00 +0000

At some point, almost every real app needs file uploads — profile pictures, PDFs, videos, CSV imports. The tempting move is to just POST the file straight to your Next.js server and save it somewhere. That works great in a tutorial and falls apart the moment a real user uploads a 200MB video, because your serverless function times out, hits its body size limit, or just burns money streaming bytes it didn't need to touch.

The fix is almost always Amazon S3 (Simple Storage Service) — a place built specifically to store files cheaply and reliably, so your Next.js app doesn't have to. But "just use S3" isn't one pattern, it's three, and picking the wrong one is why most S3 upload tutorials online feel incomplete or break in production.

In this guide, you'll build all three real-world upload patterns in Next.js 16:

Server-side proxying — the file passes through your Next.js server on its way to S3
Direct-to-S3 presigned URLs — the browser uploads straight to S3, skipping your server entirely
Multipart uploads — for large files, split into chunks so they upload reliably and can resume

By the end, you'll know exactly which pattern to reach for and have working code for each.

Why This Is Tricky

Here's the core tension: your Next.js server (especially on serverless platforms like Vercel) is not a good place for large files to pass through.

Body size limits — most hosting platforms cap how much data a single request can carry (Vercel's default is 4.5MB for serverless functions).
Function timeouts — a slow upload over a weak connection can outlive your function's execution limit.
You pay for time, not just requests — every second your function spends waiting on a file transfer is a second you're billed for, even though your server isn't doing any real work.

So the real skill here isn't "how do I upload to S3" — it's "how much of this upload actually needs to touch my server?" That question is what decides which of the three patterns you reach for.

💡 Tip: As a rule of thumb — small files (avatars, documents under a few MB) are fine to proxy through your server. Anything user-facing and potentially large (videos, zip files, high-res images) should go direct-to-S3.

Prerequisites & Setup

This guide assumes:

Next.js 16 with the App Router
TypeScript in strict mode
Tailwind CSS for the (minimal) UI examples
An AWS account with an S3 bucket

Step 1: Create an S3 Bucket

In the AWS Console:

Click Create bucket
Give it a globally unique name, e.g. devstacked-uploads-demo
Pick a region close to your users
Leave Block all public access checked — you don't need a public bucket for any of these three patterns

⚠️ Common Mistake: Making the bucket public "to make uploads easier." None of the patterns in this guide need a public bucket. Presigned URLs grant temporary, scoped access without ever exposing the bucket itself.

Step 2: Create an IAM User for Programmatic Access

Your Next.js server needs credentials to talk to S3.

Go to IAM → Users → Create user
Name it something like nextjs-s3-uploader
Attach a policy scoped to just this bucket — not full AmazonS3FullAccess:

// s3-upload-policy.json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:AbortMultipartUpload",
        "s3:ListMultipartUploadParts"
      ],
      "Resource": "arn:aws:s3:::devstacked-uploads-demo/*"
    }
  ]
}

After creating the user, open it and generate an Access key

⚠️ Common Mistake: Using your AWS root account credentials in .env.local. Always create a scoped IAM user — if those keys ever leak, the blast radius is one bucket, not your entire AWS account.

Step 3: Configure CORS on the Bucket

Two of the three patterns in this guide (presigned URLs and multipart) have the browser talk directly to S3. By default, S3 blocks cross-origin requests from your site, so you need to explicitly allow it.

In your bucket → Permissions → Cross-origin resource sharing (CORS):

// s3-cors-config.json
[
  {
    "AllowedHeaders": ["*"],
    "AllowedMethods": ["PUT", "POST", "GET"],
    "AllowedOrigins": ["http://localhost:3000", "https://yourdomain.com"],
    "ExposeHeaders": ["ETag"]
  }
]

Why ExposeHeaders: ["ETag"] matters: the multipart pattern later needs to read the ETag header back from S3 after each chunk uploads. Without exposing it, your browser can see the response succeeded but can't read the header it needs.

💡 Tip: Consider enabling S3 Versioning from Properties Tab if users may overwrite files. It provides recovery from accidental deletes or replacements.

Step 4: Install Dependencies

npm install @aws-sdk/client-s3 @aws-sdk/s3-request-presigner

@aws-sdk/client-s3 — the official AWS SDK v3 client for talking to S3
@aws-sdk/s3-request-presigner — generates temporary, signed upload URLs

Step 5: Environment Variables

# .env.local
AWS_REGION=us-east-1
AWS_ACCESS_KEY_ID=your_access_key_id
AWS_SECRET_ACCESS_KEY=your_secret_access_key
S3_BUCKET_NAME=devstacked-uploads-demo

⚠️ Common Mistake: Never prefix these with NEXT_PUBLIC_. That would ship your AWS secret key to every visitor's browser. These stay server-only, always.

Step 6: Create a Reusable S3 Client

// lib/s3-client.ts
import { S3Client } from "@aws-sdk/client-s3";

export const s3Client = new S3Client({
  region: process.env.AWS_REGION!,
  credentials: {
    accessKeyId: process.env.AWS_ACCESS_KEY_ID!,
    secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY!,
  },
});

Every pattern below imports this single client instead of creating a new one per request.

Pattern 1: Server-Side Proxying

How it works: the browser sends the file to your Next.js server, and your server forwards it to S3. Your server sits in the middle of every byte.

Browser → Next.js Route Handler → S3

This is the simplest pattern to reason about and the easiest to add validation, virus scanning, or image processing to — because your server actually sees the file. The tradeoff is exactly what we covered above: your server pays the time and bandwidth cost of the transfer, so this pattern is best kept for small files only (a few MB at most).

Step 1: Create the Upload Route Handler

// app/api/upload/route.ts
import { NextRequest, NextResponse } from "next/server";
import { PutObjectCommand } from "@aws-sdk/client-s3";
import { s3Client } from "@/lib/s3-client";
import { randomUUID } from "crypto";

const MAX_FILE_SIZE = 5 * 1024 * 1024; // 5MB
const ALLOWED_TYPES = ["image/jpeg", "image/png", "image/webp"];

export async function POST(request: NextRequest) {
  try {
    const formData = await request.formData();
    const file = formData.get("file") as File | null;

    if (!file) {
      return NextResponse.json({ error: "No file provided" }, { status: 400 });
    }

    if (!ALLOWED_TYPES.includes(file.type)) {
      return NextResponse.json({ error: "Unsupported file type" }, { status: 400 });
    }

    if (file.size > MAX_FILE_SIZE) {
      return NextResponse.json({ error: "File too large" }, { status: 400 });
    }

    const buffer = Buffer.from(await file.arrayBuffer());
    const key = `avatars/${randomUUID()}-${file.name}`;

    await s3Client.send(
      new PutObjectCommand({
        Bucket: process.env.S3_BUCKET_NAME!,
        Key: key,
        Body: buffer,
        ContentType: file.type,
      })
    );

    return NextResponse.json({ key }, { status: 200 });
  } catch (error) {
    console.error("Upload error:", error);
    return NextResponse.json({ error: "Upload failed" }, { status: 500 });
  }
}

What's happening here:

request.formData() reads the incoming multipart form data — this is how browsers send files
We validate file.type and file.size before touching S3, so bad requests fail fast and cheap
file.arrayBuffer() converts the browser File object into a Buffer that the AWS SDK can send
The S3 object Key (its path inside the bucket) includes a random UUID so two people uploading photo.jpg never overwrite each other

⚠️ Common Mistake: Trusting file.type alone for security. It's sent by the browser and can be spoofed. For anything sensitive, also validate the actual file signature (magic bytes) server-side, or run the file through a scanning service before it's considered "safe."

Step 2: Build the Upload Form

// components/proxy-upload-form.tsx
"use client";

import { useState } from "react";

export function ProxyUploadForm() {
  const [uploading, setUploading] = useState(false);
  const [message, setMessage] = useState("");

  const handleSubmit = async (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    const form = e.currentTarget;
    const fileInput = form.elements.namedItem("file") as HTMLInputElement;
    const file = fileInput.files?.[0];

    if (!file) return;

    setUploading(true);
    setMessage("");

    const formData = new FormData();
    formData.append("file", file);

    const res = await fetch("/api/upload", {
      method: "POST",
      body: formData,
    });

    const data = await res.json();
    setUploading(false);
    setMessage(res.ok ? `Uploaded: ${data.key}` : data.error);
  };

  return (
    <form onSubmit={handleSubmit} className="flex flex-col gap-3 max-w-sm">
      <input type="file" name="file" accept="image/*" required />
      <button
        type="submit"
        disabled={uploading}
        className="rounded-lg bg-primary px-4 py-2 text-white disabled:opacity-50"
      >
        {uploading ? "Uploading..." : "Upload"}
      </button>
      {message && <p className="text-sm text-muted-foreground">{message}</p>}
    </form>
  );
}

Nothing exotic here — a standard FormData submission to our route handler. This pattern is genuinely the easiest to get right, which is exactly why it's the wrong choice once files get bigger.

Pattern 2: Direct-to-S3 Presigned URLs

How it works: your server never touches the file. Instead, it asks S3 for a presigned URL — a temporary, signed link that grants permission to upload one specific file, to one specific location, for a short window of time. The browser then uploads directly to S3 using that URL.

Browser → Next.js (ask for permission) → gets presigned URL
Browser → S3 directly (actual file upload)

Think of a presigned URL like a guest pass: your server is the front desk that checks you're allowed in, then hands you a pass that only works for one door, for the next few minutes. You still never got a master key to the building.

This is the pattern you want for anything user-facing that could be more than a few MB — profile videos, portfolio images, document uploads. Your server's job shrinks down to a single, fast decision: "yes, generate a URL" or "no."

Step 1: Generate the Presigned URL

// app/api/presigned-url/route.ts
import { NextRequest, NextResponse } from "next/server";
import { PutObjectCommand } from "@aws-sdk/client-s3";
import { getSignedUrl } from "@aws-sdk/s3-request-presigner";
import { s3Client } from "@/lib/s3-client";
import { randomUUID } from "crypto";

const ALLOWED_TYPES = ["image/jpeg", "image/png", "video/mp4"];
const URL_EXPIRY_SECONDS = 60; // presigned URL is valid for 60 seconds

export async function POST(request: NextRequest) {
  try {
    const { fileName, fileType } = await request.json();

    if (!fileName || !fileType) {
      return NextResponse.json({ error: "Missing fileName or fileType" }, { status: 400 });
    }

    if (!ALLOWED_TYPES.includes(fileType)) {
      return NextResponse.json({ error: "Unsupported file type" }, { status: 400 });
    }

    const key = `uploads/${randomUUID()}-${fileName}`;

    const command = new PutObjectCommand({
      Bucket: process.env.S3_BUCKET_NAME!,
      Key: key,
      ContentType: fileType,
    });

    const uploadUrl = await getSignedUrl(s3Client, command, {
      expiresIn: URL_EXPIRY_SECONDS,
    });

    return NextResponse.json({ uploadUrl, key });
  } catch (error) {
    console.error("Presign error:", error);
    return NextResponse.json({ error: "Could not generate upload URL" }, { status: 500 });
  }
}

What's happening here:

We never receive the actual file — just its fileName and fileType, which is why this endpoint responds instantly no matter how big the file will be
getSignedUrl() doesn't make a network call to AWS — it cryptographically signs the request locally using your IAM credentials, so it's fast
expiresIn: 60 means this exact URL stops working after 60 seconds — plenty of time for the browser to start the upload, but not so long that a leaked URL stays exploitable

💡 Tip: Still validate fileType here even though you're not seeing the actual bytes. It's your only real gate at this stage — S3 will happily accept whatever ContentType the presigned request specifies.

Step 2: Upload Directly From the Browser

// components/presigned-upload-form.tsx
"use client";

import { useState } from "react";

export function PresignedUploadForm() {
  const [progress, setProgress] = useState(0);
  const [status, setStatus] = useState<"idle" | "uploading" | "done" | "error">("idle");

  const handleSubmit = async (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    const form = e.currentTarget;
    const fileInput = form.elements.namedItem("file") as HTMLInputElement;
    const file = fileInput.files?.[0];
    if (!file) return;

    setStatus("uploading");
    setProgress(0);

    // Step 1: ask our server for a presigned URL
    const presignRes = await fetch("/api/presigned-url", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ fileName: file.name, fileType: file.type }),
    });

    if (!presignRes.ok) {
      setStatus("error");
      return;
    }

    const { uploadUrl } = await presignRes.json();

    // Step 2: upload the actual file straight to S3, tracking progress
    await new Promise<void>((resolve, reject) => {
      const xhr = new XMLHttpRequest();
      xhr.open("PUT", uploadUrl);
      xhr.setRequestHeader("Content-Type", file.type);

      xhr.upload.onprogress = (event) => {
        if (event.lengthComputable) {
          setProgress(Math.round((event.loaded / event.total) * 100));
        }
      };

      xhr.onload = () => (xhr.status === 200 ? resolve() : reject());
      xhr.onerror = () => reject();
      xhr.send(file);
    })
      .then(() => setStatus("done"))
      .catch(() => setStatus("error"));
  };

  return (
    <form onSubmit={handleSubmit} className="flex flex-col gap-3 max-w-sm">
      <input type="file" name="file" accept="image/*,video/mp4" required />
      <button
        type="submit"
        disabled={status === "uploading"}
        className="rounded-lg bg-primary px-4 py-2 text-white disabled:opacity-50"
      >
        {status === "uploading" ? `Uploading... ${progress}%` : "Upload"}
      </button>
      {status === "done" && <p className="text-sm text-green-600">Upload complete!</p>}
      {status === "error" && <p className="text-sm text-destructive">Upload failed.</p>}
    </form>
  );
}

Why XMLHttpRequest instead of fetch? This is a genuinely common question. The fetch API still doesn't support upload progress tracking in a standard way — xhr.upload.onprogress does. For a file that could take a while, showing real progress is worth the slightly older API.

⚠️ Common Mistake: Forgetting to set the same Content-Type header on the PUT request that you signed the URL with. S3 checks that they match — a mismatch fails with a signature error that has nothing to do with your actual credentials, which makes it a confusing bug to track down.

Pattern 3: Multipart Uploads for Large Files

How it works: instead of uploading one large file as a single request, you split it into chunks (S3 calls these "parts"), upload each part with its own presigned URL, and then tell S3 to stitch them back together.

Browser → Next.js: "start a multipart upload"
Browser → S3: upload part 1, part 2, part 3... (each with its own presigned URL)
Browser → Next.js: "complete the upload" (with the list of parts)

This solves two real problems that plain presigned URLs don't:

Reliability — if part 4 of 10 fails on a flaky connection, you only retry part 4, not the entire 500MB file
Parallelism — multiple parts can upload at the same time instead of one after another

AWS requires every part except the last to be at least 5MB. This pattern is overkill for a 2MB avatar — it's built for videos, archives, and anything in the tens-to-hundreds-of-MB range.

Step 1: Start the Multipart Upload

// app/api/multipart/start/route.ts
import { NextRequest, NextResponse } from "next/server";
import { CreateMultipartUploadCommand } from "@aws-sdk/client-s3";
import { s3Client } from "@/lib/s3-client";
import { randomUUID } from "crypto";

export async function POST(request: NextRequest) {
  const { fileName, fileType } = await request.json();

  const key = `large-uploads/${randomUUID()}-${fileName}`;

  const { UploadId } = await s3Client.send(
    new CreateMultipartUploadCommand({
      Bucket: process.env.S3_BUCKET_NAME!,
      Key: key,
      ContentType: fileType,
    })
  );

  return NextResponse.json({ uploadId: UploadId, key });
}

This tells S3 "expect a multipart upload for this key" and gets back an UploadId — a token that ties every part together as belonging to the same file.

Step 2: Get a Presigned URL for Each Part

// app/api/multipart/presign-part/route.ts
import { NextRequest, NextResponse } from "next/server";
import { UploadPartCommand } from "@aws-sdk/client-s3";
import { getSignedUrl } from "@aws-sdk/s3-request-presigner";
import { s3Client } from "@/lib/s3-client";

export async function POST(request: NextRequest) {
  const { key, uploadId, partNumber } = await request.json();

  const command = new UploadPartCommand({
    Bucket: process.env.S3_BUCKET_NAME!,
    Key: key,
    UploadId: uploadId,
    PartNumber: partNumber,
  });

  const url = await getSignedUrl(s3Client, command, { expiresIn: 300 });

  return NextResponse.json({ url });
}

Each part needs its own presigned URL, tagged with a PartNumber (1, 2, 3...) — this is how S3 knows the order to reassemble them in later.

Step 3: Complete the Multipart Upload

// app/api/multipart/complete/route.ts
import { NextRequest, NextResponse } from "next/server";
import { CompleteMultipartUploadCommand } from "@aws-sdk/client-s3";
import { s3Client } from "@/lib/s3-client";

export async function POST(request: NextRequest) {
  const { key, uploadId, parts } = await request.json();
  // parts: { PartNumber: number; ETag: string }[]

  await s3Client.send(
    new CompleteMultipartUploadCommand({
      Bucket: process.env.S3_BUCKET_NAME!,
      Key: key,
      UploadId: uploadId,
      MultipartUpload: { Parts: parts },
    })
  );

  return NextResponse.json({ success: true, key });
}

Why does every part need an ETag? Each time S3 accepts a part, it returns an ETag in the response headers — essentially a fingerprint confirming that part uploaded correctly and intact. When you call "complete," S3 cross-checks every ETag you send against what it actually received before stitching the file together. This is exactly why we exposed the ETag header in the CORS config back in setup.

⚠️ Common Mistake: Forgetting to add a cleanup step for abandoned multipart uploads (user closes the tab mid-upload). S3 keeps incomplete parts around and bills you for that storage. Set up an S3 Lifecycle rule to auto-abort incomplete uploads after a day or two.

Step 4: Orchestrate It All From the Browser

// components/multipart-upload-form.tsx
"use client";

import { useState } from "react";

const CHUNK_SIZE = 6 * 1024 * 1024; // 6MB per part (must be 5MB+)
// S3 requires every part except the last to be at least 5MB. Choosing 6MB provides a small buffer while keeping memory usage reasonable.

export function MultipartUploadForm() {
  const [progress, setProgress] = useState(0);
  const [status, setStatus] = useState<"idle" | "uploading" | "done" | "error">("idle");

  const uploadPart = async (
    url: string,
    chunk: Blob
  ): Promise<string> => {
    const res = await fetch(url, { method: "PUT", body: chunk });
    const etag = res.headers.get("ETag");
    if (!etag) throw new Error("Missing ETag from S3 response");
    return etag;
  };

  const handleSubmit = async (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    const form = e.currentTarget;
    const fileInput = form.elements.namedItem("file") as HTMLInputElement;
    const file = fileInput.files?.[0];
    if (!file) return;

    setStatus("uploading");
    setProgress(0);

    try {
      // Step 1: start the multipart upload
      const startRes = await fetch("/api/multipart/start", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ fileName: file.name, fileType: file.type }),
      });
      const { uploadId, key } = await startRes.json();

      // Step 2: split the file into chunks and upload each one
      const totalParts = Math.ceil(file.size / CHUNK_SIZE);
      const completedParts: { PartNumber: number; ETag: string }[] = [];

      for (let partNumber = 1; partNumber <= totalParts; partNumber++) {
        const start = (partNumber - 1) * CHUNK_SIZE;
        const chunk = file.slice(start, start + CHUNK_SIZE);

        const presignRes = await fetch("/api/multipart/presign-part", {
          method: "POST",
          headers: { "Content-Type": "application/json" },
          body: JSON.stringify({ key, uploadId, partNumber }),
        });
        const { url } = await presignRes.json();

        const etag = await uploadPart(url, chunk);
        completedParts.push({ PartNumber: partNumber, ETag: etag });

        setProgress(Math.round((partNumber / totalParts) * 100));
      }

      // Step 3: tell S3 to assemble the parts into the final file
      await fetch("/api/multipart/complete", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ key, uploadId, parts: completedParts }),
      });

      setStatus("done");
    } catch (error) {
      console.error("Multipart upload failed:", error);
      setStatus("error");
    }
  };

  return (
    <form onSubmit={handleSubmit} className="flex flex-col gap-3 max-w-sm">
      <input type="file" name="file" required />
      <button
        type="submit"
        disabled={status === "uploading"}
        className="rounded-lg bg-primary px-4 py-2 text-white disabled:opacity-50"
      >
        {status === "uploading" ? `Uploading... ${progress}%` : "Upload Large File"}
      </button>
      {status === "done" && <p className="text-sm text-green-600">Upload complete!</p>}
      {status === "error" && <p className="text-sm text-destructive">Upload failed.</p>}
    </form>
  );
}

Walking through the flow: we start the upload and get back an uploadId, then loop through the file in 6MB slices using file.slice() — this is a native browser API, no library needed. For each slice, we request a fresh presigned URL, PUT the chunk directly to S3, and hold onto the ETag we get back. Once every part is uploaded, we send the full list of { PartNumber, ETag } pairs to the "complete" endpoint, and S3 assembles them into one file.

💡 Tip: The loop above uploads parts one at a time for clarity. In production, you'd typically run several uploadPart calls concurrently (e.g. 3–4 at once with Promise.all) to meaningfully speed up large uploads — just be sure to still track and report progress per part.

Which Pattern Should You Actually Use?

Situation	Pattern
Small files (avatars, PDFs under ~5MB)	Server-side proxying
You need to validate/process the file server-side before storing it	Server-side proxying
User-facing images or short videos, a few MB to ~50MB	Direct-to-S3 presigned URL
You want upload progress without server load	Direct-to-S3 presigned URL
Large files — videos, archives, datasets (50MB+)	Multipart upload
Uploads over unreliable connections that need retry-per-chunk	Multipart upload

A common real-world setup actually combines these: use a presigned URL (single or multipart, depending on size) to get the file into S3 quickly, then have S3 trigger a Lambda or your own webhook afterward to run any validation, resizing, or processing you'd otherwise have done during a server-side proxy.

Frequently Asked Questions

Do I need to use the AWS SDK, or can I just use fetch with S3's REST API directly?

You technically can call S3's REST API directly, but you'd be manually implementing AWS's request-signing algorithm (SigV4) yourself — the SDK handles that correctly and is the standard approach. Stick with @aws-sdk/client-s3 unless you have a very specific reason not to.

Is it safe to expose the S3 object key to the browser?

Yes — the key is just a file path, not a credential. What actually grants access is the signed portion of the presigned URL, which expires and is scoped to that one action. Just don't put sensitive information (like a user's email) directly in the key name if the bucket could ever become browsable.

Can I use this with the Pages Router instead of App Router?

The S3 SDK logic (creating the client, generating presigned URLs) works identically. You'd just swap the Route Handlers for pages/api/*.ts files using req/res instead of NextRequest/NextResponse.

What happens if a presigned URL expires mid-upload?

For the single presigned URL pattern, a slow upload could in theory outlive a very short expiry — that's why the expiry is a balance: long enough to comfortably start and finish, short enough to limit exposure if leaked. For multipart uploads, each part gets its own fresh URL, so this is naturally less of a concern for large files.

Do I need CloudFront in front of my bucket?

Not for uploads — CloudFront is about serving files back out fast, which is a separate concern from getting files in. If you're also displaying these uploaded files to users at scale, adding a CloudFront distribution in front of the bucket is a common next step, but it's optional for the upload flow itself. See my guide on displaying S3 images for the full breakdown of the public, presigned, and CloudFront display patterns.

Should I use Server Actions for uploads?

Server Actions work well for small files, but they still route the file through your server. The same trade-offs apply: body size limits, execution time, and bandwidth costs. For larger uploads, presigned URLs remain the recommended approach.

Wrapping Up

You now have three working, production-grade upload patterns for S3 in Next.js 16 — server-side proxying for small files you need to inspect, presigned URLs for everyday user uploads, and multipart uploads for the big stuff that needs to survive a bad connection. The pattern you reach for isn't really an S3 question — it's a question of how much of that file actually needs to pass through your server, and now you've got the code to implement whichever answer fits.

From here, the natural next step is displaying these uploaded files back to your users — covering public URLs, presigned GET links, and CloudFront delivery.

📦 Source Code: View on GitHub

Continue Learning

How to Display Images from S3 in Next.js 16 (2026 Guide) — now that your files are in S3, here's how to show them back to users safely
How to Setup Resend Email in Next.js 16 (2026 Complete Beginner Guide)
SaaS Starter Architecture with Next.js 2026
Next.js Rendering Strategies Explained: SSR, SSG, CSR, ISR & Cache Components (2026)

Upload Files to AWS S3 with Spring Boot (Clean Architecture Guide)

Sun, 12 Apr 2026 16:42:50 +0000

Uploading files to AWS S3 in Spring Boot is simple.

Designing it properly for production is where most developers struggle.

Most implementations end up like this:

controllers handling everything
direct S3 calls everywhere
no structure
hard to scale later

In this guide, you’ll learn how to build a clean, scalable file upload system.

Building file uploads in production is harder than it looks.

If you want a clean, ready-to-use setup instead of building everything yourself:
https://buildbasekit.com/boilerplates/filora-fs-pro/

Quick Answer

The best way to upload files to S3 in Spring Boot:

separate storage logic into a service layer
avoid direct S3 calls in controllers
use pre-signed URLs for scalability

Why use AWS S3

S3 is the standard for file storage in backend systems.

handles large files and high traffic
highly scalable and durable
no infrastructure management
supports secure access control

When to use S3 vs local storage

Use S3 when:

building production systems
handling user uploads
running multiple instances

Use local storage when:

prototyping
small internal tools

Avoid local storage in distributed systems.

High-level architecture

A clean file upload system should look like this:

Controller → handles incoming requests
Service → processes file logic
Storage layer → interacts with S3
Database → stores file metadata

This separation keeps your code maintainable.

File metadata design

Do not just upload files.

Store metadata like:

file name
unique ID
S3 object key
file size and type
upload timestamp
user reference

This enables search, access control, and tracking.

Example API design

A simple API structure:

POST /files → upload file
GET /files/{id} → fetch metadata
GET /files/{id}/url → get access URL

Upload flow

client sends upload request
backend validates file
file is uploaded to S3
metadata is stored in database
response returns file reference

Keep storage logic abstract

Do not tightly couple your app with S3.

define a storage interface
implement S3 separately
allow switching providers later

This makes your system flexible.

Security considerations

Always handle security properly:

validate file type and size
avoid exposing S3 bucket directly
manage credentials securely
use pre-signed URLs

Pre-signed URLs (important)

Better approach:

backend generates upload URL
client uploads directly to S3
backend stores metadata

This:

reduces server load
improves scalability

Common mistakes

calling S3 directly from controller
hardcoding credentials
skipping metadata storage
mixing upload and access logic

Final thoughts

Uploading files to S3 is easy.

Designing a clean system is what matters long term.

If you skip structure now, it will become painful later.

Skip the setup

If you're building anything serious, don't spend days structuring this.

Use a production-ready backend instead:
https://buildbasekit.com/boilerplates/filora-fs-pro/

clean architecture
S3 + pre-signed URLs
ready APIs

Build faster. Focus on real features.

Small AWS Updates, Big Impact: S3 Namespace Shift and Smarter Security Scanning

Thu, 19 Mar 2026 12:23:53 +0000

AWS Security Updates: S3 Namespace Evolution, Inspector Agentless Scanning, and Windows KB-Based Findings

AWS recently introduced a few important updates across Amazon S3 and Amazon Inspector. These changes are subtle but have real implications for how we design storage and manage security at scale.

Here’s what stands out:

1. Amazon S3: Account-Level Regional Namespaces (Big Shift in Naming)

AWS has introduced account-level regional namespaces for S3 general-purpose buckets.

This is a significant evolution from the traditional global bucket namespace model.

What’s new:

You can now create buckets within an account-specific regional namespace
This namespace is scoped to your AWS account, instead of competing globally
Available across multiple AWS regions

Why this matters:

Eliminates friction of globally unique bucket naming
Simplifies automation (Terraform / CI/CD no longer needs random suffix hacks)
Better alignment with multi-account and multi-region architectures

In simple terms:

S3 is moving from global naming constraints → account-scoped flexibility

This is a foundational change, especially for large organizations managing multiple environments.

2. Amazon Inspector: Expanded Agentless EC2 Scanning

Amazon Inspector now expands agentless EC2 scanning, increasing coverage without operational overhead.

What’s improved:

Broader vulnerability detection across:
- OS packages
- Application stacks (Python, Ruby, Apache, WordPress, etc.)
No need to install or manage agents
Works using EBS snapshot-based scanning

Why this matters:

Faster adoption across large fleets
Ideal for:
- Legacy systems
- Restricted or hardened environments
Reduces dependency on SSM agent management

This significantly improves security coverage with minimal effort.

3. Windows KB-Based Findings (Better Vulnerability Context)

AWS also introduced Windows KB-based findings in Amazon Inspector.

What changed:

Instead of multiple CVEs per vulnerability → grouped into a single KB finding
Each finding includes:
- Highest CVSS score
- EPSS score
- Exploit availability
- Direct link to Microsoft KB article

Why this matters:

Reduces noise in vulnerability reports
Makes remediation clearer and actionable
Aligns findings with how Windows patching actually works

One patch → one finding → clearer action

This is a big usability improvement for security teams managing Windows workloads.

Final Thoughts

These updates highlight a clear direction from AWS:

Simplifying infrastructure design (S3 namespaces)
Reducing operational overhead (agentless scanning)
Improving security clarity and actionability (KB-based findings)

Individually, these may look small.
Together, they remove friction across cloud operations and security workflows.

Revisit your S3 naming strategy (especially for new workloads)
Enable or validate Inspector agentless scanning
Update your vulnerability management workflows for KB-based findings

Cloud is evolving — and the small updates are often the ones that change how we build at scale.

Syncing AWS S3 Storage bucket objects to LocalStack S3 Storage bucket

Tue, 01 Apr 2025 12:56:47 +0000

Getting Started

LocalStack is a cloud service emulator that runs in a single container on your laptop or in your CI environment. With LocalStack, you can run your AWS applications or Lambdas entirely on your local machine without connecting to a remote cloud provider.

Installation

In this tutorial, we will install LocalStack CLI on our x86-64 Linux machine, for ARM64 kindly check the official documentation. The CLI starts and manages the LocalStack Docker container.

-- Download the pre-built binary --
curl --output localstack-cli-4.2.0-linux-amd64-onefile.tar.gz \
    --location https://github.com/localstack/localstack-cli/releases/download/v4.2.0/localstack-cli-4.2.0-linux-amd64-onefile.tar.gz

-- Extract the LocalStack CLI from the terminal --
sudo tar xvzf localstack-cli-4.2.0-linux-*-onefile.tar.gz -C /usr/local/bin

-- Verify installed version --
localstack --version
4.2.0

Configuring and Starting LocalStack

We need an API key from LocalStack to configure LocalStack on our local machine. Head over to LocalStack and signup. Within your LocalStack dashboard, go to WorkSpace → Auth Tokens and copy the personal auth token provided. This personal auth token will be used to activate the LocalStack pro hobby subscription which grants use access to all of LocalStack’s features such as the Resource Browser which will use in this tutorial. Now add the auth token to your local stack CLI and start LocalStack:

localstack auth set-token <YOUR_AUTH_TOKEN>
localstack start

     __                     _______ __             __
    / /   ____  _________ _/ / ___// /_____ ______/ /__
   / /   / __ \/ ___/ __ `/ /\__ \/ __/ __ `/ ___/ //_/
  / /___/ /_/ / /__/ /_/ / /___/ / /_/ /_/ / /__/ ,<
 /_____/\____/\___/\__,_/_//____/\__/\__,_/\___/_/|_|

-- LocalStack CLI: 4.2.0 --
-- Profile: default --
-- App: https://app.localstack.cloud --

[12:31:41] starting LocalStack in Docker mode ????                                                       localstack.py:512
2025-03-27T12:31:41.282  INFO --- [  MainThread] l.p.c.b.licensingv2        : Successfully activated cached license <license-id>:hobby from /home/user/.cache/localstack-cli/license.json ????✅
──────────────────────────────────── LocalStack Runtime Log (press CTRL-C to quit) ─────────────────────────────────────
LocalStack version: 4.2.1.dev87
LocalStack build date: 2025-03-26
LocalStack build git hash: c6fc9b010
2025-03-27T09:31:48.092  INFO --- [  MainThread] l.p.c.b.licensingv2        : Successfully activated cached license <license-id>:hobby from /etc/localstack/conf.d/license.json ????✅
2025-03-27T09:31:52.329  INFO --- [  MainThread] l.p.c.extensions.platform  : loaded 0 extensions
Ready.

Installing AWS CLI and LocalStack’s AWS CLI

We now need to have both the AWS official CLI and LocalStack’s AWS CLI which is a thin wrapper of the AWS official CLI for LocalStack.

AWS CLI installation

-- Verify installation of the official AWS CLI --
aws --version
aws-cli/2.25.4 Python/3.12.9 Linux/5.15.167.4-microsoft-standard-WSL2 exe/x86_64.ubuntu.24

-- Install LocalStack's AWS CLI --
pip install awscli-local
awslocal --version
aws-cli/2.25.4 Python/3.12.9 Linux/5.15.167.4-microsoft-standard-WSL2 exe/x86_64.ubuntu.24

Creating S3 Storage Bucket in LocalStack

Before syncing the buckets, we need to create an S3 storage bucket within LocalStack in our local machine:

-- Create bucket --
awslocal s3api create-bucket \
  --acl public-read \
  --bucket test-s3-bucket \
  --object-ownership BucketOwnerPreferred \
  --region us-east-2 \
  --create-bucket-configuration '{"LocationConstraint": "us-east-2"}' 

-- Sample output with bucket name set to test-s3-bucket --
{
    "Location": "http://test-s3-bucket.s3.localhost.localstack.cloud:4566/"
}

Syncing S3 Storage Buckets

In this tutorial, we will focus on two keys methods for syncing our AWS S3 storage bucket with our LocalStack S3 storage bucket within our local machine.

Method 1: Sequential sync

The sequential sync approach is whereby we sync the bucket to a local temp folder in our local machine then sync our LocalStack S3 storage bucket with data in the local temp folder.

-- Syncing bucket data to local temp folder --
aws s3 sync s3://<source-bucket i.e test-s3-bucket> ./local-folder --region <region i.e us-east-2>

-- Syncing local folder to LocalStack S3 bucket --
aws s3 sync ./local-folder s3://<destination-bucket i.e test-s3-bucket> --endpoint-url http://localhost:4566 # By default, LocalStack runs on port 4566. Make sure no service is running on this port otherwise LocalStack won't start

-- Verify upload --
awslocal s3 ls s3://test-s3-bucket
2025-03-27 13:04:21     165892 test-s3-file.jpeg

Method 2: Direct Sync (Without Local Storage)

The direct sync approach avoids syncing the bucket data to local storage first but rather syncs the bucket data directly to the LocalStack S3 storage bucket. In this tutorial, we will use a bash script to sync the buckets but you can create a python script and use boto3 and LocalStack’s python client to sync the buckets.

aws s3 ls s3://<aws-s3-bucket> --recursive | awk '{print $4}' | \
xargs -P 10 -I {} sh -c 'aws s3 cp --debug "s3://<aws-test-s3-bucket>/{}" - | awslocal s3 cp - "s3://<localstack-test-s3-bucket>/{}" --debug'

-- Sample output in terminal running localstack --
2025-03-27T10:12:24.654  INFO --- [et.reactor-0] localstack.request.aws     : AWS s3.PutObject => 200
2025-03-27T10:12:27.443  INFO --- [et.reactor-0] localstack.request.aws     : AWS s3.PutObject => 200
2025-03-27T10:12:37.219  INFO --- [et.reactor-0] localstack.request.aws     : AWS s3.PutObject => 200
2025-03-27T10:12:41.503  INFO --- [et.reactor-0] localstack.request.aws     : AWS s3.PutObject => 200
2025-03-27T10:12:45.346  INFO --- [et.reactor-0] localstack.request.aws     : AWS s3.PutObject => 200

After the upload is complete, you can head to your LocalStack dashboard navigate to local instance, go to resource browser, search for S3, choose bucket and browse your files or folders in your bucket.

Conclusion

The local storage first approach is more performant as compared to the direct approach since the direct approach relies on xargs to achieve parallel transfers using sub-processes. One can spawn multiple separate sub processes using xargs -P N when N is the number of sub processes required. The sub process parallelism is great for S3 sync as this is an I/O bound task. In terms of speed, using xargs even with tuned parallelism can be slow. If you are looking to speed up syncs, you can use tools such as s5cmd which supports true multithreading. I will sure do a tutorial on s5cmd and do a benchmark to check how it compares to using xargs in parallel mode. The approach in this tutorial was not created with the context of large S3 storage buckets. If you have a tutorial on this please share. Thanks again for reaching to the end of this tutorial. Cheers!

Mastering Amazon S3 Replication: Same-Region vs. Cross-Region Replication -

Sun, 02 Feb 2025 09:34:30 +0000

Amazon Simple Storage Service (S3) is a powerhouse for cloud storage, offering unmatched scalability, durability, and security. Among its many features, S3 Replication plays a vital role in ensuring data availability, resilience, and compliance. AWS provides two types of replication mechanisms: Same-Region Replication (SRR) and Cross-Region Replication (CRR). While both serve to replicate objects, they cater to different business needs. Let’s dive deep into their differences, use cases, and best practices.

What is Amazon S3 Replication?

S3 Replication is an AWS feature that automatically replicates objects from one S3 bucket to another. The replication can occur within the same AWS region (SRR) or across different regions (CRR). This ensures redundancy, availability, and compliance with organizational policies.

AWS S3 Replication requires enabling Versioning on both the source and destination buckets. Once set up, it replicates newly uploaded objects asynchronously while preserving metadata, object tags, and Access Control Lists (ACLs), depending on your configurations.

Same-Region Replication (SRR)

✅ What is SRR?

SRR allows replication of S3 objects within the same AWS region. This is useful for organizations that need multiple copies of data in the same geography but within different buckets.

Use Cases

Compliance & Governance: Maintain multiple copies of data within a region to meet internal compliance regulations.

Data Tiering & Organization: Separate different teams' data while keeping it in the same region for low latency.

Backup & Disaster Recovery: Keep replicated copies in a different bucket to recover from accidental deletions or corruption.

Logging & Analytics: Send logs to a centralized bucket for analysis without moving them across regions.

⚡ Benefits

Low Latency: Since data is within the same region, replication is faster.

Cost-Effective: No inter-region data transfer costs.

Better Access Control: Different teams can access separate replicated buckets without modifying the source bucket’s policies.

⚠️ Considerations

SRR does not protect against regional failures; for true disaster recovery, CRR is needed.

There might be some added storage costs depending on data volume.

Cross-Region Replication (CRR)

✅ What is CRR?

CRR replicates objects across different AWS regions, providing geographical redundancy and enhanced disaster recovery.

Use Cases

Disaster Recovery: Store copies of critical data in another region to protect against region-wide outages.

Compliance & Regulations: Meet legal requirements for keeping data in multiple geographic locations.

Global Content Distribution: Improve performance by serving data closer to end users in different regions.

High Availability & Fault Tolerance: Maintain business continuity in case of failures in one region.

⚡ Benefits

Resilient Disaster Recovery: Data is available in another region in case of primary region failure.

Reduced Latency for Global Users: Store data closer to international customers to reduce access time.

Improved Business Continuity: Ensures uninterrupted service availability.

⚠️ Considerations

Higher Costs: Inter-region data transfer fees apply.

Increased Latency: Replication takes longer due to network distance.

Regulatory Compliance: Ensure cross-border data transfers align with local regulations.

️ Setting Up S3 Replication (SRR & CRR)

To enable replication:

Enable versioning for both source and destination buckets.

Set up IAM permissions for replication.

Create a Replication Rule specifying:

Source and destination buckets

Filter conditions (prefix, object tags, etc.)

Replication options (SRR or CRR)

Enable S3 Replication Time Control (RTC) for predictable replication times (optional).

Monitor replication progress using AWS CloudWatch and S3 Replication Metrics.

SRR vs. CRR: Which One Should You Choose?

FeatureSame-Region Replication (SRR)Cross-Region Replication (CRR)
Data Transfer CostLower (No inter-region cost)Higher (Inter-region transfer fees)
LatencyLow (Faster replication)Higher (Depends on region distance)
Disaster RecoveryNo protection from regional failuresHigh protection from region-wide failures
ComplianceUseful for internal regulationsRequired for international regulations
Global AccessLimited to one regionEnables worldwide data access

Best Practices for S3 Replication

✅ Use Lifecycle Policies: Delete older versions or move replicated data to S3 Glacier for cost efficiency.
✅ Monitor with CloudWatch: Keep track of replication success rates and failures.
✅ Use Replication Time Control (RTC): Ensure predictable replication times.
✅ Encrypt Replicated Data: Enable AWS KMS encryption to secure sensitive information.
✅ Optimize Costs: Use Intelligent-Tiering for replicated objects to reduce expenses.

Conclusion

Both Same-Region Replication (SRR) and Cross-Region Replication (CRR) are powerful features in AWS S3 that serve different business needs. SRR is ideal for compliance, backups, and data segregation, while CRR is essential for disaster recovery and global distribution. Choosing the right replication strategy depends on your use case, performance requirements, and budget.

By implementing these best practices, you can ensure optimal data availability, security, and resilience in your AWS cloud environment.

Ready to enhance your AWS storage strategy? Implement S3 replication today!

AWS S3 Access Points in 2025 using CLI

Fri, 10 Jan 2025 15:44:49 +0000

Hello, Machas!

Today, I’m here to demystify S3 Access Points. No promises of turning you into a superhero, but by the end of this blog, you’ll at least upgrade from a curious bystander to the protagonist of your own AWS journey. Let’s dive in and make you the star of this S3 saga!.

I hope you might have already known what are bucket polices. If you don’t know I just give you a quick recap: bucket policies are used to restrict/allow access to any user/group/role to access bucket and its objects.

Use of Access points

Lets consider a scenario today if you want to give read permissions to some objects for a user , you will use simply bucket policy to do that .

Tomorrow if you want to give some other permissions to a role you will again use the same bucket policy.

Other day when you want to give permissions to a group if you keep on using this bucket policy this will grow and it becomes hard to read .

That’s where access points comes in rescue , instead of giving permissions to every one in one bucket policy you will create individual access points
for each one and give permissions to these access points and all these access points are attached to the bucket.

In this way bucket policy wont grow .

Now its time to get our hands dirty .

Let’s consider a scenario where you need to allow access to the objects in your bucket only through access points ,
and also grant access to a specific user in another account . Sounds simple, right?"

NAAM CHOTA HAI LEKIN SOUND BADA HAI

1. Firstly let’s create access point.

 

    aws s3control create-access-point --account-id 9848032919 --name my-access-point \
    --bucket my-bucket

Now this will create access point its network origin is internet if you want to create VPC as network origin then No internet access.
Requests are made over a specified VPC only. This will create access point and is attached to the bucket.

Grab the access point arn.

2. Next let’s grant permissions to this access point

I will now grant user KGF to access the bucket and its objects its simple!!! only if you know already know how to write bucket policy.
That’s why have a quick glance at my above attached blog.

Access point policy is similar to bucket policy.

Lets grant KGF user, get object and list bucket permissions , in the access point policy Resource is arn of the access point .

// access-policy.json

    {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": { "AWS": "arn:aws:iam::9848032919:user/KGF" },
            "Action": [
              "s3:GetObject",
              "s3:ListBucket" 
            ],
            "Resource": [
              "arn:aws:s3:ap-south-1:9848032919:accesspoint/my-access-point",
              "arn:aws:s3:ap-south-1:9848032919:accesspoint/my-access-point/object/*"
            ]
          }
        ]
      }

Now KGF user will be having get object and list bucket permission on the bucket to which this access point was attached.

3. Attach the permissions to access point

Now attach this access point policy to the access point.


    aws s3control put-access-point-policy --account-id 9848032919 --name my-access-point \
     --policy file://access-policy.json

Now if KGF user tries to access the bucket using …


    aws s3 ls my-bucket

You will get error as KGF is fresh user this user doesn’t have any IAM permissions to access the object.

If KGF user has IAM permissions then this user will be able to . But we are interested in accessing the objects in the bucket using access point .

Now also we got same error .

4. Access Point-Based Bucket Permissions

Now we have to configure bucket policy such that this will receive permissions from access point policy on the bucket/objects.


    // bucket-policy.json
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": "*",
          "Action": "s3:*",
          "Resource": [
            "arn:aws:s3:::my-bucket",
            "arn:aws:s3:::my-bucket/*"
          ],
          "Condition": {
            "StringEquals": {
              "s3:DataAccessPointArn": "arn:aws:s3:ap-south-1:9848032919:accesspoint/my-access-point"
            }
          }
        }
      ]
    }

There is one condition called DataAccessPointArn which identifies that access is coming from which accesspoint.

Now this policy allows permissions from accesspoint.

Uploading this bucket policy ..

 

    aws s3api put-bucket-policy --bucket my-bucket --policy file://bucket-policy.json

Now If I try to access the objects again as a KGF user …

I got the result ..

Now that we have allowed KGF user using access point , now our mini goal is to allow users to access the bucket/objects only via access point.

5. Allowing traffic only through access point.

As you guessed we have to change bucket policy to do that.


    //bucket-policy.json
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Deny",
          "Principal": "*",
          "Action": "s3:*",
          "Resource": [
            "arn:aws:s3:::my-bucket",
            "arn:aws:s3:::my-bucket/*"
          ],
          "Condition": {
            "StringNotEquals": {
              "s3:DataAccessPointArn": "arn:aws:s3:ap-south-1:9848032919:accesspoint/my-access-point"
            }
          }
        },
        {
          "Effect": "Allow",
          "Principal": "*",
          "Action": "s3:*",
           "Resource": [
            "arn:aws:s3:::my-bucket",
            "arn:aws:s3:::my-bucket/*"
          ],
          "Condition": {
            "StringEquals": {
              "s3:DataAccessPointArn": "arn:aws:s3:ap-south-1:9848032919:accesspoint/my-access-point"
            }
          }
        }
      ]
    }

Don’t get panic I am here to explain this.

1st rule is to deny every traffic unless it is made through access point .

2nd rule is to allow traffic from access point .

Seems Confusing right ? Deny rules has more precedence than allow rules, so deny rule here in bucket policy ,denies every one even access point permissions and over writes the access point policy , and we are again allowing permissions to flow from access point .

Uploading this bucket policy ..


     aws s3api put-bucket-policy --bucket my-bucket --policy file://bucket-policy.json

When I access as KGF user …

This worked ..

OK but lets try accessing the objects in the bucket using normal S3 URI instead of access point .

I got explicit deny error and that’s worked hurray!!!

6.Cross Account Access

Now we have almost completed our requirement, next step is we have to allow user from the other account to access objects in the bucket in our account .

If you give arn of the user in the other account as a Principal in the access point policy, only this is not enough to do so. The User in the other account must have IAM permissions to access the s3 bucket as well as this access point in our account..

IAM policy to access S3 in other account :


    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "Statement1",
                "Effect": "Allow",
                "Action": [
                    "s3:ListBucket",
                    "s3:GetObject"
                ],
                "Resource": [
                    "arn:aws:s3:::my-bucket",
                    "arn:aws:s3:::my-bucket/*"
                ]
            }
        ]
    }

As the bucket names are unique that’s why no Account IDs in resource .

IAM policy to access the access point

 

    {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Sid": "Statement1",
    "Effect": "Allow",
    "Action": [
    "s3:*"
    ],
     "Resource": [
                  "arn:aws:s3:ap-south-1:9848032919:accesspoint/my-access-point",
                  "arn:aws:s3:ap-south-1:9848032919:accesspoint/my-access-point/object/*"    
                ]
    }
    ]
    }

Now if the user has these 2 IAM Policies ,then after adding user arn as the Principal in the access point policy.

I have created user named Ali in the other account and also Ali has 2 IAM policies set.


    {
        "Version": "2012-10-17",
        "Statement": [
          {
            "Effect": "Allow",
            "Principal": { "AWS": 
                         ["arn:aws:iam::9848032919:user/KGF",
                           "arn:aws:iam::9848022338:user/Ali" ] 
                             },
            "Action": [
              "s3:GetObject",
              "s3:ListBucket" 
            ],
            "Resource": [
              "arn:aws:s3:ap-south-1:9848032919:accesspoint/my-access-point",
              "arn:aws:s3:ap-south-1:9848032919:accesspoint/my-access-point/object/*"
            ]
          }
        ]
      }

When I try to access the bucket as Ali user…

I named Ali user as Goutham-Ali on my CLI . This works!!!

OK If I try to access using Normal S3 URI

This will not work..

This brings us to end of this article.

That’s it we have allowed access to the bucket/objects only using access point and also allowed cross account access using access point .

Thanks for reading my blog, leave a like and comment if you read something useful, have a great day.

Coder Legion - Recent posts tagged aws-s3

S3 vs Supabase Storage vs Cloudinary (2026 Guide)

Quick Answer

Why This Comparison Is Tricky

At a Glance

AWS S3: Raw, Cheap, and You Own Everything

S3 Pricing Is More Than "Per GB Stored"

A Minimal S3 Upload in Next.js 16

Supabase Storage: S3 Underneath, Postgres on Top

A Minimal Supabase Storage Upload

Cloudinary: A Media Pipeline for Images and Video

A Minimal Cloudinary Upload + Display in Next.js 16

Media Optimization: Who Actually Handles It?

Security Models Compared

Can You Mix Them?

Decision Matrix

Frequently Asked Questions

Is Supabase Storage actually built on S3?

Do I need Cloudinary if I'm already using next/image?

Which one is cheapest for a small side project?

Is a presigned S3 upload URL alone enough security?

Can I switch between these later without a full rewrite?

Does Cloudinary replace the need for a CDN?

What about Cloudflare R2 as another alternative?

Wrapping Up

Continue Learning

Free Developer Tools

How to Display Images from S3 in Next.js 16 (2026 Guide)

Why This Is Tricky

Prerequisites & Setup

Allow S3 (and CloudFront) in next.config

Pattern 1: Public Bucket URLs

Step 1: Allow Public Reads on Specific Objects

Step 2: Store the Public URL Format

Step 3: Render It with next/image

Pattern 2: Presigned GET URLs for Private Files

Step 1: Generate the Presigned GET URL

Step 2: Fetch and Display It Client-Side

Pattern 3: CloudFront CDN Delivery

Step 1: Create a CloudFront Distribution

Step 2: Serve Public Assets Through CloudFront

Step 3: Serve Private Assets with Signed CloudFront URLs

Which Pattern Should You Actually Use?

Frequently Asked Questions

Can I just use a plain <img> tag instead of next/image?

Do I need CloudFront if I'm only using presigned URLs?

Why does my S3 image 403 even though I set a bucket policy?

Should I store the S3 key or the full URL in my database?

Can I resize images on the fly instead of storing multiple sizes?

Why does my image download instead of render in the browser?

Wrapping Up

Continue Learning

Next.js 16 AWS S3 File Upload Guide: Presigned URLs, Proxy & Multipart

Why This Is Tricky

Prerequisites & Setup

Step 1: Create an S3 Bucket

Step 2: Create an IAM User for Programmatic Access

Step 3: Configure CORS on the Bucket

Step 4: Install Dependencies

Step 5: Environment Variables

Step 6: Create a Reusable S3 Client

Pattern 1: Server-Side Proxying

Step 1: Create the Upload Route Handler

Step 2: Build the Upload Form

Pattern 2: Direct-to-S3 Presigned URLs

Step 1: Generate the Presigned URL

Step 2: Upload Directly From the Browser

Pattern 3: Multipart Uploads for Large Files

Step 1: Start the Multipart Upload

Step 2: Get a Presigned URL for Each Part

Step 3: Complete the Multipart Upload

Step 4: Orchestrate It All From the Browser

Which Pattern Should You Actually Use?

Frequently Asked Questions

Do I need to use the AWS SDK, or can I just use fetch with S3's REST API directly?

Is it safe to expose the S3 object key to the browser?

Can I use this with the Pages Router instead of App Router?

What happens if a presigned URL expires mid-upload?

Do I need CloudFront in front of my bucket?

Should I use Server Actions for uploads?

Can I just use a plain `<img>` tag instead of next/image?