Diseño de arquitectura: de los requisitos a la estimación de costes

Requisito que decide: alta disponibilidad Multi-AZ con picos de 10x y LEAST operational overhead sin reescribir.

Arquitectura:

flowchart LR
  U["Clientes"] --> R53["Route 53"]
  R53 --> CF["CloudFront + AWS WAF"]
  CF -->|"/static"| S3["S3: imágenes<br/>(OAC)"]
  CF -->|"dinámico"| ALB["Application Load Balancer<br/>subredes públicas, 2 AZ"]
  ALB --> ASG["Auto Scaling group<br/>EC2 PHP en subredes privadas<br/>AZ a y AZ b"]
  ASG --> EC["ElastiCache<br/>sesiones y caché"]
  ASG --> DB["Aurora MySQL<br/>escritor + réplica en otra AZ<br/>cifrado con KMS"]
  ASG --> SM["Secrets Manager"]

• Route 53 para el dominio y CloudFront delante de todo: sirve las imágenes desde S3 (acceso solo vía Origin Access Control) y cachea lo que se pueda de la parte dinámica. Reduce la carga del origen en los picos y el coste de transferencia.
• AWS WAF asociado a CloudFront con reglas gestionadas contra SQLi y una regla basada en frecuencia (rate-based) contra los bots de contraseñas. Shield Standard viene incluido.
• ALB en dos AZ y un Auto Scaling group de EC2 (launch template con la AMI de la aplicación) en subredes privadas de dos AZ, con target tracking sobre la CPU o las peticiones por destino. Scheduled scaling antes de los lanzamientos conocidos.
• La aplicación pasa a ser stateless: sesiones en ElastiCache. Es el único cambio de código relevante (configuración del gestor de sesiones de PHP).
• Aurora MySQL (compatible con la MySQL actual, migración homogénea) con una réplica en otra AZ: failover automático en torno a un minuto. Cifrado en reposo con KMS. Credenciales en Secrets Manager con rotación.
• Salida a Internet de las instancias privadas (actualizaciones): NAT Gateway. Para reducir costes en la fase inicial se puede usar un único NAT, sabiendo que es un punto único de fallo solo para la salida, no para el servicio a clientes.

Alternativas descartadas:

• Elastic Beanstalk: sería válido y aún más sencillo de operar; es una buena respuesta alternativa si el equipo no quiere gestionar el ASG.
• ECS con Fargate: excelente a medio plazo, pero exige contenerizar la aplicación.
• DynamoDB: obligaría a reescribir el acceso a datos relacional.
• RDS MySQL Multi-AZ: válida y algo más barata; Aurora gana en failover más rápido y réplicas de lectura que absorben los picos.

Justificación por pilares:

Estimación (supuestos para la calculadora):

Fíjate en que el NAT Gateway y el ALB, por sí solos, suman más de 50 USD al mes: son costes fijos que en un examen aparecen como «optimiza la red».

Requisito que decide: streaming casi en tiempo real con varios consumidores + data lake serverless y barato a 7 años.

Arquitectura:

flowchart LR
  T["Camiones"] --> KDS["Kinesis Data Streams<br/>(on-demand)"]
  KDS --> L["Lambda<br/>reglas de temperatura"]
  L --> SNS["SNS / EventBridge<br/>alertas"]
  KDS --> FH["Data Firehose<br/>conversión a Parquet"]
  FH --> S3["S3 data lake<br/>particionado por fecha"]
  N["CSV nocturno"] --> S3R["S3 zona raw"]
  S3R --> GL["AWS Glue job<br/>CSV a Parquet"]
  GL --> S3
  S3 --> CAT["Glue Data Catalog<br/>+ Lake Formation"]
  CAT --> ATH["Athena"]
  ATH --> Q["Amazon Quick<br/>informes"]

• Kinesis Data Streams (modo on-demand para no dimensionar shards) recibe los eventos. Permite varios consumidores independientes y reproceso.
• Consumidor 1: Lambda evalúa las reglas de temperatura y publica alertas en SNS (correo o SMS a operaciones) o en EventBridge para integrarlas con otros sistemas. Latencia de segundos.
• Consumidor 2: Amazon Data Firehose agrupa los eventos y los escribe en S3 convertidos a Parquet y particionados por fecha, sin código.
• El CSV nocturno llega a una zona raw de S3 y un job de AWS Glue lo transforma a Parquet.
• Glue Data Catalog registra las tablas; AWS Lake Formation concede al socio permisos a nivel de columna (sin los campos del conductor).
• Athena para SQL serverless (pagas por datos escaneados: Parquet y particiones reducen mucho el coste) y Amazon Quick (antes QuickSight) para los informes semanales.
• S3 Lifecycle: Standard 90 días → Glacier Flexible Retrieval o Deep Archive hasta los 7 años (se admite esperar horas) → expiración. Si el contrato exige que no se pueda borrar, S3 Object Lock.
• Cifrado con KMS en Kinesis, Firehose y S3; TLS en tránsito. Autenticación de los dispositivos: credenciales temporales (por ejemplo, Cognito identity pools) con permiso solo de kinesis:PutRecord sobre ese stream.

Alternativas descartadas:

• Solo Firehose: no da alertas en segundos con lógica propia ni varios consumidores.
• Amazon MSK: válido si ya usan Kafka; aquí añade gestión innecesaria.
• Redshift: potente para BI intensivo, pero para informes semanales Athena es más barato y serverless.
• EMR: exceso para una conversión CSV → Parquet nocturna.
• SQS: no conserva orden ni permite varios consumidores leyendo el mismo flujo.

Justificación por pilares:

Estimación (supuestos para la calculadora):

• Volumen: 600 eventos/s × 1 KB ≈ 0,6 MB/s ≈ 1,5 TB al mes en bruto (en Parquet comprimido ocupa bastante menos).
• Kinesis Data Streams on-demand: por GB escrito y leído y por hora de stream. Calcúlalo en la calculadora.
• Firehose: por GB ingerido y por conversión de formato.
• S3: 3 meses en Standard (0,023 USD por GB-mes en eu-south-2) y el resto en Glacier.
• Athena: por TB escaneado; estima cuántas consultas y cuántos datos escanean.
• Lambda: 600 invocaciones por segundo si procesas registro a registro; mejor por lotes (batch size) para reducir invocaciones.

Si algún servicio no está disponible en eu-south-2 en la calculadora, estima en eu-west-1 y anótalo.

Requisito que decide: rehost sin cambios de código + DR entre regiones con RTO de 1 h y RPO de 15 min al menor coste → pilot light o warm standby reducido.

Arquitectura:

flowchart TB
  subgraph ONP["Centro de datos (durante la migración)"]
    APP0["Windows + SQL Server"]
    FS0["Servidor SMB 8 TB"]
  end
  subgraph R1["Región principal: eu-south-2"]
    MGN["Application Migration Service"]
    EC2A["EC2 Windows<br/>aplicación, 2 AZ tras ALB"]
    RDS["RDS for SQL Server<br/>Multi-AZ, KMS"]
    FSX["FSx for Windows File Server<br/>Multi-AZ + AD"]
    AD["AWS Managed Microsoft AD"]
    BK["AWS Backup<br/>Vault Lock"]
  end
  subgraph R2["Región de DR: eu-west-1"]
    RDS2["Réplica o copias de RDS"]
    AMI2["AMI copiadas<br/>ASG a 0 o mínimo"]
    FSX2["Copias de FSx"]
    BK2["Vault de copia"]
  end
  APP0 -->|"replicación"| MGN --> EC2A
  FS0 -->|"DataSync por VPN"| FSX
  EC2A --> RDS
  EC2A --> FSX
  FSX --> AD
  RDS -. "réplica entre regiones" .-> RDS2
  BK -. "copia entre regiones" .-> BK2
  EC2A -. "AMI" .-> AMI2
  FSX -. "backup" .-> FSX2

• Conectividad: Site-to-Site VPN desde el centro de datos (rápida de montar; Direct Connect tardaría semanas y no hace falta para 3 meses). Las clínicas acceden a la aplicación por HTTPS (ALB con certificado de ACM) o, si la aplicación es de escritorio, por Client VPN.
• Aplicación: rehost con AWS Application Migration Service (replica los servidores sin tocar el código). Las EC2 Windows se despliegan en dos AZ tras un ALB.
• Base de datos: RDS for SQL Server Multi-AZ (menos gestión que SQL Server en EC2; migración homogénea con copia de seguridad nativa o AWS DMS). Si el proveedor exigiera acceso al sistema operativo del servidor de base de datos, la alternativa sería SQL Server en EC2.
• Ficheros: FSx for Windows File Server Multi-AZ unido a AWS Managed Microsoft AD (con una relación de confianza con el AD local durante la transición). Migración de los 8 TB con AWS DataSync por la VPN: a 1 Gbps teórico son menos de un día de transferencia pura; en la práctica, unos días compartiendo la línea. Snow Family no hace falta (y además ya no está disponible para clientes nuevos).
• Copias: AWS Backup con planes para EC2, RDS y FSx, copia a la región de DR y Backup Vault Lock en modo compliance durante 5 años (inmutabilidad). Adiós a las cintas.
• DR (pilot light / warm standby reducido) en eu-west-1:
  • RDS: réplica de lectura entre regiones para SQL Server si la edición lo admite (RPO de minutos) o, si no, copias automatizadas y snapshots replicados con la frecuencia que exija el RPO. Comprueba en la documentación qué opción cumple 15 minutos para tu edición.
  • Aplicación: AMI copiadas y un ASG a 0 (pilot light) o a 1 instancia (warm standby) listo para escalar.
  • FSx: copias de AWS Backup a la otra región (o replicación con DataSync programada si se necesita RPO más bajo).
  • Route 53 failover con health checks para cambiar el DNS a la región de DR.
  • Service Quotas revisadas en la región de DR para poder levantar la capacidad.
  • Runbook automatizado con CloudFormation o Systems Manager Automation y simulacros de DR periódicos.
• Seguridad y cumplimiento: KMS en todos los almacenes (con claves multirregión o claves en ambas regiones), TLS, CloudTrail de organización hacia un bucket con Object Lock, AWS Config para reglas de cumplimiento, GuardDuty, y los informes de cumplimiento de AWS en AWS Artifact.

Alternativas descartadas:

• Multi-site active-active: cumple con creces pero cuesta el doble; el enunciado pide no pagar una segunda región a plena capacidad.
• Backup and restore puro: difícilmente cumple RTO de 1 h con 8 TB de ficheros y la base de datos.
• Storage Gateway (S3 File Gateway): útil si los ficheros se quedaran en local; aquí se migra todo y el protocolo SMB con AD pide FSx for Windows.
• Aurora PostgreSQL con migración heterogénea: ahorraría licencias, pero el proveedor no permite cambiar el código.

Justificación por pilares:

Estimación (supuestos para la calculadora):

• EC2 Windows: 2 instancias (m-family pequeña) en la región principal; 0 o 1 en DR. La licencia de Windows va incluida en el precio por hora.
• RDS for SQL Server: la licencia incluida es una parte importante del coste; compara ediciones (Web, Standard) en la calculadora.
• FSx for Windows: 8 TB (HDD es más barato para radiografías de acceso esporádico), capacidad de rendimiento y copias.
• Site-to-Site VPN: 0,05 USD/h por conexión en eu-south-2 (≈36,5 USD/mes).
• AWS Managed Microsoft AD: por hora de controlador de dominio.
• AWS Backup: GB almacenados y copia entre regiones (transferencia entre regiones incluida en la estimación).
• Route 53: zona alojada y health checks.

Mantener dos AZ (es un requisito), pero con el mínimo del ASG en 2 instancias pequeñas cubiertas por un Compute Savings Plan; usar Spot para la capacidad adicional de los picos (la aplicación es stateless); un único NAT Gateway o eliminarlo si las instancias solo necesitan S3 y otros servicios de AWS a través de VPC endpoints; Aurora con instancias más pequeñas o Aurora Serverless v2 para la réplica; aumentar el TTL de caché en CloudFront.

Casi nada, porque todo escala solo: Kinesis on-demand, Firehose, Lambda, S3 y Athena. Lo que hay que vigilar son las cuotas (por ejemplo, la concurrencia de Lambda y el rendimiento del stream), el coste de Athena si las consultas escanean todo (particiones y Parquet son esenciales) y el coste de Kinesis on-demand frente a provisionado cuando el tráfico ya es estable y predecible.

Si el centro de datos sigue vivo a largo plazo con mucho tráfico constante hacia AWS, si necesitas latencia y ancho de banda predecibles o si el coste de transferencia por Internet supera al de un puerto de Direct Connect. En ese caso, Direct Connect como enlace principal y la VPN como respaldo. Para una migración de 3 meses, no compensa.

Con AWS Backup Vault Lock en modo compliance (ni siquiera el usuario raíz puede acortar la retención una vez pasado el periodo de gracia), los registros de CloudTrail en un bucket con S3 Object Lock, reglas de AWS Config que comprueben la configuración y los informes de cumplimiento de AWS descargados de AWS Artifact.

No hay respuesta única; se trata de razonar con el requisito que decide. Por ejemplo: en el 1, fiabilidad (los picos son el negocio); en el 2, optimización de costes (el volumen crece y el pago por uso puede dispararse); en el 3, seguridad (datos de salud) y fiabilidad a la par. En una entrevista, lo que se valora es que explicites el compromiso (trade-off) que aceptas.