Azure
SAP Actual
S/4HANA en SLES
AWS
Destino
En construcción
M390
Firewall
WatchGuard
On-Prem
Ubiquiti + HPE
QNAP NAS
10 Fases
Roadmap
53 pasos
DEV
Prioridad
Primero validar
✅ Estado de componentes
| Componente | Ubicación | Estado | Notas |
|---|---|---|---|
| SAP S/4HANA (PRD) | Azure | OPERATIVO | SLES + HANA en VMs Azure |
| SAP WebDispatcher | Azure | OPERATIVO | Balanceo y punto de entrada web |
| SAP Router | Azure | OPERATIVO | Conectividad con SAP SE |
| Azure VPN Gateway | Azure | OPERATIVO | VPN S2S hacia WatchGuard M390 |
| VNets/NSGs Azure | Azure | OPERATIVO | Subnets segregadas (app, db, gestión) |
| WatchGuard M390 | On-Prem | OPERATIVO | Firewall perimetral — Fireware OS |
| Ubiquiti (switches/APs) | On-Prem | OPERATIVO | Red LAN corporativa |
| HPE ProLiant | On-Prem | OPERATIVO | Servidores locales |
| QNAP NAS | On-Prem | OPERATIVO | Almacenamiento compartido |
| Cuenta AWS / Organización | AWS | PENDIENTE | Fase 0 del roadmap |
| AWS VPC (DEV) | AWS | PENDIENTE | Fase 1 del roadmap |
| Active Directory (AWS) | AWS | PENDIENTE | Fase 2 — Managed AD o EC2 |
| VPN AWS ↔ On-Prem | AWS/On-Prem | PENDIENTE | Fase 1 — WatchGuard BOVPN |
| SAP S/4HANA DEV (AWS) | AWS | PENDIENTE | Fase 4 — Primer ambiente AWS |
| SAP S/4HANA QAS (AWS) | AWS | FUTURO | Fase 7 — Post-validación DEV |
| SAP S/4HANA PRD (AWS) | AWS | FUTURO | Fase 8-9 — Migración final |
| Descomisión Azure | Azure | FUTURO | Post-migración PRD |
Estrategia DEV-PRIMERO: Construir y validar completamente en DEV antes de replicar a QAS y PRD. Cada fase tiene un control de calidad. Los errores se cometen en DEV, no en producción.
📋 Estrategia de ambientes
| Ambiente | Propósito | Dimensionamiento | HA/DR | Fases |
|---|---|---|---|---|
| DEV | Validar arquitectura, IaC, procesos, conectividad | Mínimo viable (r6i.xlarge HANA ~32GB) | No requerido | 0 → 6 |
| QAS | Validar funcionalidad SAP, pruebas de usuario, rendimiento | Medio (r6i.2xlarge+ según dimensionamiento) | Opcional | 7 |
| PRD | Producción — migración final desde Azure | Completo (x2idn/u- series según dimensionamiento SAP) | Obligatorio — HSR + Pacemaker | 8 → 9 |
🏗️ Arquitectura Objetivo — Multi-Cloud Híbrida
Estado actual (Azure + On-Prem) y estado futuro (AWS como destino principal). La migración es progresiva: DEV → QAS → PRD.
┌─────────────────────────────────────────────────────────────────────────────────┐
│ ☁️ AWS (DESTINO) │
│ │
│ ┌─── Transit Gateway ──────────────────────────────────────────────────────┐ │
│ │ │ │
│ │ ┌─── VPC DEV (10.10.0.0/16) ──────────┐ ┌─ VPC QAS (10.20.0.0/16) ─┐ │ │
│ │ │ ┌─────────┐ ┌─────────┐ ┌───────┐ │ │ (Fase 7 — futuro) │ │ │
│ │ │ │ SAP App │ │SAP HANA │ │ AD │ │ └──────────────────────────┘ │ │
│ │ │ │ (DEV) │ │ (DEV) │ │ (DEV) │ │ │ │
│ │ │ └─────────┘ └─────────┘ └───────┘ │ ┌─ VPC PRD (10.30.0.0/16) ─┐ │ │
│ │ │ subnet-app subnet-db subnet-ad │ │ (Fase 8 — futuro) │ │ │
│ │ │ 10.10.1.0/24 10.10.2.0 10.10.4.0 │ │ HA: HSR + Pacemaker │ │ │
│ │ └─────────────────────────────────────┘ └──────────────────────────┘ │ │
│ │ │ │
│ │ ┌─── VPC Servicios Compartidos (10.40.0.0/16) ────────────────────────┐ │ │
│ │ │ Route 53 Resolvers · Logs · Monitoreo · Bastión │ │ │
│ │ └─────────────────────────────────────────────────────────────────────┘ │ │
│ └──────────┬───────────────────────────────────────────────────────────────┘ │
│ │ VPN S2S (IKEv2/IPSec) │
└─────────────┼───────────────────────────────────────────────────────────────────┘
│
══════════╪════════════════════════ INTERNET ═════════════════════════════
│ │
┌─────────────┼──── 🏢 ON-PREMISES ────────────────┐ ┌──────┼──── ☁️ AZURE ────┐
│ ┌──────────┴──────────┐ │ │ │ (ACTUAL) │
│ │ 🔥 WatchGuard M390 │──── VPN S2S ────────────│──│──────┘ │
│ │ Firewall perimetral│ │ │ ┌──────────────────────┐│
│ └──────────┬──────────┘ │ │ │ SAP S/4HANA (PRD) ││
│ │ │ │ │ HANA + App + WebDisp ││
│ ┌──────────┴──────────┐ │ │ │ SAP Router ││
│ │ Ubiquiti (Switches │ │ │ └──────────────────────┘│
│ │ + APs + VLANs) │ │ │ VNets · NSGs · Subnets │
│ └──────────┬──────────┘ │ │ Azure VPN Gateway │
│ │ │ └──────────────────────────┘
│ ┌──────────┴───┐ ┌───────────┐ ┌───────────┐ │
│ │ HPE ProLiant │ │ QNAP NAS │ │ Clientes │ │
│ │ Servidores │ │ Almacen. │ │ LAN/WiFi │ │
│ └──────────────┘ └───────────┘ └───────────┘ │
│ Red interna: 10.0.x.0/24 (por confirmar) │
└──────────────────────────────────────────────────┘
🔄 Flujo de migración
FASE ACTUAL TRANSICIÓN ESTADO FINAL
╔═══════════════╗ ╔═══════════════════╗ ╔═══════════════════╗
║ Azure (PRD) ║ ║ Azure (PRD) ║ ║ AWS (PRD) ║
║ SAP S/4HANA ║ ─────► ║ AWS (DEV → QAS) ║ ─────► ║ SAP S/4HANA ║
║ ║ ║ AD en AWS ║ ║ AD consolidado ║
╚═══════════════╝ ╚═══════════════════╝ ╚═══════════════════╝
│ │ │
On-Prem (M390) On-Prem (M390) On-Prem (M390)
VPN → Azure VPN → Azure + AWS VPN → AWS
Azure descomisionado
🔐 Matriz de conectividad VPN
| Origen | Destino | Tipo | Estado | Fase |
|---|---|---|---|---|
| WatchGuard M390 | Azure VPN Gateway | VPN S2S (IKEv2) | OPERATIVO | — |
| WatchGuard M390 | AWS VGW/TGW | VPN S2S (IKEv2) | PENDIENTE | Fase 1.3 |
| Azure VNet | AWS VPC | VPN o peering | PENDIENTE | Fase 1.6 |
🖥️ Instancias SAP en AWS — Dimensionamiento por ambiente
| Rol | DEV | QAS | PRD |
|---|---|---|---|
| SAP HANA DB | r6i.xlarge (4v/32GB) | r6i.4xlarge (16v/128GB)* | x2idn o u-series (según dimensionamiento)* |
| SAP App Server (PAS) | r6i.large (2v/16GB) | r6i.2xlarge (8v/64GB)* | r6i.4xlarge+ (según SAPS)* |
| SAP ASCS/ERS | t3.medium (compartido) | m6i.large* | m6i.xlarge (clúster HA)* |
| WebDispatcher | t3.small | t3.medium* | m6i.large (HA)* |
| SAP Router | t3.micro | t3.small* | t3.medium* |
* El dimensionamiento QAS/PRD es estimado — requiere dimensionamiento formal con SAP Quick Sizer o SAPS actuales.
🌐 Plan de direccionamiento IP (CIDR)
CIDRs no solapados entre las tres capas. Diseñados para coexistencia durante la migración y enrutamiento limpio por Transit Gateway.
🏢 On-Premises
10.0.0.0/16
- 10.0.1.0/24 — LAN corporativa
- 10.0.2.0/24 — Servidores
- 10.0.3.0/24 — Gestión
- 10.0.10.0/24 — WiFi
- 10.0.99.0/24 — Invitados
- ⚠️ Confirmar rangos reales
☁️ Azure (actual)
10.1.0.0/16
- 10.1.1.0/24 — subnet-app
- 10.1.2.0/24 — subnet-db
- 10.1.3.0/24 — subnet-gestión
- 10.1.0.0/24 — GatewaySubnet
- ⚠️ Confirmar rangos reales
🚀 AWS — VPC DEV
10.10.0.0/16
- 10.10.0.0/24 — pública (NAT GW, bastión)
- 10.10.1.0/24 — app-a (AZ-a)
- 10.10.2.0/24 — db-a (AZ-a)
- 10.10.3.0/24 — gestión-a (AZ-a)
- 10.10.4.0/24 — ad-a (AZ-a)
- 10.10.11.0/24 — app-b (AZ-b)
- 10.10.12.0/24 — db-b (AZ-b)
🚀 AWS — VPC QAS
10.20.0.0/16
- 10.20.0.0/24 — pública
- 10.20.1.0/24 — app-a
- 10.20.2.0/24 — db-a
- 10.20.3.0/24 — gestión-a
- 10.20.4.0/24 — ad-a
- 10.20.11-12.0/24 — AZ-b
🚀 AWS — VPC PRD
10.30.0.0/16
- 10.30.0.0/24 — pública
- 10.30.1.0/24 — app-a
- 10.30.2.0/24 — db-a
- 10.30.3.0/24 — gestión-a
- 10.30.4.0/24 — ad-a
- 10.30.11-12.0/24 — AZ-b
- Multi-AZ obligatorio
🚀 AWS — VPC Compartida
10.40.0.0/16
- 10.40.0.0/24 — servicios compartidos
- 10.40.1.0/24 — endpoints Route 53
- 10.40.2.0/24 — monitoreo
- 10.40.3.0/24 — bastión / salto
⚠️ Importante: Los CIDRs de On-Premises y Azure son estimados. Antes de desplegar el primer recurso en AWS, confirmar los rangos reales para garantizar que no haya solapamiento. Un solo conflicto de CIDR puede impedir el enrutamiento VPN.
🔀 Tabla de enrutamiento — Transit Gateway
| Destino | Siguiente salto | Notas |
|---|---|---|
| 10.10.0.0/16 (DEV) | TGW → adjunto VPC DEV | Primera VPC en desplegarse |
| 10.20.0.0/16 (QAS) | TGW → adjunto VPC QAS | Fase 7 |
| 10.30.0.0/16 (PRD) | TGW → adjunto VPC PRD | Fase 8 |
| 10.40.0.0/16 (Compartida) | TGW → adjunto VPC Compartida | DNS, monitoreo, bastión |
| 10.0.0.0/16 (On-Prem) | TGW → adjunto VPN (M390) | Túnel VPN S2S |
| 10.1.0.0/16 (Azure) | TGW → adjunto VPN / rebote On-Prem | Fase 1.6 — a definir |
0
Fundación AWS — Cuenta y Gobernanza TODOS
Estructura de cuentas, IAM, registros y costos. Los cimientos que soportan todo lo demás.
Crear la organización AWS con una estructura de cuentas que soporte múltiples ambientes SAP, separación de responsabilidades y gobernanza centralizada.
Estructura recomendada de OUs:
- Raíz → Cuenta de gestión (solo facturación y administración de la organización)
- OU: Seguridad → Cuenta de registros, auditoría (CloudTrail, Config, GuardDuty)
- OU: Servicios Compartidos → Red compartida, DNS, Transit Gateway, bastión
- OU: Cargas de trabajo / Dev → Cuenta SAP DEV
- OU: Cargas de trabajo / QAS → Cuenta SAP QAS (futura)
- OU: Cargas de trabajo / Prod → Cuenta SAP PRD (futura)
- OU: Sandbox → Experimentación libre
aws organizations create-organization --feature-set ALL
aws organizations create-organizational-unit \
--parent-id r-xxxx --name "Seguridad"
aws organizations create-organizational-unit \
--parent-id r-xxxx --name "Cargas-de-trabajo"
aws organizations create-organizational-unit \
--parent-id ou-cargas --name "Dev"
SCPs (Políticas de Control de Servicio) básicas:
- Denegar regiones no autorizadas (solo habilitar la región destino, ej: us-east-1 o sa-east-1)
- Denegar desactivación de CloudTrail
- Denegar creación de usuarios IAM con acceso de consola (forzar SSO)
💡 Si no se necesita la complejidad total de Organizations desde el inicio, se puede empezar con una sola cuenta para DEV y migrar a multi-cuenta después. Pero diseñar la estructura ahora evita deuda técnica masiva.
AWS Organizations
SAP en AWS Landing Zone
Mejores prácticas SCP
Asegurar la cuenta raíz y establecer el marco de identidad y acceso.
- Cuenta raíz: MFA de hardware (YubiKey recomendado), NO crear claves de acceso
- IAM Identity Center (SSO): Configurar como fuente de identidad centralizada
- Conjuntos de permisos: AdministratorAccess (acceso de emergencia), PowerUserAccess, ReadOnlyAccess, conjuntos personalizados para SAP
- Procedimiento de emergencia: Documentar acceso de emergencia con cuenta raíz
# Verificar MFA en cuenta raíz
aws iam get-account-summary --query 'SummaryMap.AccountMFAEnabled'
# Crear alias de cuenta
aws iam create-account-alias --account-alias empresa-aws-dev
# Habilitar IAM Identity Center
aws sso-admin list-instances # verificar si está habilitado
⚠️ NUNCA crear claves de acceso para la cuenta raíz. Si ya existen, eliminarlas inmediatamente.
IAM Identity Center
Mejores prácticas IAM
Tokens MFA de hardware
Control Tower automatiza la creación de la zona de aterrizaje con barreras de protección preconfiguradas. Configura automáticamente CloudTrail, Config, y la estructura de cuentas con buenas prácticas.
- Crea cuentas de archivo de registros y auditoría automáticamente
- Configura barreras de protección (preventivas y detectivas)
- Fábrica de cuentas para crear cuentas nuevas de forma estandarizada
¿Cuándo NO usar Control Tower? Si solo se tendrá 1-2 cuentas y la organización es pequeña, puede ser sobrecarga innecesaria. Pero si se planea multi-cuenta (como este caso con DEV/QAS/PRD), es altamente recomendado.
💡 Compatible con la migración: Control Tower facilita agregar las cuentas QAS y PRD más adelante de forma estandarizada.
AWS Control Tower
Diseño de zona de aterrizaje
Referencia de barreras
Activar registros desde el día 0. Sin registros, no hay seguridad ni diagnóstico de problemas.
- CloudTrail: Registro organizacional → bucket S3 en cuenta de Seguridad (encriptado con KMS)
- AWS Config: Activar en todas las cuentas, reglas de cumplimiento básicas
- GuardDuty: Activar como administrador delegado desde la cuenta de Seguridad
- VPC Flow Logs: Se activan en Fase 1 junto con la VPC
# CloudTrail organizacional
aws cloudtrail create-trail \
--name org-trail \
--s3-bucket-name empresa-cloudtrail-logs \
--is-organization-trail \
--is-multi-region-trail \
--enable-log-file-validation \
--kms-key-id arn:aws:kms:region:account:key/key-id
aws cloudtrail start-logging --name org-trail
# Activar GuardDuty
aws guardduty create-detector --enable
CloudTrail organizacional
Reglas AWS Config
Configuración GuardDuty
Configurar alertas de costos ANTES de desplegar infraestructura. Evitar sorpresas en la factura.
- AWS Budgets: Presupuesto mensual con alertas al 50%, 80%, 100%
- Etiquetas de asignación de costos: Definir etiquetas obligatorias:
Environment(dev/qas/prd),Project(sap-migration),CostCenter,Owner - Cost Explorer: Activar y revisar semanalmente
- Savings Plans: NO comprar aún — primero entender el consumo real en DEV
# Crear presupuesto de alerta
aws budgets create-budget \
--account-id 123456789012 \
--budget '{
"BudgetName": "Presupuesto-Mensual-Dev",
"BudgetLimit": {"Amount": "500", "Unit": "USD"},
"TimeUnit": "MONTHLY",
"BudgetType": "COST"
}' \
--notifications-with-subscribers '[{
"Notification": {
"NotificationType": "ACTUAL",
"ComparisonOperator": "GREATER_THAN",
"Threshold": 80
},
"Subscribers": [{
"SubscriptionType": "EMAIL",
"Address": "infra@empresa.com"
}]
}]'
💡 El ambiente DEV de SAP en instancias r6i.xlarge + almacenamiento gp3 debería costar aproximadamente $300-600 USD/mes (depende de región y horas de uso). Apagar instancias DEV fuera de horario laboral puede ahorrar ~60%.
AWS Budgets
Etiquetas de asignación de costos
Optimización de costos SAP en AWS
La región AWS impacta latencia, costos, disponibilidad de instancias certificadas para SAP, y cumplimiento normativo.
- Factores clave: Latencia hacia on-premises, disponibilidad de instancias x2idn/u-series para HANA PRD, costo por región, requisitos de residencia de datos
- Opciones típicas para LATAM: us-east-1 (Virginia — más servicios, más barato), sa-east-1 (São Paulo — menor latencia a Sudamérica)
- Verificar que las instancias certificadas SAP estén disponibles en la región elegida
# Verificar disponibilidad de instancias SAP en una región
aws ec2 describe-instance-type-offerings \
--location-type availability-zone \
--filters Name=instance-type,Values=r6i.xlarge,x2idn.16xlarge \
--region us-east-1 \
--query 'InstanceTypeOfferings[].{Type:InstanceType,AZ:Location}'
⚠️ Elegir la región ahora y mantenerla. Cambiar de región después de desplegar es esencialmente empezar de cero.
Instancias certificadas SAP en AWS
Selección de región AWS
SAP Note 1656099
🎯 Resultado Fase 0: Cuenta AWS segura, gobernada, con registros, alertas de costo y estructura lista para recibir cargas de trabajo.
1
Redes DEV — VPC, VPN y Conectividad DEV
Construir la red que conecta AWS con on-premises y Azure. Sin red, no hay nada.
VPC 10.10.0.0/16 con subnets segregadas por función y distribuidas en 2 AZs para preparar la arquitectura que se replicará en QAS y PRD.
- pública-a/b: NAT Gateway, bastión (si aplica), ALB
- app-a/b: Servidores de aplicación SAP, WebDispatcher
- db-a/b: SAP HANA DB (subnet dedicada para aislamiento)
- gestión-a: Gestión, monitoreo, acceso administrativo
- ad-a/b: Active Directory (Multi-AZ requerido por Managed AD)
# Crear VPC
aws ec2 create-vpc --cidr-block 10.10.0.0/16 \
--tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=vpc-sap-dev},{Key=Environment,Value=dev}]'
# Habilitar DNS
aws ec2 modify-vpc-attribute --vpc-id vpc-xxx --enable-dns-support
aws ec2 modify-vpc-attribute --vpc-id vpc-xxx --enable-dns-hostnames
# Crear subnets (ejemplo AZ-a)
aws ec2 create-subnet --vpc-id vpc-xxx --cidr-block 10.10.0.0/24 \
--availability-zone us-east-1a \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=sn-publica-dev-a}]'
aws ec2 create-subnet --vpc-id vpc-xxx --cidr-block 10.10.1.0/24 \
--availability-zone us-east-1a \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=sn-app-dev-a}]'
aws ec2 create-subnet --vpc-id vpc-xxx --cidr-block 10.10.2.0/24 \
--availability-zone us-east-1a \
--tag-specifications 'ResourceType=subnet,Tags=[{Key=Name,Value=sn-db-dev-a}]'
💡 Aunque DEV no necesita HA multi-AZ, crear la estructura en 2 AZs desde ahora asegura que el diseño sea replicable a PRD sin cambios. Coherencia > perfección.
Diseño de VPC
Redes SAP en AWS
Dimensionamiento de subnets
Configurar el enrutamiento: subnets públicas con IGW, subnets privadas con NAT GW para salida a internet (actualizaciones de SO, descargas SAP).
- IGW: Adjuntar a la VPC
- NAT Gateway: En subnet pública, IP elástica asignada. Para DEV un solo NAT GW es suficiente.
- Tablas de rutas: Pública (0.0.0.0/0 → IGW), Privada (0.0.0.0/0 → NAT GW)
# Internet Gateway
aws ec2 create-internet-gateway --tag-specifications 'ResourceType=internet-gateway,Tags=[{Key=Name,Value=igw-dev}]'
aws ec2 attach-internet-gateway --internet-gateway-id igw-xxx --vpc-id vpc-xxx
# IP elástica + NAT Gateway
aws ec2 allocate-address --domain vpc --tag-specifications 'ResourceType=elastic-ip,Tags=[{Key=Name,Value=eip-natgw-dev}]'
aws ec2 create-nat-gateway --subnet-id sn-publica-a --allocation-id eipalloc-xxx
# Tabla de rutas privada
aws ec2 create-route-table --vpc-id vpc-xxx --tag-specifications 'ResourceType=route-table,Tags=[{Key=Name,Value=rt-privada-dev}]'
aws ec2 create-route --route-table-id rtb-xxx --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-xxx
💡 El NAT Gateway cuesta ~$32 USD/mes + transferencia de datos. Para DEV, considerar apagarlo fuera de horario o usar instancias NAT (más barato pero menos confiable).
NAT Gateway
Tablas de rutas
Paso crítico. Establecer el túnel VPN IPSec entre el WatchGuard M390 on-premises y AWS. Esta es la arteria principal de comunicación.
Lado AWS:
- Crear Virtual Private Gateway (VGW) y adjuntar a VPC DEV (o Transit Gateway si se planea multi-VPC)
- Crear Customer Gateway con la IP pública del WatchGuard M390
- Crear conexión VPN (2 túneles por redundancia)
# Opción A: VGW (más simple para empezar con DEV)
aws ec2 create-vpn-gateway --type ipsec.1 --tag-specifications 'ResourceType=vpn-gateway,Tags=[{Key=Name,Value=vgw-dev}]'
aws ec2 attach-vpn-gateway --vpn-gateway-id vgw-xxx --vpc-id vpc-xxx
# Customer Gateway (IP pública del M390)
aws ec2 create-customer-gateway \
--type ipsec.1 \
--public-ip 203.0.113.1 \
--bgp-asn 65000 \
--tag-specifications 'ResourceType=customer-gateway,Tags=[{Key=Name,Value=cgw-watchguard-m390}]'
# Conexión VPN
aws ec2 create-vpn-connection \
--type ipsec.1 \
--customer-gateway-id cgw-xxx \
--vpn-gateway-id vgw-xxx \
--options '{"StaticRoutesOnly":true}' \
--tag-specifications 'ResourceType=vpn-connection,Tags=[{Key=Name,Value=vpn-onprem-dev}]'
# Descargar configuración (formato genérico)
aws ec2 describe-vpn-connections --vpn-connection-ids vpn-xxx
Lado WatchGuard M390 (Fireware):
- VPN → Branch Office VPN → BOVPN Manual
- Gateway: IP remota = IPs de los 2 túneles AWS, ID local = IP pública del M390
- Fase 1: IKEv2, AES-256-CBC, SHA-256, Grupo DH 14 (2048-bit) o superior, Tiempo de vida 28800s
- Fase 2: ESP, AES-256-CBC, SHA-256, PFS Grupo DH 14, Tiempo de vida 3600s
- Túnel: Red local = 10.0.0.0/16 (on-prem), Red remota = 10.10.0.0/16 (VPC DEV)
⚠️ AWS genera 2 túneles por conexión VPN (redundancia). Configurar AMBOS en el M390. Si solo se configura 1, la conmutación por error no funciona. La clave precompartida es diferente para cada túnel.
💡 Si planeas conectar múltiples VPCs (DEV + QAS + PRD), considera usar Transit Gateway desde el inicio en lugar de VGW. El TGW actúa como concentrador central y evita tener una VPN por VPC.
AWS VPN S2S
WatchGuard BOVPN hacia AWS
Parámetros IKEv2
Transit Gateway VPN
El Transit Gateway es el punto central de enrutamiento entre todas las VPCs y las conexiones VPN. Aunque solo tengamos DEV ahora, desplegarlo ya prepara la infraestructura para QAS y PRD sin rediseño.
- Crear TGW en la cuenta de Servicios Compartidos o Red
- Adjuntar VPC DEV al TGW
- Adjuntar la VPN al TGW (en lugar de VGW)
- Tablas de rutas del TGW: separar enrutamiento por ambiente
# Crear Transit Gateway
aws ec2 create-transit-gateway \
--description "TGW central - Migración SAP" \
--options '{
"AmazonSideAsn": 64512,
"AutoAcceptSharedAttachments": "disable",
"DefaultRouteTableAssociation": "enable",
"DefaultRouteTablePropagation": "enable",
"DnsSupport": "enable",
"VpnEcmpSupport": "enable"
}' \
--tag-specifications 'ResourceType=transit-gateway,Tags=[{Key=Name,Value=tgw-central}]'
# Adjuntar VPC DEV
aws ec2 create-transit-gateway-vpc-attachment \
--transit-gateway-id tgw-xxx \
--vpc-id vpc-dev-xxx \
--subnet-ids sn-app-a sn-app-b
💡 TGW cuesta ~$36 USD/mes por adjunto + $0.02/GB procesado. Con 2 adjuntos (VPC + VPN), el costo fijo es ~$72/mes. Vale la pena para evitar rediseño.
Transit Gateway
Tablas de rutas TGW
TGW + VPN
Crear Security Groups con principio de mínimo privilegio para cada componente SAP.
- sg-sap-hana: TCP 30013,30015,30017 (HANA) desde sg-sap-app; TCP 22 desde sg-gestion
- sg-sap-app: TCP 3200-3299 (Diálogo), 3300-3399 (Gateway), 3600 (Message Server), 8000-8443 (ICM/HTTP) desde sg-webdisp; TCP 22 desde sg-gestion
- sg-webdisp: TCP 443,8443 desde on-prem (10.0.0.0/16); TCP 22 desde sg-gestion
- sg-ad: TCP/UDP 389,636,88,445,135,3268,3269,49152-65535; ICMP; desde CIDR de VPC
- sg-gestion: TCP 22 desde on-prem; TCP 3389 (si Windows) desde on-prem
# SG para HANA
aws ec2 create-security-group --group-name sg-sap-hana-dev \
--description "SAP HANA DB - DEV" --vpc-id vpc-xxx
# Regla: HANA desde servidores de aplicación
aws ec2 authorize-security-group-ingress \
--group-id sg-hana-xxx \
--protocol tcp --port 30013-30017 \
--source-group sg-app-xxx
# Regla: SSH desde gestión
aws ec2 authorize-security-group-ingress \
--group-id sg-hana-xxx \
--protocol tcp --port 22 \
--source-group sg-gestion-xxx
⚠️ Referencia de puertos SAP HANA: 3<instancia>13 (SQL/MDX), 3<instancia>15 (indexserver), 3<instancia>17 (XSA). Para instancia 00: 30013, 30015, 30017. Para instancia 02: 30213, 30215, 30217. Confirmar tu número de instancia.
Security Groups
Puertos SAP TCP/IP
SAP Note 2477204
Si SAP DEV en AWS necesita comunicarse con servicios en Azure (ej: durante copia de sistema), hay varias opciones:
- Opción A — Rebote por on-prem: Tráfico AWS → VPN → M390 → VPN → Azure. Simple, usa lo existente, pero duplica latencia y consume ancho de banda del M390.
- Opción B — VPN Azure ↔ AWS directa: VPN S2S entre Azure VPN GW y AWS TGW. Mejor rendimiento, más complejo.
- Opción C — Sin conexión directa: Para DEV, hacer copia de sistema vía respaldo/restauración (S3/Blob) sin necesidad de conexión en tiempo real.
Recomendación para DEV: Opción C (respaldo/restauración) o Opción A (rebote) si se necesita conectividad puntual. No invertir en VPN directa Azure↔AWS hasta que se confirme la necesidad.
💡 Compatible con migración: La opción C es la más limpia porque no crea dependencias de red entre nubes. Para PRD, se evaluará HANA System Replication entre nubes que sí requiere conectividad directa.
VPN Azure-AWS
Migración SAP por respaldo/restauración
Configurar resolución DNS entre AWS, on-premises y (opcionalmente) Azure.
- Zona alojada privada:
dev.aws.empresa.localasociada a VPC DEV - Endpoints de resolución Route 53: Entrante (on-prem → AWS) y Saliente (AWS → on-prem)
- Reglas de reenvío:
empresa.local→ DNS on-prem;ad.empresa.local→ AD en AWS
# Zona alojada privada
aws route53 create-hosted-zone \
--name dev.aws.empresa.local \
--vpc VPCRegion=us-east-1,VPCId=vpc-xxx \
--caller-reference "dev-$(date +%s)" \
--hosted-zone-config PrivateZone=true
# Endpoint de resolución entrante (on-prem consulta a AWS)
aws route53resolver create-resolver-endpoint \
--creator-request-id "entrante-dev" \
--name "resolver-entrante-dev" \
--security-group-ids sg-dns-xxx \
--direction INBOUND \
--ip-addresses SubnetId=sn-gestion-a,Ip=10.10.3.10 SubnetId=sn-gestion-b,Ip=10.10.13.10
Zonas privadas Route 53
Endpoints de resolución
DNS híbrido
Activar registros de flujo para diagnóstico y seguridad, luego validar toda la conectividad de extremo a extremo.
# VPC Flow Logs a CloudWatch
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-xxx \
--traffic-type ALL \
--log-destination-type cloud-watch-logs \
--log-group-name /vpc/flow-logs/dev \
--deliver-logs-permission-arn arn:aws:iam::role/VPCFlowLogRole
Lista de verificación de validación:
- ☐ Ping desde on-prem (10.0.x.x) a una EC2 de prueba en VPC DEV (10.10.x.x)
- ☐ Ping desde EC2 DEV hacia on-prem
- ☐ Resolución DNS bidireccional
- ☐ Traceroute para verificar ruta (debe pasar por VPN)
- ☐ Verificar estado VPN en consola AWS y WatchGuard Traffic Monitor
- ☐ Medir latencia de referencia (ping -c 100)
VPC Flow Logs
Diagnóstico de VPN
🎯 Resultado Fase 1: Red AWS DEV conectada a on-premises vía VPN, con DNS funcional, Security Groups configurados y conectividad validada de extremo a extremo.
2
Active Directory DEV DEV
Desplegar el servicio de directorio que autenticará usuarios y servicios en AWS.
Decisión clave que impacta costo, control y complejidad.
| Criterio | AWS Managed AD | AD en EC2 |
|---|---|---|
| Gestión | AWS gestiona DCs, parches, replicación | Tú gestionas todo |
| Control | Limitado (sin acceso al SO del DC) | Control total |
| HA | Multi-AZ automático | Manual (2 EC2 en distintas AZ) |
| Extensiones de esquema | Sí (SAP puede requerirlas) | Sí (control total) |
| Costo (Estándar) | ~$87 USD/mes | ~$60-80 USD/mes (2× t3.medium) |
| Costo (Empresarial) | ~$290 USD/mes | Mismo (depende de instancia) |
| Confianza con on-prem | Confianza de bosque soportada | Cualquier tipo de confianza |
| Integración AWS | Nativa (WorkSpaces, RDS, FSx, etc.) | Manual (AD Connector o config) |
Recomendación: Para la mayoría de casos SAP, AWS Managed Microsoft AD (Edición Estándar) es suficiente para DEV. Si se requiere control absoluto sobre el DC o GPOs avanzadas, AD en EC2.
💡 Compatible con migración: Managed AD se puede compartir entre VPCs (DEV, QAS, PRD) usando VPC compartida o AD multi-VPC. No hay dependencia — se puede migrar a AD en EC2 si se necesita después.
AWS Managed AD
Mejores prácticas AD en EC2
AD para SAP en AWS
Despliegue en las subnets AD (10.10.4.0/24 y 10.10.14.0/24 si multi-AZ).
# AWS Managed AD (Estándar)
aws ds create-microsoft-ad \
--name ad.empresa.local \
--short-name EMPRESA \
--password 'C0mplexP@ssw0rd!' \
--edition Standard \
--vpc-settings VpcId=vpc-xxx,SubnetIds=sn-ad-a,sn-ad-b \
--tags Key=Environment,Value=dev Key=Project,Value=sap-migration
# Verificar estado (tarda ~30 min)
aws ds describe-directories --query 'DirectoryDescriptions[].{Id:DirectoryId,Name:Name,Status:Stage}'
Para AD en EC2 (alternativa):
- 2× EC2 t3.medium (Windows Server 2022) en AZ-a y AZ-b
- Instalar rol AD DS, promover a controladores de dominio
- Configurar Sites & Services con las subnets de AWS
⚠️ La contraseña del administrador de Managed AD solo se muestra una vez. Guardarla en AWS Secrets Manager inmediatamente.
Crear Managed AD
AD DS en EC2
Si existe un AD on-premises, crear una relación de confianza para que los usuarios corporativos puedan autenticarse en AWS.
- Prerequisitos: VPN funcional (Fase 1.3), resolución DNS bidireccional, puertos AD abiertos en WatchGuard M390 y Security Groups
- Tipo de confianza: Confianza de bosque (bidireccional) es lo más flexible
- Puertos requeridos en firewall: TCP/UDP 53 (DNS), 88 (Kerberos), 135 (RPC), 389 (LDAP), 445 (SMB), 636 (LDAPS), 3268-3269 (GC), 49152-65535 (RPC dinámico)
# Crear reenviador condicional en AWS AD (hacia DNS on-prem)
aws ds create-conditional-forwarder \
--directory-id d-xxx \
--remote-domain-name onprem.empresa.local \
--dns-ip-addrs 10.0.2.10 10.0.2.11
# Crear confianza
aws ds create-trust \
--directory-id d-xxx \
--remote-domain-name onprem.empresa.local \
--trust-password 'TrustP@ssw0rd!' \
--trust-direction Two-Way \
--trust-type Forest
En WatchGuard M390: Crear política de firewall que permita tráfico AD entre on-prem (10.0.0.0/16) y subnets AD de AWS (10.10.4.0/24) para los puertos listados.
Confianza AD con Managed AD
Puertos AD
Políticas WatchGuard BOVPN
Asegurar que las VMs en AWS resuelvan nombres del dominio AD, y que AD resuelva nombres en Route 53.
- Conjunto de opciones DHCP de la VPC apuntando a los DCs de Managed AD como servidores DNS
- Regla de salida del resolvedor Route 53 para
ad.empresa.local→ IPs de los DCs
# Conjunto de opciones DHCP con DNS de AD
aws ec2 create-dhcp-options \
--dhcp-configurations Key=domain-name-servers,Values=10.10.4.10,10.10.14.10 \
Key=domain-name,Values=ad.empresa.local
aws ec2 associate-dhcp-options --dhcp-options-id dopt-xxx --vpc-id vpc-xxx
Conjuntos de opciones DHCP
DNS con Managed AD
Probar el Active Directory de extremo a extremo antes de desplegar SAP.
- ☐ Crear EC2 de prueba (Windows + Linux)
- ☐ Unión al dominio Windows: verificar en AD que aparece el objeto de equipo
- ☐ Unión al dominio Linux (SSSD/realmd):
realm join ad.empresa.local - ☐ Verificar autenticación con usuario del dominio
- ☐ Verificar que GPOs se aplican (si Windows)
- ☐ Probar confianza: autenticarse con usuario del dominio on-prem desde EC2 en AWS
- ☐ Verificar resolución DNS:
nslookup ad.empresa.localynslookup onprem.empresa.local
# Unión al dominio Linux (SLES)
sudo zypper install -y realmd sssd adcli samba-client
sudo realm discover ad.empresa.local
sudo realm join -U admin@AD.EMPRESA.LOCAL ad.empresa.local
sudo realm list
id admin@ad.empresa.local
Unir Linux a AD
Configuración SSSD
Diagnóstico de unión al dominio
🎯 Resultado Fase 2: Active Directory operativo en AWS DEV, con confianza hacia on-premises, DNS integrado y unión al dominio validada.
3
Cómputo y Almacenamiento DEV DEV
Preparar la infraestructura de cómputo y almacenamiento para SAP.
Preparar los componentes base para lanzar instancias SAP.
- Par de claves: Crear o importar par de claves SSH para acceso a instancias SLES
- AMI: Usar SLES for SAP del AWS Marketplace (incluye parámetros de kernel y paquetes específicos para SAP)
- Perfil de instancia IAM: Rol EC2 con permisos para CloudWatch, S3 (respaldos), SSM
# Par de claves
aws ec2 create-key-pair --key-name kp-sap-dev --query 'KeyMaterial' --output text > kp-sap-dev.pem
chmod 400 kp-sap-dev.pem
# Buscar AMI SLES for SAP más reciente
aws ec2 describe-images \
--owners amazon \
--filters "Name=name,Values=suse-sles-sap-15-sp5*" "Name=architecture,Values=x86_64" \
--query 'sort_by(Images, &CreationDate)[-1].{Name:Name,Id:ImageId,Date:CreationDate}'
# Rol IAM para EC2 SAP
aws iam create-role --role-name EC2-SAP-Dev-Role \
--assume-role-policy-document '{
"Version":"2012-10-17",
"Statement":[{"Effect":"Allow","Principal":{"Service":"ec2.amazonaws.com"},"Action":"sts:AssumeRole"}]
}'
aws iam attach-role-policy --role-name EC2-SAP-Dev-Role \
--policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
aws iam attach-role-policy --role-name EC2-SAP-Dev-Role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
SLES for SAP en AWS
Roles IAM para EC2
SAP Note 1656099
Instancia optimizada en memoria para la base de datos HANA.
- Instancia recomendada DEV:
r6i.xlarge(4 vCPU, 32 GB RAM) — suficiente para HANA DEV con carga mínima - Alternativa mayor:
r6i.2xlarge(8 vCPU, 64 GB) si el conjunto de datos DEV es significativo - Ubicación: subnet-db-a (10.10.2.0/24)
- Volúmenes EBS para HANA:
| Montaje | Tipo EBS | Tamaño DEV | IOPS | Rendimiento |
|---|---|---|---|---|
| /hana/data | gp3 | 100 GB | 3000 (por defecto) | 125 MB/s |
| /hana/log | gp3 | 50 GB | 3000 | 125 MB/s |
| /hana/shared | gp3 | 100 GB | 3000 | 125 MB/s |
| /usr/sap | gp3 | 50 GB | 3000 | 125 MB/s |
| /backup | gp3 | 200 GB | 3000 | 125 MB/s |
| / (raíz) | gp3 | 50 GB | 3000 | 125 MB/s |
# Lanzar instancia HANA
aws ec2 run-instances \
--image-id ami-xxxxxxxxx \
--instance-type r6i.xlarge \
--key-name kp-sap-dev \
--subnet-id sn-db-dev-a \
--security-group-ids sg-sap-hana-dev \
--iam-instance-profile Name=EC2-SAP-Dev-Profile \
--block-device-mappings '[
{"DeviceName":"/dev/sda1","Ebs":{"VolumeSize":50,"VolumeType":"gp3"}},
{"DeviceName":"/dev/sdf","Ebs":{"VolumeSize":100,"VolumeType":"gp3","DeleteOnTermination":false}},
{"DeviceName":"/dev/sdg","Ebs":{"VolumeSize":50,"VolumeType":"gp3","DeleteOnTermination":false}},
{"DeviceName":"/dev/sdh","Ebs":{"VolumeSize":100,"VolumeType":"gp3","DeleteOnTermination":false}},
{"DeviceName":"/dev/sdi","Ebs":{"VolumeSize":50,"VolumeType":"gp3","DeleteOnTermination":false}},
{"DeviceName":"/dev/sdj","Ebs":{"VolumeSize":200,"VolumeType":"gp3","DeleteOnTermination":false}}
]' \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=sap-hana-dev},{Key=Environment,Value=dev},{Key=Component,Value=hana-db}]'
💡 gp3 es suficiente para DEV (~$0.08/GB/mes). Para PRD, se evaluará io2 Block Express para /hana/log (latencia sub-milisegundo, crítico para el rendimiento de escritura de HANA).
Almacenamiento SAP HANA en AWS
Tipos de volúmenes EBS
SAP Note 1943937
Instancias para el servidor de aplicación (ASCS + PAS) y WebDispatcher.
- Servidor de aplicación (PAS + ASCS combinado para DEV):
r6i.large(2 vCPU, 16 GB). En DEV se pueden combinar ASCS + PAS en una sola instancia. - WebDispatcher:
t3.small(2 vCPU, 2 GB). Liviano para DEV. - Ubicación: subnet-app-a (10.10.1.0/24)
💡 En PRD, ASCS y PAS estarán en instancias separadas con clúster HA (ASCS/ERS). Para DEV, combinar reduce costo sin impacto funcional.
Dimensionamiento de servidor de aplicación SAP
WebDispatcher en AWS
Almacenamiento de objetos para respaldos, directorio de transportes SAP y media de instalación.
empresa-sap-respaldos-dev— Respaldos HANA (Backint o basados en archivo), instantáneas EBSempresa-sap-media— Media de instalación SAP (SWPM, kernel, instalador HANA)empresa-sap-transportes-dev— Archivos de transporte si se comparten entre sistemas
# Bucket de respaldos con ciclo de vida
aws s3api create-bucket --bucket empresa-sap-respaldos-dev \
--region us-east-1
aws s3api put-bucket-encryption --bucket empresa-sap-respaldos-dev \
--server-side-encryption-configuration '{
"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms"}}]
}'
# Ciclo de vida: mover a Glacier después de 30 días
aws s3api put-bucket-lifecycle-configuration --bucket empresa-sap-respaldos-dev \
--lifecycle-configuration '{
"Rules":[{
"ID":"Mover-a-Glacier",
"Status":"Enabled",
"Transitions":[{"Days":30,"StorageClass":"GLACIER"}],
"Filter":{"Prefix":"hana-backup/"}
}]
}'
Ciclo de vida S3
SAP HANA Backint para S3
Encriptación S3
Configurar respaldo automatizado de las instancias SAP DEV.
- Plan de AWS Backup: Respaldo diario de volúmenes EBS, retención 7 días para DEV
- Bóveda: Bóveda encriptada con KMS
- Basado en etiquetas: Respaldar todo recurso con etiqueta
Backup=daily
# Crear bóveda de respaldos
aws backup create-backup-vault --backup-vault-name sap-dev-vault
# Crear plan de respaldo (JSON simplificado)
aws backup create-backup-plan --backup-plan '{
"BackupPlanName": "SAP-Dev-Diario",
"Rules": [{
"RuleName": "RespaldoDiario",
"TargetBackupVaultName": "sap-dev-vault",
"ScheduleExpression": "cron(0 3 * * ? *)",
"StartWindowMinutes": 60,
"CompletionWindowMinutes": 180,
"Lifecycle": {"DeleteAfterDays": 7}
}]
}'
AWS Backup
Instantáneas EBS
Respaldo para SAP
🎯 Resultado Fase 3: Infraestructura de cómputo y almacenamiento lista para instalar SAP. Instancias creadas, volúmenes configurados, respaldos automáticos activos.
4
SAP S/4HANA DEV en AWS DEV
Instalar y configurar el primer sistema SAP en AWS. El momento de la verdad.
Configurar el sistema operativo según los requisitos SAP antes de la instalación.
- Registrar SLES con SUSEConnect (licencia SAP incluida en AMI del AWS Marketplace)
- Montar volúmenes EBS en los puntos de montaje SAP
- Ajustar parámetros de kernel según SAP Notes
- Instalar paquetes requeridos
# Montar volúmenes EBS (ejemplo)
mkfs.xfs /dev/nvme1n1 # /hana/data
mkfs.xfs /dev/nvme2n1 # /hana/log
mkfs.xfs /dev/nvme3n1 # /hana/shared
mkdir -p /hana/{data,log,shared} /usr/sap /backup
# Agregar a /etc/fstab con UUID
# Paquetes necesarios
zypper install -y \
sapconf saptune \
libatomic1 libnuma1 \
insserv-compat \
tuned
# Aplicar perfil SAP
saptune solution apply HANA
saptune service enable
saptune service start
# Verificar
saptune solution verify HANA
⚠️ Ejecutar
saptune solution verify HANA ANTES de instalar SAP. Cada parámetro no conforme puede causar problemas de rendimiento difíciles de diagnosticar después.
SAP Note 2205917 (ajuste SLES)
saptune
Preparación SO SAP en AWS
Instalar la base de datos SAP HANA usando hdblcm (HANA Database Lifecycle Manager).
- Copiar media HANA desde S3 al servidor
- Ejecutar hdblcm con los parámetros adecuados
- SID y número de instancia deben coincidir con el sistema origen (si es copia de sistema) o ser nuevos (instalación limpia)
# Copiar media desde S3
aws s3 cp s3://empresa-sap-media/HANA/ /tmp/hana-media/ --recursive
# Instalar HANA (interactivo)
cd /tmp/hana-media/DATA_UNITS/HDB_LCM_LINUX_X86_64
./hdblcm --action=install
# O no-interactivo:
./hdblcm --action=install \
--components=server \
--sid=HDB \
--number=00 \
--sapadm_password=XXXXXX \
--system_user_password=XXXXXX \
--datapath=/hana/data/HDB \
--logpath=/hana/log/HDB
# Verificar
su - hdbadm
HDB info
hdbsql -i 00 -u SYSTEM -p XXXXX "SELECT VERSION FROM SYS.M_DATABASE"
Guía de instalación SAP HANA
Referencia hdblcm
SAP Note 2235581
Instalar los componentes de la capa de aplicación usando SAP Software Provisioning Manager (SWPM).
- ASCS (ABAP Central Services): Message Server + Enqueue Server. Instalar primero.
- Instancia de base de datos: Cargar el esquema en HANA (si es instalación limpia con SWPM)
- PAS (Primary Application Server): Instalar después de la carga de BD
- Para DEV, ASCS y PAS pueden ir en la misma instancia EC2
# Ejecutar SWPM
cd /tmp/sap-media/SWPM
./sapinst SAPINST_HTTPS_PORT=4237
# Acceder al asistente vía navegador (túnel SSH)
# https://localhost:4237/sapinst/docs/index.html
# Post-instalación — verificar
su - <sid>adm
sapcontrol -nr 00 -function GetProcessList
sapcontrol -nr 01 -function GetProcessList
💡 AWS Launch Wizard for SAP puede automatizar toda esta instalación (HANA + servidor de aplicación) con una interfaz guiada. Vale la pena evaluarlo para reducir errores manuales:
Consola AWS → Launch Wizard → SAP
Guía SWPM
AWS Launch Wizard for SAP
SAP Note 2927211
Configurar los componentes de punto de entrada y conectividad SAP.
- WebDispatcher: Punto de entrada HTTP/HTTPS para Fiori, SAP GUI HTML, APIs. Termina SSL, distribuye carga.
- SAP Router: Túnel seguro hacia SAP SE para soporte remoto y notas. No exponerlo a internet.
💡 Para DEV, WebDispatcher y SAP Router pueden compartir una instancia t3.small. En PRD serán instancias dedicadas con HA.
Configuración WebDispatcher
Configuración SAP Router
SAP Note 48243
Dos opciones para poblar el sistema DEV en AWS:
- Opción A — Instalación limpia: Instalar SAP S/4HANA limpio con SWPM. Ideal si se quiere un DEV nuevo.
- Opción B — Copia de sistema (respaldo/restauración): Tomar respaldo HANA del DEV en Azure, transferir a AWS, restaurar. Mantiene datos y configuración.
Procedimiento de copia de sistema (Opción B):
- Respaldo completo de HANA en Azure DEV:
hdbsql → BACKUP DATA USING FILE - Subir respaldo a Azure Blob, copiar a S3 (usando azcopy + aws s3 cp, o directamente desde la VM)
- Descargar respaldo en EC2 AWS en /backup
- Restaurar con SWPM (Copia de sistema → Sistema destino → Basado en respaldo/restauración)
- Post-copia: cambiar hostname, licencia SAP temporal, reconfigurar RFCs, ajustar STMS
# En Azure DEV - respaldo HANA
hdbsql -i 00 -u SYSTEM -p XXXXX \
"BACKUP DATA USING FILE ('/backup/COMPLETE_DATA_BACKUP')"
# Transferir (ejemplo vía azcopy → S3)
azcopy copy '/backup/COMPLETE_DATA_BACKUP*' \
'https://storageaccount.blob.core.windows.net/hana-backup/'
aws s3 cp s3://empresa-sap-respaldos-dev/migracion/ /backup/ --recursive
# Restaurar con SWPM en AWS
./sapinst SAPINST_HTTPS_PORT=4237
# Seleccionar: System Copy → Target System → HANA → Based on Backup
⚠️ Después de una copia de sistema, la licencia SAP debe ser renovada (TCode SLICENSE). Solicitar licencia temporal a SAP inmediatamente. El sistema funciona 30 días sin licencia.
Guía de copia de sistema SAP
Respaldo/restauración HANA
SAP Note 2183363
Configurar AWS Backint Agent para que los respaldos de HANA vayan directamente a S3.
- AWS Backint Agent es gratuito y certificado por SAP
- Integra con hdbsql BACKUP/RECOVER y SAP HANA Cockpit
- Soporte para respaldo completo, incremental, diferencial y de registros de transacción
# Instalar AWS Backint Agent
aws s3 cp s3://awssap-backint-agent/aws-backint-agent-installer.tar.gz /tmp/
cd /tmp && tar xzf aws-backint-agent-installer.tar.gz
./install.sh --sid=HDB --bucket=empresa-sap-respaldos-dev --region=us-east-1
# Verificar
su - hdbadm
hdbsql -i 00 -u SYSTEM -p XXXXX "BACKUP DATA USING BACKINT ('/backint/FULL')"
aws s3 ls s3://empresa-sap-respaldos-dev/backint/ --recursive
AWS Backint Agent
SAP Note 2935898
Configuración HANA Backint
Validación funcional completa del sistema SAP DEV en AWS.
- ☐ Inicio de sesión SAP GUI exitoso (vía WebDispatcher o directo)
- ☐ Transacciones críticas: SM21 (registro del sistema), ST22 (volcados), SM50/SM66 (procesos), DB02 (espacio BD)
- ☐ SM51 — verificar instancias activas
- ☐ STMS — Sistema de gestión de transportes configurado
- ☐ Conexiones RFC funcionando (SM59)
- ☐ HANA Cockpit / HANA Studio accesible
- ☐ Respaldo HANA exitoso vía Backint a S3
- ☐ Restauración de prueba exitosa
- ☐ Línea base de rendimiento: ST06 (monitor SO), ST02 (buffers), ST04 (rendimiento BD)
- ☐ Acceso web Fiori Launchpad (si aplica)
Transacciones de monitoreo SAP
Verificaciones de salud HANA
🎯 Resultado Fase 4: SAP S/4HANA DEV completamente funcional en AWS. Primer sistema SAP en la nube destino — validación real de la arquitectura.
5
Seguridad y Monitoreo DEV DEV
Asegurar y observar el entorno. Lo que no se monitorea, no se gestiona.
Configurar observabilidad completa de las instancias SAP.
- CloudWatch Agent: Instalar en cada EC2 para métricas de SO (memoria, disco, swap) — EC2 nativo solo reporta CPU y red
- Registros: Enviar /var/log/messages, registros de rastreo HANA, syslog SAP a CloudWatch Logs
- Alarmas: CPU > 85% x 5min, Memoria > 90%, Disco > 80%, StatusCheckFailed
- Panel de control: Vista unificada de todos los componentes SAP
# Instalar CloudWatch Agent
sudo zypper install -y amazon-cloudwatch-agent
# O: sudo rpm -U https://s3.amazonaws.com/amazoncloudwatch-agent/suse/amd64/latest/amazon-cloudwatch-agent.rpm
# Configurar (asistente interactivo)
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
# Iniciar
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
-a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json
CloudWatch Agent
Application Insights para SAP
Alarmas CloudWatch
Servicio especializado de AWS para monitoreo SAP que detecta automáticamente componentes SAP y crea paneles preconfigurados.
- Detecta automáticamente HANA, ASCS, Diálogo, WebDispatcher
- Métricas específicas de SAP: memoria HANA, replicación, alertas
- Integración con SNS para notificaciones
💡 Application Insights es gratuito — solo se paga por los registros/métricas de CloudWatch subyacentes.
Application Insights para SAP
Monitoreo SAP en AWS
Auditar y endurecer la seguridad del entorno DEV.
- Security Hub: Activar con estándar AWS Foundational Security Best Practices
- Inspector: Escaneo de vulnerabilidades en las EC2
- Endurecimiento del SO: Deshabilitar SSH con root, fail2ban/sshguard, registros de auditoría
- Seguridad SAP: Cambiar contraseñas por defecto, revisar perfiles de autorización, desactivar usuarios SAP* y DDIC en mandante productivo
- Encriptación: EBS encriptado (KMS), S3 SSE-KMS, datos en tránsito (TLS)
Security Hub
Mejores prácticas de seguridad SAP
AWS Inspector
Gestión centralizada de encriptación y secretos.
- KMS: Clave gestionada por el cliente para EBS, S3, RDS. Rotación automática.
- Secrets Manager: Almacenar credenciales SAP, contraseña SYSTEM de HANA, contraseña de administrador AD. Rotación automática.
# Crear clave gestionada por el cliente
aws kms create-key --description "Clave de encriptación SAP DEV" \
--tags TagKey=Environment,TagValue=dev
# Guardar secreto en Secrets Manager
aws secretsmanager create-secret \
--name sap/dev/hana-system-password \
--secret-string '{"username":"SYSTEM","password":"XXXXXX"}' \
--kms-key-id alias/sap-dev-key
KMS
Secrets Manager
Un respaldo que no se ha probado restaurar no es un respaldo.
- ☐ Restaurar respaldo HANA Backint desde S3 en la misma instancia
- ☐ Restaurar instantánea EBS en un volumen nuevo y verificar datos
- ☐ Documentar RTO/RPO observados para DEV
- ☐ Verificar que las políticas de ciclo de vida de S3 funcionan (objetos se mueven a Glacier)
⚠️ Hacer esta prueba ANTES de pasar a Fase 6. En PRD, un fallo de restauración es una crisis. Descubrirlo en DEV es una lección valiosa.
Procedimientos de restauración HANA
Restauración de instantáneas EBS
🎯 Resultado Fase 5: Entorno DEV monitoreado, asegurado, con respaldos validados. Confianza real en la operación.
6
Control de Calidad — Validación DEV y decisión Avanzar/No Avanzar DEV
El punto de control formal antes de replicar a QAS. Se valida TODO.
Todo debe estar ✅ antes de proceder a QAS:
- ☐ VPN On-Prem ↔ AWS estable (disponibilidad > 99% en periodo de prueba)
- ☐ Latencia VPN aceptable (< 50ms para operación SAP)
- ☐ Active Directory funcional, unión al dominio exitosa, confianza con on-prem OK
- ☐ SAP HANA operativo, sin alertas en HANA Cockpit
- ☐ Servidor de aplicación SAP operativo, transacciones ejecutándose sin error
- ☐ WebDispatcher accesible desde on-prem
- ☐ Respaldos automáticos ejecutándose diariamente
- ☐ Restauración de respaldo validada exitosamente
- ☐ Monitoreo activo (paneles CloudWatch, alarmas configuradas)
- ☐ Security Hub sin hallazgos críticos
- ☐ Costos mensuales DEV dentro del presupuesto
- ☐ Documentación completa del despliegue
- ☐ Guías de operación básica documentadas
Documentar todo lo aprendido durante el despliegue DEV para mejorar el proceso en QAS/PRD.
- ¿Qué salió bien? (replicar)
- ¿Qué problemas surgieron? (prevenir)
- ¿Qué tomaría menos tiempo con IaC? (automatizar)
- ¿El dimensionamiento DEV fue adecuado? (ajustar para QAS)
- ¿La arquitectura de red necesita cambios? (refinar para QAS/PRD)
💡 Este es el momento ideal para empezar a codificar la infraestructura en Terraform/CloudFormation. Lo que se hizo manual en DEV, se automatiza para QAS y PRD.
Presentar resultados a las jefaturas para obtener aprobación para QAS.
- Entregables:
- 📄 Informe de validación DEV (lista de verificación completada)
- 📄 Reporte de costos reales vs presupuesto
- 📄 Lecciones aprendidas documentadas
- 📄 Plan de QAS con estimación de tiempo y costo
- 📄 Riesgos identificados y mitigaciones
💡 Consejo: Incluir capturas de pantalla de paneles CloudWatch y resultados de transacciones SAP como evidencia visual. Las jefaturas aman las métricas con gráficos.
🎯 Resultado Fase 6: Validación formal completada. Aprobación obtenida. Confianza del equipo y las jefaturas para avanzar a QAS.
7
Despliegue QAS en AWS QAS
Replicar la arquitectura validada en DEV. Ahora con lecciones aprendidas e idealmente con IaC.
Crear VPC QAS replicando el diseño de DEV (subnets, tablas de rutas, NACLs, Security Groups). Si se codificó en Terraform durante Fase 6.2, ejecutar terraform apply con nuevas variables.
- Adjuntar VPC QAS al Transit Gateway existente
- Actualizar tablas de rutas del TGW para incluir 10.20.0.0/16
- Actualizar políticas de VPN en WatchGuard M390 para incluir red QAS
TGW multi-VPC
Módulo Terraform VPC
Extender Active Directory para servir a la VPC QAS.
- Managed AD: Compartir directorio con VPC QAS:
aws ds share-directory - AD en EC2: Desplegar DCs réplica en subnets QAS, configurar Sites & Services
- Actualizar opciones DHCP de VPC QAS para apuntar a los DCs
Compartir Managed AD
AD Sites & Services
Instalar SAP QAS con dimensionamiento mayor que DEV para soportar pruebas de integración y pruebas de aceptación de usuario con datos reales.
- HANA:
r6i.4xlarge(16 vCPU, 128 GB) o según dimensionamiento SAP - Servidor de aplicación:
r6i.2xlarge(8 vCPU, 64 GB) - EBS: gp3 con IOPS/rendimiento ajustados si DEV mostró necesidad
- Copia de sistema desde Azure QAS o refresco desde Azure PRD
Configurar el sistema de transportes SAP entre DEV y QAS, ambos en AWS.
- STMS: Definir ruta de transporte DEV → QAS
- Conexiones RFC entre sistemas (SM59)
- Directorio de transportes compartido (EFS o NFS) o CTS+ (si es entre sistemas)
💡 Si QAS también reemplazará al QAS en Azure, la ruta de transportes completa será: DEV(AWS) → QAS(AWS) → PRD(Azure, temporalmente) → PRD(AWS, post-migración).
Configuración STMS
Gestión de transportes SAP
Pruebas de aceptación de usuario y pruebas de integración en QAS.
- Coordinar con equipos funcionales SAP para ejecutar escenarios de prueba
- Probar integraciones con sistemas on-premises (IDocs, RFCs, APIs)
- Probar rendimiento con carga simulada
- Validar conectividad desde todas las ubicaciones de usuarios
🎯 Resultado Fase 7: SAP QAS operativo en AWS, ruta de transportes configurada, pruebas de aceptación completadas. El paisaje SAP DEV+QAS está en AWS.
8
Preparación PRD en AWS PRD
El ambiente productivo. Aquí no hay margen de error. HA, DR, y dimensionamiento completo.
VPC PRD con redundancia completa en 2 AZs. Todas las subnets duplicadas, 2 NAT Gateways (uno por AZ).
⚠️ En PRD, un solo NAT Gateway no es aceptable. Si la AZ del NAT GW cae, todo el tráfico saliente de la otra AZ se pierde.
Diseño VPC con HA
Mejores prácticas Multi-AZ
Configuración de alta disponibilidad para HANA en PRD.
- HANA System Replication (HSR): Modo SYNC entre 2 nodos en AZs distintas
- Clúster Pacemaker: En SLES con sap_suse_cluster_connector
- Cercado (STONITH): Agente de cercado AWS — usa la API de EC2 para detener/iniciar instancias
- IP de superposición: IP virtual que "flota" entre nodos usando manipulación de tablas de rutas
- Instancias: x2idn.16xlarge, x2idn.24xlarge, o u-series según dimensionamiento (certificadas SAP)
⚠️ La configuración de HA de HANA en AWS es compleja y crítica. Seguir EXACTAMENTE la guía SAP on AWS HA de SUSE/AWS. Un error en el cercado puede causar cerebro dividido y corrupción de datos.
SAP HANA HA en AWS (SUSE)
Agente STONITH AWS
SAP Note 2309025
SUSE HA para SAP
Alta disponibilidad para ABAP Central Services.
- ASCS (enqueue) y ERS (replicación de enqueue) en instancias separadas, AZs distintas
- Clúster Pacemaker con ENSA2 (Enqueue Server 2)
- EFS para /sapmnt (compartido entre nodos)
ASCS/ERS HA en AWS
EFS para SAP
Configuración ENSA2
Dimensionamiento formal basado en datos reales del sistema Azure PRD actual.
- Ejecutar SAP Early Watch Alert / Quick Sizer con datos actuales
- Revisar SAPS, huella de memoria HANA, pico de IOPS
- Seleccionar instancia certificada AWS en Directorio de Hardware SAP HANA
- EBS: io2 Block Express para /hana/log (PRD requiere latencia sub-ms)
Directorio de Hardware SAP HANA
SAP Quick Sizer
Guía de dimensionamiento SAP en AWS
Definir la estrategia de recuperación ante desastres para SAP PRD.
- Opción 1 — Entre AZs (más simple): HSR síncrono entre AZs = HA. Respaldos a S3 con replicación entre regiones para DR.
- Opción 2 — Entre regiones (más robusto): HSR asíncrono a otra región. Mayor costo, mejor RPO para desastres regionales.
- Recomendación para la mayoría: Opción 1 para empezar. Replicación entre regiones de respaldos S3 cubre escenarios de pérdida de región.
DR SAP en AWS
Replicación S3 entre regiones
Modos HSR de HANA
🎯 Resultado Fase 8: Infraestructura PRD en AWS construida con HA completa, dimensionamiento adecuado y estrategia de DR definida. Lista para la migración.
9
Migración y Transición Productiva PRD
El día D. Migrar SAP producción de Azure a AWS. Minuto a minuto, sin margen de error.
NUNCA hacer la transición de PRD sin al menos un ensayo completo.
- Ejecutar el procedimiento completo de migración usando datos de QAS o copia de PRD
- Medir tiempo de cada paso: respaldo, transferencia, restauración, tareas post-copia
- Identificar cuellos de botella (transferencia de datos es usualmente el mayor)
- Probar procedimiento de reversión: ¿se puede volver a Azure PRD rápidamente?
- Documentar tiempos reales vs estimados
⚠️ El ensayo es la inversión más valiosa de todo el proyecto. Cada hora de ensayo ahorra 10 horas de crisis durante la transición real.
Ensayo de migración SAP
Planificación de transición
Plan detallado con tiempos, responsables y criterios de reversión.
- Pre-transición (semana anterior): Comunicación a usuarios, congelamiento de cambios SAP, respaldo completo verificado
- Estrategia de migración:
- Opción A: Respaldo/Restauración — Respaldo HANA en Azure, transferencia a S3, restauración en AWS. Tiempo de inactividad = tiempo de transferencia + restauración.
- Opción B: HSR entre nubes — HANA System Replication Azure→AWS (requiere conectividad directa). Minimiza inactividad = solo tiempo de cambio (~minutos).
- Opción C: SAP DMO (Database Migration Option) — Si se cambia de base de datos o se hace actualización simultánea.
Criterios de reversión:
- Si la restauración falla → revertir a Azure PRD (debe seguir intacto durante la transición)
- Si SAP no arranca en AWS → revertir a Azure PRD
- Punto de no retorno: solo después de validación funcional completa
Estrategias de migración SAP
HSR entre nubes
Guía SAP DMO
Ejecutar la transición siguiendo el plan minuto a minuto.
- ☐ Parar SAP en Azure PRD
- ☐ Respaldo final HANA (o cambio HSR)
- ☐ Transferir datos a AWS (si respaldo/restauración)
- ☐ Restaurar en AWS PRD
- ☐ Tareas post-migración (hostname, licencia, RFCs, impresoras, etc.)
- ☐ Iniciar SAP en AWS PRD
- ☐ Validación funcional (pruebas de humo)
- ☐ Actualización DNS (si WebDispatcher cambia de IP)
- ☐ Actualizar políticas VPN en WatchGuard M390
- ☐ Comunicar a usuarios: SAP operativo en nueva plataforma
Periodo de 2-4 semanas post-migración con monitoreo intensivo y equipo disponible 24/7.
- Monitoreo continuo: CloudWatch, HANA Cockpit, SM21, ST22
- Atención inmediata a cualquier incidencia reportada por usuarios
- Comparar métricas de rendimiento AWS vs Azure (línea base)
- Optimizar si es necesario (IOPS, memoria, tipo de instancia)
Descomisionar los recursos SAP en Azure de forma ordenada después de confirmar estabilidad en AWS.
- No apagar Azure PRD inmediatamente. Mantener 30 días como respaldo de emergencia.
- Después de 30 días estables: parar VMs (ahorrar cómputo, mantener discos)
- Después de 60 días: exportar datos a S3 si se necesitan, eliminar VMs
- Después de 90 días: eliminar VNets, NSGs, VPN Gateway, cuentas de almacenamiento
- Verificar que no queden recursos huérfanos generando costos
# Verificar recursos Azure restantes
az resource list --query "[].{Nombre:name,Tipo:type,GR:resourceGroup}" -o table
# Exportar estado final para documentación
az group export --name rg-sap-prod --include-parameter-default-value > azure-sap-estado-final.json
💡 Mantener la suscripción Azure activa pero vacía durante 6 meses por si se necesitan registros históricos o recuperación de datos. Después, evaluar cancelación.
Limpieza de recursos Azure
Gestión de costos Azure
🏆 Resultado Fase 9: SAP S/4HANA productivo migrado a AWS. Azure descomisionado. Migración completada exitosamente. 🎉
🔗 Diagrama de dependencias entre fases
El camino crítico es lineal: 0→1→2→3→4→5→6. Después del control de calidad, QAS y PRD siguen secuencialmente.
Fase 0 — Fundación AWS (Cuenta, IAM, Registros, Costos)
│
├── Fase 1 — Redes DEV (VPC, VPN, TGW, DNS)
│ │
│ ├── Fase 2 — Active Directory DEV
│ │ │
│ │ └── Fase 3 — Cómputo y Almacenamiento DEV
│ │ │
│ │ └── Fase 4 — SAP S/4HANA DEV ← PRIMER SAP EN AWS
│ │ │
│ │ └── Fase 5 — Seguridad y Monitoreo DEV
│ │ │
│ │ └── Fase 6 — Control de Calidad (Avanzar/No Avanzar)
│ │ │
│ │ ├── Fase 7 — Despliegue QAS
│ │ │ │
│ │ │ └── Fase 8 — Preparación PRD (HA/DR)
│ │ │ │
│ │ │ └── Fase 9 — Migración y Transición
│ │ │ │
│ │ │ └── ✅ MIGRACIÓN COMPLETA
│ │ │
│ │ └── [Paralelo] IaC — Codificar en Terraform lo hecho manual en DEV
│ │
│ └── [Paralelo desde Fase 1] Conectividad Azure ↔ AWS (si se necesita)
│
└── [Independiente] WatchGuard M390 — Actualizar firmware, políticas
📝 Notas sobre el orden
| Regla | Descripción |
|---|---|
| Camino crítico | Fases 0→1→2→3→4→5→6 son secuenciales. No se puede saltar. |
| DEV primero | Fases 0-6 son exclusivamente DEV. Los errores se cometen aquí. |
| Control de calidad | Fase 6 es un punto de control formal. Sin aprobación, no se avanza a QAS. |
| IaC en paralelo | Después de completar DEV manual, codificar en Terraform para QAS/PRD. |
| QAS antes de PRD | QAS valida el proceso automatizado antes de tocar producción. |
| PRD = HA obligatoria | Fase 8 agrega HSR, Pacemaker, clúster — no negociable para producción. |
| Ensayo obligatorio | Fase 9.1 (ensayo) ANTES de la transición real. Sin excepciones. |
⏱️ Estimación de tiempos (orientativa)
| Fase | Duración estimada | Notas |
|---|---|---|
| Fase 0 — Fundación | 1-2 semanas | Depende de aprobaciones internas |
| Fase 1 — Redes | 1-2 semanas | VPN puede demorar por coordinación con ISP/WatchGuard |
| Fase 2 — Active Directory | 1 semana | Managed AD: horas. Confianza + validación: días. |
| Fase 3 — Cómputo y almacenamiento | 1 semana | EC2 + EBS es rápido si IAM y red están listos |
| Fase 4 — SAP DEV | 2-4 semanas | Instalación SAP + copia de sistema + validación |
| Fase 5 — Seguridad y monitoreo | 1-2 semanas | En paralelo con pruebas de Fase 4 |
| Fase 6 — Control de calidad | 1 semana | Documentación + presentación a jefaturas |
| TOTAL DEV | 8-14 semanas | |
| Fase 7 — QAS | 3-5 semanas | Más rápido que DEV gracias a lecciones aprendidas |
| Fase 8 — Preparación PRD | 4-6 semanas | HA/DR agrega complejidad significativa |
| Fase 9 — Transición | 2-4 semanas | Incluye ensayo + transición real + soporte intensivo |
| TOTAL PROYECTO | ~6-8 meses | Estimación conservadora, depende de dedicación y complejidad SAP |