Module:8

AWS Migration and Hybrid

Architecture
 Introduction to AWS Migration
• Definition: AWS Migration involves moving applications, data, and workloads from on-
premises infrastructure or other cloud environments to AWS.
• Importance: Migration to AWS enables increased scalability, cost savings, flexibility, and
access to advanced cloud services.
• Goal: To transition smoothly while optimizing for security, performance, and cost.

Benefits of Migrating to AWS

• Scalability & Elasticity: Automatic scaling to meet demand.
• Cost Efficiency: Pay-as-you-go pricing, reduced hardware costs.
• Security & Compliance: Built-in security tools, compliance certifications.
• Innovation: Access to advanced services (AI, ML, IoT, etc.) to drive innovation.
• Global Reach: Multiple regions and Availability Zones for redundancy and low latency.
 AWS Migration Strategies
• A migration strategy is the approach used to migrate a workload into the AWS Cloud.
There are seven migration strategies for moving applications to the cloud, known as
the 7 Rs:

• Retire (Identifying and decommissioning obsolete applications)

• Retain (Keeping certain applications on-premises if migration isn’t feasible)
• Rehost (“Lift and Shift”): Moving applications without modification.
• Relocate (transfer a large number of servers, comprising one or more applications, at a given time)
• Repurchase (Moving to a new product (e.g., switching to SaaS)).
• Replatform (“Lift, Tinker, and Shift”): Making small optimizations for efficiency.
• Refactor or re-architect (Modifying or rebuilding applications to leverage AWS)
Retire
 This is the migration strategy for the applications that you want to decommission or archive. Retiring the application
means that you can shut down the servers within that application stack. The following are common use cases for
the retire strategy:

 There is no business value in retaining the application or moving it to cloud.

 You want to eliminate the cost of maintaining and hosting the application.

 You want to reduce the security risks of operating an application that uses an operating system (OS) version or
components that are no longer supported.

 You might want to retire applications based on their performance.

 For example, you might want to retire applications that have an average CPU and memory usage below
5 percent, known as zombie applications. You might also choose to retire some applications that have an
average CPU and memory usage between 5 and 20 percent over a period of 90 days, known as idle applications.
You can use the utilization and performance data from your discovery tool to identify zombie and idle
applications.

 There has been no inbound connection to the application for the last 90 days.
Retain

 This is the migration strategy for applications that you want to keep in your source environment or applications that you are not ready to
migrate. You might choose to migrate these applications in the future.

 The following are common use cases for the retain strategy:

 Security and compliance – You might want to retain applications in order to remain in compliance with data residency requirements.

 High risk – You might decide to retain an application because it requires a detailed assessment and plan prior to migration.

 Dependencies – You might decide to retain an application if you need to migrate one or more other applications first.

 Applications that are recently upgraded – You might want to postpone migrating the application until the next technical refresh
because you recently invested in upgrading your current system.

 No business value to migrate – There is no business value for migrating some applications to the cloud, such as those with only a few
internal users.

 Plans to migrate to software as a service (SaaS) – You might choose retain an application until the SaaS version is released by the
vendor. This is a common strategy for vendor-based applications.
Rehost

 Rehosting (lift and shift) is the process of migrating your on-premises application to the
cloud without modifying it.
 This strategy is used mostly to migrate large-scale applications to satisfy specific business
goals, such as launching a product in an accelerated timeline or leaving an on-premises
data center.
 The applications are rehosted on Amazon Elastic Compute Cloud (Amazon EC2) Windows
instances that meet the requirements of the applications you migrate.
Relocate
 In AWS, relocating or migrating resources generally refers to moving applications, data, or entire
infrastructure from an on-premises environment, another cloud, or different AWS regions.
1. Relocate Between AWS Regions
• Amazon S3, Amazon RDS Amazon EC2 Amazon VPC
2. Migrating Data
• AWS DataSync
• Amazon RDS, DynamoDB
3. Moving Applications
• Elastic Beanstalk and CloudFormation
4. Networking and Security
• Set up VPC peering or Transit Gateway if applications need to communicate across regions or accounts.
• Use IAM roles and security group adjustments to ensure proper access in the new region.
5. Automated Migration Tools
• AWS Migration Hub, AWS Application Migration Service (MGN
6. Relocating for Compliance or Disaster Recovery
• AWS CloudEndure: Useful for disaster recovery setups with real-time replication to different regions.
• Cross-Region Backups: Automated in RDS, DynamoDB, and S3 to maintain backup copies in different
 Repurchase
 Repurchasing in AWS involves replacing your existing applications with AWS-native or SaaS
(Software as a Service) solutions. This strategy is often used to reduce operational overhead and
take advantage of the scalability, flexibility, and cost-effectiveness of managed services. Here’s a
breakdown of repurchasing in AWS:
 1. Identify AWS SaaS and Managed Service Alternatives
• Review your existing software or applications to find AWS-native services that can replace them.
For example:
 2. Adopt SaaS Solutions Available in AWS Marketplace
 3. Evaluate Licensing and Migration Path
 4. Configure and Customize AWS Services
• For example, configure Amazon RDS for database replication, backups, and multi-AZ
deployments, or set up AWS IAM to control access to services securely.
 5. Data Migration
 6. Testing and Validation
 7. Monitor and Optimize Post-Deployment
• Utilize AWS CloudWatch for real-time monitoring and AWS Cost Explorer for managing costs.
Replatform
Replatforming in AWS, also known as "lift, tinker, and shift," involves moving applications to AWS while making minimal changes to
optimize their use of cloud-native services. Unlike rehosting (which is a straightforward migration), replatforming leverages some AWS
features to enhance performance, scalability, or cost-efficiency without a complete application redesign. Here’s a guide to replatforming in
AWS:
 1. Identify Optimization Opportunities
 2. Select Managed Services for Core Components
• For databases, replace traditional on-premises or EC2-based databases with Amazon RDS or Amazon DynamoDB to reduce
administrative overhead.
• For storage, replace local file systems or self-hosted NAS/SAN with Amazon S3 or Amazon EFS, which offer scalable storage and
durability.
• For containerized applications, consider moving workloads to Amazon Elastic Kubernetes Service (EKS) or Amazon ECS to reduce
management effort.
 3. Implement Serverless Where Possible
• Move parts of the application that don't require dedicated server management to AWS Lambda for a serverless approach.
 4. Database Migration and Optimization
• Use AWS Database Migration Service (DMS) to help migrate your database to a managed service while performing schema or
format conversions as needed.
 5. Enhance Security and Compliance
• Use AWS IAM for fine-grained access control and role-based access.
• AWS Key Management Service (KMS) can handle encryption for storage and databases, making data security and compliance
easier to manage.
 6. Monitor and Optimize Continuously
• Use AWS CloudWatch for monitoring and alerts, AWS X-Ray for tracing, and AWS Cost Explorer for monitoring and optimizing
costs.
Refactoring or re-architecting
Refactoring or re-architecting in AWS involves rethinking and redesigning your applications to fully leverage cloud-native
features and modern architectures, like microservices, serverless, and containerization. This process often requires a significant
code overhaul or application redesign, as it focuses on optimizing for scalability, resilience, and cost-efficiency within the AWS
ecosystem. Here’s a guide to refactoring or re-architecting in AWS:
 1. Break Down Monolithic Applications into Microservices
• Microservices Architecture: Refactor a monolithic application into smaller, independent services that can be developed,
deployed, and scaled separately.
• Amazon API Gateway can manage RESTful APIs to route requests to individual microservices.
 2. Leverage Managed Databases and Data Stores
• Move to Amazon DynamoDB for a fully managed NoSQL database that supports serverless operation and auto-scaling.
 3. Adopt Containers for Portability and Flexibility
• Containerize applications using Docker and orchestrate them with Amazon Elastic Kubernetes Service (EKS), Amazon
Elastic Container Service (ECS), or AWS Fargate for a serverless container solution.
 4. Optimize Storage and Data Management
• Use Amazon S3 as the primary storage for application data, allowing scalable, durable, and cost-effective data storage.
• Use Amazon Glacier for archival storage of data that’s accessed infrequently, reducing storage costs for historical data.
 5. Enhance Security with AWS Best Practices
• Implement AWS Identity and Access Management (IAM) to set fine-grained permissions for resources.
• Use AWS Key Management Service (KMS) to handle encryption for sensitive data and enable automatic encryption for
storage.
 6. Implement Observability and Monitoring
• AWS CloudWatch can provide metrics and logs to monitor application performance and health in real-time.
AWS Database Migration Service (DMS
AWS DMS is designed specifically to help migrate databases to AWS. It supports continuous data replication with minimal
disruption and provides options to manage both homogeneous (e.g., Oracle to Oracle) and heterogeneous (e.g., Oracle to
MySQL) migrations. This service is ideal for a financial institution due to its ability to facilitate data replication and ensure zero
data loss, maintaining data accuracy and minimizing downtime during the migration.
 Implementation Steps
1. Preparation and Planning:
o Assess the current on-premises database and select the appropriate AWS database target (e.g., Amazon RDS, Amazon
Aurora).
o Set up the AWS DMS environment, including creating a replication instance within the AWS Management Console or
using the AWS CLI.
2. Configure Source and Target Endpoints:
o Configure the source endpoint (on-premises database) and target endpoint (AWS database).
o Set up security configurations, such as IAM roles, security groups, and encryption options.
3. Create and Run the Migration Task:
o Set up the migration task with options for a full-load migration and ongoing replication to capture changes made to the
source database.
o Enable data validation and error handling settings for monitoring data consistency.
4. Monitoring and Cutover:
o Monitor the migration task using AWS DMS Console or CloudWatch to ensure data is being replicated without errors.
o
AWS Server Migration Service (SMS)

 AWS SMS is a purpose-built service for migrating on-premises servers, specifically virtualized workloads (such as VMware or
Hyper-V), to AWS. SMS can transfer applications, along with the underlying operating systems and data, with low downtime
and supports phased replication, making it suitable for complex, data-intensive financial applications that require high
availability during migration.
 Implementation Steps
1. Preparation and Environment Setup:
o Ensure access to the on-premises virtualized servers (e.g., VMware, Hyper-V).
o Install the AWS SMS Connector on the on-premises environment to enable seamless integration with AWS SMS.
2. Configure and Schedule Replication:
o Set up a replication job for each application server, selecting options for frequency and scheduling of incremental
snapshots.
o Define security configurations, including encryption settings, for secure data transfer.
3. Replication Monitoring and Testing:
o Use the AWS SMS Console or CloudWatch to monitor the replication status and verify that data is being transferred
successfully.
o Perform testing on the AWS-hosted servers to validate their readiness for production use, including running functional and
performance tests.
4. Cutover and Final Sync:
o After validating the AWS environment, schedule a final synchronization and cutover to redirect applications to the AWS-
hosted environment.
o
AWS Snowball Edge

 AWS Snowball Edge is a portable, rugged device designed to physically transfer large volumes of data from an on-premises
environment to AWS. It offers local compute and storage capabilities, allowing data processing to continue on-site even
during migration. For financial institutions with high data sensitivity, Snowball Edge provides secure, tamper-resistant data
transfer with built-in encryption, ensuring data remains protected throughout the migration process.
 Implementation Steps
1. Order and Set Up Snowball Edge:
o Order a Snowball Edge device through the AWS Management Console, specifying data capacity requirements.
o Upon receiving the device, connect it to the on-premises network and configure it using the AWS Snowball client.
2. Prepare and Transfer Data:
o Use AWS DataSync or a custom data transfer script to move legacy database and server data to the Snowball Edge.
o For continuous data updates, configure Snowball Edge with DataSync to ensure recent changes are also transferred to
AWS.
3. Secure Data Shipping:
o Once data is transferred, physically ship the device back to AWS, where AWS staff securely upload the data to the
designated AWS storage service.
o Track the shipment status using the AWS Console to ensure secure handling throughout.
4. Final Sync and Cutover:
o Perform a final sync of data changes made during transit using AWS DMS or other AWS services for minimal data gaps.
o Redirect applications to the AWS-hosted databases once verified, completing the cutover.
AWS Snowmobile
 AWS Snowmobile is a high-capacity data transfer solution, transporting up to 100 petabytes of data in a secure, climate-
controlled shipping container. It is intended for large-scale migrations where physical network transfer is impractical,
making it highly suitable for financial institutions managing vast data warehouses. Snowmobile’s security features—
including GPS tracking, 24/7 surveillance, and optional armed security escorts—ensure safe data transport, which is
especially crucial for regulatory compliance in finance.
 Implementation Steps
1. Engage AWS for Snowmobile Services:
o Initiate discussions with AWS for Snowmobile use. Due to its scale, AWS will collaborate with the financial
institution to create a tailored migration plan.
2. Prepare Data for Transfer:
o Identify and prepare the datasets and applications that will be transferred. This may include structuring and filtering
data for optimal transfer efficiency.
3. On-Site Data Loading:
o AWS Snowmobile arrives at the institution’s location, where AWS personnel assist in loading the data.
o During this time, AWS security protocols ensure that data is handled with compliance and minimal risk.
4. Final Data Sync and Cutover:
o Once Snowmobile completes the upload to AWS, perform a final data sync to account for any changes since the initial
data transfer.
o Complete the cutover to AWS-hosted applications after verification, decommissioning on-premises systems as
necessary.