Module 04
Lift and shift servers with AWS MGN, apply the Well-Architected Framework, and progressively modernize through containers to serverless.
AWS MGN is the primary service for lift-and-shift migrations. It automates the conversion of source servers to run natively on AWS, supporting both agent-based and agentless replication with minimal downtime during cutover.
| Setting | Description |
|---|---|
| Instance type right-sizing | Override default instance type for optimal performance/cost |
| Start instance on launch | Control whether instance auto-starts after creation |
| Copy private IP | Maintain IP addressing for application compatibility |
| Transfer server tags | Preserve metadata and organizational tags |
| OS licensing | Bring your own license (BYOL) or use included licensing |
You can cut over individual servers or multiple servers simultaneously. For each cutover, MGN deletes any previous test instance, launches a new cutover instance reflecting the latest source state, and reports success or failure.
AnyCompany Bank leverages MGN's non-disruptive testing capability to validate migrated application servers against production traffic patterns before committing to cutover. This is essential for payment processing servers where any unexpected behavior could impact transaction integrity.
The Well-Architected Framework provides a consistent approach for evaluating architectures and implementing designs that scale over time. It should be applied throughout all migration phases — not just after workloads are in the cloud.
| Scenario | Why It Matters |
|---|---|
| Migrations | Prevent negative impact from workload failures; apply across all three migration phases |
| Workload Redesign | Identify impact of proposed changes; ensure continuous improvement |
| New Workloads | Align stakeholders to common approach; ensure availability and business continuity |
AWS Well-Architected Tool — Free in-console tool for regularly evaluating workloads, identifying high-risk issues, and recording improvements over time.
Well-Architected Lenses — Domain-specific guidance that extends the framework for particular workload types (e.g., serverless, SaaS, financial services).
AnyCompany Bank applies the Reliability and Security pillars with particular rigor. Core banking systems require multi-AZ deployments, automated failover, and encryption at rest and in transit. The Well-Architected review process helps ensure these requirements are met consistently across all migrated workloads.
Application modernization is an ongoing, iterative process — not a one-time event. The goal is to progressively transform legacy architectures into cloud-native designs that deliver business agility, engineering effectiveness, and operational excellence.
| Pathway | Description |
|---|---|
| Move to Cloud Native | Decompose monoliths into microservices with event-driven architectures |
| Move to Containers | Package applications in containers for portability and orchestration (ECS/EKS) |
| Move to Managed Databases | Replace self-managed databases with RDS, Aurora, or DynamoDB |
| Move to Open Source | Reduce licensing costs by adopting open-source alternatives |
| Move to Modern Analytics | Migrate to cloud-native analytics platforms (Redshift, Athena, QuickSight) |
| Move to Modern DevOps | Implement CI/CD pipelines, infrastructure as code, and automated testing |
AnyCompany Bank's modernization journey is progressive: start by containerizing the payment processing monolith (reducing deployment risk), then decompose into microservices (enabling independent scaling of high-volume payment channels), and eventually adopt serverless for event-driven processes like notification delivery and reconciliation.
Modernization typically follows a staged progression. Each stage builds on the previous one, delivering incremental value while reducing risk compared to a "big bang" transformation.
Strategy: Lift and shift to resilient, secure networks
Architecture: Users → Route 53 → EC2 instances
Benefit: Gain cloud infrastructure benefits immediately without rewriting applications. Meet data center exit timelines.
Strategy: Add managed services for critical components
Architecture: Users → Route 53 → CloudFront → ELB → EC2 Auto Scaling → RDS
Benefit: Improved resilience with load balancing, auto scaling, and managed database. S3 + CloudFront for static assets.
Strategy: Move to container orchestration
Architecture: Users → Route 53 → CloudFront → ELB → Amazon ECS → RDS
Benefit: Agility and cost savings through containerized workloads. Faster deployments, better resource utilization.
Strategy: Complete re-architecture with managed services
Architecture: Users → Route 53 → CloudFront → API Gateway → Lambda → DynamoDB
Benefit: Zero server management, pay-per-use pricing, virtually unlimited scalability. S3 for static content, EFS for Lambda storage.
Not every application needs to reach Stage 4. The right target architecture depends on the workload's requirements, team capabilities, and business value. Some applications deliver optimal value at Stage 2 or 3.
AnyCompany Bank's core banking ledger may remain at Stage 2 (managed infrastructure with RDS) due to its relational data model and ACID requirements. Meanwhile, the notification service and fraud detection pipeline can leap to Stage 4 (serverless) where event-driven, pay-per-use architecture aligns perfectly with variable transaction volumes.