Lesson 3.1: Storage and relational data architecture for AWS applications
Storage decisions in Amazon Web Services directly influence durability, scaling behavior, cost control, and failure recovery. As developers, we are not just selecting a storage service. We are defining how data survives outages, scales under load, and behaves during failover.
In scenario-based exams such as the DVA-C02, storage questions test how well we understand availability boundaries, scaling patterns, and recovery behavior, not feature memorization.
Amazon S3 architecture and object life cycle strategy
Amazon S3 is regional object storage designed for high durability across multiple Availability Zones. It stores objects accessed via API calls and is not a file system or relational database.
Storage classes and life cycle policies
S3 provides multiple storage classes optimized for different access patterns. Frequently accessed data uses S3 Standard, while infrequently accessed data can transition to lower-cost classes such as Standard-IA or archival tiers. When access patterns are unknown or unpredictable, Intelligent-Tiering is the preferred choice, as it automatically moves objects between tiers without requiring manual lifecycle rules.
Life cycle policies complement storage classes by automating object transitions and expirations. This approach optimizes cost and enforces governance, ensuring that logs, uploads, and temporary artifacts do not remain indefinitely in high-cost storage.
A typical lifecycle configuration via CLI:
aws s3api put-bucket-lifecycle-configuration \
--bucket my-bucket \
--lifecycle-configuration file://lifecycle.json
For exam reasoning, lifecycle policies are often the correct answer when the requirement involves automatic cost reduction over time.
Versioning, event notifications, and access patterns
Versioning protects against accidental deletion or overwrite by maintaining multiple versions of an object. Once enabled, deletion behavior changes, which impacts both application logic and storage costs.
S3 event notifications enable event-driven architectures by triggering services such as Lambda, SQS, or EventBridge when objects are created or deleted.
For example, an upload can trigger processing:
aws s3api put-bucket-notification-configuration \
--bucket my-bucket \
--notification-configuration file://events.json
To provide temporary, secure access without exposing credentials, pre-signed URLs can be used. Additionally, S3 Access Points simplify access control in multi-tenant architectures by offering distinct access policies tailored to different groups or applications.
Amazon Elastic Block Store (EBS) vs. Amazon Elastic File System (EFS): block and shared storage decisions
Amazon Elastic Block Store (EBS) provides block storage attached to a single EC2 instance within one Availability Zone (AZ). EBS is suited for transactional workloads, operating systems, and low-latency disk access. Being AZ-scoped means an EBS volume exists in only one AZ; it cannot be directly attached across AZs. Recovery across AZs requires snapshots, which are stored in S3 and can be used to create new volumes in other AZs. This is a high-frequency exam concept.
Amazon Elastic File System (EFS) provides a shared file system accessible across multiple Availability Zones. It supports concurrent access from multiple instances, making it suitable for distributed, containerized, or multi-instance workloads.
Practical guidance:
- Use EBS for single-instance, performance-sensitive storage.
- Use EFS when multiple instances need shared access.
Creating an EBS volume:
aws ec2 create-volume --availability-zone us-east-1a --size 20
Multi-AZ vs. read replicas (RDS/Aurora)
Before discussing backups, it is important to distinguish between Multi-AZ deployments and read replicas, as exam questions often test this concept.
- Multi-AZ deployments create a synchronous standby in another Availability Zone and provide automatic failover using the same endpoint, improving both availability and durability.
- Read replicas use asynchronous replication to scale read traffic. They do not provide automatic failover unless promoted manually.
Key distinction:
- Multi-AZ → high availability and automatic failover
- Read replicas → read scalability
Selecting the wrong model is a common exam trap.
Backups, snapshots, and failover behavior
RDS provides automated backups with point-in-time recovery. Manual snapshots persist until deleted and are typically taken before major changes.
Aurora separates compute from storage and replicates storage six ways across three Availability Zones, enabling faster failover and improved durability.
To enable Multi-AZ for an existing RDS instance and apply the change immediately, you can run the following CLI command:
aws rds modify-db-instance \
--db-instance-identifier mydb \
--multi-az \
--apply-immediately
Architectural alignment across storage layers
Each storage option maps to a specific access pattern:
- S3 for durable object storage and event-driven workflows
- EBS for single-instance block storage
- EFS for shared file systems
- RDS and Aurora for relational data
Durability in AWS is often built in, but availability and scaling depend on configuration. Multi-AZ protects against AZ failures. Read replicas scale reads but do not replace the primary automatically. Lifecycle policies control cost over time, while event notifications enable distributed processing.
In development-focused scenarios such as DVA-C02, storage questions test whether we understand how these behaviors affect application design under failure, scaling, and cost constraints.
My name is Naeem ul Haq. I’ve been working with AWS since its early days and have deep expertise across its evolving ecosystem.
