Actualización editorial: artículo original de 2017, reescrito y ampliado el 31 de octubre de 2026.
Amazon Web Services (AWS) es una plataforma de nube pública que entrega infraestructura, plataformas administradas y servicios de aplicación bajo demanda. La idea central no es “alquilar un servidor en Internet”, sino consumir capacidades mediante API: cómputo, almacenamiento, red, bases de datos, analítica, integración, seguridad, inteligencia artificial y muchas otras.
Ese modelo cambia la forma de operar tecnología. La infraestructura puede describirse como código, aprovisionarse en minutos, medirse con telemetría y ajustarse a la demanda. A cambio, el cliente debe diseñar con disciplina: una cuenta sin gobierno, permisos amplios o recursos sin etiquetas puede escalar problemas con la misma rapidez con la que escala aplicaciones.
1. Regiones, zonas de disponibilidad y puntos de presencia
Una Región es un área geográfica independiente. Dentro de ella existen varias Zonas de Disponibilidad (AZ), cada una formada por uno o más centros de datos con energía, conectividad y operación separadas. Los servicios regionales permiten distribuir una aplicación entre AZ para reducir el impacto de la falla de un edificio o de una zona completa.
Los puntos de presencia acercan servicios como Amazon CloudFront, Route 53 y AWS WAF a los usuarios. La elección de Región afecta latencia, precio, disponibilidad de servicios, residencia de datos y requisitos regulatorios. Por eso debe ser una decisión arquitectónica explícita.
2. Las capas principales de una arquitectura AWS
| Capa | Servicios frecuentes | Pregunta de diseño |
|---|---|---|
| Identidad y gobierno | IAM, IAM Identity Center, Organizations, Control Tower, KMS | ¿Quién puede hacer qué, en cuál cuenta y con qué evidencia? |
| Red y entrega | VPC, Transit Gateway, Route 53, CloudFront, Elastic Load Balancing | ¿Cómo entra, sale y se segmenta el tráfico? |
| Cómputo | EC2, Auto Scaling, ECS, EKS, Lambda, App Runner | ¿Necesito controlar el sistema operativo o solo ejecutar código? |
| Datos | S3, EBS, EFS, FSx, RDS, Aurora, DynamoDB, ElastiCache | ¿Qué modelo de consistencia, latencia, durabilidad y recuperación requiere el negocio? |
| Operación | CloudWatch, CloudTrail, Config, Systems Manager, X-Ray | ¿Cómo detecto, explico y corrijo una degradación? |
| Seguridad | GuardDuty, Security Hub, Inspector, Macie, WAF, Shield | ¿Cómo prevengo, detecto y respondo? |
3. Elegir el modelo de cómputo
Amazon EC2
EC2 entrega máquinas virtuales con control del sistema operativo. Es útil para aplicaciones heredadas, productos comerciales certificados, appliances y cargas con requisitos específicos de CPU, memoria, GPU o red. El equipo administra el sistema invitado, parches, agentes, capacidad y estrategia de escalamiento.
Contenedores con ECS o EKS
Amazon ECS ofrece orquestación nativa de AWS. Amazon EKS entrega Kubernetes administrado y resulta apropiado cuando el ecosistema Kubernetes, la portabilidad de manifiestos o herramientas como Helm y operadores son requisitos reales. En ambos casos, AWS Fargate puede ejecutar tareas o pods sin administrar nodos para los escenarios compatibles.
Serverless con AWS Lambda
Lambda ejecuta funciones en respuesta a eventos y cobra según solicitudes y duración. Reduce trabajo de servidores, pero obliga a diseñar pensando en límites, concurrencia, tiempo de inicialización, observabilidad distribuida y servicios externos. Serverless funciona muy bien para integración, automatización, APIs de tráfico irregular y procesamiento asíncrono; no es automáticamente la mejor opción para todo proceso permanente.
4. Almacenamiento: objeto, bloque y archivo
- Amazon S3: almacenamiento de objetos para archivos, respaldos, data lakes y contenido estático. Conviene habilitar versionado, cifrado, políticas de ciclo de vida y bloqueo público cuando corresponda.
- Amazon EBS: volúmenes de bloque asociados a EC2. Se seleccionan por capacidad, IOPS, throughput y patrón de acceso.
- Amazon EFS: sistema de archivos NFS administrado y elástico para clientes Linux.
- Amazon FSx: familias administradas para Windows File Server, Lustre, NetApp ONTAP y OpenZFS.
La copia de seguridad debe ser independiente del mecanismo de alta disponibilidad. Replicar datos entre zonas protege frente a fallas de infraestructura, pero también puede replicar borrados, corrupción o errores de aplicación. AWS Backup, snapshots, versionado y copias entre cuentas o regiones cubren riesgos diferentes.
5. Bases de datos: administrar menos cuando sea posible
Amazon RDS administra tareas como aprovisionamiento, respaldos, reemplazo de host y, según el motor y la configuración, alta disponibilidad. Amazon Aurora es compatible con MySQL o PostgreSQL en la capa de protocolo y ofrece una arquitectura de almacenamiento distribuida propia. DynamoDB es una base NoSQL de clave-valor y documentos con operación completamente administrada.
La decisión no debe comenzar por el nombre del servicio. Primero se definen modelo de datos, transacciones, consistencia, latencia, tasa de escritura, volumen, recuperación, portabilidad y habilidades del equipo. Después se elige el servicio que satisface esas condiciones con menor carga operativa.
6. Identidad, cuentas y gobierno
El usuario raíz de una cuenta debe protegerse con MFA, no usarse para tareas diarias y no tener llaves de acceso permanentes. Las personas deberían autenticarse de forma federada mediante IAM Identity Center o el proveedor corporativo de identidad. Las aplicaciones usan roles con credenciales temporales.
En organizaciones medianas o grandes, una sola cuenta para todo crea un límite de impacto demasiado amplio. AWS Organizations y Control Tower permiten separar producción, desarrollo, seguridad, registros y cargas compartidas. Las Service Control Policies limitan el máximo de permisos disponible, pero no conceden permisos por sí mismas.
# Ejemplo conceptual: verificar la identidad usada por la CLI
aws sts get-caller-identity
# Exigir cifrado y bloquear acceso público se implementa como política,
# controles preventivos y validaciones automatizadas; no como una tarea manual.7. Red: la VPC como límite de conectividad
Una Amazon VPC contiene subredes, tablas de rutas, controles de seguridad y puntos de conexión. Una arquitectura web típica distribuye balanceadores públicos y cargas privadas en al menos dos AZ. Las bases de datos permanecen en subredes privadas y reciben tráfico solamente desde la capa de aplicación.
- Usar Security Groups como firewall con estado y reglas referenciadas entre capas.
- Evitar direcciones públicas en servidores que no necesitan recibir tráfico directo.
- Centralizar salida y conectividad híbrida solo cuando el modelo operativo lo justifique.
- Registrar flujo de red y consultas DNS cuando ayuden a investigación y detección.
- Preferir VPC Endpoints para acceder privadamente a servicios compatibles.
8. Responsabilidad compartida
AWS protege la infraestructura física, las regiones, el hardware y la capa de virtualización. El cliente protege sus identidades, datos, configuraciones y aplicaciones. La frontera cambia según el servicio: en EC2 el cliente también administra el sistema operativo invitado; en un servicio administrado, AWS asume más componentes internos, pero el cliente sigue siendo responsable de accesos, datos y configuración.
La documentación de seguridad de AWS Organizations resume este modelo. “Administrado” significa que AWS opera una parte mayor de la plataforma; no significa que la aplicación quede segura por defecto.
9. Observabilidad y operación
Una plataforma operable combina métricas, logs, trazas, eventos y auditoría. CloudWatch recibe telemetría de recursos y aplicaciones. CloudTrail registra llamadas de API. AWS Config evalúa el estado de configuración. Systems Manager ayuda a administrar flotas sin depender de acceso SSH directo.
Las alarmas deben corresponder a síntomas que requieren una acción. Monitorear cada métrica disponible produce ruido; medir disponibilidad, latencia, errores, saturación y objetivos del negocio produce señales útiles. Cada alarma crítica debe tener dueño, canal, contexto y procedimiento de respuesta.
10. Costos: diseñar antes de optimizar
El costo en AWS combina consumo, almacenamiento, solicitudes, licencias, soporte y transferencia de datos. El precio unitario bajo no garantiza una factura baja si la arquitectura mueve grandes volúmenes entre zonas, conserva snapshots sin política o sobredimensiona recursos.
- Definir etiquetas obligatorias: aplicación, ambiente, dueño y centro de costo.
- Activar Cost Explorer, presupuestos y detección de anomalías desde el inicio.
- Medir utilización y ajustar tamaño antes de comprometer consumo.
- Aplicar Savings Plans o Reserved Instances únicamente sobre una línea base estable.
- Revisar almacenamiento, transferencia y recursos inactivos cada mes.
El Cost Optimization Hub consolida recomendaciones de ajuste, recursos ociosos y compromisos de consumo. Es una entrada para la conversación FinOps, no un reemplazo de la validación técnica.
11. Infraestructura como código
CloudFormation, AWS CDK, Terraform y otras herramientas permiten versionar infraestructura y revisarla como software. El objetivo no es solamente crear recursos: es obtener entornos repetibles, cambios trazables y recuperación verificable.
# Flujo mínimo de entrega de infraestructura
validar → analizar seguridad → generar plan → revisar → aplicar → verificar
# La cuenta de producción no debería depender de cambios manuales
# que no existan en el repositorio y en el historial de despliegue.12. Los seis pilares de una arquitectura bien diseñada
El AWS Well-Architected Framework organiza las decisiones en seis pilares: excelencia operativa, seguridad, fiabilidad, eficiencia del rendimiento, optimización de costos y sostenibilidad. No es una certificación ni una lista para marcar una sola vez; es un método de revisión continua de riesgos y compromisos.
| Pilar | Ejemplo de pregunta |
|---|---|
| Excelencia operativa | ¿Podemos desplegar y revertir de forma repetible? |
| Seguridad | ¿Qué identidad accede a cada dato y cómo queda auditado? |
| Fiabilidad | ¿Qué ocurre cuando falla una AZ o una dependencia? |
| Rendimiento | ¿El servicio elegido responde al patrón real de carga? |
| Costos | ¿Quién es dueño del gasto y qué valor entrega? |
| Sostenibilidad | ¿Estamos usando recursos y datos innecesarios? |
13. Ruta práctica para comenzar
- Crear una landing zone con cuentas separadas, identidad federada y registro central.
- Definir red, DNS, cifrado, etiquetas y controles mínimos como productos reutilizables.
- Elegir una carga de bajo riesgo y documentar requisitos, RTO, RPO y presupuesto.
- Implementar por código con pipeline, pruebas y observabilidad.
- Ejecutar pruebas de falla y recuperación antes de declarar producción.
- Revisar la carga con Well-Architected y convertir riesgos en trabajo priorizado.
Conclusión
AWS sirve cuando convierte infraestructura en una capacidad repetible y gobernada. El valor no proviene de usar la mayor cantidad de servicios, sino de elegir los mínimos necesarios, comprender sus límites y operarlos con seguridad, evidencia y control financiero. Una buena arquitectura de nube hace explícitos sus compromisos: qué automatiza, qué tolera, cuánto cuesta y cómo se recupera.