Storage and Data Selection
What This Chapter Is About
Teach AWS data placement as a set of access-pattern, ownership, lifecycle, consistency, durability, performance, compliance, and cost decisions.
Keep one durable idea in view:
Data service selection starts with how the data is read, written, owned, protected, and retained.
Sections
How the Chapter Develops
The chapter develops in this order:
Establish access pattern and ownership as the first decision frame.
Separate S3, EBS, EFS, and FSx by storage shape.
Compare RDS/Aurora and DynamoDB by transaction needs, access patterns, scaling, and operating model.
Add analytics, search, cache, backup, encryption, lifecycle, and cost controls.
Apply the model to product catalog, orders, images, search, analytics, and backups.
What You Will Be Able to Do
By the end of this chapter, the reader should be able to:
Choose storage and data services by access pattern rather than service popularity.
Explain why transactional, analytical, object, search, and cache workloads need different designs.
Discuss durability, consistency, lifecycle, encryption, backup, and cost as architecture concerns.
Give a practical recommendation for a mixed e-commerce data platform.
Key Ideas
Data shape and access pattern matter before service name.
S3 is not a database replacement just because it is durable and cheap.
Relational and NoSQL choices should reflect query patterns, consistency needs, and operational expectations.
Analytics and search are often secondary access paths, not the source of truth.