AWS Migration Strategy for Enterprises

The 7 Rs: the right decision framework

AWS defines 7 migration strategies (the 7 Rs) representing different levels of transformation and risk. The key is assigning the right R to each workload based on its criticality, technical complexity, and strategic business value.

• Retire: eliminate workloads that no longer have business value. In a typical assessment, 10-15% of systems can be retired.
• Retain: keep on-premises systems that aren't ready for cloud or where migration lacks clear ROI.
• Rehost (Lift and Shift): move the VM as-is to AWS with AWS MGN. Fastest, minimal transformation, but preserves all technical debt.
• Replatform: minimal optimizations without changing the core architecture (migrate DB to RDS, containers on ECS).
• Repurchase: replace with SaaS (migrate in-house CRM to Salesforce, on-prem ERP to SAP Cloud).
• Refactor/Re-architect: redesign for cloud-native (microservices, serverless). Higher long-term ROI, higher short-term cost and risk.
• Relocate: move VMware infrastructure to VMware Cloud on AWS without changing tooling.

In practice, an enterprise migration uses multiple Rs simultaneously. High-complexity critical systems start with Rehost and evolve to Refactor after stabilizing in cloud. Auxiliary systems can go directly to Repurchase.

AWS Landing Zone: the right account architecture

Before migrating a single workload, the AWS account structure (the Landing Zone) must be defined. A correct multi-account architecture is the most important preventive control in AWS — it determines the blast radius of incidents, billing isolation, and the ability to delegate access with least privilege.

AWS Organizations
├── Root
├── OU: Security
│   ├── Account: Log Archive         # CloudTrail, Config, centralized logs
│   └── Account: Security Tooling    # Security Hub, GuardDuty, IAM Access Analyzer
├── OU: Infrastructure
│   └── Account: Network             # Transit Gateway, Direct Connect, Route 53
├── OU: Workloads
│   ├── OU: Production
│   │   └── Account: prod-payments
│   └── OU: Non-Production
│       └── Account: staging-payments
└── Account: Management              # Consolidated billing, AWS Organizations

AWS Control Tower automates the creation and management of this Landing Zone with pre-configured security guardrails. For companies new to AWS, Control Tower is the starting point — never create accounts manually without a governance framework.

VPC Design: decisions you can't change later

The VPC CIDR range design is one of the most permanent decisions in AWS. Once a VPC is in production with workloads and peering connections, changing the CIDR range may require recreating all resources.

# Terraform — VPC with public, private, and intra subnets (no internet access)
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name = "prod-vpc"
  cidr = "10.0.0.0/16"

  azs              = ["us-east-1a", "us-east-1b", "us-east-1c"]
  private_subnets  = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets   = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]
  intra_subnets    = ["10.0.201.0/24", "10.0.202.0/24", "10.0.203.0/24"]

  enable_nat_gateway     = true
  single_nat_gateway     = false  # NAT per AZ for real HA
  enable_dns_hostnames   = true
  enable_dns_support     = true
}

EKS vs. ECS: the container decision in AWS

EKS (managed Kubernetes) and ECS (AWS-native container service) solve the same problem with different tradeoffs. The right decision depends on the team, workload complexity, and long-term strategy.

• ECS with Fargate: lower operational complexity, native IAM/CloudWatch/ALB integration, no Kubernetes knowledge required. Ideal for companies prioritizing adoption speed over portability.
• EKS with Karpenter: greater flexibility, portability to other clouds (or on-premises), access to the full Kubernetes ecosystem. Karpenter replaces the Cluster Autoscaler with 10x faster scaling and per-instance-type cost optimization.
• The trap: EKS with traditional node groups and Cluster Autoscaler is the worst of the three options — Kubernetes complexity without Karpenter's benefits.

# Karpenter NodePool — provision Spot instances when possible
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: default
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot", "on-demand"]
        - key: kubernetes.io/arch
          operator: In
          values: ["amd64"]
      nodeClassRef:
        apiVersion: karpenter.k8s.aws/v1
        kind: EC2NodeClass
        name: default
  limits:
    cpu: 1000
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized

Database migration with AWS DMS

AWS Database Migration Service enables migrating databases to RDS or Aurora with minimal downtime through continuous replication. The process: create a full load + CDC (Change Data Capture) task, validate data parity, and perform the cutover in a planned window with minutes of downtime.

Cost control from day one

The main post-migration shock in AWS is the bill. Without controls from the start, cloud costs are significantly higher than datacenter for the same workload.

• AWS Compute Optimizer: analyzes real EC2, Lambda, and ECS usage and recommends the optimal instance type. On average identifies 20-30% over-provisioning.
• Savings Plans and Reserved Instances: for stable base workloads, 1-3 year commitments reduce cost 40-70% vs. on-demand.
• AWS Cost Anomaly Detection: automatic alerts when spending rises unexpectedly. Catches configuration errors generating unplanned costs.
• Spot Instances with Karpenter: for interruption-tolerant workloads (batch, CI/CD runners, dev environments), Spot reduces compute cost by 70-90%.