Estrategia de Migración a AWS para Empresas

Las 7 Rs: el framework de decisión correcto

AWS define 7 estrategias de migración (las 7 Rs) que representan diferentes niveles de transformación y riesgo. La clave está en asignar la R correcta a cada workload según su criticidad, complejidad técnica y valor estratégico para el negocio.

• Retire: eliminar workloads que ya no tienen valor de negocio. En un assessment típico, el 10-15% de los sistemas puede retirarse.
• Retain: mantener en on-premises sistemas que no están listos para cloud o cuya migración no tiene ROI claro.
• Rehost (Lift and Shift): mover la VM tal cual a AWS con AWS MGN. Más rápido, mínima transformación, pero conserva toda la deuda técnica.
• Replatform: mínimas optimizaciones sin cambiar la arquitectura central (migrar DB a RDS, contenedores en ECS).
• Repurchase: reemplazar por SaaS (migrar CRM propio a Salesforce, ERP on-prem a SAP Cloud).
• Refactor/Re-architect: rediseñar para cloud-native (microservicios, serverless). Mayor ROI a largo plazo, mayor costo y riesgo a corto.
• Relocate: mover infraestructura VMware a VMware Cloud on AWS sin cambiar herramientas.

En la práctica, una migración empresarial usa múltiples Rs simultáneamente. Los sistemas críticos con complejidad alta empiezan con Rehost y evolucionan a Refactor después de estabilizarse en cloud. Los sistemas auxiliares pueden ir directamente a Repurchase.

AWS Landing Zone: la arquitectura de cuenta correcta

Antes de migrar un solo workload, la estructura de cuentas AWS (el Landing Zone) debe estar definida. Una arquitectura multi-cuenta correcta es el control preventivo más importante en AWS — determina el blast radius de incidentes, el aislamiento de billing, y la capacidad de delegar acceso con mínimo privilegio.

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

AWS Control Tower automatiza la creación y gestión de este Landing Zone con guardrails de seguridad preconfigurados. Para empresas nuevas en AWS, Control Tower es el punto de partida — no crear cuentas manualmente sin el framework de governance.

VPC Design: decisiones que no se pueden cambiar después

El diseño del rango CIDR de la VPC es una de las decisiones más permanentes en AWS. Una vez que la VPC está en producción con workloads y peering connections, cambiar el rango CIDR es una operación que puede requerir recrear todos los recursos.

# Terraform — VPC con subnets públicas, privadas e intra (sin acceso a internet)
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 por AZ para HA real
  enable_dns_hostnames   = true
  enable_dns_support     = true
}

EKS vs. ECS: la decisión de contenedores en AWS

EKS (Kubernetes gestionado) y ECS (servicio de contenedores nativo de AWS) resuelven el mismo problema con tradeoffs distintos. La decisión correcta depende del equipo, la complejidad del workload y la estrategia de largo plazo.

• ECS con Fargate: menor complejidad operacional, integración nativa con IAM/CloudWatch/ALB, sin conocimiento de Kubernetes requerido. Ideal para empresas que priorizan velocidad de adopción sobre portabilidad.
• EKS con Karpenter: mayor flexibilidad, portabilidad a otros clouds (o on-premises), acceso a todo el ecosistema Kubernetes. Karpenter reemplaza el Cluster Autoscaler con escalado 10x más rápido y optimización de costos por tipo de instancia.
• La trampa: EKS con node groups tradicionales y Cluster Autoscaler es la peor opción de las tres — complejidad de Kubernetes sin los beneficios de Karpenter.

# Karpenter NodePool — provisionar instancias Spot cuando sea posible
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

Migración de bases de datos con AWS DMS

AWS Database Migration Service permite migrar bases de datos a RDS o Aurora con downtime mínimo mediante replicación continua. El proceso: crear una tarea de full load + CDC (Change Data Capture), validar la paridad de datos, y hacer el cutover en una ventana planificada con downtime de minutos.

{
  "TableMappings": {
    "rules": [
      {
        "rule-type": "selection",
        "rule-id": "1",
        "rule-name": "include-all",
        "object-locator": {
          "schema-name": "produccion",
          "table-name": "%"
        },
        "rule-action": "include"
      }
    ]
  },
  "ReplicationTaskSettings": {
    "TargetMetadata": {
      "TargetSchema": "",
      "SupportLobs": true,
      "FullLobMode": false,
      "LobChunkSize": 64
    },
    "FullLoadSettings": {
      "TargetTablePrepMode": "DO_NOTHING"
    }
  }
}

Control de costos desde el día uno

El principal shock post-migración en AWS es la factura. Sin controles desde el inicio, los costos en cloud son significativamente más altos que en datacenter para el mismo workload.

• AWS Compute Optimizer: analiza el uso real de EC2, Lambda, y ECS y recomienda el tipo de instancia óptimo. En promedio identifica un 20-30% de over-provisioning.
• Savings Plans y Reserved Instances: para workloads base estables, el compromiso de 1-3 años reduce el costo un 40-70% vs. on-demand.
• AWS Cost Anomaly Detection: alertas automáticas cuando el gasto sube inesperadamente. Detecta errores de configuración que generan costos no previstos.
• Spot Instances con Karpenter: para workloads tolerantes a interrupciones (batch, CI/CD runners, ambientes de desarrollo), Spot reduce el costo de cómputo un 70-90%.