AWS SAA-C03 Drill: Stateful Application Storage - The Shared State Trade-off Analysis

While preparing for the AWS SAA-C03, many candidates get confused by stateful vs. stateless architecture patterns. In the real world, this is fundamentally a decision about shared state management vs. operational complexity. Let’s drill into a simulated scenario.

The Architecture Drill (Simulated Question)

#

Scenario

#

TechDocs Inc. operates a document management web application on AWS. Initially, the application ran on a single Amazon EC2 instance with user-uploaded documents stored on an attached Amazon EBS volume. To improve fault tolerance and scalability, the infrastructure team deployed a second EC2 instance in a different Availability Zone, attached a separate EBS volume, and placed both instances behind an Application Load Balancer (ALB).

After deployment, users began reporting a critical issue: when they refresh their browser, they can only see some of their documents—not the complete set. Different page refreshes show different subsets of documents.

The Requirement:

#

Design a solution that ensures users can consistently view all their documents on every page load, while maintaining the multi-AZ high availability architecture.

The Options

#

• A) Replicate data between the two EBS volumes so both contain all documents.
• B) Configure the Application Load Balancer with sticky sessions to route users to the server containing their documents.
• C) Migrate data from both EBS volumes to Amazon EFS and modify the application to save new documents to Amazon EFS.
• D) Configure the Application Load Balancer to send requests to both servers and aggregate documents from both sources.

Correct Answer

#

C) Migrate data from both EBS volumes to Amazon EFS and modify the application to save new documents to Amazon EFS.

The Architect’s Analysis

#

Correct Answer

#

Option C: Amazon EFS with application modification.

The Winning Logic

#

This solution addresses the root cause of the problem: lack of shared state across multiple compute instances. Here’s why it represents the optimal trade-off:

1. Shared File System: EFS provides POSIX-compliant network file storage accessible from multiple EC2 instances simultaneously across different Availability Zones.

2. Single Source of Truth: All documents exist in one location, eliminating data synchronization complexity and ensuring consistency.

3. Horizontal Scalability: You can add or remove EC2 instances without worrying about data distribution—all instances access the same file system.

4. Durability & Availability: EFS automatically replicates data across multiple AZs within a region (11 nines of durability).

5. Operational Simplicity: No custom replication logic, no sticky session configuration, no aggregation layer needed.

The Trap (Distractor Analysis)

#

• Why not Option A (EBS Replication)?

  • Operational Nightmare: EBS volumes cannot be natively attached to multiple instances simultaneously (except for io2 Block Express in read-only multi-attach mode, which doesn’t help here).
  • You’d need to build custom bidirectional synchronization logic—complex, error-prone, and creates eventual consistency issues.
  • Cost Escalation: Every new instance requires a new EBS volume + synchronization overhead.
  • Violates AWS Best Practices: This is reinventing the wheel poorly.

• Why not Option B (Sticky Sessions)?

  • Fragile Architecture: Users can only see documents uploaded via the specific instance they’re “stuck” to.
  • Poor Fault Tolerance: If that instance fails, the user loses access to those documents until the instance recovers.
  • Doesn’t Solve the Core Problem: Documents are still siloed; you’re just masking the symptom.
  • Session Drain Challenges: Maintenance becomes complex (can’t easily take instances out of rotation).

• Why not Option D (Request Aggregation)?

  • Application Complexity: Requires significant application logic changes to query both instances and merge results.
  • Performance Penalty: Double the I/O operations for every request.
  • Load Balancer Limitation: ALBs don’t natively support request broadcasting and response aggregation—you’d need a custom proxy layer.
  • Latency Impact: The user waits for the slowest response from either instance.

The Architect Blueprint

#

Diagram Note: The ALB distributes traffic across both EC2 instances, which both mount the same Amazon EFS file system via mount targets in their respective Availability Zones, ensuring all instances have access to all documents.

Real-World Application (Practitioner Insight)

#

Exam Rule

#

For the SAA-C03 exam, when you see:

• Multiple instances + user-uploaded content + inconsistent data visibility → Amazon EFS
• Keywords: “stateful application,” “shared files,” “multiple AZs,” “all instances need same data”

Real World

#

In production environments, we’d also consider:

1. Performance Tier Selection:

   • Use EFS Standard for frequently accessed documents
   • Use EFS Infrequent Access (IA) with lifecycle policies for older documents (saves ~85% on storage costs)

2. Caching Layer:

   • Implement CloudFront with S3 for public/static documents
   • Use ElastiCache (Redis) to cache file metadata and reduce EFS I/O

3. Hybrid Approach:

   • For high-throughput scenarios, some teams use Amazon S3 + application-level object storage SDKs instead of EFS
   • S3 offers better cost scaling ($0.023/GB/month vs. EFS $0.30/GB) but requires application refactoring

4. Performance Tuning:

   • Choose EFS Bursting vs. Provisioned Throughput based on workload patterns
   • Monitor CloudWatch metrics: PercentIOLimit, BurstCreditBalance

5. Security Hardening:

   • Use EFS Access Points with IAM policies for application-specific mount points
   • Enable encryption at rest and in transit (required for compliance in most industries)

Disclaimer

This is a study note based on simulated scenarios for the AWS SAA-C03 exam. It is not an official question from AWS or the certification body. The scenario has been rewritten to illustrate core architectural principles while avoiding reproduction of copyrighted material.