AWS Academy Cloud Architecting — Module 3: Adding a Storage Layer

Module Objective: Design a storage layer for a cloud architecture using Amazon S3, and explain how Region choice affects a storage design.

First architectural layer: This module begins the layer-by-layer build-out of the café architecture that continues through Module 8.

The Simplest Architecture

Every architecture starts somewhere. The simplest possible AWS architecture for the café case study is a single Amazon S3 bucket serving a static website — no servers, no databases, just durable object storage and a public endpoint.

Starting from this minimal baseline makes it easier to see exactly what problem each later layer (compute, database, networking, security) is added to solve.

🔵 Note Architects often prototype with the simplest viable design first, then add layers deliberately — rather than starting from a maximally complex "best practice" architecture no one has validated a need for yet.

Using Amazon S3 as an Architectural Building Block

As an architectural component — not just a storage service — Amazon S3 offers static website hosting, event notifications that can trigger other services, and a durable backing store that many other AWS services build on top of.

Architectural Role	How S3 Fills It
Origin store	Backs a CDN distribution (Amazon CloudFront) for global content delivery
Event source	S3 event notifications can trigger AWS Lambda functions or messaging services on object changes
Data lake foundation	Serves as the durable, low-cost landing zone for analytics pipelines
Static website host	Serves HTML, CSS, and JavaScript directly, with no server to manage

✅ Tip — S3 Is Often the First Service Chosen Because it requires no provisioning and scales automatically, S3 is frequently the starting building block in a new architecture, even when the final design will include compute and database layers.

Storing Data in Amazon S3

Architecturally, decisions about how data is organized in S3 — key naming, storage class assignment, and lifecycle rules — affect both application performance and long-term cost, and should be made deliberately rather than left as defaults.

Design Decision	Architectural Consideration
Key naming strategy	Avoiding sequential prefixes for very high request rates helps distribute load evenly
Storage class assignment	Matching a storage class to actual access frequency, not just to the lowest advertised price
Versioning	Protects against accidental overwrite, at the cost of additional storage for older versions

⚠️ Warning — Defaults Aren't Always the Right Design S3's default settings work for a simple use case, but a production architecture typically needs explicit decisions about versioning, lifecycle policies, and encryption rather than relying on defaults.

Moving Data To and From Amazon S3

As an architecture grows, data needs a path into and out of S3 beyond simple uploads — from application code, from other AWS services, and in some cases from large-scale, one-time data transfers.

Method	Best For
AWS SDK / CLI / console	Application-driven or manual transfers of typical file sizes
S3 Transfer Acceleration	Speeding up uploads over long distances by routing through CloudFront edge locations
AWS DataSync	Automated, ongoing transfer of large datasets between on-premises storage and S3
AWS Snowball	Physical device-based transfer for very large datasets where network transfer would take too long

🔵 Note The right transfer method is mostly a function of data volume and network conditions — Snowball exists specifically for the case where even a fast internet connection would take weeks to move the data.

Choosing Regions for Your Architecture

Even for a storage-only architecture, Region choice affects latency to users, data-residency compliance, and cost — the same four factors introduced in AWS Academy Cloud Foundations, now applied to a specific design decision.

As later modules add compute, database, and networking layers, the Region chosen here becomes the anchor that those layers are built around.

✅ Tip — Decide Region Early Because later layers (compute, database, VPC) are all Region-scoped, choosing the Region in this early storage-only stage avoids costly rework once more components depend on it.

Key Terms for Module 3

static website hosting: An Amazon S3 feature that serves HTML, CSS, and JavaScript directly without a web server
S3 event notification: A mechanism that triggers another AWS service, such as Lambda, when an S3 object changes
AWS DataSync: A service for automated, ongoing transfer of large datasets into or out of AWS
AWS Snowball: A physical device-based data transfer service for very large datasets

Review Questions

Why might an architect start a design with just an S3 bucket before adding compute or database layers?
What architectural roles can Amazon S3 play beyond simple file storage?
When would AWS Snowball be a better fit than S3 Transfer Acceleration for moving data into AWS?
Why does Region choice made at the storage layer affect decisions in later modules?