Domain 4 of 4 · Chapter 1 of 4

Selecting workloads for migration

Selection as a lifecycle: discover, assess, prioritize, wave

The cheapest workload to move is the one you delete, and you only find those candidates by inventorying the estate before you assign any strategy, which is why skipping discovery and guessing a strategy is the wrong answer almost every time. The professional skill the exam tests is running a disciplined, evidence-driven funnel: inventory the estate, assess each application, assign one of the 7 Rs, then sequence the survivors into waves. That is the decision layer of a migration, kept separate from the execution layer the migration-approach sibling covers.

Discovery comes first because selection is an evidence problem

You cannot rationally assign a strategy to an application you have not inventoried. AWS Application Discovery Service[1] collects configuration, utilization, and dependency data about on-premises servers and databases, and integrates with AWS Migration Hub[2] so you can view discovered servers, group them into applications, and track each application's migration status from a single console. The grouping step matters: the unit of selection is the application, not the individual server, because a single business application usually spans several coupled servers.

The 7 Rs are a selection lens, not just an execution menu

The seven common migration strategies (7 Rs)[4] (retire, retain, rehost, relocate, repurchase, replatform, and refactor/re-architect) are the framework for assigning a disposition to each application. Used as a selection lens, two of them remove work from the migration entirely: retire decommissions applications that are unused, redundant, or near end-of-life, and retain keeps an application on-premises for now (for compliance, latency, or a pending decision). Both are legitimate selection outcomes, not failures. The cheapest workload to move is the one you delete, so finding retire/retain candidates early is where discovery pays for itself.

Utilization classes flag retire/retain candidates

AWS Prescriptive Guidance gives precise names to low-utilization servers that discovery surfaces: an application averaging under 5% CPU/memory is a "zombie application"[4], and one averaging between 5% and 20% over a 90-day period is an "idle application"[4]. Both are commonly retired or retained rather than rehosted: paying to lift-and-shift dead weight is a classic over-spend the exam wants you to avoid. (Note the exact AWS naming: <5% is zombie, not "idle"; 5–20% is idle, not "underutilized.")

Prioritize by value, effort, and risk; then sequence into waves

Once each surviving application has an R, prioritize what to move first by weighing business value against migration effort and risk: favor high-value, low-effort, low-dependency applications early to prove the migration pattern and build momentum, deferring complex, tightly-coupled applications to later waves. Wave planning then groups the selected applications into batches migrated together, sequenced by dependency, risk, and business priority. Dependency mapping from Application Discovery Service is what tells you which applications must move in the same wave: the service lets you export data about the network connections between servers[1] so coupled components are not split across cutovers (e.g. an app server and its database landing in different waves and breaking).

1. Discover inventory the estate 2. Assess each application 3. Assign one of the 7 Rs 4. Sequence into waves the survivors retire / retain Removed before waves
The portfolio-selection funnel: discover, assess, assign an R, then sequence into waves. Apps marked retire or retain leave the funnel before wave planning.

Discovery and assessment tooling: ADS, Migration Hub, Evaluator

The selection toolchain is three layers: Application Discovery Service collects the raw inventory, Migration Hub aggregates and tracks it, and Migration Evaluator plus Strategy Recommendations turn that data into a funding decision and a per-app strategy. Knowing which tool answers which requirement is the bulk of the question pool for this task.

Application Discovery Service: agentless vs agent vs file import

Application Discovery Service offers three discovery methods[1]:

Method Deployment Captures Key limit
Agentless Collector (OVA in VMware vCenter) Per vCenter Static config + CPU/RAM/disk utilization for every VM, plus database engine/schema metadata vCenter-only (no physical servers); cannot see running processes inside a VM
Discovery Agent (Windows/Linux) Per server Static config, detailed time-series performance, running processes, inbound/outbound network connections Must be installed on each server
File-based import Per estate (CSV) Whatever you provide in the template No live utilization; assessment is only as good as the file

The decisive distinction the exam leans on: the Agentless Collector cannot "look inside" each VM, so it cannot determine the running processes[1], and it is vCenter-only. For physical (non-VMware) servers you need the Discovery Agent (or file-based import). Use agentless for breadth (inventory a large VMware estate fast with no per-guest install) and the agent for depth (process-level dependency detail and time-series data, which only the agent can export to Amazon Athena or a CSV file[1] for deeper analysis). For VMware VMs you can run both simultaneously.

Beyond visualization, Application Discovery Service is built to feed a cost model: using its APIs you can export the system performance and utilization data for discovered servers and input that into your cost model[1] to compute the cost of running them on AWS. (Note: Application Discovery Service is no longer open to new customers[1], with AWS Transform offered as the successor, but it remains squarely in scope for the SAP-C02 blueprint.)

Migration Hub home Region: a single, fixed repository

Migration Hub is the single pane that aggregates discovery and migration status across applications, and the most heavily tested fact here is the home Region. All discovered data is stored in your Migration Hub home Region[1], so you must set the home Region before performing any discovery. There is one home Region per account, and from that one console you can track migrations into any AWS Region[2]. A multi-data-center, multi-target-Region migration still uses Migration Hub in only the single chosen home Region.

The API restriction makes this concrete: write actions (create, notify, associate, disassociate, import, put) are rejected from outside the home Region, except registering agents and collectors, while read actions (list, describe, stop, delete) are permitted anywhere[2]. You can register agents in other Regions, but StartDataCollection will only enable collection from the home Region. The practical exam takeaway: pick one home Region up front (it is the repository for the whole portfolio), and don't propose a per-data-center or per-target-Region Migration Hub.

Migration Evaluator: the TCO business case

When the requirement is "justify the migration spend" or "compare on-prem vs AWS cost," the answer is AWS Migration Evaluator[3]. Its collector is agentless, a single Windows VM using WMI, SNMP, vSphere, and T-SQL[3], and you can alternatively provide existing inventory and utilization via flat files[3] instead of running the collector. It supports x86-architecture servers and attached block storage only[3] (not mainframes or network devices). Its two outputs are the selection driver:

Strategy Recommendations: which R per application

When the team is unsure which R fits each application, Migration Hub Strategy Recommendations[6] analyzes server inventory and application binaries (Microsoft IIS, Java Tomcat/JBoss), and optionally source code and databases, to recommend a migration strategy (rehost, replatform, or refactor) with a deployment destination, suggested tools, and anti-pattern reports per application. It is the tool that automates the per-app R assignment instead of a manual workshop.

Collect Application Discovery Service Aggregate & track Migration Hub Decide Migration Evaluator TCO / business case Strategy Recommendations which R per application Agentless Collector inventories a VMware estate for breadth; the Discovery Agent adds process and time-series depth per server.
Three-layer toolchain: Application Discovery Service collects, Migration Hub aggregates and tracks, and Migration Evaluator plus Strategy Recommendations decide funding and each app's R.

Licensing and data-transfer sizing as selection inputs

Two factors that look like execution detail are actually selection inputs at the professional level: software licensing can change an application's R, and the size and speed of its data can gate whether and when it can move. Getting these wrong is how a workload that looked like an easy rehost becomes a stalled wave.

Licensing can flip the strategy: License Manager and BYOL

Commercial licenses (Microsoft, Oracle, SAP, IBM) are a first-class selection concern because they change cost and feasibility. AWS License Manager[7] manages software licenses across Regions and accounts and is the tool for Bring Your Own License (BYOL): re-purposing existing license inventory for cloud resources[7]. It tracks any software licensed by virtual cores (vCPUs), physical cores, sockets, or number of machines[7] and lets administrators set rule-based hard or soft limits to stop non-compliant usage before it happens[7].

Two capabilities matter for the select decision specifically:

Licensing also pushes specific replatform/refactor choices that belong in the selection conversation. To migrate off SQL Server licensing while minimizing rewrite, Babelfish for Aurora PostgreSQL[8] lets SQL Server applications connect natively to Aurora PostgreSQL with few code changes, a replatform/refactor candidate that the license cost can justify.

Data-transfer sizing decides the how and the when

How much data an application carries, and over what link, is a selection input because it determines whether an online migration is even feasible inside the wave's window. The selection-time question is online over the network vs offline shipping, and the figure above reads it as a three-way branch by volume and link: DataSync online for modest data, Snow Family shipped offline when a large volume on a constrained link faces a hard deadline, and Direct Connect for sustained ongoing hybrid traffic.

Volume / link Selection signal Service family
Modest data, adequate bandwidth, recurring or incremental Online transfer is fine AWS DataSync[9]
Large data, constrained bandwidth, hard deadline Network would take too long, ship it AWS Snow Family[10]
Sustained high-bandwidth, ongoing hybrid migration Provision a dedicated link AWS Direct Connect[11]

A simple rule of thumb keeps the selection sane: estimate transfer time as data volume divided by usable link throughput. If shipping is faster than the wire, the workload's data tier points to the Snow Family. One firm fact to carry: Snowmobile is retired[10]. For multi-petabyte estates the answer is fleets of Snowball Edge devices, Direct Connect, or DataSync, never Snowmobile. The execution mechanics of these services live in the migration-approach sibling; here they are only the lens for deciding whether a data-heavy workload can make a given wave.

Data volume vs link and deadline? Modest data, adequate bandwidth Large data, constrained link, hard deadline Sustained high-bandwidth, ongoing hybrid AWS DataSync online over the network AWS Snow Family ship it offline AWS Direct Connect dedicated link
Data-transfer sizing as a selection decision: DataSync online for modest data, Snow Family shipped offline on a deadline, Direct Connect for ongoing hybrid.

Exam-pattern recognition: SAP-C02 selection scenarios

SAP-C02 selection questions are recognizable by their stems: a number of servers across multiple data centers, a discovery or assessment tool named, and a requirement to inventory, justify, recommend a strategy, or sequence. Match the requirement to the tool and reject the distractor that confuses selection with execution.

"Multiple data centers / multiple target Regions, configure Migration Hub"

When a multinational migrates from data centers in several geographies into several AWS Regions, the trap answer is to set up Migration Hub per data center or per target Region. Correct: choose a single Migration Hub home Region and track everything from there. This is the single-fixed-repository rule from Discovery and assessment tooling above: you track migrations into any AWS Region from the one home-Region console[2], and all discovery data is stored only in that home Region[1]. Why distractors fail: multiple home Regions don't exist per account; a home Region in each target Region contradicts the single-repository design; and discovery data physically lives only in the home Region, so a second Region's console would be empty.

"Build a business case / justify the spend / CFO needs cost detail"

Correct: AWS Migration Evaluator[3], Quick Insights for a fast estimate, and the Business Case report when the requirement adds Microsoft SQL license analysis or detailed cost models[3]. If the stem says a Quick Insights report already exists and the CFO now wants the deeper, defensible analysis, the next step is the Business Case report, not re-running discovery. Why distractors fail: Cost Explorer reports on existing AWS spend, not a projected on-prem-to-AWS TCO; Application Discovery Service supplies utilization data but does not itself produce the licensing business case; and Pricing Calculator is a manual estimate, not a portfolio-wide modeled business case.

"Inventory a large VMware estate fast" vs "need process/dependency detail"

Large VMware estate, fast inventory, no per-server install → Agentless Collector (OVA in vCenter). Need running processes and detailed network dependencies → Discovery Agent on the relevant servers, because the agentless collector cannot see processes inside a VM[1]. Physical (non-VMware) servers → Discovery Agent or file-based import, since the Agentless Collector is vCenter-only[1]. Why distractors fail: "install the agent everywhere" over-engineers a fast inventory; "use agentless for physical servers" is impossible (vCenter-only); and only the agent can export time-series data and network connections to Athena/CSV[1] for the deep analysis some stems require.

"Unsure which migration strategy per application"

Correct: Migration Hub Strategy Recommendations[6], it analyzes inventory and application binaries (IIS, Java Tomcat/JBoss), optionally source code, and returns a per-app rehost/replatform/refactor recommendation with a destination and anti-pattern report. Why distractors fail: Application Discovery Service gathers the data but does not assign an R; Migration Evaluator outputs cost, not a strategy; and a manual 7-Rs workshop is the answer only when no inventory exists to feed the tool.

"We have discovery data, what next / export to a cost model"

When a stem says agents (or the agentless collector) have been collecting for weeks and the team must turn that into a plan, the next step is to group servers into applications and export utilization/dependency data: Application Discovery Service exports performance and utilization data via its APIs for input into a cost model[1] and network-connection data to determine dependencies and group servers into applications[1]. Why distractors fail: jumping straight to Application Migration Service skips the grouping/assessment that selection requires; re-running discovery wastes the data already collected.

"Sequence the chosen applications into waves"

When servers belong to many interdependent applications and the team must order the migration, the answer is wave planning driven by dependency mapping: use the network-connection data from Application Discovery Service to keep coupled components in the same wave[1], and sequence waves by dependency, risk, and business value (low-risk, high-value, low-dependency first). Why distractors fail: migrating servers in arbitrary or alphabetical order splits dependent components across cutovers; moving the largest/most-complex app first maximizes risk before the pattern is proven.

"Retire or retain instead of migrate"

A stem describing servers averaging single-digit CPU, or an application that legally cannot leave the data center, is steering you to retire (decommission the zombie/idle workload[4]) or retain (keep it on-prem this wave). Why distractors fail: rehosting a near-dead or compliance-locked workload spends money and a wave slot on something that should not move at all. Selection means choosing not to migrate when that is the right call.

The 7 Rs: when each strategy is the right selection

StrategyWhat you changeEffort / costPick it when
RetireDecommission the app entirelyLowest (negative cost)Discovery shows the app is unused, redundant, or near end-of-life
RetainNothing. Leave it where it isNone nowCompliance, latency, or a pending decision keeps it on-prem this wave
RelocateMove at hypervisor level, no OS/app changeVery lowVMware estate moving wholesale (e.g. VMware Cloud on AWS) with no rewrite
RehostLift-and-shift, no code changeLowSpeed matters; few app changes (e.g. AWS Application Migration Service to EC2)
RepurchaseReplace with a different productLow-mediumA SaaS equivalent exists (drop-and-shop, e.g. CRM → Salesforce)
ReplatformLift-and-reshape, light optimizationMediumSmall wins available without a rewrite (e.g. self-managed Oracle → Amazon RDS)
Refactor / re-architectRewrite for cloud-nativeHighestLong-term agility/scale justifies the spend; legacy architecture blocks growth

Decision tree

App still used & in business value? No / dead Retire (decommission) Yes Compliance / latency forces on-prem? Yes Retain No SaaS product can replace it? Yes Repurchase (drop-and-shop to SaaS) No Willing to change OS or app code? No change Relocate (hypervisor) whole VMware estate, or Rehost via App Migration Service Light tweak Replatform lift-and-reshape, e.g. Oracle → Amazon RDS Rewrite Refactor / re-architect cloud-native rewrite (highest effort / cost) Always: inventory with Application Discovery Service + Migration Hub first; justify spend with Migration Evaluator; sequence chosen apps into waves by value / risk
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

The 7 Rs frame the disposition of every app

The 7 Rs are the seven migration strategies AWS uses to decide each application's fate before any move runs: retire, retain, rehost, relocate, repurchase, replatform, and refactor/re-architect. They build on the 5 Rs Gartner identified in 2011, and portfolio assessment assigns one R per application across the estate.

Rehost is lift-and-shift with no application changes

Rehost ("lift and shift") moves an application to AWS without changing it to exploit cloud capabilities, for example, re-deploying an on-prem stack onto EC2. It is the fastest, lowest-effort path and the default when speed of exit beats optimization, since you can optimize or re-architect more easily once the workload already runs in the cloud.

Trap Treating rehost as the strategy that delivers cloud-native savings. It deliberately makes no optimizations; that's replatform or refactor.

Relocate moves at the hypervisor level, keeping the platform

Relocate ("hypervisor-level lift and shift") moves servers from an on-prem platform to a cloud service for that same platform, e.g. VMware workloads to VMware Cloud on AWS, without buying hardware, rewriting apps, or changing operations. It is the quickest path because the application's architecture is untouched; the contrast with rehost is that rehost re-deploys onto native EC2 while relocate preserves the source platform.

Trap Picking relocate when the target is native EC2. Once you re-deploy onto EC2 instances rather than a same-platform cloud service, that is rehost, not relocate.

Replatform optimizes lightly without re-architecting

Replatform ("lift, tinker, and shift" / "lift and reshape") moves the application to the cloud and adds some optimization to cut cost or gain managed-service benefits, but stops short of a rewrite. The canonical example is migrating a self-managed Oracle database to Amazon RDS for Oracle. Choose it when a small managed-service or licensing win is available without changing the core architecture.

Trap Choosing replatform when the database engine itself is being changed. Moving self-managed Oracle to RDS for Oracle is replatform, but converting Oracle to Aurora PostgreSQL re-architects the data layer and is refactor.

Repurchase is drop-and-shop to a SaaS replacement

Repurchase ("drop and shop") replaces the application with a different product, typically swapping a traditional license for a SaaS model, for example, moving a CRM to Salesforce. Choose it when an equivalent SaaS exists and the custom application adds no differentiation worth maintaining infrastructure and licenses for.

Trap Calling a same-vendor license-to-SaaS swap a rehost. Replacing the product with a different offering (even a hosted version of the same app) is repurchase, not rehosting the existing binaries.

Refactor/re-architect is the highest effort and cost

Refactor/re-architect rewrites the application to take full advantage of cloud-native features for agility, performance, and scalability, typically porting the operating system and database (e.g. on-prem Oracle to Amazon Aurora PostgreSQL). It delivers the most agility but is the most complex, expensive, and time-consuming of the 7 Rs, so it must be justified by strong business demand, and AWS advises against refactoring during a large migration, modernizing afterward instead.

Trap Choosing refactor as the default for a large migration. AWS recommends rehost/relocate/replatform at scale and modernizing after the move, because refactoring many apps at once is hard to manage.

Retire decommissions; retain defers the move

Retire decommissions applications with no business value: discovery commonly flags "zombie" servers (under ~5% average CPU/memory) and "idle" ones (5–20% over 90 days, or no inbound connection for 90 days) as retire candidates. Retain keeps an app in the source environment for now (for compliance/data-residency, unresolved dependencies, a recent upgrade, or a pending SaaS release) and both are legitimate portfolio outcomes, not failures to migrate.

Trap Tagging a low-utilization but business-critical app as retire. Zombie/idle thresholds only flag candidates, but a still-needed app with constraints (compliance, dependencies) is retain, not retire.

Migration Hub tracks the whole portfolio from one home Region

AWS Migration Hub aggregates discovery data and migration status across applications into a single console, letting you track moves into any target Region from one place. You must choose a Migration Hub home Region before any write action, and all Application Discovery Service discovery and planning data is stored only in that home Region.

Trap Assuming discovery data lives in each migration's target Region. It is stored only in the single Migration Hub home Region, regardless of where workloads land.

16 questions test this
Application Discovery Service feeds the portfolio inventory

AWS Application Discovery Service collects configuration, utilization, and dependency data about on-premises servers and databases and integrates with Migration Hub, where you group discovered servers into applications. You can export its performance and utilization data into a cost model and its server-to-server network connections to map dependencies for grouping.

Trap Reaching for Application Discovery Service to produce the migration cost business case. It collects raw on-prem inventory and dependency data, but Migration Evaluator is the service that builds the TCO/business case.

5 questions test this
Agentless Collector inventories vCenter without touching guests

The Application Discovery Service Agentless Collector is an OVA appliance loaded into VMware vCenter that discovers all VMs and hosts and captures utilization (CPU, RAM, disk) without installing anything inside each guest. It cannot "look inside" a VM, so it does not see running processes or collect time-series data, and it is vCenter-only: it does not discover physical servers.

Trap Reaching for the Agentless Collector to inventory physical servers. It is vCenter-only; physical machines need the Discovery Agent or file-based import.

Discovery Agent adds process and time-series depth per server

The Application Discovery Service Discovery Agent installs on each Windows or Linux server, including physical servers and not just VMware VMs, and additionally collects running processes, detailed time-series performance, and inbound/outbound network connections. Install it on the subset of servers where you need process-level dependency detail the Agentless Collector cannot provide.

Trap Assuming the Discovery Agent only works on VMware VMs like the Agentless Collector. The agent installs per-server on physical Windows/Linux hosts too and is how you cover non-VMware machines.

4 questions test this
Use agentless for breadth, the agent for depth

Pair the two discovery methods: the Agentless Collector inventories a large VMware estate quickly, while the Discovery Agent goes on the subset of servers needing process-level and time-series network-dependency data. Non-VMware physical servers require the agent (or file-based import) because the Agentless Collector is vCenter-only.

Trap Installing the Discovery Agent across the entire large VMware estate for breadth. The agentless OVA covers the whole estate quickly, and you reserve the per-server agent for the subset needing process-level depth.

1 question tests this
Migration Evaluator builds the TCO business case

AWS Migration Evaluator produces the total-cost-of-ownership business case that justifies a migration. It outputs Quick Insights (a fast projected Amazon EC2, EBS, and OS-license cost view over a one-year time frame) and a detailed Business Case report adding further cost models, Microsoft SQL Server license analysis, and Bring Your Own License (BYOL) modeling. It is the exam's answer for "justify migration spend" or "compare on-prem vs AWS cost."

Trap Using Application Discovery Service or Compute Optimizer to produce the migration cost business case. Discovery feeds raw data and Compute Optimizer rightsizes running AWS resources; Migration Evaluator is the dedicated TCO/business-case tool.

8 questions test this
Migration Evaluator's collector is agentless and x86-only

Migration Evaluator's collector is a single Windows Server VM using WMI, SNMP, vSphere, and T-SQL, no agents are deployed on the workloads, and you can instead supply existing inventory via flat files. It models x86 servers and attached block storage only; it does not support Solaris, AIX, other non-x86 devices, storage appliances, mainframes, or network devices.

Trap Picking Migration Evaluator to build a business case for an AIX, Solaris, or mainframe estate. Its collector models x86 servers and block storage only and cannot scope non-x86 platforms.

4 questions test this
Strategy Recommendations suggests the R per application

Migration Hub Strategy Recommendations analyzes server inventory, runtime environment, and application binaries (Microsoft IIS, Java Tomcat/JBoss), and, if you configure source access, source code and databases, to recommend a migration strategy of rehost, replatform, or refactor per application, each with a deployment destination, suggested tools, and an anti-pattern report. It is the service that names the strategy automatically rather than leaving you to assign each R by hand.

Trap Expecting Strategy Recommendations to also produce the cost business case. It names the per-app R (rehost/replatform/refactor) and tooling, while Migration Evaluator handles the TCO justification.

1 question tests this
Prioritize by business value against effort and risk

Sequence the portfolio by weighing business value against migration effort and risk: move high-value, low-effort, low-dependency applications first to prove the pattern and build momentum, then defer complex, tightly-coupled apps to later waves. Early wins de-risk the program before you tackle the hard, interdependent systems.

Trap Leading the program with the most complex, tightly-coupled flagship app for maximum impact. High-value low-effort apps go first to prove the pattern and de-risk before the hard interdependent systems.

Wave planning sequences workloads by dependency

Wave planning groups selected applications into batches (waves) migrated together, ordered by dependency, risk, and business priority. Dependency mapping from Application Discovery Service tells you which components are coupled, so tightly-linked applications move in the same wave and aren't split across separate cutovers.

Trap Sequencing waves purely by business priority and ignoring discovered dependencies. Splitting coupled components across cutovers breaks the application mid-migration.

4 questions test this
Selection decides what and which strategy, not the transfer

Portfolio selection is discovery, assessment, the 7-Rs decision, TCO, and wave planning, deciding what to migrate and the strategy per app. The actual transfer (AWS Application Migration Service, AWS DMS, DataSync, Snow Family) is the separate migration-execution decision, so a "which tool moves the data" question belongs to execution, not selection.

Trap Answering a "which tool moves the servers/data" question with a selection service like Migration Evaluator or Strategy Recommendations. The actual transfer is execution (MGN, DMS, DataSync, Snow), a separate decision from selection.

Data exploration queries discovered dependencies in Athena

Turning on data exploration (the StartContinuousExport API / Migration Hub console toggle) lands Discovery Agent data in an S3-backed Athena database, where predefined or custom SQL runs over process detail, server-to-server network connections, and time-series performance to find affinities for move groups. You can upload extra sources such as a CMDB export and connect Amazon QuickSight for BI reporting on the results.

Trap Expecting data exploration to query Agentless Collector output in Athena. It surfaces Discovery Agent data (process, network connections, time-series), which the agentless collector does not capture.

10 questions test this
SCT multiserver assessment scores many databases from one CSV

The AWS Schema Conversion Tool multiserver assessor takes a single CSV connections file of source database details plus candidate target engines and produces one aggregated CSV report. For each source-target pair it reports the percentage of code, storage, and syntax objects convertible automatically or with minimal change, plus a conversion-complexity score (1 = lowest to 10 = highest), the efficient way to choose the best target engine per database and build a prioritized roadmap before any conversion.

Trap Treating the SCT complexity score as a 1-to-10 scale where 1 is hardest. 1 is the lowest (easiest) conversion complexity and 10 is the highest.

5 questions test this
Compute Optimizer: opt in from management, delegate to a member

Opt in to AWS Compute Optimizer from the Organizations management account and include all member accounts (this enables trusted access), then register a member account as the delegated administrator so rightsizing recommendations for every account are viewed and managed without using the management account day to day. The delegated admin sets recommendation preferences (such as enhanced infrastructure metrics) and member opt-in status, and can export recommendations to an S3 bucket as CSV for analysis in QuickSight.

Trap Opting in to Compute Optimizer from the delegated administrator account. The opt-in for the organization must happen from the management account, which then registers a member as delegated admin.

4 questions test this

Also tested in

References

  1. What is AWS Application Discovery Service?
  2. AWS Migration Hub home Region
  3. AWS Migration Evaluator FAQs FAQ
  4. Migration strategies: the 7 Rs
  5. What is AWS Application Migration Service?
  6. What are Migration Hub Strategy Recommendations?
  7. What is AWS License Manager?
  8. Babelfish for Aurora PostgreSQL
  9. What is AWS DataSync?
  10. What is the AWS Snow Family?
  11. What is AWS Direct Connect?