Región AWS Chile: cuatro escenarios de migración y las decisiones de arquitectura detrás de cada uno

En revisiones recientes con clientes que hoy operan en regiones fuera de Chile, una de las primeras preguntas ha sido si conviene mover las cargas a Chile apenas abra la región. Al revisar aplicación por aplicación, la respuesta rara vez es una fecha única: disponibilidad de servicios, compromisos vigentes, dependencias y requisitos regulatorios terminan separando el portafolio en distintas olas.

AWS mantiene anunciada una nueva región en Chile para 2026. Para quienes ya ejecutan cargas en AWS, o están preparando su primera migración, la fecha de apertura es una variable del plan; el resto depende de la arquitectura y de las condiciones de cada carga.

El diseño depende de dónde están hoy la aplicación y sus datos, cuánto corte puede tolerar la carga, qué compromisos financieros siguen vigentes y qué evidencias debe presentar la organización antes de mover producción.

En este análisis uso cuatro puntos de partida que aparecen con frecuencia en conversaciones de arquitectura en Chile:

• infraestructura on-premises que quiere migrar por primera vez a AWS;
• cargas que hoy operan en US East (N. Virginia), us-east-1;(puede ser cualquier otra)
• cargas reguladas que necesitan demostrar continuidad y recuperación antes del cambio;
• plataformas SaaS que deben resolver residencia de datos por cliente.

Nota de vigencia: AWS publica la región de Chile como prevista para 2026 y todavía no está disponible al momento de esta revisión. Servicios, features, versiones y precios mencionados en este análisis deben confirmarse contra el catálogo regional cuando AWS publique la disponibilidad efectiva. La Ley 21.719 de protección de datos personales tiene entrada en vigencia el 1 de diciembre de 2026; existe un proyecto en tramitación para postergar su entrada en vigencia y, mientras no se publique, rige la fecha de 2026. Las decisiones regulatorias deben validarse con las áreas legales y de riesgo de cada organización.

Los tres relojes de cada carga

La apertura de una región fija cuándo es posible mover una carga, pero cada carga avanza con tres relojes, y el más lento decide la fecha:

Figura 1. La decisión se toma por carga. Dos aplicaciones del mismo portafolio pueden entrar en olas distintas si sus relojes no se alinean al mismo tiempo.

Planificar únicamente la ejecución deja fuera dependencias que pueden retrasar una carga aunque la landing zone esté preparada. Una carga PCI puede funcionar técnicamente en Chile el día de apertura y aun así esperar a que la región entre en el alcance de la atestación correspondiente.

Este enfoque también evita una premisa que genera problemas desde el inicio: migrar todo por la sola existencia de una región local. En un portafolio real es razonable que ciertas cargas migren, otras permanezcan temporalmente en Virginia y otras cambien de patrón antes de moverse.

Escenario A: on-premises en Chile y primera migración a AWS

Este escenario suele empezar con una pregunta simple: si la región está en Chile, ¿conviene mover la infraestructura actual tal como está o modernizarla durante la migración?

No tomaría esa decisión para todo el inventario al mismo tiempo. Separo las cargas por dependencia, ciclo de vida y tolerancia al cambio.

Opción 1: rehost

Tiene sentido cuando la prioridad es salir del data center con pocos cambios en la aplicación. AWS Transform MGN, nombre actual de AWS Application Migration Service desde junio de 2026, mantiene replicación continua a nivel de bloque y permite ejecutar el cutover por olas.

El beneficio operativo es reducir cambios simultáneos. El costo es que la arquitectura de destino puede conservar limitaciones del origen: servidores sobredimensionados, acoplamiento entre componentes o dependencias que luego requerirán otra etapa de modernización.

Opción 2: replatform durante la migración

Es razonable cuando la aplicación admite cambios controlados y el equipo quiere evitar trasladar determinados componentes tal como están. Una base de datos podría pasar a un servicio administrado compatible, una capa web podría desplegarse en contenedores y el almacenamiento compartido podría separarse del cómputo.

La migración deja de ser una réplica del data center. El análisis debe incluir compatibilidad del motor, comportamiento de sesiones, archivos locales, jobs, dependencias de red y procedimientos de operación.

Opción 3: transición híbrida

Algunas dependencias no cruzan a la nube en la misma ola. Muchas organizaciones mantendrán sistemas de registro, appliances, mainframe o bases heredadas on-premises durante meses.

En ese caso, la conectividad híbrida se diseña desde el inicio. Direccionamiento, DNS, rutas, inspección, capacidad y comportamiento ante pérdida del enlace se resuelven antes de mover una aplicación que seguirá consultando servicios locales.

Figura 2. El patrón de referencia separa gobierno, conectividad y cuentas de carga. AWS Transform MGN y AWS DMS aparecen como mecanismos posibles de migración; el servicio concreto depende de cada servidor y motor de datos.

Qué elegiría por carga

La landing zone debería existir antes de la primera ola productiva. Migrar primero a cuentas creadas con urgencia y reorganizar después identidad, logging, red y controles multiplica los cambios sobre cargas que ya estarán operando en producción.

Escenario B: cargas actuales en N. Virginia (región tomada como ejemplo)

Aquí la infraestructura ya está en AWS. El problema cambia: hay que decidir cuánto tiempo convivirán las dos regiones y qué parte del sistema se puede reconstruir desde código.

Un terraform apply contra una región nueva crea recursos. Datos, endpoints regionales, AMIs, cuotas, certificados, KMS, DNS, integraciones y dependencias creadas manualmente quedan fuera de su alcance.

Alternativa 1: redespliegue y corte programado

Es el camino más simple cuando existe una ventana de mantenimiento aceptable.

La infraestructura se despliega en Chile desde IaC, los datos se sincronizan, se ejecutan pruebas funcionales y de rendimiento y se realiza un cambio controlado de tráfico. Si la validación falla, el origen sigue disponible durante la ventana de rollback.

Este patrón evita mantener producción activa en dos regiones durante mucho tiempo, pero concentra más riesgo en el momento del corte.

Alternativa 2: convivencia temporal y desplazamiento progresivo

Para canales con baja tolerancia a interrupciones, mantengo Virginia y Chile operativos durante una etapa transitoria.

La capa global puede utilizar AWS Global Accelerator o Amazon Route 53, según el protocolo, el comportamiento del cliente y el mecanismo de rollback requerido. En Global Accelerator, el traffic dial regula qué porcentaje del tráfico que llega a un endpoint group regional se atiende ahí; el reparto global resultante depende de dónde están los usuarios.

Durante la convivencia, mantener coherencia de datos mientras ambas regiones atienden tráfico suele requerir más trabajo que el balanceo.

• Amazon S3: Cross-Region Replication para objetos nuevos y Batch Replication para histórico.
• Amazon DynamoDB: global tables.
• Amazon Aurora: Aurora Global Database, según motor y versión.
• Otros motores: replicación nativa del motor, AWS DMS u otro patrón que cumpla el RPO definido.

Figura 3. Arquitectura transitoria región-a-región. La capa global desplaza tráfico y los datos se sincronizan con el mecanismo adecuado para cada servicio.

Si el equipo quiere validar la región antes de convertirla en primaria, Chile también puede entrar primero como DR. Ese patrón se detalla en el escenario C y aplica igual a cargas no reguladas.

El IaC define cuánto trabajo aparece

Antes de diseñar la ola, hago una prueba de despliegue en una cuenta no productiva y busco, entre otros puntos:

• ARNs o nombres regionales escritos directamente en el código;
• AMIs fijas;
• referencias a us-east-1 en módulos, pipelines o scripts;
• endpoints globales donde convenga utilizar endpoints regionales;
• claves KMS y políticas dependientes de región;
• recursos existentes que nunca fueron incorporados al estado de IaC;
• cuotas que se aumentaron en Virginia y no existen todavía en Chile.

Ese ejercicio entrega una medida de portabilidad más útil que revisar si el repositorio contiene Terraform o CloudFormation.

Escenario C: carga regulada que opera en N. Virginia

Para una carga regulada hay que validar que Chile puede ejecutar la aplicación y demostrar que el cambio puede hacerse dentro de los controles de continuidad, seguridad y operación definidos por la organización.

Según la tolerancia al corte y la evidencia requerida, evaluaría un corte directo, convivencia productiva temporal o un enfoque DR-first.

Corte directo con ambiente paralelo

Chile se construye y prueba antes de la ventana. Los datos se sincronizan y la aplicación cambia de región en un evento planificado.

Puede ser suficiente cuando la carga admite una ventana clara, el RPO/RTO está cubierto y el comité acepta el mecanismo de rollback.

Convivencia productiva temporal

Ambas regiones atienden producción durante una fase controlada. Es útil cuando se necesita observar comportamiento real antes de retirar Virginia, pero agrega complejidad de datos, soporte y costos.

DR-first

Chile se incorpora primero como región de recuperación. Se construye la replicación, se ejecutan pruebas de failover y se registran los tiempos y resultados. Solo después se evalúa promover Chile a primaria.

Figura 4. El cambio de región se apoya en un patrón de recuperación probado. Virginia puede permanecer temporalmente como sitio de rollback o convertirse en DR después del switchover.

DR-first permite presentar al comité resultados de pruebas, tiempos observados, comportamiento de replicación, runbooks y criterios de retorno al origen. La migración se ensaya como un ejercicio de recuperación antes de ejecutarse como cambio de región.

En motores que soportan un switchover administrado entre regiones, uso el mecanismo nativo. En Aurora Global Database, por ejemplo, un switchover planificado se ejecuta así:

aws rds switchover-global-cluster \ --global-cluster-identifier gdb-core \ --target-db-cluster-identifier arn:aws:rds:${REGION_CL}:111122223333:cluster:core-cl 

Cada motor se comporta distinto en pérdida de datos, DNS y reconexión de clientes, y el runbook debe reflejar el mecanismo real que se usará en producción.

Cuándo preferiría DR-first

Lo evaluaría primero cuando:

• la carga ya exige un DR regional separado;
• el comité necesita resultados de failover antes de autorizar el movimiento de producción;
• el costo de mantener dos regiones durante la transición es aceptable;
• el RPO/RTO puede probarse con el mecanismo real que luego se utilizará en producción.

Si la aplicación no requiere DR multi-región y dispone de una ventana amplia de mantenimiento, un despliegue paralelo con corte planificado es más simple.

Escenario D: SaaS que atiende clientes chilenos desde Virginia

En una plataforma multi-tenant, residencia de datos rara vez significa mover toda la plataforma a Chile. Moverla completa es lo más simple de razonar, pero obliga a mover tenants que no necesitan residencia en Chile y penaliza a los clientes de otros países.

La primera pregunta es qué datos del tenant deben permanecer en una geografía determinada. Después hay que revisar si logs, backups, analytics, exportaciones y procesos de soporte siguen esa misma regla.

Alternativa 1: separar solo el plano de datos

La aplicación puede seguir compartiendo ciertos componentes globales mientras los datos regulados se almacenan por región.

Este enfoque reduce duplicación de cómputo, pero exige revisar cada flujo para impedir que datos sujetos a residencia terminen en caches, logs, colas, índices de búsqueda o procesos analíticos fuera de la región prevista.

Alternativa 2: arquitectura celular

Cada región ejecuta una celda con cómputo y datos propios. Un plano de control mantiene el directorio de tenants y decide a qué celda enviar cada solicitud.

Figura 5. El tenant se asigna a una celda. El diseño debe incluir datos operacionales y no limitar la residencia únicamente a la base transaccional.

La arquitectura celular introduce más componentes y más operación, pero reduce el acoplamiento entre geografías y permite mover tenants de forma individual. La decisión depende del número de tenants, requisitos contractuales, aislamiento requerido y capacidad del producto para operar con varias celdas.

Costos que pueden cambiar la decisión

Una migración de región también tiene efectos financieros que deben revisarse antes de ordenar las olas.

No cerraría el business case de Chile hasta que AWS publique precios regionales y el catálogo efectivo. Una carga puede ser técnicamente migrable y, aun así, convenir moverla después del vencimiento de un compromiso existente.

Controles técnicos que reviso antes de la primera ola

Hay problemas que no aparecen en el diagrama principal y pueden detener un despliegue:

• habilitación de la nueva región en las cuentas correspondientes;
• políticas SCP que restrinjan aws:RequestedRegion;
• soporte de AWS Control Tower antes de agregar Chile como governed Region;
• endpoints regionales de STS en pipelines y automatizaciones;
• estrategia KMS para claves que deban existir en más de una región;
• pools de IPAM sin solapamiento;
• cuotas regionales de EC2, EBS, VPC, NAT Gateway y otros servicios;
• certificados y secretos regionales;
• rutas de Transit Gateway y conectividad con Direct Connect;
• comprobación de las versiones y features concretos disponibles en Chile.

La comprobación de paridad debería automatizarse. AWS publica el catálogo de servicios por región como parámetros públicos de SSM, lo que permite comparar origen y destino en minutos:

REGION_US="us-east-1" REGION_CL="<región-chile>" for r in $REGION_US $REGION_CL; do aws ssm get-parameters-by-path \ --path /aws/service/global-infrastructure/regions/$r/services \ --query 'Parameters[].Value' --output text \ | tr '\t' '\n' | sort > services_$r.txt done # Servicios presentes en Virginia y ausentes en Chile comm -23 services_$REGION_US.txt services_$REGION_CL.txt 

El resultado tiene que alimentar la decisión de cada carga, no una declaración general de que "Chile está lista". La paridad de servicio es el primer filtro; la paridad de features (versiones de motor, tipos de instancia, integraciones) se valida después, carga por carga.

Dónde usaría IA en este proceso

La IA entra en tareas concretas de estos escenarios; la decisión arquitectónica sigue siendo del equipo.

La existencia de un servicio o feature en Chile no la confirma el agente: la fuente de verdad es la documentación regional y las pruebas del equipo.

La residencia también aplica a las herramientas. Al momento de esta revisión, el AWS MCP Server opera en N. Virginia y Frankfurt, y AWS FinOps Agent, todavía en preview, corre en N. Virginia. Si el caso de negocio de la migración incluye restricciones de residencia, conviene saber dónde se almacenan y procesan inventarios, logs, código o datos operacionales antes de entregarlos a cualquiera de estos servicios.

Errores que se repiten

• ❌ Planificar solo el reloj de ejecución. La landing zone puede estar lista y la carga seguir bloqueada por disponibilidad o cumplimiento.
• ❌ Mover cómputo sin mover datos. Una aplicación en Chile que consulta una base en Virginia introduce latencia interregional y puede generar cargos de transferencia de datos según el flujo y los servicios utilizados.
• ❌ Ignorar compromisos vigentes. RIs y EC2 Instance Savings Plans en Virginia siguen facturándose después del corte.
• ❌ Declarar listo un DR que nunca se probó. Sin failover ejecutado, el DR es un supuesto.
• ❌ Retirar el origen al día siguiente del corte. La región de origen debe mantenerse como rollback durante un período definido y medible.
• ❌ Pedirle a un agente que confirme paridad regional. Esa respuesta sale del catálogo oficial y de pruebas propias.

Matriz de decisión

Con esa información, Chile puede terminar siendo la región primaria, un sitio de DR, una celda para determinados tenants o el destino de una parte del portafolio. Esas cuatro decisiones producen diseños distintos aunque todas comiencen con la misma pregunta: qué hacemos cuando la región AWS Chile esté disponible.

Preguntas antes de asignar una carga a una ola

1. ¿Están alineados los tres relojes? Disponibilidad regional, evidencia de cumplimiento y ejecución lista.
2. ¿Dónde está la gravedad de los datos? Si los datos no se mueven, la aplicación tampoco debería.
3. ¿Qué ventana de corte tolera la carga? Ninguna, minutos ensayados o una ventana planificada.
4. ¿Qué tan completo es el IaC? La prueba de despliegue en una cuenta no productiva lo responde.
5. ¿Qué compromisos financieros quedan en el origen? El calendario de vencimientos también es un reloj.

Happy learning on AWS 🚀

Referencias oficiales consultadas

• AWS — Región AWS Sudamérica (Chile)
• BCN — Ley 21.719
• Garrigues — Proyecto de modificación de la Ley 21.719 (Boletín 18.623-07)
• AWS — Application Migration Service is now AWS Transform MGN
• AWS — Global Accelerator traffic dials
• AWS — Database Savings Plans
• AWS — The AWS MCP Server is now generally available
• AWS — AWS FinOps Agent (preview) FAQs