Amazon EC2 a fondo: diseño práctico de servidores virtuales sin confusión — Comparativa real con GCP Compute Engine y Azure VM

Introducción (puntos clave)

Este artículo es una guía práctica lista para usar en el campo, centrada en AWS Amazon EC2 e incluye una comparación funcional punto por punto con Google Compute Engine (GCE) y Azure Virtual Machines (Azure VM).
Conclusión por adelantado: Para la “IaaS clásica” de disponibilidad y escalabilidad, estandariza en EC2 con Auto Scaling Group + ELB + Launch Template para mayor estabilidad. GCE destaca por los tipos de máquina personalizados (vCPU/memoria granulares), mientras que Azure se integra de forma natural con AD/AAD y redes virtuales, encajando bien con la gobernanza empresarial.
El meollo del diseño está en cinco áreas: selección de instancias, diseño de almacenamiento, red/seguridad, escalado/disponibilidad y automatización operativa.
Incluye muestras de CLI listas para usar (en paralelo para EC2/GCE/Azure VM), user data (cloud-init), plantillas para diseño de ASG/escalado y una lista de verificación operativa.
Lectores previstos: Departamentos de TI que migran a la nube, desarrolladores de apps web/negocio, ingenieros SRE/infraestructura, responsables de seguridad/gobernanza y líderes técnicos de startups. Para quienes quieren captar rápido la visión general desde lift & shift de VMs on-prem hasta diseño moderno de scale-out.

1. Qué es Amazon EC2: de los básicos de IaaS a “patrones que deberías usar hoy”

Amazon Elastic Compute Cloud (EC2) proporciona servidores virtuales (IaaS) bajo demanda. Lanzas instancias desde AMIs (imágenes de máquina) y defines límites de red con VPC/subredes/grupos de seguridad.
El EC2 moderno usa comúnmente virtualización basada en Nitro, lo que permite diseñar para rendimiento estable, aislamiento seguro y ENA flexible (red de alta velocidad). Para disponibilidad, la distribución multi-AZ es la base; combinar Auto Scaling Groups (ASG) con Elastic Load Balancing (ELB) facilita auto-recuperación ante fallos y seguimiento de fluctuaciones de demanda.

En la práctica, estandarizas parámetros de lanzamiento (AMI/tipo/disk/user data/rol) con Launch Templates, gestionas capacidad min/desired/max vía ASG, y usas escalado por seguimiento de objetivo para autoajustar a metas como CPU o latencia de solicitud—este es el patrón “por defecto”.

2. Casos de uso representativos (patrones de diseño y puntos de comparación)

Clústeres Web/API que priorizan disponibilidad
- Escala con ASG + ALB (HTTP/HTTPS) y distribuye entre múltiples AZs. Usa EBS para el root y mantén estado externo en RDS/ElastiCache/EFS.
- En GCE, usa Managed Instance Group (MIG) + HTTP(S) Load Balancing; en Azure, Virtual Machine Scale Sets (VMSS) + Application Gateway/Front Door como patrones equivalentes.
Procesamiento batch / ejecución de jobs
- Reduce costos con Spot Instances. Ideal para cargas tolerantes a interrupciones (MapReduce, transcodificación de video).
- GCE Spot VMs y Azure Spot VMs siguen la misma idea. El rediseño para re-ejecución y checkpoints es clave.
HPC / Machine Learning
- Requiere red de gran ancho de banda, GPUs/almacenamiento de alta velocidad. Usa Placement Groups o Dedicated Hosts para aislar ruido.
- Equivalentes aproximados: familias A2/A3 de GCP y HB/HC/ND/NC de Azure. Prioriza ancho de banda de red, generación de GPU y rendimiento de almacenamiento.
Lift & Shift de servidores empresariales
- Empieza con una AZ × ASG (min 1 / max 1) para asegurar auto-curación. Usa Systems Manager (SSM) para SO/parches y simplificar operaciones.
- GCE ofrece OS Config; Azure proporciona Update Management/Automation para funciones similares.

3. Selección de instancias: 5 pasos para evitar la confusión

Elige la familia adecuada y el tamaño correcto para equilibrar rendimiento y costo.

Selecciona una familia
- Propósito general: Equilibrada; adecuada para la mayoría de cargas web/API.
- Optimizada para cómputo: Procesamiento CPU-bound; servidores de apps/juegos, etc.
- Optimizada para memoria: BDs en memoria/cachés/analítica a gran escala.
- Optimizada para almacenamiento: Para OLAP/procesamiento de logs con NVMe local.
- Aceleradas (GPU/FPGA, etc.): Entrenamiento/inferencia de IA, render GPU.
Modalidad de almacenamiento
- Elige EBS (bloque persistente) o instance store (rápido, no persistente).
- Usa EBS por defecto para el disco root. Considera instance store solo para temporales/cachés.
Rendimiento de red
- Selecciona tamaños con ENA y enhanced networking según ancho de banda/pps requeridos.
Requisitos de disponibilidad
- Decide entre ASG multi-AZ o Dedicated Hosts/Dedicated Instances para mayor aislamiento de ruido.
Modelo de precios
- Valida en On-Demand → optimiza estado estable con Savings Plans/RI → absorbe picos/batch con Spot.

Comparativa con GCE: Los tipos de máquina personalizados permiten especificar vCPU/memoria (GB) de forma fina. Comparativa con Azure: Gran variedad de SKUs (tamaños) y funciones como Proximity Placement Groups para optimizar latencia.

4. Diseño de almacenamiento: elegir entre EBS / Instance Store / EFS / FSx

EBS (Elastic Block Store)
- Tipos: SSD de propósito general (gp*), Provisioned IOPS (io*), Throughput Optimized (st), Cold HDD (sc), etc.
- Ideal para discos root/datos. Gestiona generaciones con snapshots. Habilita cifrado por defecto.
Instance Store
- NVMe de alta velocidad físicamente adjunto. No persistente—se pierde al parar/reiniciar.
- Restringe a temporales/shuffle/cache.
EFS (NFS compartido) / FSx (Windows/Lustre/ONTAP, etc.)
- Usa EFS/FSx cuando se necesita acceso compartido entre apps. Elige según rendimiento/latencia.

GCE: Persistent Disk (PD) con opciones Standard/SSD/Extreme; Local SSD es de ultra-baja latencia pero no persistente.
Azure: Managed Disks (Standard HDD/SSD, Premium/Ultra). Azure Files ofrece almacenamiento compartido.

5. Red y seguridad: el “pack de cuatro” inicial para cerrar primero

VPC/Subredes
- Usa subredes privadas + NAT/proxy para salida. Mantén subredes públicas al mínimo.
Security Groups (SG)
- Firewalls virtuales stateful. Aplica mínimo privilegio. NACLs son controles complementarios a nivel CIDR.
Identidad
- Usa roles IAM (instance profiles) para evitar credenciales embebidas. Obliga IMDSv2.
Acceso operativo
- Usa SSM Session Manager para shell/túneles sin bastión. Retira distribución de claves y gestión de bastiones.

GCE: VPC/Firewall, adjunta service accounts a instancias. OS Login simplifica la integración IAM.
Azure: VNet/NSG/ASG, elimina credenciales con Managed Identity. Bastion/Just-In-Time para acceso seguro.

6. Disponibilidad y escalado: haz de ASG + ELB tu “equipo estándar”

Auto Scaling Group (ASG)
- Health checks reemplazan instancias fallidas. Políticas: programadas/seguimiento de objetivo/por pasos.
Elastic Load Balancing (ALB/NLB/GWLB)
- ALB: L7—HTTP/HTTPS con enrutado por path/host.
- NLB: L4—ultra-baja latencia, IPs estáticas; fuerte para gRPC/alto throughput.
Multi-AZ / Multi-Región
- La distribución por AZ es obligatoria. Para multi-región, diseña Route 53/health checks y replicación de datos.

GCE: Managed Instance Group + Cloud Load Balancing (HTTP(S) global).
Azure: VMSS + Application Gateway/Load Balancer/Front Door.

7. Automatización y bootstrap: un “ritual de lanzamiento” repetible

Usa Launch Templates + user data (cloud-init) para inicialización declarativa.
Hornea AMIs (p. ej., con Packer) para pre-incluir configuraciones costosas, reduciendo tiempo de arranque.
Estandariza configuración y parcheo con Systems Manager (State Manager/Run Command/Patch Manager).

GCE: Startup Script/Metadata, Instance Templates.
Azure: VM Extensions (Custom Script), Shared Image Gallery.

8. Monitorización, operaciones y trazabilidad

CloudWatch: Métricas (CPU/red/disk) y Agent para métricas del SO/recogida de logs.
CloudTrail: Rastro de actividad API—sigue operaciones de instancia/red/clave.
SSM: Visibilidad de inventario/vulnerabilidades/parcheo.
Alertas: Define primero SLO/SLI, y prioriza indicadores ligados a la experiencia (p95 de latencia) sobre umbrales crudos.

GCE: Cloud Monitoring/Logging, Ops Agent.
Azure: Azure Monitor/Log Analytics, Diagnostic Settings.

9. Optimización de costos: movimientos firmes y sin drama

Rightsizing: Mide CPU/memoria/disco/red y reduce un nivel cuando aplique.
Combina modelos de precio:
- On-Demand…para dev/experimentación.
- Savings Plans/Reserved Instances…para cargas estables.
- Spot…para picos/batch.
Paradas programadas: Auto-stop noches/fines de semana.
Externaliza el estado: Haz las instancias stateless para facilitar scale-down y reemplazo.
Optimiza almacenamiento: Revisa tipos EBS, ajusta IOPS en SSD de propósito general, poda snapshots sin uso.

GCE: Committed Use Discounts + Spot, Sustained Use Discounts (automáticos).
Azure: Reserved VM Instances + Spot, con auto-stop/horarios similares.

10. “Glosario multi-nube” para conversaciones operativas más fluidas

Definición de lanzamiento: Launch Template (EC2) / Instance Template (GCE) / Modelo de VMSS + Imagen (Azure)
Autoescalado: ASG (EC2) / MIG (GCE) / VMSS (Azure)
Balanceador L7: ALB (EC2) / HTTP(S) LB (GCE) / Application Gateway (Azure)
Entrega de credenciales: IAM Role (EC2) / Service Account (GCE) / Managed Identity (Azure)
Acceso sin bastión: SSM Session Manager (EC2) / IAP + OS Login (GCE) / Bastion/Just-in-Time (Azure)

11. Ejemplos prácticos (hands-on en 3 nubes)

11.1 Lanzamiento EC2 (mínimo, con User Data)

# 1) Security Group (ejemplo abre 80/22; omite 22 si operas vía SSM)
aws ec2 create-security-group \
  --group-name web-sg --description "web sg" --vpc-id vpc-xxxxxxxx

aws ec2 authorize-security-group-ingress \
  --group-id sg-xxxxxxxx --protocol tcp --port 80 --cidr 0.0.0.0/0

# 2) Par de claves (no necesario si operas vía SSM)
aws ec2 create-key-pair --key-name web-key > web-key.pem && chmod 400 web-key.pem

# 3) Lanzamiento (ejemplo más corto sin Launch Template)
cat > user-data.sh <<'EOF'
#cloud-config
packages:
  - nginx
runcmd:
  - systemctl enable nginx
  - systemctl start nginx
EOF

aws ec2 run-instances \
  --image-id ami-xxxxxxxxxxxxxxxxx \
  --instance-type t3.small \
  --subnet-id subnet-xxxxxxxx \
  --security-group-ids sg-xxxxxxxx \
  --iam-instance-profile Name=ec2-app-role \
  --user-data file://user-data.sh \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=web-1}]'

11.2 GCE (Despliegue “más corto” equivalente)

gcloud compute instances create web-1 \
  --zone=asia-northeast1-b \
  --machine-type=e2-small \
  --metadata=startup-script='#!/bin/bash
sudo apt -y update && sudo apt -y install nginx
sudo systemctl enable nginx && sudo systemctl start nginx' \
  --tags=http-server

11.3 Azure VM (Despliegue “más corto” equivalente)

az group create -n rg-web -l japaneast
az vm create -g rg-web -n web-1 \
  --image UbuntuLTS --size Standard_B1ms \
  --custom-data cloudinit.yaml \
  --admin-username azureuser --generate-ssh-keys
az vm open-port -g rg-web -n web-1 --port 80
# cloudinit.yaml es casi equivalente al cloud-config de EC2

11.4 Auto Scaling (EC2: puntos clave para Launch Template + ASG + ALB)

# Launch Template
aws ec2 create-launch-template \
  --launch-template-name web-lt \
  --launch-template-data '{
    "ImageId":"ami-xxxxxxxxxxxxxxxxx",
    "InstanceType":"t3.small",
    "IamInstanceProfile":{"Name":"ec2-app-role"},
    "SecurityGroupIds":["sg-xxxxxxxx"],
    "UserData":"'"$(base64 -w0 user-data.sh)"'"
  }'

# Auto Scaling Group (2 AZs, seguimiento de objetivo CPU 50%)
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --launch-template LaunchTemplateName=web-lt \
  --min-size 2 --max-size 6 --desired-capacity 2 \
  --vpc-zone-identifier "subnet-a,subnet-b"

aws autoscaling put-scaling-policy \
  --auto-scaling-group-name web-asg \
  --policy-name cpu50 \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{"PredefinedMetricSpecification":{"PredefinedMetricType":"ASGAverageCPUUtilization"},"TargetValue":50.0}'

12. Seguridad y gobernanza operativa: “reglas estándar” prácticas

Frontera pública clara: Haz público el ALB; mantén instancias EC2 privadas. Evita exponerlas directamente a Internet.
Cero credenciales embebidas: Usa siempre IAM Roles/Managed Identity/Service Accounts; nunca guardes claves en variables/archivos.
IMDSv2/protección de metadata: Obligatorio contra SSRF. Controla acceso a metadata también en GCE/Azure.
Parcheo: Usa SSM Patch Manager, etc., con calendarios regulares. En emergencias, aplica blue/green por etapas.
Centraliza logs: Envía logs de app a CloudWatch Logs (o equivalentes en GCE/Azure). Supón logs estructurados para mejorar observabilidad.

13. Diseño de disponibilidad en la práctica: 3 patrones

Web de tres capas estándar
- ALB → ASG (app) → RDS/EFS/ElastiCache. Favorece scale-out.
API sin estado + autenticación externa
- ALB + Cognito/IdP para auth; usa despliegues inmutables en el ASG para evitar drift.
HPC/Baja latencia
- Elige el Placement Group adecuado (Cluster/Spread/Partition). Para almacenamiento, instance store + FS paralelo.

En GCE/Azure, los fundamentos se mantienen: LB + grupo de escalado + estado externalizado (BD/Cache).

14. Errores comunes y cómo evitarlos

Ir a producción en una sola AZ: Caída total ante fallo. Trata ASG + multi-AZ como “línea mínima”.
Bastiones de larga vida: Caldo de cultivo de riesgo. Muévete a SSM Session Manager/IAP/Bastion JIT.
Secretos en instancias: Claves en env/archivos. Migra a Parameter Store/Secrets Manager/Key Vault/Secret Manager.
Mantener estado local: Bloquea el escalado. Lleva a EBS/EFS/objeto/BD externa.
Proliferación de snapshots: Define generaciones/retención/etiquetas y poda regularmente.
Monitorización reactiva: Define SLO/SLI/alertas antes del lanzamiento.

15. Lista de verificación de diseño (asegura en la primera semana)

Objetivos: Define con números distribución AZ / rendimiento (p95) / tiempo de recuperación / límites operativos.
Instancias: Familia/tamaño/modelo de precio, gestión de AMI, user data.
Almacenamiento: Tipo EBS/IOPS/snapshots/cifrado, necesidad de FS compartido.
Red: VPC/CIDR/subredes, SG/NACL/rutas, DNS/resolución de nombres.
Seguridad: Roles IAM/IMDSv2/gestión de claves, SSM para operar sin bastión.
Escalado: Capacidad/políticas del ASG, health checks, método de despliegue (Rolling/Blue-Green/Canary).
Monitorización: Métricas/recogida de logs/tableros/alertas, necesidad de tracing.
Coste: Rightsizing/horarios de parada/cobertura Spot, política de Savings/RI.
Gestión de cambios: IaC (Terraform/CloudFormation/Bicep/DM) y pasos de revisión.
Plan de salida: AMI/snapshots/migración de datos, limpieza de DNS/certificados/monitorización.

16. Runbook operativo (patrón de primera respuesta a incidentes)

Detección: Verifica rápido detalles de alerta y alcance de impacto (AZ/ASG/targets).
Auto-recuperación: Confirma reemplazo en curso del ASG y recuento sano de targets en el LB.
Mitigación temporal: Baja umbrales de scale-out y añade capacidad extra.
Aislar causa raíz: Compara deploy/AMI/user data/dependencias externas (BD/Cache) recientes.
Arreglo permanente: Mejora health checks, límites de recursos (ulimit) y añade puntos de observabilidad.
Postmortem: Registra aprendizajes en dashboards/runbooks y actualiza etiquetas/nombres/políticas.

17. Casos de estudio (3 ejemplos)

17.1 Plataforma de API de startup (plazo ajustado)

Arquitectura: ALB → ASG (familia de propósito general) → RDS (gestionado) → CloudWatch.
Claves: Horneado de AMI + user data para reproducibilidad; paradas nocturnas para costo.
Otras nubes: En GCE, MIG + HTTP(S) LB + Cloud SQL; en Azure, VMSS + AppGW + Azure Database.

17.2 Batch de procesamiento de imágenes (prioridad costo)

Arquitectura: SQS (cola) → flota de instancias Spot → resultados a S3.
Claves: Manejo de interrupciones y reintentos; guarda checkpoints en S3.
Otras nubes: Usa GCE/Azure Spot VMs + colas (Pub/Sub / Storage Queue) de forma similar.

17.3 Migración escalonada de sistemas internos core (seguridad primero)

Arquitectura: ASG (min 1 / max 1) para auto-curación → escalar a multi-AZ al crecer la carga.
Claves: Operación sin bastión con SSM, define fecha base de parches; guarda logs de auditoría en otra cuenta.
Otras nubes: GCE OS Config/Shielded VM, Azure Update Management/Defender for Cloud para postura comparable.

18. Resumen comparativo de tres nubes (visión del practicante)

Claridad en opciones de diseño: GCE (custom types sencillos) ≧ EC2 (patrones ricos) ≧ Azure (opciones amplias; depende del diseño)
Gobernanza empresarial/afinidad de red: Azure ＞ EC2 ≧ GCE
Madurez del autoescalado: EC2 (ASG maduro + muchos ejemplos) ≧ GCE (MIG simple) ≧ Azure (VMSS con muchas funciones)
Consistencia operativa (sin bastión/trazabilidad): EC2 (SSM/CloudTrail) ≧ Azure (JIT/Bastion/Activity) ≧ GCE (OS Login/IAP/Audit Logs)
Flexibilidad en optimización de costos: EC2 (combinaciones Savings/Spot) ≧ GCE (Committed/Sustained/Spot) ≧ Azure (Reserved/Spot)

19. Lectores previstos y resultados concretos

Departamentos de TI (migración de VMs on-prem): Establece migración equivalente → auto-curación → monitorización/parcheo/auditoría estandarizados en EC2 usando el patrón ASG + SSM.
Desarrolladores web/negocio: Aprende API sin estado + estado externalizado, y entrega seguro con rolling/canary.
Ingenieros SRE/infraestructura: Con VPC/SG/IMDSv2/agregación de logs como base, construye alertado basado en SLO.
Responsables de seguridad/gobernanza: Define barandillas globales para sin secretos en hosts, acceso sin bastión y retención de auditoría.
Líderes técnicos de startups: Setup mínimo viable → “patronización” → IaC, para construir una plataforma pequeña al inicio, amplia al escalar rápidamente.

20. Resumen: EC2 se mantiene firme cuando lo ejecutas como “patrón”

Al operar Amazon EC2 con el patrón repetible ASG + ELB + Launch Template, podrás equilibrar mejor disponibilidad, rendimiento y costo. Centra el almacenamiento en EBS, externaliza el estado y usa SSM para acceso sin bastión. Cuanto más sigas estos principios, con más confianza podrás reemplazar para recuperar durante incidentes y manejar despliegues y escalado sin miedo.
La misma mentalidad de diseño aplica entre nubes mapeando a MIG/VMSS. Empieza llevando a IaC el setup mínimo, luego optimiza costos en el orden medir → rightsizing → aplicar descuentos.

Apéndice A: cloud-init (servidor web mínimo)

#cloud-config
package_update: true
packages:
  - nginx
write_files:
  - path: /var/www/html/healthz.html
    content: "ok"
runcmd:
  - systemctl enable nginx
  - systemctl start nginx
  - printf "location /healthz { return 200 'ok'; add_header Content-Type text/plain; }" \
      > /etc/nginx/snippets/healthz.conf
  - 'sed -i "/server_name _;/a include snippets/healthz.conf;" /etc/nginx/sites-available/default'
  - systemctl reload nginx

Apéndice B: Grupos de seguridad (mínimo, acceso solo desde ALB)

# SG de app: permite 80/TCP solo desde el SG del ALB
APP_SG=$(aws ec2 create-security-group --group-name app-sg --description "app" --vpc-id vpc-xxx --query GroupId --output text)
ALB_SG=$(aws ec2 create-security-group --group-name alb-sg --description "alb" --vpc-id vpc-xxx --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id $APP_SG --protocol tcp --port 80 --source-group $ALB_SG
aws ec2 authorize-security-group-ingress --group-id $ALB_SG --protocol tcp --port 80 --cidr 0.0.0.0/0

Apéndice C: Procedimiento simple semanal de rightsizing

Usa CloudWatch/Monitoring y el Agent para visualizar CPU/memoria/disco/red.
Si durante dos semanas consecutivas ves CPU p95 < 40% y memoria p95 < 60%, considera bajar un nivel.
Confirma holgura con una prueba de carga, luego reduce tamaño. Aplica rolling updates en el ASG para cero downtime.
Cada tres meses, revisa la cobertura de modelos de descuento (Savings/RI/Committed/Reserved).

Apéndice D: Plantillas de estrategia de despliegue (Rolling/Blue-Green/Canary)

Rolling: Aumenta el equivalente a MaxSurge en el ASG y reemplaza en secuencia. Riesgo bajo.
Blue-Green: Prepara un ASG nuevo por separado → cambia target groups. Rollback simple.
Canary: 1 instancia → subconjunto pequeño → todas. Decide por etapas usando métricas/logs/trazas.
Común: Documenta claramente URLs de health check/orden de migración de BD/feature flags en el runbook.

Apéndice E: Tres cosas que puedes hacer hoy

Crea un Launch Template, pon cloud-init en user data y haz lanzamientos reproducibles.
Asegura auto-curación primero con un ASG (min 1 / max 1). Añade ALB en el siguiente paso.
Habilita SSM Agent + Session Manager, retira bastiones y distribución de claves, y configura la recogida de logs al mismo tiempo.

—Con esto, tu segundo paso con EC2 queda muy sólido. La próxima vez cubriremos AWS Lambda, comparándolo con Cloud Functions/Azure Functions también. ¡Atento!