Cómo crear realmente una arquitectura de nube de AWS segura y fiable sin perder la cabeza

Introducción

Si alguna vez ha intentado diseñar una arquitectura de nube en AWS desde cero, probablemente ya lo sabe: es libertad y caos a partes iguales. Hay mil maneras de construir algo, y otras tantas de meter la pata.

Un breve vistazo a la documentación de AWS puede hacerte pensar: "Genial, nos limitaremos a observar las prácticas de primer nivel". Pero en entornos reales-internacionales, las prácticas de primera clase no a menudo viven en el primer contacto con las necesidades reales de la empresa comercial, los límites de gama de precios, o el error humano. Por eso, trabajar con profesionales como perfsys desde el principio puede evitar que más adelante se juegue a la ruleta con agujeros de protección y complicaciones de escalado.

El objetivo no es sólo conseguir algo que funcione. Se trata de construir un sistema que no se caiga cuando el tráfico se dispare o una región se apague, y que no deje la puerta abierta de par en par a Internet.

Empecemos por lo obvio: AWS es una bestia

Con AWS se puede crear prácticamente cualquier cosa. Desde startups de dos personas a plataformas empresariales en expansión, los bloques de construcción están todos ahí - EC2, Lambda, RDS, S3, IAM, VPCs, y la lista continúa. ¿El problema? Cuantas más opciones tienes, más fácil es crear un lío enredado.

No es que AWS esté mal diseñado. Es que hay que diseñarlo bien. De lo contrario, acabas con lo que algunos equipos llaman "espaguetis en la nube": servicios interdependientes, secretos codificados, sin etiquetado, sin registro y sin ninguna idea de cuánto cuesta cada cosa.

La fiabilidad y la seguridad no son un lujo

Resulta tentador tratar la seguridad y la fiabilidad como problemas del futuro. "Lo aseguraremos después de la puesta en marcha". "Añadiremos la supervisión en el próximo sprint". Pero pregúntele a cualquiera que se haya enfrentado a una violación de datos o a una interrupción de varias horas: saltarse esos pasos es la forma de acabar pasando la noche en vela.

Qué significa realmente la fiabilidad

No se trata de garantías de tiempo de actividad en una presentación de diapositivas. Se trata de ingeniería para el fracaso. Los servicios se caen. Los discos fallan. Las API dejan de funcionar. Lo que importa es si su sistema sigue funcionando cuando las cosas se rompen.

¿Tiene redundancia en todas las zonas de disponibilidad? ¿Puede su sistema tolerar el fallo de un nodo de base de datos sin perder datos ni producir errores? ¿Está ejecutando cargas de trabajo críticas en una única región porque "es lo más fácil de desplegar"? Estas son las preguntas que separan los sistemas que funcionan de los que son resistentes.

¿Y la seguridad? No es sólo IAM

Sí, la gestión de identidades y accesos (IAM) es el primer muro. Pero la seguridad va mucho más allá. Cubos S3 de acceso público. Roles sobre-permitidos. Secretos codificados en funciones Lambda. Registro desactivado "para ahorrar costes". Todo esto son bombas de relojería.

El uso del marco aws well architected puede ayudar a identificar estos problemas antes de que exploten. Desglosa la arquitectura en cinco áreas clave -seguridad, fiabilidad, excelencia operativa, eficiencia del rendimiento y optimización de costes- y obliga a los equipos a evaluar cada una de ellas, honestamente. No es una solución milagrosa, pero obliga a plantearse preguntas difíciles.

Los pilares que realmente importan

Muy bien, entremos en materia. Esto es lo que importa a la hora de crear una arquitectura segura y fiable en AWS, y dónde se equivocan los equipos con más frecuencia.

Utilice los roles de IAM de la forma correcta (sí, de verdad)

Los roles IAM son poderosos. Demasiado potentes, a veces. Es demasiado fácil poner "AdministratorAccess" porque algo no funciona, prometer arreglarlo más tarde... y luego no arreglarlo nunca.

Necesitas bloquear esto desde el principio. El principio del menor privilegio no es sólo una buena práctica, es la única forma sensata de operar. Es decir:

• Funciones delimitadas por servicio

• Evitar comodines en los permisos

• Credenciales efímeras

• MFA obligatorio para usuarios humanos

¿Suena como un dolor? Pues lo es. Pero también lo es explicarle a tu jefe por qué alguien filtró datos de clientes desde un Lambda mal configurado.

Separe su red como si fuera en serio

Esta es otra área donde los atajos son contraproducentes. No necesitas una configuración de red supercompleja, pero algunos conceptos básicos ayudan mucho:

• Subredes públicas sólo para las cosas que deben estar frente a Internet (por ejemplo, ALBs)

• Subredes privadas para todo lo demás

• Pasarelas NAT para el acceso saliente controlado

• Puntos finales de VPC para el tráfico de servicios de AWS sin llegar a la Internet pública

Una VPC plana con todo en la misma subred puede parecer fácil. Hasta que algo se rompe y se lleva todo por delante.

Registro y supervisión: No se puede arreglar lo que no se ve

Esto ya no debería ser objeto de debate. El registro no es opcional. Si no está capturando CloudTrail, métricas de CloudWatch y registros de flujo de VPC, está volando a ciegas.

Pero aquí está el truco: el registro por sí solo no es suficiente. Hay que mirar los registros. Cree alertas para las cosas que importan. Filtre el ruido. Y asegúrese de que los registros están centralizados en todas las cuentas y regiones. La visibilidad fragmentada no es visibilidad.

Cifre todo (sin excepciones)

Utilice KMS para los datos en reposo. Utilice TLS para los datos en tránsito. Rote las claves. Supervise el acceso. Esta es una de esas áreas en las que ser perezoso ahora sale muy caro después.

Y no se olvide de cosas como el cifrado de RDS, la configuración de volúmenes de EBS y la aplicación de TLS de API Gateway. Estos pequeños detalles se acumulan.

Infraestructura como código o fracaso

¿Sigue desplegando haciendo clic en la consola de AWS? Eso está bien para desarrollo, pero es peligroso para producción.

Utilice Terraform, CloudFormation o CDK. Lo que prefiera su equipo, elija uno y cíñase a él. Controla las versiones de tus plantillas. Utiliza CI/CD para desplegar. Automatice las reversiones. Los despliegues manuales son una invitación abierta a cometer errores.

Además: etiquétalo todo. Los recursos sin etiquetas son como cables sin etiquetas: nadie sabe para qué sirven y todo el mundo tiene miedo de tocarlos.

Escalar sin hundirse

Seamos claros: a AWS le encanta que sobreaprovisiones. Tú obtienes "rendimiento", ellos obtienen tu dinero. Escalar de forma eficiente consiste en conocer tus patrones y planificarlos.

Utiliza grupos de autoescalado, instancias puntuales (con cuidado) y capas de caché. Pero lo más importante: haz pruebas bajo carga. Lo último que quiere es descubrir que su instancia RDS se funde bajo tráfico real dos días después de su lanzamiento.

Además, reserve capacidad cuando tenga sentido. Ahorrará dinero y evitará fallos sorpresa en el aprovisionamiento.

Los planes de recuperación ante desastres no son opcionales

¿Qué ocurre si se cae una región? ¿Y si se corrompe la base de datos principal? Si la respuesta es "eh... tendríamos problemas", es hora de replantearse la estrategia de recuperación ante desastres.

Esto no significa construir una copia idéntica de su infraestructura en otra región. Significa saber:

• Qué restauraría

• Cuánto tardaría

• Qué datos se perderían (si los hubiera)

• Quién es responsable de qué durante una conmutación por error

Y sí: debe probar su plan de recuperación. De lo contrario, no es más que ficción.

Antipatrones comunes que hay que evitar

Vamos a repasar algunos de los "no-no" que aparecen con demasiada frecuencia:

• Una gran cuenta para todo: utilice AWS Organizations. Separe prod, dev, staging, etc.

• Dejar intactas las VPC y los grupos de seguridad predeterminados: bloquéelos.

• Confiar demasiado en las instancias t2.micro "para pruebas": acabarán en producción.

• No presupuestar los costes de CloudWatch: sí, el registro cuesta dinero. No registrar cuesta más.

• Dar acceso a "arreglarlo rápidamente": arregle su proceso en su lugar.

¿Palabras finales? Sea flexible y mantenga la cordura

La arquitectura en la nube no consiste en encontrar la configuración perfecta. Se trata de construir algo que sea flexible, robusto y comprensible no sólo para la persona que lo escribió.

Nunca se está realmente "hecho", y eso está bien. Lo que importa es ser intencionado. Hacer preguntas difíciles desde el principio. Auditar con frecuencia. Automatizar lo importante. Y saber cuándo pedir ayuda.

Porque, seamos sinceros, AWS es potente, pero también es fácil perderse en él. Trabajar con ingenieros experimentados que viven y respiran la arquitectura de la nube puede marcar la diferencia entre "funciona, casi siempre" y "dormimos por la noche".

Y para eso merece la pena construir.