Situation and constraints
Cedar Retail has gathered every kind of data into one network file share. Product photos, a virtual server's operating-system disk, employee documents, order records, and shopping-cart sessions all live behind the same storage appliance. The appliance is difficult to scale, and the team assumes that one AWS storage service should replace it.
That assumption hides several different access patterns. Product photos are retrieved as whole objects. A virtual server expects a block device it can format and mount. Employees need a shared file system with directories. Orders have relationships and transactional rules. Shopping-cart state can be represented by a key and value at very high scale.
Cedar must separate storage from database choices and then plan lifecycle and backup behavior. The goal is category recognition, not a detailed schema or performance design.
The decision to make
Cedar should map each data shape to the interface the application expects.
- Store product photos and exported documents as objects in Amazon S3.
- Give an EC2 instance a persistent block volume with Amazon EBS.
- Provide shared Linux-compatible file access with Amazon EFS.
- Put relational order data in Amazon RDS or consider Amazon Aurora when its managed MySQL- or PostgreSQL-compatible capabilities fit.
- Put simple, large-scale key-value or document access patterns in Amazon DynamoDB.
- Use AWS Backup when the company needs centralized, policy-based backup across supported AWS resources.
These services can be used together. S3 is not automatically the database for every application, and RDS is not the place to store every image merely because a database can hold binary data.
A practical mental model
Think of three storage interfaces and two database models.
Object storage is a warehouse where each sealed package has a unique label. An application stores and retrieves an object by key through an API. This fits images, videos, backups, logs, and data-lake files. Amazon S3 is the core AWS object storage service.
Block storage is a blank virtual disk. An operating system formats it with a file system and reads or writes blocks. Amazon EBS volumes attach to EC2 instances and behave like persistent block devices.
File storage is a shared filing room with directories, file names, and file-system semantics. Amazon EFS provides managed, elastic Network File System (NFS) storage that multiple supported compute clients can access.
A relational database stores structured data in related tables and supports SQL and transactions. Amazon RDS manages familiar relational database engines, while Amazon Aurora is an AWS-built relational engine compatible with MySQL and PostgreSQL.
A NoSQL key-value database starts from known access keys instead of joins across related tables. DynamoDB is a serverless, managed key-value and document database. “NoSQL” does not mean “no structure” or “better than SQL”; it means a different data model and access approach.
Match the need to the category
| Cedar need | Category | AWS service | Key distinction |
|---|---|---|---|
| Product images and exports | Object storage | Amazon S3 | API-accessed objects in buckets |
| EC2 boot or data disk | Block storage | Amazon EBS | Volume attached as a block device |
| Shared application files | File storage | Amazon EFS | Managed shared NFS file system |
| Orders, customers, and line items | Relational database | Amazon RDS or Amazon Aurora | Tables, relationships, SQL, and transactions |
| Cart or session lookup by key | NoSQL key-value database | Amazon DynamoDB | Key-based access with managed scaling |
The table is a recognition guide, not an instruction that only one answer can ever work. A real workload may store product metadata in a database and product images in S3. It may write database backups separately from application objects. The important skill is identifying the dominant interface and data model.
Managed databases also change operating responsibility. Running a database engine on EC2 gives Cedar control but leaves the team responsible for the guest operating system, database installation, patching, backups, and availability design. RDS manages more of that platform work. Cedar still owns its data, schema, access, queries, and service configuration.
Aurora belongs to the relational category; it is not DynamoDB with SQL. DynamoDB belongs to the NoSQL category; it does not provide the same relational join model as RDS. The shared database comparison expands these boundaries.
Storage classes, lifecycle, and backup
Not every S3 object needs the same price and retrieval behavior. S3 offers storage classes for different access patterns, including frequently accessed, infrequently accessed, archive, and automatically tiered use cases. The correct class depends on how often data is accessed, how quickly it must be retrieved, how long it will remain, and any minimum-duration or retrieval charges.
An S3 Lifecycle policy can transition eligible objects to another storage class or expire them according to rules. Lifecycle is data-management automation. It is not automatically a backup: if a lifecycle rule expires the only copy, it has implemented deletion, not recovery.
AWS Backup centralizes and automates backup policies for supported services. Backup plans can define schedules and retention and apply across supported resources. Cedar still needs recovery requirements and restore testing. A successful backup job does not prove that the business can restore the right data within its required time.
Native protection features and AWS Backup can overlap. At this level, remember the purpose: lifecycle manages how data ages; backup creates recoverable copies according to protection policy. The S3 lifecycle and storage classes reference and AWS Backup reference provide the deeper operational detail.
Recommended reasoning
Cedar should begin with the question “how must this data be accessed?” If the answer is whole objects through an API, start with S3. If an EC2 operating system needs a disk, start with EBS. If multiple Linux-based clients need a shared mounted file system, start with EFS.
For application records, Cedar should ask whether relationships, SQL, and transactions are central. If yes, use a managed relational option such as RDS or Aurora. If the workload has well-defined key-based access at large scale and does not need relational joins, DynamoDB may fit.
Then Cedar should classify access frequency and retention. Put S3 objects into appropriate storage classes or use lifecycle rules when access changes predictably. Define backup policies based on business recovery needs, centralize supported backup work with AWS Backup where useful, and test restores.
This reasoning avoids two common mistakes: selecting a service because it is famous, and treating data protection as an afterthought after the storage or database has been selected.
Where the manifest services fit
Amazon S3 is object storage. Amazon EBS is persistent block storage for EC2. Amazon EFS is managed elastic file storage. Use the shared S3, EBS, and EFS comparison rather than memorizing disconnected definitions.
Amazon RDS manages relational database engines. Amazon Aurora is a managed MySQL- and PostgreSQL-compatible relational database built for AWS. Amazon DynamoDB is a managed, serverless key-value and document database. Their shared database comparison explains selection signals and tradeoffs.
AWS Backup centralizes policy-based backups for supported AWS resources. It does not replace the need to know which resources are supported, define retention, control access to backups, or verify restoration.
Common exam confusion
- S3 versus EBS: S3 stores objects through an API. EBS supplies a block volume to EC2.
- EBS versus EFS: EBS is a block device commonly attached to an instance. EFS is shared file storage using file-system semantics.
- S3 storage class versus separate service: A storage class changes an S3 object's cost and access characteristics; the object remains in S3.
- Lifecycle versus backup: Lifecycle automates transitions or expiration. Backup preserves recoverable copies according to protection policy.
- RDS versus a database on EC2: RDS shifts more database-platform operations to AWS. A self-hosted database on EC2 leaves more work and control with the customer.
- Aurora versus DynamoDB: Aurora is relational and SQL-compatible. DynamoDB is NoSQL key-value and document storage.
- Managed versus responsibility-free: Cedar still owns data classification, access, schemas, configuration, and recovery requirements.
Recall prompts
- Which storage category fits whole product images retrieved by key?
- Why would an EC2 operating system use EBS rather than S3 as its disk?
- What requirement points toward EFS?
- When do relational requirements point toward RDS or Aurora?
- What access pattern points toward DynamoDB?
- How does an S3 Lifecycle policy differ from a backup policy?
- Why must Cedar test restores even when backup jobs succeed?
Summary
Cedar should separate its data by interface and model. S3 stores objects, EBS provides block volumes, and EFS provides shared file storage. RDS and Aurora serve relational data needs, while DynamoDB serves key-value and document access patterns.
After choosing the category, Cedar should match S3 storage classes to access patterns, use lifecycle rules deliberately, and apply tested backup policies through AWS Backup where supported. The strongest Cloud Practitioner answer starts with the data need, not a universal favorite service.
Official references: CLF-C02 Domain 3, AWS storage decision guide, AWS database decision guide, S3 storage classes, and AWS Backup.