AWS
Por qué lo recomiendo como la conversación de nube por defecto para operadores de red y seguridad
He trabajado en AWS, Azure y GCP a profundidad de conocimiento práctico multi-cloud, no como especialista puro de AWS, pero lo suficiente en deployments reales para saber dónde la plataforma vale lo que cuesta y dónde castiga los atajos. Este es el caso que les hago a los clientes que evalúan su primer compromiso serio de nube para cargas de red y seguridad, y la forma del costo que ningún vendedor imprime en su brochure.
Por qué AWS funciona
Cuatro razones se sostienen en todos los deployments.
Primitivas de networking que componen
VPC, Transit Gateway, PrivateLink y Direct Connect. Una vez que internalizas las cuatro, casi cualquier topología que construirías on-prem tiene un equivalente gestionado: hub-and-spoke, aislamiento multi-cuenta, puente híbrido, micro-segmentación a nivel de servicio.
La primera vez que una pequeña malla de cuentas converge sobre un solo Transit Gateway con servicios compartidos en una VPC, la simplificación operacional es inconfundible. La matriz de peering que solías dibujar en una pizarra colapsa en un solo attachment por cuenta.
Portafolio de seguridad con peso de auditoría
GuardDuty para detección de amenazas sobre VPC flow logs, DNS y CloudTrail. Security Hub para agregación tipo CSPM-lite. IAM Identity Center para SSO con federación a Entra y Okta. Macie para clasificación de datos en S3. Cada uno carga peso de auditoría; juntos reemplazan varias herramientas de terceros.
Entregarle a un auditor hallazgos de GuardDuty más controles de Security Hub más logs de CloudTrail cubre la mayor parte de un set anual de controles SOC 2 sin un SIEM de tercero. La plataforma está haciendo trabajo de auditoría por el que antes pagabas aparte.
Identidad que se integra con lo que ya tienes
IAM Identity Center federa limpiamente con Entra ID, Okta y Google Workspace. No hay que reinventar tu IDP para correr AWS, y no hay que mantener un directorio paralelo solo-cloud que se desincronice de la fuente de verdad.
El problema doloroso de "somos dueños de la identidad de AWS Y de la identidad on-prem Y de la identidad SaaS de terceros" se disuelve una vez que Identity Center es el broker. Un alta en RRHH, un offboard, cuatro planos afectados.
Credibilidad multi-región para LATAM
São Paulo (sa-east-1) es el ancla regional para la mayoría de cargas LATAM. Las Local Zones de Bogotá y Santiago extienden el alcance de baja latencia sin forzar el compromiso de una segunda región completa.
La latencia desde una oficina de Caracas a sa-east-1 típicamente aterriza alrededor de 130–160ms: no es excelente, pero es funcional para cargas que no son en tiempo real, y muy superior al round-trip de 210ms+ contra us-east-1. El ancla regional importa más de lo que sugiere el mapa de marketing.
Dónde encaja mejor
No para todas las empresas. El encaje es más nítido cuando uno de estos te describe:
Equipos con al menos madurez baseline de operaciones de red y seguridad. Alguien que sabe qué es una route table y cómo se ve una política de menor privilegio. AWS premia ese modelo mental y castiga el enfoque de "vamos a levantar lo que sea".
Aislamiento por equipo, por ambiente, por clase de datos. Organizations más Control Tower es el camino; el account vending y las SCP como guardrails pertenecen a la fundación, no a un refactor del segundo año.
Direct Connect para ancho de banda predecible y menor egress, Site-to-Site VPN para caminos de respaldo resilientes o sucursales pequeñas. El puente a on-prem deja de ser un experimento científico una vez que Transit Gateway termina ambos.
SOC 2, ISO 27001 y prep de PCI se aligeran drásticamente cuando los servicios gestionados de AWS cargan un buen pedazo de los controles. El auditor ya vio los paquetes de evidencia de AWS antes.
Si tu stack ya es Microsoft 365 + Entra ID y Azure se siente como la siguiente puerta, la evaluación de Microsoft puede ser la primera conversación más honesta.
Los tradeoffs honestos
Marketing no va a imprimir estos. Yo sí, en producción. Toca para expandir.
Forma del costoEl cómputo es predecible; el movimiento de datos es la sorpresa
El NAT Gateway cobra por GB procesado, el tráfico cross-AZ se factura en ambas direcciones, la ingesta de CloudWatch Logs tiene precio por GB, y el egress de salida a internet tiene su propio medidor. La factura del primer mes casi siempre expone una línea malentendida, usualmente NAT o CloudWatch. Corre Cost Explorer en la primera semana, configura alertas de Budgets antes de que aterrice la primera carga, y trata al egress como una restricción de diseño, no como una nota al pie.
Complejidad de IAMLas políticas de IAM son poderosas e implacables
Wildcards, ARNs de recursos, conditions, SCPs a nivel de Organization, permission boundaries, session policies. Acertar al menor privilegio requiere diseño intencional. El camino de recuperación desde una política sobre-permisiva es más difícil que el camino desde una demasiado restrictiva, porque el blast radius de la primera solo aparece en una revisión post-incidente. Diseña el modelo de política antes de empezar a hacer click; revísalo otra vez después del primer trimestre.
Sprawl de servicios200+ servicios, y saber cuál resuelve el problema es un skill aparte
Tres servicios de colas, cuatro formas de correr contenedores, varios data stores adyacentes. El catálogo premia profundidad, no amplitud: elige los pocos servicios que encajan con tu problema real y resiste la tentación de pasear por el resto. La respuesta correcta es casi siempre menos servicios elegidos deliberadamente, con una racional escrita de por qué cada uno está en el stack. De lo contrario el diagrama de arquitectura deriva en un tour de features y nadie puede explicar por qué.
Lock-inLos servicios gestionados más allá de cómputo y almacenamiento reducen la portabilidad rápido
Una vez que adoptas DynamoDB, EventBridge, Step Functions, Cognito, o el stack analítico más profundo, la portabilidad se estrecha rápido. No es único de AWS (el mismo cálculo aplica a Azure y GCP) pero vale entrar con los ojos abiertos. El framing honesto es que estás cambiando portabilidad por profundidad operacional, y ese cambio está bien siempre que el equipo lo haga deliberadamente y no por accidente siguiendo lo que sugería la documentación esa semana.
AWS premia la arquitectura intencional. La misma profundidad que lo hace poderoso es lo que castiga el enfoque de "vamos a levantar lo que sea".
¿Es lo correcto para tu empresa?
Cuatro dimensiones para revisar antes de comprometerte:
- Tamaño: 50–10.000+ empleados con apetito de operaciones de red y seguridad. Las jugadas puras de startup serverless son otra conversación; quieren defaults distintos y se apoyan más en PaaS gestionado que lo que esta evaluación asume.
- Madurez de IT: Al menos un ingeniero que haya leído el Well-Architected Framework y esté dispuesto a diseñar antes de hacer click. La plataforma premia a los equipos que dibujan la arquitectura en papel primero, y absorbe el costo de los equipos que no, solo que más lento y más caro.
- Stack existente: On-prem moviéndose a la nube, O ya cloud-native consolidando, O multi-cloud racionalizando. Si estás profundamente alineado con Microsoft, corre la evaluación de Microsoft / Azure en paralelo antes de comprometerte.
- Geografía: Global. LATAM tiene sa-east-1 más Local Zones en Bogotá y Santiago; el soporte en inglés es fuerte, y el soporte enterprise en español está disponible a través de partners con manos locales. EU tiene la historia más fuerte de residencia de datos; APAC es maduro en la mayoría de países.
Si tres de las cuatro coinciden, AWS está en la shortlist. Si las cuatro coinciden, probablemente es la respuesta correcta.
Quién lo implementa
Internamente, el implementador líder debería ser un arquitecto de nube o ingeniero de red senior con exposición real a AWS. SAA-C03 (Solutions Architect Associate) es el baseline práctico para el equipo; SAP-C02 (Solutions Architect Professional) para el líder en trabajo de multi-cuenta o Transit Gateway. Las decisiones tomadas en la semana uno (estructura de cuentas, broker de identidad, topología de red, guardrails baseline) son caras de refactorizar una vez que las cargas de producción dependen de ellas, y la profundidad de la cert mapea directamente a qué tan confiadamente se toman esas decisiones.
La ayuda externa vale la pena para el primer build de landing zone. Un AWS Partner que ya haya shippeado deployments de Control Tower, account vending y los guardrails baseline de SCP cinco veces te ahorra el costo de descubrimiento en las partes que se ven simples en los docs y no lo son en la práctica. Los consultores independientes (yo incluido) juegan un rol también, especialmente en las capas de red e identidad donde la forma del deployment es más contenida y las decisiones de arquitectura se benefician de un segundo par de ojos.
Si estás levantando tu primera landing zone de AWS o migrando cargas desde on-prem, hablemos. Arrancamos con una llamada de scoping de 30 minutos; si encaja, especificamos el engagement desde ahí.
Primeros pasos
- Lee la evaluación de Microsoft 365 + Entra ID + Intune primero si eres una empresa de Office. El camino de nube más limpio para organizaciones alineadas con Microsoft puede ser Azure en vez de AWS; el broker de identidad ya está en su lugar y la fricción es menor. En el peor caso confirmas que AWS es la respuesta; en el mejor caso te ahorras un año de trabajo de integración.
- Elige la carga de entrada y arranca pequeño. Mi secuencia recomendada:
- VPC + Transit Gateway. Baseline de networking antes que cualquier otra cosa. Las decisiones de topología son caras de deshacer.
- IAM Identity Center + federación SSO. Baseline de identidad antes de que aterricen las cargas. Federa a tu IDP existente, no construyas uno paralelo.
- GuardDuty + Security Hub + CloudTrail. Baseline de visibilidad antes de escalar. Quieres logs el día que la primera carga corre, no el día después del primer incidente.
- Cost Explorer + Budgets. Baseline financiero antes de la primera factura grande. Las alertas al 50%, 80% y 100% de la expectativa mensual no son opcionales.
- Engancha un AWS Partner para el deployment de la landing zone. Control Tower, Organizations y SCPs hechos bien en el día uno te ahorran migraciones después. El margen del partner es pequeño al lado del costo de refactorizar una estructura de cuentas después de que las cargas de producción ya se mudaron.
Más allá de los primeros pasos: tomo trabajo de red y seguridad en AWS para clientes SMB y mid-market en LATAM y remoto globalmente. Hablemos de tu roadmap de nube. Te digo en 30 minutos si es trabajo de AWS, trabajo de Azure, o trabajo de “arregla lo que ya tienes”.