Amazon S3

What S3 is

S3 stores files — “objects” — in buckets and serves them over HTTP(S). There’s no server to manage: you upload objects and S3 handles durability, scaling, and availability. For a website, it can serve HTML, CSS, JS, and images directly from a bucket, or — the path you actually want in production — act as the origin behind a CloudFront distribution.

Design Beaver models S3 as a regional, API-accessed service rather than something that sits inside a VPC subnet, and validates as you draw which services can use it and how that connection has to be set up to be correct.

When to use S3 (and when not to)

Reach for S3 when you’re serving files with no server-side logic, when you need an origin behind CloudFront for a public-facing site, or when you’re storing objects that don’t need the query and index capability a database gives you.

Don’t reach for it when you need HTTPS on the bucket’s website endpoint directly — S3 website endpoints don’t support it, and the fix is CloudFront, not a bucket setting. It’s also the wrong tool when you need server-side rendering or dynamic per-request responses.

Variants: storage classes

S3’s “variants” are storage classes — the dial between how fast you can retrieve data and how little you pay to keep it. Standard is the default a static site’s assets sit in; the Glacier tiers trade retrieval speed for cost.

S3 pricing

You pay for what you store, plus requests and data transfer — and the storage class you pick moves the per-GB number by more than an order of magnitude.

How S3 connects to other services

S3 is rarely a lone box on a diagram — it’s an origin, an event source, and a destination. Each of those edges has a requirement that makes it actually work, and Design Beaver models them so it knows what belongs on each connection.

• ←CloudFront

  CloudFront distribution uses the S3 bucket as its origin

• ↔Lambda

  S3 event notifications trigger a Lambda function (e.g. process file on upload)

• ←EC2

  An application running on the EC2 instance reads/writes S3 objects via the AWS SDK (e.g. uploading user content, reading config/assets, writing logs or backups)

• →SQS

  S3 event notifications (object created/removed) are delivered to an SQS queue, so a consumer can process uploads asynchronously without S3 invoking it directly

• →SNS

  S3 event notifications are published to an SNS topic, which then fans the event out to multiple subscribers (several queues/functions reacting to the same upload)

• →EventBridge

  With EventBridge notifications turned on for the bucket, S3 sends every object event (created, removed, restored, etc.) to the default event bus, where rules route and filter it to any target — richer routing than S3's built-in SNS/SQS/Lambda notifications, and the way to reach targets S3 can't notify directly (e.g. a FIFO queue)

What S3 can’t connect to

A few edges look plausible on a canvas but aren’t real AWS integrations. Design Beaver flags them instead of letting you draw a diagram that can’t be built.

• ✕RDS

  No native direct integration — S3 is not a drawable connection target for RDS; data movement between them (e.g. Aurora's S3 import/export) is an engine feature invoked by application code, not an architectural connection

• ✕Route 53

  S3 has no relationship with Route 53 pointing outward from it — a Route 53 alias record can point at an S3 website endpoint, but that's Route 53 connecting to S3, never S3 connecting to Route 53

• ✕DynamoDB

  Peer AWS storage/database services with no native direct integration between them — S3's export/import features for other services (e.g. Aurora) don't extend to DynamoDB, and an application would use both independently rather than connecting them as an architectural edge

Anti-patterns Design Beaver catches

Gotchas that bite in production

• S3 website endpoints don’t do HTTPS. If someone asks why they can’t get a padlock on their S3 site, this is why — the fix is CloudFront in front, not a bucket setting.
• Use OAC, not the legacy OAI. Origin Access Control is the current best practice for restricting CloudFront → S3 access. OAI (Origin Access Identity) is the older mechanism; new setups should use OAC.
• A fully public website bucket works, but it’s the anti-pattern. Serving directly from a public bucket means no HTTPS, no CDN, and disabling Block Public Access. Put CloudFront in front and keep the bucket private.
• S3 event notifications to a queue have rules. They reach standard SQS queues, not FIFO — route through EventBridge if an event needs to land in a FIFO queue.

Further reading

• Official AWS documentation
• Why we built a validation engine