Data Selection Mental Model

Goal

The previous chapter asked where code should run. This chapter asks where data should live.

That sounds like a database question, but it is wider than that. A workload may have product images, order records, inventory lookups, user sessions, search indexes, analytics tables, audit records, backups, archives, and cached responses. Those are not all the same kind of data, and they should not all be forced into one service just because one service is familiar.

This section gives you the selection model before the service names become dense.

The Short Version

The right AWS data service depends on the job the data must perform.

Before choosing S3, EBS, EFS, FSx, RDS, Aurora, DynamoDB, Redshift, OpenSearch, ElastiCache, or AWS Backup, ask:

• How is the data written?

• How is it read?

• Who owns the source of truth?

• Is this operational data, a derived view, a cache, an index, a backup, or an archive?

• What consistency, durability, latency, recovery, retention, encryption, and cost expectations apply?

Service names help you translate the decision into AWS. The design starts with the data job.

Start With The Data Job

Use this simple map:

What is the data job?
  |
  +-- Object or blob storage          -> S3
  +-- Instance-attached disk          -> EBS
  +-- Shared file access              -> EFS or FSx
  +-- Relational transactions         -> RDS or Aurora
  +-- High-scale key lookups          -> DynamoDB
  +-- Search and exploration          -> OpenSearch
  +-- Analytics and reporting         -> Redshift or data lake patterns on S3
  +-- Low-latency temporary reads     -> ElastiCache
  +-- Backup, archive, retention      -> AWS Backup, S3 lifecycle, snapshots

This is not a final architecture. It is a first sorting pass. Once you know the job, you can ask the deeper questions: expected scale, failure behavior, ownership, access control, compliance, restore time, data freshness, and cost.

Source Of Truth Versus Derived Data

One of the most useful data architecture questions is:

If two copies disagree, which one wins?

The answer identifies the source of truth. For example, an order record may live in a transactional database because the business needs consistency, auditability, and careful updates. A search index may contain a copy of order or product data, but it exists to answer search queries quickly. If the index is wrong, you rebuild or refresh it from the source. The index should not silently become the system of record.

The same distinction applies to caches, analytics tables, reporting extracts, and data lake objects. They may be extremely important, but their responsibility is different. A cache exists to reduce latency or load. An analytics store exists to answer aggregate questions. A backup exists to recover. An archive exists to retain data at a different cost and access profile.

When teams skip this distinction, designs become fragile. People update derived stores directly, reconciliation becomes unclear, and outages turn into debates about which copy is real.

The Main Decision Questions

For each data shape, ask these questions before naming a service:

This is why "best database" is usually the wrong first question. A better question is: "What data responsibilities does this workload have?"

Example: Order Management Data

Imagine an order-management platform:

• Product images are large objects served to users and reused in downstream processing.

• Orders and payments require transactional consistency and auditability.

• Inventory availability needs fast reads and careful update rules.

• Search needs flexible text queries across product names, categories, and attributes.

• Analytics needs sales trends across time, regions, channels, and product groups.

• Backups need recoverability and retention rules.

A single database answer is unlikely to serve all of those jobs well. A practical design may use S3 for images and durable object storage, a relational database for orders and payments, DynamoDB for known high-scale access patterns, OpenSearch for search, Redshift or a data lake for analytics, ElastiCache for hot reads, and AWS Backup or snapshots for recovery.

The important point is not that every architecture needs all of those services. The point is that each data shape deserves a responsibility.

Common Mistakes

• Choosing a database before naming the query patterns.

• Treating every copy of data as the source of truth.

• Putting search, analytics, and transactional writes into one store because it feels simpler at first.

• Designing backup policies without testing restore.

• Keeping all data in hot storage because lifecycle and retention were never discussed.

• Ignoring who owns schema changes, data quality, encryption keys, and access evidence.

If Someone Asks You

How do you choose AWS storage or database services?

A good answer is:

I start by naming the data job. Is this object storage, attached block storage, shared files, transactional data, high-scale key lookups, search, analytics, cache, backup, or archive? Then I ask about access patterns, ownership, source of truth, consistency, durability, latency, recovery, retention, encryption, and cost. Only after that do I map the responsibility to AWS services such as S3, EBS, EFS, FSx, RDS, Aurora, DynamoDB, Redshift, OpenSearch, ElastiCache, or AWS Backup.

What You Should Remember

Data architecture starts by naming the data job.

Questions to Check Your Understanding

1. What is the difference between a source of truth and a derived index?

2. Why do access patterns matter before database choice?

3. Which data decisions affect cost over time?