Day 19 covered RDS and DMS — the relational side of AWS databases. Today we cover three services that each solve a problem relational databases weren't built for: flexible, high-speed data access at massive scale (DynamoDB), heavy analytical queries over huge datasets (Redshift), and shaving latency off frequently accessed data (ElastiCache).
Amazon DynamoDB
DynamoDB is AWS's NoSQL database service — a non-relational database, and it's one of the most commonly used AWS database services among developers, largely because of how little operational overhead it carries.
The core distinction from RDS: a relational database organizes data into tables with a fixed schema and relationships between tables (joins). DynamoDB instead stores data as items (similar to rows) inside tables, but without a fixed schema — different items in the same table can have different attributes. Every item is identified by a primary key, which can be just a partition key (a single unique identifier) or a composite of a partition key and a sort key (letting you group related items together and query them efficiently, like all orders for one customer, sorted by date).
Performance is the headline feature. DynamoDB is built for single-digit millisecond latency at virtually any scale — it doesn't slow down as your table grows the way a poorly-indexed relational table might. This is exactly why it's a common choice for things like session storage, shopping carts, gaming leaderboards, and IoT data ingestion — workloads that need to read and write huge volumes of simple, predictable data extremely fast.
Capacity modes matter for cost and performance planning: on-demand mode automatically scales to handle your traffic with no capacity planning at all, billing per request — good for unpredictable or spiky workloads. Provisioned mode lets you specify read/write capacity units upfront, which is cheaper at steady, predictable traffic levels but requires you to actually estimate your load correctly.
A couple of things worth knowing beyond the fundamentals: DAX (DynamoDB Accelerator) is an in-memory cache built specifically for DynamoDB, sitting in front of it to push response times from single-digit milliseconds down to microseconds for read-heavy workloads. And Global Tables let you replicate a DynamoDB table across multiple AWS Regions automatically, with multi-region, multi-active read and write access — useful for globally distributed applications that need low latency for users everywhere, not just near one Region.
Amazon Redshift
If RDS is "database in AWS," Redshift is "data warehouse in AWS" — and that distinction matters a lot, because a data warehouse is built to solve a fundamentally different problem than a regular database.
A regular database (RDS) is optimized for transactional workloads — lots of small, fast reads and writes, like a checkout process or a user login. A data warehouse is optimized for analytical workloads instead — running complex queries that aggregate and analyze huge volumes of historical data, like "what were our total sales by region for the last three years." Trying to run that kind of query against a transactional database can bring it to a crawl; that's precisely the gap Redshift fills.
The performance difference comes down to architecture. Redshift uses columnar storage instead of row-based storage — meaning it stores each column of data together rather than each row together. For analytical queries that typically only touch a handful of columns out of a much wider table (like just "region" and "sales" out of a table with fifty columns), this means Redshift only has to read the relevant columns rather than scanning entire rows, which is dramatically faster at scale. Redshift also uses Massively Parallel Processing (MPP) — a cluster made up of a leader node (which plans and coordinates queries) and multiple compute nodes (which actually execute the query in parallel across their own slice of the data), so a query that would take a single server a long time gets split across many nodes working simultaneously.
Worth knowing: Redshift Spectrum lets you run SQL queries directly against data sitting in S3, without having to load it into Redshift first — useful when you have huge volumes of raw data in S3 and only want to pay for querying it occasionally, rather than the cost of always keeping it loaded into a warehouse cluster.
Amazon ElastiCache
ElastiCache is an in-memory database caching service, and its whole purpose is reducing latency and increasing performance for data your application needs frequently.
Here's the underlying idea: an application server normally talks to a database server for every piece of data it needs. But a lot of real-world traffic is repetitive — the same product page, the same user profile, the same search result, requested over and over by different users in a short window. Instead of hitting the database every single time for data that hasn't changed, ElastiCache sits in front of the database as a cache memory layer: frequently accessed data gets stored in fast, in-memory cache, and subsequent requests for that same data get served straight from the cache instead of round-tripping to the database.
ElastiCache offers two engines, and they're not interchangeable — they solve caching differently:
- Redis supports rich data structures (lists, sets, sorted sets, hashes, not just simple key-value pairs), offers built-in replication and persistence (so cached data can survive a restart), and supports pub/sub messaging — making it suitable for more than just caching, like leaderboards or real-time messaging.
- Memcached is simpler and purely a caching layer — no persistence, no complex data structures — but it's easy to scale horizontally across multiple nodes and is a good fit when all you need is straightforward key-value caching without the extra features Redis brings.
A common real-world pattern: a user searches for a product on an e-commerce site ten times in an hour. Without caching, that's ten separate trips to the database for identical data. With ElastiCache in front of the database, the first search hits the database and gets cached; the next nine are served instantly from cache memory, dramatically reducing both latency for the user and load on the database.
How they fit together
These three services rarely compete with each other — they usually sit alongside RDS/DynamoDB, each handling a different part of the same application's traffic: DynamoDB (or RDS) handles the actual transactional reads and writes, ElastiCache absorbs the repetitive, frequently-requested reads to keep latency low and database load down, and Redshift sits off to the side entirely, periodically ingesting data for heavy analytical reporting that has nothing to do with live application traffic.
Quick Recap Questions
- What's the fundamental structural difference between how DynamoDB stores data and how a relational database does?
- Why is columnar storage such a big performance advantage for Redshift's typical analytical queries?
- What's the practical difference between Redis and Memcached, and when would you pick one over the other?
- Why would you put ElastiCache in front of a database instead of just scaling the database itself?
Where to read & follow
- Hashnode: https://sr-palatasingh.hashnode.dev/series/aws-devops-blog
- GitHub: https://github.com/sr-palatasingh/AWS-DevOps-Blog/tree/main/posts
- LinkedIn: https://www.linkedin.com/in/soumyaranjan-palatasingh/
Coming up next
| Day | Topic | Services |
|---|---|---|
| 21 | Identity & Governance | IAM, Organizations |
Top comments (0)