4.3 New Architecture for Migrated Workloads
Official task mapping
SAP-C02 task 4.3: Compute, storage and database knowledge; compatible target-platform selection. This lesson applies the official task to an original design exercise; it is not an exhaustive exam syllabus.
Prerequisites
Review storage choices, compute platforms and database platforms. Be able to explain the relevant failure boundary and access/cost model before choosing a service.
Select the target contract
| Service | Interface/model | Appropriate starting requirement |
|---|---|---|
| EBS | EC2-attached block storage | Boot/data disks and compatible database workloads |
| EFS | Shared NFS/POSIX filesystem | Supported Linux shared-file applications |
| FSx for Windows File Server | SMB and Active Directory integration | Windows-oriented file shares |
| FSx for Lustre | Parallel Lustre filesystem | High-throughput HPC/data-processing workloads |
| S3 | Object APIs | Object-aware applications, archives and data lakes |
EBS is not a customer-facing iSCSI service. S3 is not a transparent POSIX replacement. Filesystem permissions, locking, metadata and application behavior matter more than a simplistic HDD/SSD label.
EC2 suits workloads requiring OS/control or incompatible managed features. ECS/EKS require container suitability and an operating model; Fargate support and constraints differ by platform. Standard Lambda invocations have execution/resource constraints; specialized compute modes need their own documented assessment. Managed databases require engine/extension, licensing and SQL compatibility validation.
Relocation is a strategy, not proof that a particular VMware offering is available through the same vendor/channel as an old guide. Verify current commercial/support terms before proposing a product.
Compute/container/database selection
| Target | Useful fit | Migration validation |
|---|---|---|
| EC2 | OS control, legacy dependencies and self-managed engines | AMI/driver/license, disks, recovery and patching |
| ECS | Supported containers with AWS-oriented orchestration | Task contract, identity, networking and deployment |
| EKS | Required Kubernetes APIs/ecosystem | Cluster/add-ons, policies and operational skill |
| Fargate | Supported ECS/EKS serverless container capacity | Platform-specific constraints and cost profile |
| Lambda | Supported event-driven execution | Mode/runtime, duration, concurrency and dependencies |
| RDS/Aurora | Supported managed relational engines | Extensions, SQL, license and topology |
| DynamoDB | Key/access-pattern-oriented data | Remodeling, consistency, indexes and transactions |
| Self-managed DB | Required unsupported features/control | Operating burden, backups, HA and licensing |
An EKS choice needs a Kubernetes requirement or operating rationale; it is not automatically superior to ECS. “Managed” shifts responsibilities but does not remove them.
For storage, preserve permissions, metadata, locks, identity, throughput and recoverability. Windows clients can use supported SMB file shares; EFS’s NFS/POSIX contract is different. EBS Multi-Attach is a special coordinated block-storage feature, not a generic shared file service.
Pilot using representative reads/writes, authentication, permissions and a crash/restart. Measure transfer and cutover separately from steady-state performance. Keep the source contract/license and reverse-data plan visible before declaring a target architecturally better.
Scenario and rationale
A Windows application depends on SMB locking and domain identities, while a Linux batch system needs parallel reads from S3-derived datasets. Evaluate FSx for Windows for the first and FSx for Lustre for the second, with benchmarks and identity/network design. Keep an unsupported database on EC2 initially if a managed target would break required extensions.
Reject EFS merely because it is “shared”: the Windows SMB/AD contract is different. Reject replacing every disk with S3 without code and consistency changes. Managed operation is a benefit, not a compatibility guarantee.
Practice drill
Build a compatibility matrix listing protocols, OS, identity, locks, throughput, availability, licensing and backup/restore. Select one target per workload and one rejected alternative. Design a pilot with representative file/transaction tests and a rollback path before production cutover.
References
- Official Domain 4 task guide
- EBS overview
- FSx for Windows architecture
- FSx for Lustre overview
- Container hosting choices
Return to Domain 4. The drill is proposed study work, not a claim of a completed deployment.