Amazon S3

S3 is the most commonly mis-optimised cloud service. Storage fees are rarely the problem — the real killers are request volume and egress traffic. Plenty of teams default to Standard for everything and later find 40% of the bill sitting under "requests", because the application treats object storage as a local disk and hits it on every page view. Here is the decision order: which storage class, how to configure lifecycle rules, and which hidden costs to shut off first.

Specs & pricing

Step 1: classify by access frequency first

The differences between S3 classes are fundamentally a trade of retrieval speed against price. Layering by data age is the reliable approach: - Hot data (images, JS/CSS, API responses) → Standard. Latency-sensitive; compression never compensates. - Warm data (user uploads, video source files) → Standard-IA or Intelligent-Tiering. - Cold data (monitoring logs, backups, de-listed content) → Glacier tiers. Intelligent-Tiering is worth considering first: it watches access patterns and moves objects between tiers automatically, billed daily. Its only downside is a small monitoring fee, which makes it less attractive than manual rules for buckets with predictable access patterns.

Step 2: make costs fall automatically with lifecycle rules

Step 3: shut off the two hidden costs

• Request volume: every GET, PUT, and LIST is billed separately. Put a CDN in front of S3 for high-frequency small files such as avatars and thumbnails so the requests are served from the edge instead of going to origin every time.
• Egress traffic: downloading from S3 to the internet is billed per GB and is usually the largest line on an AWS invoice. Cross-region internal transfers are billed too — co-locating your application and the bucket removes that cost entirely.
• Fragmented small objects: storage is billed in 64KB increments, so millions of 1–10KB files cost far more than expected. Batch or compact them if they are not needed individually.

Step 4: never serve static assets straight from S3

Putting CloudFront in front of S3 pays off in three ways: 1. Egress gets cheaper — traffic from the CDN back to S3 stays on AWS’s internal network and is not billed as public egress. This is the most direct saving. 2. Requests move to the edge — the CDN answers the user, so S3 no longer accrues a GET charge on every request. 3. Latency drops — users fetch from the nearest edge rather than the region where the bucket lives. If your architecture has every request flowing through the application server, moving images and static files off that path onto a CDN is usually the highest-leverage S3 optimisation available.

How to get set up

1. Describe the use case: what you are storing, how often it is read, whether you need CDN acceleration or cross-region replication.
2. Confirm the configuration: region, storage class, and lifecycle rules — with the discount and billing model written into the order confirmation.
3. Account opening: we handle AWS account provisioning and payment verification — no personal card binding, no identity documents.
4. Hand-over: once live you create the bucket yourself in the AWS console; we help configure permissions, lifecycle rules, and CDN integration.