VMware Cloud on AWS — Relocate Strategy

Recap: Where We Left Off

Foundations You'll Need Today

1. Why This Is on the Exam

The SAP-C02 exam tests migration strategy as a decision problem, not as a product catalog. The 7 Rs framework gives you seven labels for how a workload moves, and Relocate is the one that most candidates misclassify because it sounds like Rehost. Both move a server to AWS without rewriting the application, so the instinct is to treat them as synonyms and pick whichever name appears in the answer choices. They are not synonyms, and the exam knows it. Rehost lands the workload on native EC2 as an AMI, which means the guest operating system and application are preserved but the hypervisor is not — the VM becomes an EC2 instance and the surrounding VMware management plane is gone. Relocate moves the VM to VMware Cloud on AWS, where it continues to run on a VMware hypervisor, continues to be managed by vCenter, and continues to be visible to the same operational tooling the team already uses.

That distinction maps to Domain 3 of the exam, which covers migration and modernization, and it shows up in scenarios that give you a hard constraint rather than a preference. The constraint is usually one of three things: a team with deep VMware operational investment and no appetite to retrain on native AWS tooling, a workload with a vendor support contract that is only valid on VMware, or a migration deadline short enough that any application-level change is off the table. When you see those constraints, Relocate is the answer. When you see a scenario that wants to reduce operational overhead, eliminate licensing cost, or modernize toward managed services, Relocate is a trap — it preserves exactly the overhead the scenario is trying to remove.

The exam also tests Relocate as an interim state rather than a destination. A common pattern is a two-phase migration where phase one relocates a large VMware estate quickly to meet a data center exit deadline, and phase two gradually refactors individual workloads onto native services. Recognizing that Relocate can be a deliberate waypoint rather than a final architecture is often what separates the correct answer from a plausible one.

2. How VMware Cloud on AWS Actually Works

VMware Cloud on AWS is a jointly engineered service: VMware supplies the software-defined data center stack (vSphere, vSAN, NSX), and AWS supplies the underlying bare-metal infrastructure and operates the physical facilities. The result is a VMware software-defined data center running on dedicated AWS bare-metal hosts inside an AWS Availability Zone, delivered as a single-tenant SDDC that you connect to your VPC. From the customer's perspective it looks like a vSphere cluster with a vCenter Server, a vSAN datastore, and NSX-based networking — because it is one. From AWS's perspective it is a managed service with an Elastic Network Interface into your account, which is the seam where the two worlds meet.

The networking seam is the part worth understanding deeply, because most exam questions about VMware Cloud on AWS are really questions about connectivity. The SDDC is deployed into a VPC that AWS owns and manages, and it is attached to your VPC through a high-bandwidth, low-latency Elastic Network Interface called the ENI. That attachment is what lets your native AWS resources — EC2 instances, RDS databases, load balancers — talk to VMs running in the SDDC without traversing the public internet. You can also connect the SDDC to your on-premises network over a VPN or Direct Connect, which is what makes the migration path work: the source VMs on-prem and the target SDDC are on the same logical network, so the migration is a live vMotion rather than a copy-and-rebuild.

HCX is the piece that makes the migration itself practical. HCX is a VMware technology that establishes an encrypted, optimized tunnel between the source vSphere environment and the target SDDC, then performs the actual workload movement. It supports several migration modes, and the important one for Relocate is vMotion-based live migration, which moves a running VM with no reboot and no application downtime. HCX also handles the less glamorous work: it extends Layer 2 networks from on-prem into the SDDC so that a VM keeps its IP address across the move, and it can stretch or translate network segments so that the source and target can coexist during a phased cutover. Without network extension, a relocated VM would land with an IP address that nothing on-prem can route to, and the migration would require a re-addressing exercise that defeats the purpose.

The practical consequence is that Relocate is not a data copy operation in the way MGN is. MGN replicates blocks continuously to a staging area and then launches a cutover instance, which is fundamentally a copy. HCX vMotion moves the running VM's execution state — memory, CPU registers, device state — across the tunnel while the VM keeps running, which is why the downtime is measured in seconds rather than minutes. That is a meaningful difference when the workload has a stateful in-memory component or a long application startup sequence.

3. The Core Decision Boundary: Relocate vs. Rehost

Every Relocate scenario question reduces to a single fork: does the workload need to keep running on a VMware hypervisor, or is it acceptable for it to become a native EC2 instance? Everything else — cost, timeline, tooling, licensing — flows from that answer. If the answer is yes, Relocate is the only strategy that satisfies it, because Rehost by definition converts the VM to an AMI and the hypervisor layer disappears. If the answer is no, Relocate is almost always the more expensive and more operationally complex choice, because you are paying for a VMware software stack and a dedicated SDDC footprint to run workloads that could run on ordinary EC2 instances.

The subtlety is that the constraint is rarely stated as "we need VMware." It is stated as a consequence. A vendor support contract that specifies VMware as the supported platform is a hypervisor constraint. A team whose entire operational runbook, monitoring integration, and backup tooling is built on vSphere is a hypervisor constraint, even though nothing technically prevents the workload from running on EC2. A regulatory requirement that the workload remain on a platform the organization has certified is a hypervisor constraint. The exam expects you to translate these into the underlying requirement and then pick the strategy that satisfies it.

The table below lays out the fork in the terms the exam uses. Read it as a decision procedure: start at the left column, and the first row that matches your scenario determines the strategy.

One more boundary worth naming: Relocate is not the same as running VMware on EC2. You can install a hypervisor on an EC2 instance, but that is a self-managed, unsupported configuration and it is not what the exam means by Relocate. The exam's Relocate answer is specifically VMware Cloud on AWS, a managed service with AWS-operated infrastructure and a VMware-operated control plane.

4. Configuration Modes and Their Tradeoffs

Once you have decided to relocate, the next set of choices determines how the migration actually behaves and what it costs. The first is the SDDC deployment size and host type. VMware Cloud on AWS is sold in units of hosts, and the SDDC scales by adding hosts to the cluster. The host type determines the CPU, memory, and storage capacity per host, and the initial host count determines the baseline cost. This is the single largest cost lever in the whole architecture, because you are paying for dedicated bare-metal capacity whether or not the VMs on it are busy. A common mistake is to size the SDDC for peak migration throughput and then leave it at that size after the migration completes, which is why the exam likes scenarios that ask you to right-size after cutover.

The second choice is the HCX migration mode, and this is where the downtime characteristics come from. HCX offers several modes, and they trade off downtime against complexity and network requirements. vMotion-based migration moves a running VM with near-zero downtime but requires the source and target to be on a stretched Layer 2 network and requires the source vSphere version to be compatible. Cold migration powers the VM off, moves it, and powers it back on, which is simpler and works across more version combinations but costs a maintenance window. Bulk migration is a scheduled, parallelized cold migration designed for moving many VMs at once, and it is the mode you reach for when you have hundreds of VMs and a weekend window rather than a handful of VMs and a zero-downtime requirement. Replication-assisted migration keeps a replica in sync and then does a short cutover, which is useful when the source cannot be stretched but you still want a small window.

The third choice is the network extension model. HCX Network Extension stretches a Layer 2 segment from on-prem into the SDDC, which preserves IP addresses and lets source and target coexist. That is what enables phased cutover, but it also means traffic between the two sites traverses the HCX tunnel, which has bandwidth and latency implications. The alternative is to re-address the workload during migration, which avoids the stretched segment but requires application configuration changes and DNS updates. For a workload the team does not want to touch, network extension is usually the right answer, and the exam will often signal this by mentioning that the application has hard-coded IP addresses or that the cutover must be gradual.

Finally, there is the question of what happens to the SDDC after the migration. You can keep it as the permanent runtime for the relocated workloads, which is the pure Relocate outcome. You can keep it as a staging environment while you refactor workloads off it, which is the interim pattern. Or you can decommission it once the workloads have been rehosted or refactored, which is the cheapest long-term outcome but requires a second migration. The exam tends to reward answers that acknowledge this lifecycle rather than treating the SDDC as permanent by default.

5. Sizing, Limits, and Quotas

Sizing a Relocate migration starts with the source estate, not with the target. You need to know how many VMs you are moving, their aggregate CPU and memory demand, their storage footprint, and their network throughput requirements. Application Discovery Service and Migration Evaluator are the tools that produce this inventory, and they are the same tools you would use for a Rehost migration — the discovery phase does not change based on the strategy. What changes is how you translate the inventory into target capacity. For Rehost, you map each VM to an EC2 instance type. For Relocate, you map the aggregate demand to a number of SDDC hosts, and the mapping is coarser because you are buying whole hosts rather than individual instances.

The SDDC itself has a minimum host count for a cluster, and it scales in host increments. Storage is provided by vSAN, which pools the local storage across the hosts in the cluster, so adding a host adds both compute and storage capacity. That coupling is worth noting: you cannot independently scale compute and storage within a single cluster the way you can with EC2 and EBS. If your workload is storage-heavy but compute-light, you may end up buying more compute than you need in order to get the storage capacity, which is a real cost consideration the exam may probe.

Networking limits matter as much as compute limits. The connection between the SDDC and your VPC is a high-bandwidth ENI, and the connection to on-premises runs over VPN or Direct Connect. During a live migration, all the VM's memory state and any in-flight storage writes traverse the HCX tunnel, so the tunnel bandwidth directly determines how fast you can migrate and how many VMs you can migrate in parallel. A common failure in real migrations is under-provisioning the network path and then discovering that vMotion of a large-memory VM takes hours because the tunnel is saturated. The exam will sometimes give you a bandwidth figure and a data volume and expect you to reason about whether the migration fits in the window.

Licensing is the other sizing dimension that is easy to overlook. VMware Cloud on AWS pricing bundles the VMware software licensing into the host cost, which means you are not separately paying for vSphere or vSAN licenses on the target. But the source-side licensing may not transfer cleanly, and any third-party software licensed per-socket or per-host may need to be re-licensed for the new environment. For a workload with expensive per-socket licensing, this can dominate the cost model, and the exam may present a scenario where the licensing cost is the reason Relocate is the wrong answer.

6. Failure Modes and What They Look Like in Production

The most common failure in a Relocate migration is a network extension that works in testing and breaks under production load. HCX Network Extension stretches a Layer 2 segment across the tunnel, and stretched Layer 2 has well-known pathologies: broadcast storms that were previously contained to one site now propagate to both, and any application that relies on low-latency Layer 2 adjacency will see its assumptions violated. The symptom is usually intermittent and hard to attribute — a database that was fine on-prem starts timing out after the stretch, or a cluster heartbeat that was reliable starts flapping. The first diagnostic move is to check whether the affected traffic is crossing the stretched segment and to measure the round-trip latency across the tunnel, because the fix is often to move the workload fully to one side rather than leave it straddling the stretch.

The second failure mode is a migration that completes but leaves the workload with a dependency on the source environment. This happens when the migration moves the VM but not everything the VM talks to — a license server, a DNS forwarder, a backup target, or a monitoring collector that still lives on-prem. The VM runs, but it is silently degraded, and the degradation only surfaces when the on-prem dependency is decommissioned. The symptom is a workload that passes its post-migration smoke test and then fails weeks later during the data center exit. The diagnostic move is a dependency audit before cutover, which is exactly what Application Discovery Service's agent-based mode is for.

The third failure mode is cost drift. The SDDC is sized for the migration, the migration completes, and nobody shrinks the cluster. Because VMware Cloud on AWS bills per host per hour, an oversized SDDC is a continuous, compounding cost that does not show up as an incident and therefore does not get fixed. The symptom is a migration that was declared successful but whose run rate never drops to the expected post-migration level. The diagnostic move is a scheduled right-sizing review after the migration window closes, comparing actual vSAN utilization and CPU demand against provisioned host capacity.

A fourth, less common failure is version incompatibility discovered mid-migration. HCX vMotion requires the source vSphere version to be within a supported range of the target SDDC version, and if the source is too old, the live migration mode is unavailable and you fall back to cold or bulk migration. Discovering this after you have committed to a zero-downtime cutover plan is expensive, which is why version compatibility is a pre-migration checklist item rather than a mid-migration discovery.

7. The Operational and SRE Angle

Relocate changes what you monitor, because the failure surface moves. In a native AWS architecture you monitor CloudWatch metrics, ALB target health, and Auto Scaling group state. In a relocated architecture you still have those for the AWS-side resources, but the workloads themselves are inside an SDDC that reports through vCenter and vSAN rather than through CloudWatch. That means your observability has two planes, and the operational risk is that the two planes are not correlated. An incident that starts as a vSAN datastore latency spike may surface as an application timeout in CloudWatch, and if nobody has wired the two together, the on-call engineer sees only the downstream symptom.

The practical SRE response is to treat the SDDC as a monitored dependency with its own SLOs, and to make sure the vSphere-side signals are exported into the same alerting pipeline as the AWS-side signals. VMware Cloud on AWS exposes SDDC health through the VMware Cloud console and through vCenter, and the useful signals are host CPU and memory pressure, vSAN capacity and latency, and HCX tunnel health during migration windows. During a migration, the HCX tunnel is the single most important thing to watch, because a degraded tunnel slows every in-flight migration and can cause a vMotion to stall. A runbook for a migration window should include a tunnel health check as a gate before starting each batch of VMs.

Backup and recovery need explicit attention because the tooling changes. If the organization's backup strategy was vSphere-based, it may continue to work against the SDDC, but the recovery target is now inside AWS and the recovery procedure may need to account for the SDDC's own availability characteristics. The exam-relevant point is that Relocate does not automatically give you a better DR posture — it gives you a different one, and the RTO and RPO have to be re-derived for the new environment rather than assumed to carry over from on-prem.

Finally, there is a change-management angle. A Relocate migration moves workloads without changing them, which means the application teams may not be involved at all. That is efficient, but it also means the teams that understand the workload's failure modes are not in the loop when it moves. A mature runbook includes a post-migration review with the application owners, even when the migration itself required no application changes.

8. Edge Cases and Exam Gotchas

The first gotcha is treating Relocate and Rehost as interchangeable because both avoid application changes. They are not interchangeable, and the exam will offer both as answer choices in a scenario where only one satisfies the stated constraint. The discriminator is always the hypervisor requirement: if the scenario mentions VMware support, vSphere tooling, or a platform certification, Relocate is correct; if it mentions reducing overhead or moving to managed services, Rehost or Replatform is correct.

The second gotcha is assuming Relocate is a permanent architecture. It can be, but the exam frequently frames it as an interim step, and an answer that treats it as the final state when the scenario describes a longer modernization roadmap may be wrong. Read the scenario for language about future phases, and if it is there, the correct answer may be Relocate now and Refactor later rather than Relocate as the destination.

The third gotcha is confusing VMware Cloud on AWS with running VMware on EC2. The former is a managed service with AWS-operated infrastructure; the latter is a self-managed configuration that the exam does not consider a valid Relocate answer. If an answer choice says "install vSphere on EC2 instances," it is a distractor.

The fourth gotcha is forgetting that HCX requires network extension to preserve IP addresses. A scenario that says the application has hard-coded IP addresses and cannot be re-addressed is pointing at network extension, and an answer that omits it is incomplete even if it correctly identifies Relocate as the strategy.

The fifth gotcha is cost. Relocate is almost always the most expensive of the 7 Rs on a per-workload basis, because you are paying for dedicated hosts and a VMware software stack. A scenario that emphasizes cost optimization as the primary driver is usually not a Relocate scenario, even if the workload is currently on VMware. The exam expects you to weigh the constraint against the cost rather than defaulting to the strategy that requires the least change.

The sixth gotcha is the licensing trap. A workload with per-socket third-party licensing may become dramatically more expensive after relocation, and a scenario that mentions expensive licensing is often testing whether you notice that Relocate does not solve the licensing problem — it may worsen it.

9. Relocate vs. the Strategies It Gets Confused With

Relocate sits in a cluster of strategies that all avoid application changes, and the exam relies on that similarity to build distractors. The table below separates them by what they actually preserve and what they cost. The rule of thumb is that the more you preserve, the more you pay, and the exam is usually testing whether you preserved the right thing rather than the most things.

The comparison that matters most is Relocate versus Rehost, because they are the two answers that both avoid touching the application. The discriminator is the hypervisor. If the scenario's constraint is about the platform the workload runs on, Relocate is correct. If the constraint is only about the application not changing, Rehost is correct and cheaper. The exam will often include both, and the scenario will contain exactly one phrase that decides it.

The second comparison worth internalizing is Relocate versus Replatform. Replatform is the "lift, tinker, and shift" strategy — you move the workload but swap a component for a managed service, such as replacing a self-managed database with RDS. A scenario that says the team wants to reduce operational burden while keeping the application largely intact is a Replatform scenario, not a Relocate scenario, because Relocate reduces nothing. If the scenario says the team cannot change anything at all, Relocate is back in play.

Finally, Relocate versus Retain. Retain is the answer when a blocker makes migration impossible in the current window, and the exam sometimes pairs it with Relocate in a portfolio scenario: relocate the workloads that can move, retain the ones that cannot. Recognizing that a portfolio can use multiple strategies simultaneously is often the difference between a correct answer and an answer that forces a single strategy onto every workload.

Hands-On Lab: Comparing Relocate and Rehost for a Single VM

Scenario Question Drills

Peek into Tomorrow

Sources