Mobilize
During the mobilize phase of your migration, you need to evaluate the different components that make up the building blocks of your migrated workloads and make trade-offs to select the performance that fits your business requirements. To do this, you need to set up the right metrics for performance monitoring, evaluate the different options to build your architecture, and benchmark the migrated workload against the on-premises workload to measure the different components' performance and adjust if needed.
MIG-PERF-07: How do you verify that the shared services used for migration during the mobilize phase are performing efficiently? |
---|
The mobilize phase lays the foundation for tools, process, and culture that accelerate your migration at scale. The account planning, Architecture selection, monitoring, and observability setup in the mobilize phase are building blocks for any future migrations done. Some of the shared services we set up and validate in the mobilize phase are landing zones, AWS Transit Gateway, and Amazon VPC Lattice.
MIG-PERF-BP-7.1: Identify the right CloudWatch metrics to capture or detect anomaly and identify performance blockers for shared services
This BP applies to the following best practice areas: Architecture selection
Implementation guidance
Suggestion 7.1.1: Identify the right metrics and detect anomalies.
During cloud migration, it's essential to monitor AWS resource performance effectively. CloudWatch Metrics Insights helps by providing a SQL query engine to analyze performance metrics in real-time, aiding in the detection of trends and patterns during the migration process. For more focused monitoring, CloudWatch anomaly detection can be enabled for critical metrics, using machine learning to forecast normal behavior and alert on anomalies. Additionally, metrics explorer is a tag-based tool that allows for the organization and visualization of metrics by tags and resource properties, which is particularly useful for maintaining oversight during and after resource migration.
MIG-PERF-BP-7.2: Select the best performing cloud infrastructure that can scale for additional workloads in future without any performance impact
This BP applies to the following best practice areas: Architecture selection
Implementation guidance
Suggestion 7.2.1: Select the best performing architecture from storage, database, compute, and network perspective.
During the mobilize phase, you are essentially laying the groundwork for your first wave of migration and any future migrations. In this phase, you define and implement an AWS landing zone, and other AWS security and network services that can scale as you migrate additional applications. There are multiple approaches and considerations when selecting the best performing architecture, like factoring cost requirements into decisions, or selecting the best compute, or storage, or database, or network architecture. The best performing architecture in your case would be what best fit your requirements.
For more detail, see the following:
Suggestion 7.2.2: Use existing reference patterns for your architecture to achieve a cost-effective solution.
AWS Solutions Architects, AWS Reference Architectures
MIG-PERF-BP-7.3: Reduce the blast radius for performance impact into a single account
This BP applies to the following best practice areas: Architecture selection
Implementation guidance
Suggestion 7.3.1: Organize your AWS accounts to isolate performance impact.
As you are laying the foundation during the mobilize phase of the migration, account structuring is essential to safeguard performance. Account structuring or organizing can isolate performance impact to a single account, reducing the blast radius. Customers can use AWS Organizations
MIG-PERF-BP-7.4: Benchmark existing workloads for performance
Implementation guidance
Suggestion 7.4.1: Benchmark the performance of an existing workload to understand how it performs on the cloud.
Use the data collected from benchmarks to drive architectural decisions. Benchmarking is generally quicker to set up than load testing and is used to evaluate the technology for a particular component. Benchmarking is often used at the start of a new project, when you lack a full solution to load test.
You can either build your own custom benchmark tests, or you can use an industry standard test, such as TPC-DS
When benchmarking, it is important to pre-warm your test environment to ensure valid results. Run the same benchmark multiple times to capture any variance over time.
Because benchmarks are generally faster to run than load tests, they can be used earlier in the deployment pipeline and provide faster feedback on performance deviations. When you evaluate a significant change in a component or service, a benchmark can be a quick way to see if you can justify the effort to make the change. Using benchmarking in conjunction with load testing is important because load testing informs you about how your workload will perform in production.