We have seen several options for storing data: RDS/Aurora (relational), DynamoDB (NoSQL), and ElastiCache (cache). And AWS has even more. With so much variety, the key question arises: which one should I use for my case? This subchapter gives you the criteria to choose well. It closes Part II and is one of the most practical pieces of knowledge in the book.

AWS advocates the idea of purpose-built databases: instead of forcing all your data into a single type of database, you choose the type that best fits each need. A large application often uses several different databases at once, each for what it does best.

Analogy: You don’t use a hammer for everything. To hammer, you use a hammer; to screw, a screwdriver; to cut, a saw. It’s the same with databases: each type is the ideal tool for a certain job.

Ask yourself these questions about your data and your case:

1. Do my data have a clear structure and relationships between them?
2. Do I need complex queries (filters, joins, reports)?
3. What scale and performance do I need?
4. Do the data change flexibly or do they have a fixed schema?
5. Am I repeating many identical reads?

Let’s see how these guide you toward each option.

• Your data have a clear structure and relationships (users who have orders, orders that have products…).
• You need complex queries: multiple filters, joins between tables, reports, aggregations.
• Consistency and data integrity are critical (banking, billing, inventory).
• Your application uses SQL.

Examples: management systems, banking, billing, e-commerce (the orders part), classic enterprise applications. Aurora if you need more performance/scale; vanilla RDS if you want something simpler and more economical.

• You need massive scale and consistent millisecond performance.
• You access data mainly by a known key (“give me item X”).
• Your data are flexible or change structure frequently.
• You want zero administration (serverless).

Examples: shopping carts, user profiles, sessions, catalogs with variable attributes, IoT data, applications with millions of users and huge spikes.

• You repeat many identical reads and want to speed them up.
• You want to relieve the load on your main database.
• You need “hot” data instantly (sessions, rankings, counters).

Remember: the cache accompanies another database; it does not replace it. It’s a speed layer in front.

The last three rows are specialized databases that AWS also offers. We haven’t detailed them, but it’s good to know they exist for specific cases (we’ll see Redshift in Chapter 29).

In real life, a serious application mixes several. Let’s look at a complete example.

Real Example — an online store:

• RDS/Aurora (relational): stores orders, payments, and invoices, where consistency and relationships are critical. Here you need SQL and strong guarantees.
• DynamoDB (NoSQL): stores shopping carts and sessions, which require huge scale and fast access by user id.
• ElastiCache (cache): stores the most visited product catalog so pages load instantly without hammering the database.
• OpenSearch: powers the product search engine with advanced text searches.

Each piece uses the database that best solves its problem. Forcing everything into one would make the application slower, more expensive, or more fragile.

Don’t get overwhelmed by so many options. When you’re starting out:

If in doubt, a relational database (RDS/Aurora) is almost always a safe and versatile choice. It covers most needs. Add DynamoDB when you have a clear case of massive scale or access by key, and ElastiCache when you notice the database is suffering from repeated reads. Start simple and specialize only when you need to.

• AWS promotes specialized databases: choose the type that best fits each need, instead of forcing everything into one.
• Relational (RDS/Aurora): structure, relationships, complex queries, consistency (SQL).
• NoSQL (DynamoDB): massive scale, consistent performance, access by key, flexibility.
• Cache (ElastiCache): speed up repeated reads and relieve the database (always accompanying another).
• Serious applications combine several according to each problem.
• If you’re unsure at the start, a relational database is the safe and versatile option; specialize when the need arises.

With this, you close Chapter 8 and Part II. You now know the essential AWS services: compute (EC2), storage (S3), networking (VPC), identity (IAM), and databases. In Part III we take a big leap: we’ll learn to define all this infrastructure as code with Terraform.