- Para entender los elementos complejos del panel de VPC de AWS, se creó un mapa mental que permite ver de un vistazo la relación entre los recursos de redes de AWS
- Tomando como referencia principal AWS Networking Fundamentals de Toni Pasanen, se organizaron los recursos relacionados con redes enfocándose en su estructura de conexiones
- La razón por la que las redes de AWS se vuelven complejas es la variedad de tipos de conexión, que incluyen conexiones entre cuenta y on-premises, cuenta a cuenta, VPC a VPC, subred a subred, VPC a internet y VPC a servicios de AWS
- El resultado es un mapa mental que conecta entre sí los componentes de redes de AWS, y también se puede consultar el original en Lucidchart
- Los desarrolladores que están ordenando por primera vez las redes de AWS pueden usarlo para entender visualmente cómo se relacionan los distintos recursos
Confusión que comenzó en el panel de VPC
- Hasta antes de marzo de 2023, era difícil entender qué estaba pasando en el panel de VPC de AWS
- Había tantos elementos que la barra de desplazamiento del panel izquierdo era larga, y resultaba complicado identificar cómo se conectaba cada recurso
Material de referencia y enfoque de organización
- Para entender los distintos recursos involucrados en las redes de AWS, se leyó en su mayor parte AWS Networking Fundamentals de Toni Pasanen
- Después de leer el libro, se concluyó que la razón de que existan tantos recursos de redes de AWS es la gran cantidad de formas de conexión posibles
Tipos de conexión que se manejan en las redes de AWS
- Las redes de AWS incluyen varios tipos de conexión
- Conexión entre una cuenta de AWS y un entorno on-premises
- Conexión entre cuentas
- Conexión entre VPC
- Conexión entre subredes
- Conexión entre una VPC e internet
- Conexión entre una VPC y servicios específicos de AWS
Resultado del mapa mental
- Para unir todas las piezas, se creó un mapa mental de los conceptos de redes de AWS
- El original editable se puede ver en el enlace de Lucidchart
- Se solicita retroalimentación sobre si es útil y si tiene errores
1 comentarios
Comentarios en Hacker News
No entiendo por qué la depuración de políticas IAM y problemas de autenticación en AWS es tan desastrosa
Si alguien quiere competir, aquí es donde debería enfocarse. Perdí horas tratando de encontrar la causa de un error de falta de permisos, y la documentación oficial te dice que revises manualmente como 8 políticas distintas que podrían estar aplicando, como SCP, IAM, políticas de recursos, etc.
Al final, incluso cuando encuentras la documentación para usar Athena y CloudTrail, la mitad de las solicitudes faltan sin razón, y aunque el mensaje de error tenga un ID de solicitud, no se puede consultar fácilmente con eso. Deberían dejarte buscar directamente por ID de solicitud y mostrar claramente qué política la rechazó
De principio a fin es un completo desastre, y hasta da la impresión de que mantenerlo así ayuda a vender más contratos de soporte
En proyectos personales, salvo casos muy raros, casi siempre elijo otras opciones que dan mucho más valor. Hace unos 10 años AWS se vendía como “nosotros administramos los sistemas, así que despidan a todos los sysadmins”, pero ahora un buen ingeniero DevOps de AWS es caro y difícil de encontrar, y además, si sigues de verdad las recomendaciones de AWS, sobre todo en configuraciones grandes, el costo se dispara muchísimo
Cuando quería dar acceso a una Function App a una base de datos SQL, bastaba con usar el nombre real de la Function App, y si había alias, se podía limitar con el identificador del objeto. Ya no hacen falta contraseñas ni certificados; simplemente funciona
Si además usas cosas como el paquete de autenticación y Application Insights, siempre que sepas leer logs, casi nunca te quedas atorado mucho tiempo preguntándote “¿qué demonios pasó aquí?”
Eso sí, en Azure también tienes que saber de antemano dónde están las trampas, y si no, caes en frustraciones parecidas. Microsoft deja muchas mejores pistas que AWS sobre dónde están esas trampas, pero convenientemente faltan algunas pistas, al punto de que parece que necesitas un mago con 20 años de experiencia para atravesar el último velo y evitar que el costo y la complejidad se multipliquen por 5 o por 10
Depurar cuentas de servicio es todavía más complicado porque a veces hasta hay que reiniciar máquinas o clústeres. Sería increíble tener una herramienta tipo “traceroute de la nube” que te dijera exactamente dónde está el problema
Para ser justos, sí hay herramientas de mínimo privilegio que todavía no he probado: IAM Access Analyzer https://aws.amazon.com/blogs/security/iam-access-analyzer-ma..., AirIAM https://github.com/bridgecrewio/AirIAM, Google Cloud Policy Simulator https://cloud.google.com/policy-intelligence/docs/iam-simula...
Es realmente irritante, y deberían poner a diseñadores UX e ingenieros a diseñarlo, pero no lo hacen
Si ese tipo de servicio se ofrece a los clientes, potencialmente también podría ofrecérseles a atacantes, y de hecho podría violar las políticas de seguridad y cumplimiento de algunas empresas
Aun así, creo que al menos debería poder elegirse si el cliente firma un documento aceptando un riesgo grande, como “hacer cosas peligrosas con el usuario root de AWS”
Como las solicitudes en AWS están tan distribuidas, conceptualmente una arquitectura parecida a GraphQL parece encajar con este tipo de sistema. Tampoco está tan lejos de sistemas de trazabilidad como OTEL.
Por eso me desagrada tener que lidiar con AWS. Aprender esto no es conocimiento técnico, sino conocimiento de producto
Leí la serie TCP/IP Illustrated de principio a fin y la dominé por completo, y ese conocimiento me ha servido durante décadas
En cambio, el conocimiento de AWS, aunque es complejo por sí mismo, me hace resistirme a aprenderlo cada vez. Al ver este diagrama, no me queda claro qué tanto éxito tuvo si el objetivo era simplificar
Por ejemplo, si el objetivo era permitir que clientes empresariales reprodujeran una red empresarial virtual o una red virtual de centro de datos, esas son mucho más complejas que el stack TCP de un cliente
Para usos simples, los valores predeterminados también son simples. En casos complejos sí se necesita conocimiento específico de productos de AWS, pero la mayoría de los conceptos de fondo se comparten con otras nubes o con redes on-premises. Es parecido a aprender el enésimo lenguaje de programación
TCP/IP es conocimiento útil para programadores de redes. En la clase universitaria de redes trabajábamos con redes, subredes, tablas de enrutamiento, protocolos de enrutamiento como RIP, OSPF y BGP, NAT, etc., en equipos reales, y como había mucho patrocinio de Cisco, al final del semestre estábamos al nivel de una certificación CCNA
También aprendimos mucho “conocimiento de producto”, como cómo funcionan los productos de Cisco, pero la mayor parte se me olvidó, y los conceptos centrales se trasladan bien a Azure, AWS y GCP. Las VPC en la nube son el equivalente virtual de redes reales, igual que las máquinas virtuales son el equivalente de máquinas reales
En particular, NAT realmente confunde a la gente. Más básicamente, a muchos ingenieros también les cuesta la notación CIDR o incluso TCP en sí. Por ejemplo, creen que
send()envía el búfer entregado como una sola unidad, o querecv()siempre recibe un “mensaje” completo. También se confunden mucho entre un timeout de conexión y un reset del peerAun así, ojalá no hiciera falta este conocimiento. IPv6 hace las redes tan grandes que elimina gran parte de la planificación del tamaño de subredes. NAT podría desaparecer en el infierno helado. Tampoco quisiera volver a ver VPN nunca más; simplemente usa TLS. También me gustaría eliminar los firewalls de nube que usan direcciones IP como si fueran autenticación y los errores engañosos que eso provoca. Azure es terrible en esta parte
Como mucho software profesional, al principio era simple por necesidad, pero con el tiempo se volvió complejo, y AWS creció rápidamente gracias al atractivo de la infraestructura completamente administrada y bajo demanda, y a los recursos que Amazon le metió
Sigue siendo enorme el valor de no tener que manejar hardware directamente, pero además del precio visible, claramente pagas el costo de conocimiento específico del proveedor, difícil de trasladar
En cambio, hay un montón de conceptos de una sola función como “internet gateway”, “NAT gateway”, “egress only internet gateway” y “transit gateway”. Al final, parece que va a surgir una generación de ingenieros que solo entienden la “nube” y no cómo funciona realmente
Basta con entregarle a AWS todos los componentes “no diferenciadores” y concentrarse en el negocio que sí saben hacer
Si simplemente hubieran ofrecido direccionamiento global normal y firewalls, la mayor parte de esta complejidad habría desaparecido
Olvidamos con facilidad para qué sirve internet a nivel IP y qué problemas resuelve la arquitectura de extremo a extremo
Lo que AWS enseña como redes “Well-Architected™” en realidad se parece más a una adoración rentable de la carga, y lleva a complejidad, laberintos de redes 10.x parecidas entre sí, choques de direcciones, proxies improvisados cuando intentas hacerlas comunicarse, menor seguridad real y dependencia del proveedor. La complejidad es enemiga de la seguridad
No es que los antiguos administradores de sistemas ganaran la mitad o una cuarta parte de mi compensación; normalmente una sola persona administraba suficiente hardware como para cubrir a 100 desarrolladores. El overhead para que el resto evitara esta expansión de alcance y el daño cerebral era algo así como 0.5%
En AWS está ocurriendo otra vez, literalmente, la muerte de la especialización
Y el direccionamiento global y los firewalls, ¿no son básicamente posibles si creas una VPC con solo una subred pública y usas los security groups como firewall? La práctica recomendada son subredes públicas/privadas y gateways NAT, pero no me parece imposible depender solo de security groups
Eso también está detrás de una IP anycast global
Por eso surge mucha de la complejidad innecesaria que vemos en redes de nube
Parece que este mapa mental podría simplificarse aún más con unos cuantos conceptos de redes.
Entonces desaparecerían la mayoría de las relaciones y flechas, y los conceptos de AWS podrían mapearse también a otras nubes o incluso a una red doméstica.
https://news.ycombinator.com/item?id=18925350 es un recurso que visualiza muy bien lo básico. Si empiezas por qué es una red y qué es dentro y fuera, el modelo mental se vuelve mucho más sencillo, y las funciones de AWS tienen bastante sentido incluso sin conocer todos los detalles.
Al final resume un sistema complejo de forma clara y concisa. Es un recurso al que voy a volver la próxima vez que me toque abrirme paso por la selva de AWS.
Por ejemplo, una subred dentro del rectángulo de una zona de disponibilidad, con la VPC por fuera, y ese rectángulo dentro de la región. Más o menos así, aunque mejor dibujado: https://images.edrawsoft.com/articles/aws-diagram-examples/e...
Recuerdo los tiempos emocionantes de los inicios de la nube, cuando el networking de AWS era simple.
Aun así, se veía venir esto. Si quieres ser todo para todos, al final no te queda otra que replicar la locura del networking de centros de datos heredados con IPv4.
Hace poco intenté hacer algo conceptualmente simple en Azure: no dejar una cuenta de almacenamiento con respaldos de base de datos expuesta a internet para que cualquiera pudiera meterle mano.
Pensé que bastaría con activar el firewall, pero en la lista de permitidos solo se podían poner subredes, y además había que agregarlas una por una. No servía una red virtual completa, ni tampoco “todas mis redes virtuales”, que sí funciona en otros lados.
También está la función de Private Endpoint, pero degrada el rendimiento y cuesta extra. Supongo que cambiar una dirección de “public” a “private” en una red definida por software debe ser tan difícil que hay que recompensar a los duendes de la nube.
Pero en la práctica ni siquiera funciona. Como había que sobrescribir el DNS para que el cliente lo encontrara, lo conecté al dominio de AD y entonces los servicios PaaS ya no podían acceder.
Al final se me fue una semana creando una zona DNS privada, que también cuesta más, conectándola a la red hub, agregando además el servicio DNS Resolver, que también cuesta más, y configurando una enorme cantidad de reglas para que el dominio de AD siguiera funcionando.
Lo único que quería era que, si se filtraba la clave de almacenamiento, un hacker ruso no pudiera acceder a los respaldos. Tal vez la próxima semana logre actualizar la plantilla de suscripción para volver a desplegar la red virtual con la configuración DNS actualizada. ¿Que no es idempotente? Quizá salga en vista previa el próximo año.
Luego, para lo que sí deba ser público, puedes usar un public gateway o Front Door. No me encanta, pero tampoco es que antes no fuera muy complejo. Solo que ahora los desarrolladores están mucho más expuestos al caos absoluto del networking empresarial, que antes era estrictamente trabajo de operaciones.
Le digo magia porque es una parte de la configuración DNS que no tocas directamente. Sobre todo si usas App Service y varias suscripciones, no puedes compartir subredes y tienes que planear con anticipación para no quedarte sin espacio de direcciones IP al usar slots de aplicación.
Lo que no entiendo de Azure es por qué el valor predeterminado empresarial no es “nada en internet”. Deberías abrirlo cuando necesites exponerlo a internet. De todos modos, poner algo en internet ya es un proceso complejo porque requiere varias configuraciones como balanceadores de carga. Como mínimo, aunque sea en la configuración empresarial, lo predeterminado debería ser quedar fuera de internet.
No sé si Microsoft lo hace difícil porque vende certificaciones de Azure, pero no entiendo por qué en 2023 haya que preocuparse por esta complejidad desde la configuración por defecto. Que sea muy customizable está bien.
Este material está muy bueno. Siempre me ha parecido que la documentación de Google Cloud introduce este tipo de complejidad relativamente bien cuando hace falta, pero nunca había visto una vista general tan completa como esta.
Eso sí, para ver la imagen hubo que batallar bastante. En la página sale demasiado pequeña y ni siquiera se puede hacer clic; si la abres en una pestaña nueva, te manda a una página inútil estilo imgur y sigue viéndose chica. Al final tuve que descargar la imagen para poder verla bien.
Este material es increíble. Muestra muy bien lo poderosos que pueden ser los mapas mentales y los diagramas al aprender productos de nube u otros conceptos.
Los usé mucho cuando estudiaba para certificaciones de AWS, y aunque escribiera notas largas, entendía muchísimo mejor al ver los servicios conectados en un mapa que como una simple sucesión de páginas. Claro, cada quien aprende de forma distinta.
No termino de entender todas las críticas de este hilo. La mayoría de los sistemas de red que ofrece AWS se usan cuando hacen falta.
Puede que no sean elegantes, pero hacen el trabajo. Además, una buena parte de los componentes específicos de AWS corresponde directamente a conceptos reales de redes. Una AZ es un cage, una VPC es una VLAN y un PL equivale más o menos a una VPN P2P entre cuentas.
La mayor parte de lo demás también son componentes de red normales que verías en cualquier entorno grande.
La empresa donde trabajo opera una red global bastante compleja y se conecta con AWS por DX desde varios PoP. Usamos todo lo que aparece en este diagrama y cada componente tiene un propósito bien definido.
Si este diagrama te parece excesivamente complejo, probablemente sea porque no usas todo esto, no lo usas para el propósito previsto o simplemente no eres un ingeniero de redes.
¿De verdad hay alguien que pueda leer la imagen? Incluso en escritorio no logro verla con una resolución legible.
https://miparnisariblog.files.wordpress.com/2023/03/aws-netw... sigue siendo una página web, y aunque la imagen es más grande, no se vuelve más fácil de leer.
Aun así, si la guardas al menos funciona. Después de eso, necesitas una pantalla grande. Mide 7,763 × 4,684 píxeles.
Se ve tremendamente complejo. De las tres grandes empresas de nube, solo conozco GCP; incluso ahí el networking no es simple, pero al menos es hasta cierto punto intuitivo y consistente
Estaría bueno que alguien con más experiencia en multicloud comparara, entre las Big 3, qué tan fácil o difícil es configurar la comunicación interna y externa
No es algo sorprendente, porque la mayoría también tiene equivalentes directos en los propios estándares de networking. Al final, ambos son solo maneras de ver el mundo del software-defined networking