Selecting Compute, Storage, and Database Platforms for Migrated Workloads
Key Takeaways
- SAP-C02 Task 4.3 asks you to pick landing compute, storage, and database platforms for existing workloads and to match that landing to the 7 R already chosen—not to reopen the whole portfolio strategy.
- Amazon EC2 is the default rehost runtime; AWS Elastic Beanstalk is a replatform choice for supported web stacks; AWS Outposts is for residency or on-premises latency; Amazon Lightsail is rarely the Professional target in a multi-account landing zone.
- Amazon EBS gp3 is the usual guest disk; io2 Block Express is for sustained high IOPS, published sub-millisecond design latency, or Multi-Attach; Amazon EFS is Linux NFS; Amazon FSx matches Windows/SMB, Lustre, NetApp ONTAP, or OpenZFS; Amazon S3 is object storage, not a boot volume.
- AWS Storage Gateway Volume Gateway presents iSCSI volumes to on-premises servers with cached (primary data in Amazon S3) or stored (full local dataset, snapshots to S3) modes during hybrid moves.
- Amazon RDS or Amazon Aurora is the usual replatform database; self-managed engines on EC2 remain correct when RDS cannot host the extension or version; Amazon DynamoDB and Amazon OpenSearch Service are selected by access pattern, not as silent replacements for every relational system.
Why Task 4.3 is a landing-zone problem
SAP-C02 Task 4.3 asks you to determine a new architecture for existing workloads. Independent SAP-C02 study material by OpenExamPrep treats that as matching the 7 R you already chose to a landing compute, storage, and database platform—not as a second debate about whether the company should migrate. Domain 4, Accelerate Workload Migration and Modernization, is 20% of scored content. Tasks 4.1 and 4.2 decided whether a workload moves and which transfer tool copies it. Task 4.3 decides what it runs on after the copy.
Continue Meridian Health Systems, the fictional 200-application healthcare estate used in the migration-planning chapter: about 120 rehosted line-of-business virtual machines, 30 replatform candidates (SQL Server to Amazon RDS, a few web apps), VMware clusters that must keep a vSphere-style control plane, a retained claims mainframe, a residency-bound imaging archive, and idle reporting boxes marked retire. If you land every rehost on Amazon Lightsail because the monthly price is predictable, you will fail the next stem that needs AWS Transit Gateway, interface VPC endpoints, and organization-wide AWS Key Management Service (AWS KMS) keys. If you land a simple PHP clinic brochure on a custom Amazon Elastic Compute Cloud (Amazon EC2) Auto Scaling group with a self-managed MySQL pair “because this is the Professional exam,” you overbuilt a replatform that AWS Elastic Beanstalk plus Amazon Relational Database Service (Amazon RDS) already covers.
The exam guide’s Task 4.3 knowledge list is explicit. Compute examples are Amazon EC2 and Elastic Beanstalk. Storage examples are Amazon Elastic Block Store (Amazon EBS), Amazon Elastic File System (Amazon EFS), Amazon FSx, Amazon S3, and AWS Storage Gateway Volume Gateway. Database examples are Amazon DynamoDB, Amazon OpenSearch Service, Amazon RDS, and self-managed databases on Amazon EC2. Amazon Lightsail and AWS Outposts appear on the broader in-scope service catalog. Lightsail is a rarely correct Professional target for a complex organization. Outposts is the target when data residency or on-premises latency forbids a Region-only landing.
Map each R to a landing architecture
AWS Prescriptive Guidance still prefers rehost, replatform, relocate, and retire at factory scale, then modernize after the move. Task 4.3 is where that preference becomes instance families, file systems, and engines. Do not “rehost” a workload onto AWS Lambda in the same wave you promised a 14-month lease exit. That is refactor during the move—the strategy AWS tells you to avoid at large-migration scale unless the other Rs are not an acceptable option.
| 7 R | Typical landing compute | Typical storage | Typical database | Meridian example |
|---|---|---|---|---|
| Rehost | EC2 (often via AWS Application Migration Service / AWS Transform MGN) with right-sized families | EBS on the guests; S3 for snapshots and backups | Keep the engine: self-managed on EC2, or park the database for a later replatform wave | Clinic directory Windows/Linux VMs |
| Replatform | Elastic Beanstalk for supported web stacks; EC2 only when you need OS-level control Beanstalk hides | EFS or FSx when you drop local disks for shared files; S3 for static assets | RDS or Aurora for the same engine family | SQL Server VM → RDS for SQL Server |
| Relocate | Cloud version of the same platform (for example a VMware control plane on AWS), not a silent rewrite onto EC2 | Storage that platform already uses | An RDS instance moved across VPC, account, or Region without an engine change | VMware clusters that must keep vSphere operations |
| Refactor / re-architect | Later: containers or Lambda (next sections) | S3 and EFS as cloud-native I/O | DynamoDB, Aurora Serverless, other purpose-built engines | Patient-portal bottleneck after it is safely in AWS |
| Repurchase | Vendor SaaS compute you do not design | Vendor-managed | Vendor-managed; you integrate identity and network | COTS HR/payroll SaaS |
| Retain / retire | None in the landing zone yet / none | Imaging may stay on premises until assessed | Mainframe DB stays | Claims engine; idle departmental reporting |
Compute: EC2, Elastic Beanstalk, Outposts, and why Lightsail is rare
Amazon EC2 is the default rehost runtime. You choose instance family from utilization (compute, memory, storage, accelerated, network), tenancy, and purchase model. Rehosted Windows and Linux guests keep their disks as EBS volumes. You attach instances to landing-zone subnets, security groups, and instance profiles that AWS Control Tower and AWS Organizations already defined. EC2 is also the escape hatch when Elastic Beanstalk’s opinionated platform cannot express a custom network inspection hop, a Dedicated Host license, or an unsupported runtime.
AWS Elastic Beanstalk is a replatform compute choice for web applications in supported languages. The AWS decision guide (last updated 17 February 2025) lists Python, Java, PHP, Node.js, Ruby, .NET, and Go. You upload application versions; Beanstalk provisions EC2, load balancing, Auto Scaling, and health monitoring. AWS charges for the resources Beanstalk creates, not a separate Beanstalk tax. Beanstalk can integrate RDS, S3, and Amazon CloudWatch, and it can run Docker or deploy onto Amazon Elastic Container Service (Amazon ECS). Use it when the team wants to stop babysitting Amazon Machine Images (AMIs) for a conventional web tier and the landing zone can still place the environment in the right VPC. Do not treat Beanstalk as a substitute for a multi-account network hub. Do not use it as the runtime for a mainframe or a lab instrument.
AWS Outposts extends AWS infrastructure and services on premises. Choose Outposts when the stem requires data residency (imaging that cannot leave the hospital), manufacturing-floor latency, or a local AWS API surface next to plant hardware. You can run EC2 and EBS there, and you can run containers. Outposts is not the answer merely because the company is “hybrid.” Hybrid connectivity (AWS Direct Connect, AWS Site-to-Site VPN, Transit Gateway) plus Regional EC2 is the usual hybrid pattern. Outposts is when the compute itself must sit in the building.
Amazon Lightsail bundles virtual servers, simple load balancing, managed databases, and a content delivery network at fixed monthly prices. The same AWS decision guide positions it for simple websites and applications with limited need for advanced networking or deep integration with RDS, DynamoDB, or Lambda. Lightsail load balancing is documented for low-volume HTTP/HTTPS (AWS cites up to 5 GB per hour and 400,000 connections per hour on the Lightsail balancer). A Professional stem that mentions organization service control policies, Transit Gateway, Gateway Load Balancer inspection, or a 40-account landing zone is asking for EC2, Beanstalk, or containers in a VPC, not Lightsail. Lightsail can still appear as a distractor because it is in-scope on the exam catalog.
Storage: block, file, object, and Volume Gateway
Match access pattern, protocol, and shared versus exclusive attachment. Rehosted guests boot from EBS. Shared Linux home directories that used NFS land on EFS. Windows file servers land on Amazon FSx for Windows File Server, not on EFS. Object backups, static content, and data lakes land on S3. Hybrid iSCSI that must remain visible to on-premises application servers while the rest of the estate moves is Volume Gateway, which the Task 4.3 knowledge list names explicitly.
| Service | Protocol / API | Who attaches | Migration tell |
|---|---|---|---|
| Amazon EBS | Block volume | Usually one EC2 instance; io2 Multi-Attach for clustered SCSI-style needs | Rehosted VM disks; gp3 default; io2 Block Express when the stem needs tighter latency, 99.999% durability, or Multi-Attach |
| Amazon EFS | NFS for Linux | Many EC2, ECS, EKS, and Lambda clients; Regional file system | Shared Linux homes, lift of NFS appliances |
| FSx for Windows File Server | SMB, Active Directory integration | Windows and other SMB clients | Lift of Windows file servers |
| FSx for Lustre | High-performance POSIX | Linux HPC and ML clients | Imaging pipelines, genomics, video |
| FSx for NetApp ONTAP | NFS, SMB, iSCSI | Mixed NAS estates | Existing ONTAP feature set |
| FSx for OpenZFS | NFS | Linux ZFS-style servers | Instant clones and snapshots familiar to ZFS operators |
| Amazon S3 | Object API | Applications, Amazon CloudFront, analytics | Backups, static content, data lakes, images as objects |
| Volume Gateway | iSCSI to on-premises servers | Cached (primary data in S3, hot subset locally) or stored (entire dataset local, snapshots to S3) | Hybrid volume migration or disaster-recovery copies before the application itself moves |
gp3 is the current general-purpose SSD generation AWS recommends for most workloads. AWS documents a baseline of 3,000 IOPS and 125 MiB/s at any volume size, with performance provisioned independently of size up to 80,000 IOPS and 2,000 MiB/s, and about 20 percent lower price per GiB than gp2. Console volume creation defaults to gp3. io2 Block Express is the path when a rehosted database needs sustained high IOPS, the sub-millisecond design latency AWS publishes for 16 KiB I/O, or Multi-Attach. Do not pick st1 or sc1 HDD volumes for a latency-sensitive OLTP disk. Do not pick EFS for a Windows SMB share. Do not pick S3 as the boot volume for a rehosted guest.
Database platforms for migrated workloads
Task 4.3 databases are where the engine lives after the move, not yet the full purpose-built modernization conversation. That conversation is Task 4.4.
Amazon RDS (including Amazon Aurora provisioned clusters) is the default replatform for MySQL, PostgreSQL, SQL Server, Oracle (where RDS offers the edition), and MariaDB when you want patching, Multi-AZ failover, and backups as a service. Self-managed on Amazon EC2 remains correct when the engine version, custom extensions, or vendor support matrix is not an RDS feature, or when the 7 R is still rehost of the database host. Amazon DynamoDB is the landing store when the access pattern is already key-value or you are refactoring a session or catalog table off a relational engine—not when you need multi-table joins and stored procedures unchanged this weekend. Amazon OpenSearch Service is the landing for search and log analytics that used Elasticsearch or OpenSearch on virtual machines.
A Meridian SQL Server reporting instance with a supported edition and a need to stop patching Windows replatforms to RDS for SQL Server. The same engine on EC2 is the rehost when an unsupported CLR extension blocks RDS. DynamoDB is the wrong target for that reporting instance. OpenSearch is the wrong target unless the stem is actually a search or log cluster.
Exam traps
- Lightsail for a multi-account Transit Gateway landing zone.
- Outposts because “hybrid” when Regional EC2 plus Direct Connect already meets latency and residency.
- EFS for SMB; FSx for Windows File Server for Linux NFS; S3 as a virtual-machine disk.
- DynamoDB as the silent replacement for every RDS database.
- Elastic Beanstalk as a mainframe or custom appliance runtime.
- A Lambda plus DynamoDB landing on a wave that was sold as rehost.
- Inventing an AWS exam pass-rate percentage as a migration success metric. AWS does not publish exam-level pass-rate percentages.
Meridian Health Systems is landing a rehosted three-tier clinic directory into a 40-account Control Tower environment. The application must sit in landing-zone private subnets, attach to Transit Gateway, use customer-managed KMS keys, and keep a path to Amazon RDS in a later wave. A vice president wants Amazon Lightsail because the monthly price is fixed. Which landing compute should the architect recommend?
Meridian’s clinic staff still save encounter attachments to an on-premises Windows file server that uses SMB and Microsoft Active Directory. The 7 R for that server is replatform to a managed file system in the landing-zone VPC. Linux NFS home directories for a separate research Linux farm are in scope in the same wave. Which storage pair matches both protocols?
A Meridian reporting database runs Microsoft SQL Server on a virtual machine with a vendor CLR extension that Amazon RDS for SQL Server does not support. Analysts join many tables and run stored procedures. Product managers want “DynamoDB so we are modern.” Which Task 4.3 database platform matches the 7 R and the engine constraint?