Architectural Design for Existing Workloads (SAP-C02)

This guide focuses on Content Domain 4: Accelerate Workload Migration and Modernization, specifically Task 4.3: Determine a new architecture for existing workloads. The goal is to transition from a 'lift-and-shift' mindset to an optimized, cloud-native architecture by selecting the right compute, storage, and database services.

Learning Objectives

By the end of this module, you should be able to:

• Select the optimal compute platform (EC2 vs. Beanstalk vs. Containers).
• Evaluate storage services based on performance, protocol, and cost requirements.
• Map legacy data stores to appropriate AWS database platforms (RDS vs. NoSQL).
• Design a 3-tier architecture that leverages managed services to reduce operational overhead.

Key Terms & Glossary

• 7Rs of Migration: The strategic framework (Retain, Retire, Rehost, Replatform, Refactor, Relocate, Repurchase) used to categorize migration approaches.
• COTS (Commercial Off-The-Shelf): Software purchased from a third party that typically limits architectural changes (often leading to Rehosting).
• Managed Container Platform: Services like Amazon ECS or EKS that handle the orchestration, scaling, and management of containerized applications.
• Serverless: A cloud-native development model that allows you to build and run applications without managing servers (e.g., AWS Fargate, Lambda).

The "Big Idea"

The core philosophy of Task 4.3 is "The Right Tool for the Right Job." In a legacy environment, developers often use a single relational database for every use case (search, session storage, transactions). In AWS, a modern architecture decomposes these functions. The "Big Idea" is to move away from monolithic maintenance toward a decoupled, managed ecosystem where each component (Compute, Storage, DB) is selected based on specific performance and scalability metrics.

Formula / Concept Box

Architectural Mapping Table

Hierarchical Outline

• I. Assessing the Application Profile
  • Monolithic vs. Microservices: Determining if the code can be decoupled.
  • Resource Requirements: CPU, Memory, I/O, and Network throughput mapping.
• II. Compute Platform Selection
  • Amazon EC2: Best for full OS access and complex legacy dependencies.
  • AWS Elastic Beanstalk: Best for rapid deployment of web apps with automated infrastructure.
  • Amazon ECS/EKS: Best for containerized workloads requiring high density.
  • AWS Fargate: Best for serverless container execution (no EC2 management).
• III. Storage Strategy
  • Block (EBS): Low latency, single-instance attachment.
  • File (EFS/FSx): Shared access, POSIX compliance (EFS) or Windows-native (FSx).
  • Object (S3): High durability, global access via API.
• IV. Database Modernization
  • Relational (RDS/Aurora): For transactional consistency (ACID).
  • Key-Value (DynamoDB): For high-velocity, single-digit millisecond latency at scale.
  • Caching (ElastiCache): For offloading read-heavy workloads from the primary DB.

Visual Anchors

Compute Selection Logic

Database Mapping (Latency vs. Complexity)

\begin{tikzpicture} \draw[thick,->] (0,0) -- (6,0) node[anchor=north] {Complexity}; \draw[thick,->] (0,0) -- (0,5) node[anchor=east] {Scale/Latency}; \draw[fill=blue!20] (1,1) circle (0.5) node {RDS}; \draw[fill=green!20] (3,3) circle (0.6) node {Aurora}; \draw[fill=red!20] (5,4.5) circle (0.7) node {DDB}; \node at (1,0.3) {Fixed Schema}; \node at (5,0.3) {NoSQL}; \end{tikzpicture}

Definition-Example Pairs

• Rehosting (Lift-and-Shift): Moving an application to the cloud with minimal changes.
  • Example: Moving a legacy .NET 4.5 application from a local Hyper-V server to an Amazon EC2 instance running Windows Server 2019.
• Replatforming (Lift-and-Reshape): Modifying the application to leverage managed services without changing core code.
  • Example: Moving an on-premises Oracle database to Amazon RDS for Oracle to automate patching and backups.
• Shared File Storage (EFS): A managed file system that can be mounted by multiple compute instances simultaneously.
  • Example: A fleet of web servers on EC2 sharing a common directory for user-uploaded profile pictures.

Worked Examples

Scenario: The Legacy 3-Tier Web App

Context: A retail company has a monolithic Java application using a local SQL Server and a shared drive (SMB).

1. Analyze: The application is stateful and uses local file paths.
2. Modernize Storage: Replace the SMB share with Amazon FSx for Windows File Server to maintain native Windows compatibility while gaining cloud scalability.
3. Modernize Compute: Move the Java app to AWS Elastic Beanstalk. This provides auto-scaling and load balancing without rewriting the code.
4. Modernize Database: Migrate SQL Server to Amazon RDS for SQL Server (Multi-AZ) to ensure high availability and offload administrative tasks.
5. Result: The architecture is now resilient, self-healing, and requires 40% less manual intervention.

Checkpoint Questions

1. When should a Solutions Architect choose Amazon EC2 over AWS Fargate for a containerized workload?
2. Which storage service is most appropriate for a legacy application that requires sub-millisecond latency and block-level access?
3. Why might a company choose Amazon Aurora over standard Amazon RDS for a MySQL workload?
4. What is the primary benefit of using AWS Migration Hub in Task 4.1 through 4.3?

Muddy Points & Cross-Refs

• ECS vs. EKS: Use ECS if you want deep AWS integration and simplicity. Use EKS if you are already standardized on Kubernetes or require portability across multi-cloud environments.
• EBS vs. Instance Store: EBS is persistent; Instance Store is ephemeral (lost on stop/terminate). Only use Instance Store for temporary data like buffers or caches.
• Cross-Ref: Refer to Domain 1 (Organizational Complexity) for how to manage these architectures across a multi-account AWS Organizations environment.

Comparison Tables

AWS Storage Comparison