🎯 By the end of this module you should be able to…
- Explain what DynamoDB is, how partition and sort keys work, and when NoSQL beats a relational database.
- Compare DynamoDB capacity modes and describe DAX, streams and global tables.
- Explain what a data warehouse is for, and how Redshift's columnar, MPP design makes it fast.
- Describe CloudFront: edge locations, origins, cache behaviours, TTLs and invalidations.
- Explain what Route 53 does and pick the right routing policy for a scenario.
- Assemble all four into one architecture and say what each contributes.
Amazon DynamoDB
A fully managed, serverless key-value and document database. There are no servers to size, no patching, and it delivers single-digit millisecond latency at essentially any scale.
| Term | Meaning |
|---|---|
| Table | A collection of items. There is no fixed schema beyond the key. |
| Item | One record — the equivalent of a row. Up to 400 KB. |
| Attribute | One field on an item. Different items in a table can have different attributes. |
| Partition key | Hashed to decide which physical partition stores the item. Mandatory. |
| Sort key | Optional. Items with the same partition key are stored together, ordered by it. |
| GSI / LSI | Secondary indexes that let you query on attributes other than the main key. |
Partition key: StudentID Sort key: CourseCode
{ "StudentID": "ITM-2026-014", "CourseCode": "AWS-FND",
"Name": "Aisha Khan", "Marks": 88, "Completed": true }
{ "StudentID": "ITM-2026-014", "CourseCode": "LINUX-101",
"Name": "Aisha Khan", "Marks": 74, "Attempts": 2 }Note that the second item has an Attempts attribute the first does not. That is legal,
and it is exactly what "schemaless" means in practice.
Choosing a partition key well
Good partition keys
- High cardinality — many distinct values
- Access spread evenly across values
- Examples: user ID, order ID, device ID
Poor partition keys
- Few distinct values —
Statuswith three possible values - One value far hotter than the rest — today's date
- Result: a "hot partition" that throttles while the rest of the table idles
| Feature | What it gives you |
|---|---|
| On-demand capacity | Pay per request, scales instantly. Best for unpredictable traffic and for learning. |
| Provisioned capacity | You set read and write capacity units; cheaper for steady, predictable load. Auto scaling available. |
| DAX | An in-memory cache in front of DynamoDB — microsecond reads, no application rewrite. |
| DynamoDB Streams | An ordered log of every change, which can trigger a Lambda function. |
| Global tables | Multi-Region, multi-active replication. Strong consistency across Regions is now available as an option. |
| PITR | Point-in-time recovery to any second in the last 35 days. |
| TTL | Automatically delete expired items at no cost — ideal for sessions and carts. |
Query uses the partition key and reads only the matching partition — fast and cheap. Scan reads the entire table and filters afterwards — slow and expensive. If your application scans, your key design is wrong. This is the single most common DynamoDB mistake.
When to choose DynamoDB over RDS
| Choose DynamoDB when… | Choose RDS / Aurora when… |
|---|---|
| Access patterns are known and key-based | You need ad-hoc joins and complex queries |
| You need massive scale with predictable latency | You need multi-table ACID transactions and reporting |
| The schema varies between records | The data is genuinely relational and normalised |
| Serverless, no capacity planning | An existing application speaks SQL |
Amazon Redshift
A fully managed data warehouse: built for analytical queries over very large volumes of historical data, not for the thousands of small transactions a second an application database handles.
| OLTP (RDS, DynamoDB) | OLAP (Redshift) | |
|---|---|---|
| Typical query | "Fetch order 12345" | "Total revenue per region per month for three years" |
| Rows touched | One, or a few | Billions |
| Storage layout | Row-oriented | Column-oriented |
| Optimised for | Many small reads and writes | Few very large aggregations |
Why columnar storage is so much faster for analytics
- ⚙️MPP — massively parallel processing A leader node plans the query; compute nodes each work on their slice in parallel.
- 🗜️Compression Column data compresses several times better than row data, cutting both storage cost and I/O.
- 🚀RG (Graviton) node types The current generation, superseding RA3. They include a built-in data-lake query engine, so you can query open table formats in S3 directly.
- 🌐Redshift Spectrum Query data sitting in S3 without loading it into the warehouse at all.
- ⚡Redshift Serverless No cluster to size. You pay for the capacity a query actually consumes — ideal for spiky analytics and for students.
DynamoDB answers "what is this one record?". Redshift answers "what does all the data say?". If the question contains SUM, AVG, GROUP BY or "over the last three years", it is Redshift.
Amazon CloudFront
A content delivery network. It caches your content at hundreds of edge locations so users are served from somewhere near them instead of from your origin on the other side of the world.
| Concept | What it is |
|---|---|
| Distribution | The CloudFront configuration, with its own d111111abcdef8.cloudfront.net domain name. |
| Origin | Where the real content lives — an S3 bucket, a load balancer, or any HTTP server. |
| Cache behaviour | Per-path-pattern rules: /images/* can cache for a day while /api/* caches not at all. |
| TTL | How long an object may be served from cache before the edge revalidates it. |
| Invalidation | Force-expire an object before its TTL. Useful, but a versioned filename is cheaper and better. |
| OAC | Origin Access Control — lets CloudFront read a private S3 bucket, so the bucket never has to be public. |
The S3 website endpoint you build in the lab is HTTP only. Put CloudFront in front of it with a free ACM certificate and you get HTTPS, a global cache, HTTP/2 and HTTP/3, and the option to make the bucket private again with OAC. That single change is the difference between a classroom demo and a production-style architecture — and it is worth saying so in your project presentation.
What else CloudFront gives you
- Lower origin cost — cache hits never touch S3 or your servers.
- TLS termination at the edge, with free certificates from AWS Certificate Manager.
- AWS Shield Standard DDoS protection, included at no extra cost.
- AWS WAF attaches here — see Module 10.
- Geo restriction — allow or block whole countries.
- Lambda@Edge and CloudFront Functions — run small pieces of code at the edge.
Amazon Route 53
A highly available DNS service, a domain registrar, and a health-checking service. The name is a joke: DNS runs on port 53.
Record types you must know
| Type | Points to | Example use |
|---|---|---|
| A | An IPv4 address | example.com → 203.0.113.25 |
| AAAA | An IPv6 address | example.com → 2600:1f18::1 |
| CNAME | Another domain name | www.example.com → example.com. Cannot be used at the zone apex. |
| MX | A mail server | Mail routing for the domain |
| TXT | Arbitrary text | Domain verification, SPF, DKIM |
| NS / SOA | Name servers / zone authority | Created automatically with the hosted zone |
| Alias | An AWS resource | AWS-specific. Works at the zone apex, resolves to CloudFront, ALB, S3 website or another Route 53 record — and queries to it are free. |
You cannot put a CNAME at the apex (example.com with nothing in front). An Alias
record can go there, points at AWS resources, and costs nothing to query. For any AWS target, choose
Alias.
Routing policies
| Policy | Chooses by | Use it for |
|---|---|---|
| Simple | One record, one answer | A single server or distribution |
| Weighted | A percentage you set | Blue/green and canary releases, A/B testing |
| Latency-based | Lowest measured latency to the user | Multi-Region apps where speed matters most |
| Failover | Health check on the primary | Active–passive disaster recovery |
| Geolocation | Where the user is | Language, licensing or legal requirements |
| Geoproximity | Distance, with a bias you can shift | Gradually moving traffic between Regions |
| Multivalue answer | Up to eight healthy records, at random | Simple client-side load spreading with health checks |
"Send 10% of users to the new version" → weighted. "Serve users from the nearest Region" → latency. "Fail over to a standby site" → failover. "Users in Germany must hit the Frankfurt site" → geolocation.
Putting the four together
Route 53 decides where to send the user. CloudFront decides how fast they get it. DynamoDB serves the one record the request needs. Redshift answers the questions the business asks about all the records.
Key takeaways
- ✅DynamoDB is serverless key-value: partition key decides the partition, sort key orders within it.
- ✅Query is cheap; Scan reads the whole table. Scanning means the key design is wrong.
- ✅Redshift is columnar and MPP — built for aggregations over huge history, not for single-row lookups.
- ✅CloudFront caches at edge locations; a cache hit never reaches your origin.
- ✅Use CloudFront + ACM to put HTTPS in front of an S3 website, and OAC to keep the bucket private.
- ✅Alias records work at the zone apex, point at AWS resources, and are free to query. CNAMEs cannot.
- ✅Match the routing policy to the requirement: weighted, latency, failover, geolocation.