Conceitos de networking da AWS em diagramas

• Para entender os itens complexos do painel da AWS VPC, foi criado um mapa mental que permite ver de relance as relações entre os recursos de networking da AWS
• Tomando AWS Networking Fundamentals, de Toni Pasanen, como principal material de referência, os recursos relacionados a networking foram organizados com foco na estrutura de conexões
• O motivo de o networking da AWS se tornar complexo é a variedade de tipos de conexão, incluindo conexões conta-on-premises, conta-conta, VPC-VPC, subnet-subnet, VPC-Internet e VPC-serviços AWS
• O resultado é um mapa mental que conecta entre si os componentes de networking da AWS, e o original no Lucidchart também pode ser consultado
• Desenvolvedores que estão organizando o networking da AWS pela primeira vez podem usá-lo para entender visualmente como vários recursos se relacionam

---

Confusão que começou no painel da VPC

• Até março de 2023, era difícil entender o que estava acontecendo no painel da AWS VPC
• Havia tantos itens, a ponto de a barra de rolagem do painel esquerdo ser longa, que era difícil identificar como cada recurso se conectava

Materiais de referência e direção da organização

• Para entender os vários recursos envolvidos no networking da AWS, foi lida em grande parte a obra de Toni Pasanen, AWS Networking Fundamentals
• Depois de ler o livro, chegou-se à conclusão de que há muitos recursos de networking da AWS porque existem muitas formas possíveis de conexão

Tipos de conexão tratados no networking da AWS

• O networking da AWS inclui vários tipos de conexão
  • Conexão entre conta AWS e on-premises
  • Conexão entre conta e conta
  • Conexão entre VPC e VPC
  • Conexão entre subnet e subnet
  • Conexão entre VPC e Internet
  • Conexão entre VPC e serviços específicos da AWS

Resultado do mapa mental

• Para conectar as várias peças, os conceitos de networking da AWS foram organizados em um mapa mental
• O original editável pode ser visto no link do Lucidchart
• É solicitado feedback sobre sua utilidade e sobre a existência de possíveis erros

[GN⁺]

Opiniões do Hacker News

• Não entendo por que depurar políticas de IAM e problemas de autenticação na AWS é uma bagunça tão grande
  Se alguém quiser virar concorrente, é nisso que deve focar. Perdi horas tentando descobrir a causa de erros de falta de permissão, e a documentação oficial diz para vasculhar manualmente umas 8 políticas que podem se aplicar, como SCP, IAM, políticas de recursos etc.
  No fim, mesmo encontrando documentos que usam Athena e CloudTrail, metade das requisições fica de fora sem motivo, e mesmo quando a mensagem de erro tem um ID de requisição, não dá para consultá-lo facilmente. Deveria ser possível consultar diretamente pelo ID da requisição e ver com clareza qual política a negou
  É um caos completo do começo ao fim, e às vezes parece que manter as coisas assim ajuda a vender mais contratos de suporte

  • Vendo com cinismo, até fico feliz com essa situação. Empresas que embarcaram na onda da AWS estão pagando o preço, e meu salário está incluído nisso
    Em projetos pessoais, salvo raríssimas exceções, quase sempre escolho outras opções que oferecem melhor custo-benefício. Uns 10 anos atrás, a AWS era vendida mais ou menos como “nós gerenciamos os sistemas, então demitam todos os administradores de sistemas”; hoje, um bom engenheiro DevOps de AWS é caro e difícil de encontrar, e, especialmente em configurações grandes, seguir corretamente as recomendações da AWS também custa uma fortuna
  • No Azure, a combinação de identidade gerenciada do sistema e AAD foi realmente conveniente na minha experiência
    Ao conceder a um app de funções acesso a um banco de dados SQL, bastava usar o nome real do app de funções; se houvesse um alias, era só restringir pelo identificador do objeto. Senhas ou certificados não são mais necessários, simplesmente funciona
    Usando pacotes de autenticação junto com coisas como Application Insights, partindo do pressuposto de que você sabe ler logs, quase nunca se fica muito tempo travado no “o que diabos aconteceu?”
    Dito isso, no Azure também é preciso saber de antemão onde estão as minas; se não souber, você cai em frustrações parecidas. A Microsoft deixa pistas sobre a localização das minas muito melhores do que a AWS, mas algumas pistas são convenientemente omitidas, a ponto de ser preciso alguém com 20 anos de experiência, quase um mago, para atravessar o último véu e evitar que custo e complexidade cresçam 5 a 10 vezes
  • Na AWS e no GCP, controle de acesso e privilégio mínimo são realmente difíceis
    A depuração de contas de serviço às vezes exige até reiniciar máquinas ou clusters, o que dificulta ainda mais. Seria incrível ter uma ferramenta tipo “cloud traceroute” que apontasse exatamente onde o problema ocorreu
    Para ser justo, ainda há ferramentas de privilégio mínimo que eu não experimentei: 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...
  • Quase tudo na API da AWS chega perto de ser uma bagunça. Sem nenhum bom motivo, eles embrulham objetos dentro de outros objetos, e depois os embrulham de novo, empurrando para os clientes o trabalho de aprender e implementar estruturas de dados complexas
    É realmente irritante, e isso deveria ser projetado com designers de UX e engenheiros trabalhando juntos, mas não é o que acontece
  • Dar mais informações de depuração em falhas de IAM também significa abrir mais uma camada de informação para atacantes
    Se esse tipo de serviço for oferecido a clientes, potencialmente também pode ser oferecido a atacantes, e pode até violar políticas de segurança e compliance de algumas empresas
    Ainda assim, acho que os clientes deveriam poder optar por isso se assinassem um documento reconhecendo grandes riscos, como “fazer algo perigoso com o usuário root da AWS”
    Como as requisições da AWS são tão distribuídas, conceitualmente uma configuração parecida com GraphQL parece combinar com esse tipo de sistema. Também não fica muito distante de sistemas de rastreamento como OTEL

• Por isso eu detesto ter que lidar com AWS. Aprender isso não é conhecimento técnico, é conhecimento de produto.
  Li a série TCP/IP Illustrated do começo ao fim e a dominei completamente, e esse conhecimento foi útil por décadas.
  Já o conhecimento de AWS é complexo por si só, mas eu acabo me recusando a aprendê-lo toda vez. Olhando este diagrama, não sei o quanto eles tiveram sucesso se o objetivo era simplificação.

  • Se houver uma troca com outros objetivos além de simplicidade, dá para entender melhor.
    Por exemplo, se o objetivo for permitir que clientes enterprise reproduzam uma rede corporativa virtual ou uma rede de datacenter virtual, elas são muito mais complexas do que uma pilha TCP de cliente.
    Para usos simples, os padrões também são simples. Em casos complexos, é verdade que é preciso conhecimento específico dos produtos da AWS, mas a maioria dos conceitos de base é compartilhada com outras nuvens ou redes on-premises. É parecido com aprender a enésima linguagem de programação.
  • Não necessariamente; é mais uma questão de olhar pela lente de outra área.
    TCP/IP é um conhecimento útil para programadores de rede. Nas aulas de redes da faculdade, lidávamos em equipamentos reais com redes, sub-redes, tabelas de roteamento, protocolos de roteamento como RIP, OSPF e BGP, NAT etc., e, com muito patrocínio da Cisco, no fim do semestre chegávamos ao nível da certificação CCNA.
    Também aprendemos bastante “conhecimento de produto”, como o modo de funcionamento dos produtos Cisco, mas esqueci a maior parte disso; os conceitos centrais se transferem bem para Azure, AWS e GCP. Uma VPC na nuvem é o equivalente virtual de uma rede real, assim como uma máquina virtual é o equivalente de uma máquina real.
    Em especial, NAT realmente confunde as pessoas. Mais fundamentalmente, muitos engenheiros têm dificuldade até com notação CIDR ou com o próprio TCP. Por exemplo, acham que o buffer passado para send() é enviado como uma única unidade, ou que recv() sempre recebe uma “mensagem” completa. Também há muita confusão sobre a diferença entre timeout de conexão e reset pelo par.
    Dito isso, eu gostaria que esse conhecimento não fosse necessário. O IPv6 torna as redes tão grandes que elimina boa parte de coisas como planejamento de tamanho de sub-redes. NAT pode desaparecer no inferno gelado. Eu também preferia nunca mais ver VPN, bastaria usar TLS. Também queria eliminar firewalls de nuvem que tratam endereço IP como autenticação e os erros enganosos que isso causa. A Azure é terrível nesse ponto.
  • Vejo isso como a situação do sapo sendo fervido aos poucos. O objetivo da AWS não é simplicidade, é participação de mercado.
    Como muitos softwares profissionais, no começo era simples por necessidade, mas foi ficando complexo com o tempo, e a AWS inchou rapidamente por causa do apelo de infraestrutura totalmente gerenciada sob demanda e dos recursos que a Amazon despejou nela.
    O valor de não precisar lidar diretamente com hardware ainda é grande, mas, além do preço anunciado, você claramente paga o custo de um conhecimento proprietário de fornecedor que dificulta a migração.
  • Acho que teria sido melhor se tivessem usado terminologia padrão. Por exemplo, bastaria um conceito como um roteador virtual, em que fosse possível configurar internet, NAT, conexões com outras VPCs, regras de firewall etc.
    Em vez disso, há um monte de conceitos pontuais como “internet gateway”, “NAT gateway”, “egress only internet gateway” e “transit gateway”. No fim, acho que vai surgir uma geração de engenheiros que só entende “nuvem” e não sabe como as coisas realmente funcionam.
  • É trabalho pesado que não diferencia o negócio. A empresa deixa de precisar treinar e contratar engenheiros com conhecimento profundo de TCP/IP e roteadores de hardware, e de limpar e manter a bagunça depois que eles saem.
    Basta entregar à AWS todos os componentes “não diferenciadores” e se concentrar no negócio em que a empresa é boa.

• Se simplesmente oferecessem endereçamento global comum e firewall, a maior parte dessa complexidade desapareceria.
  Nós esquecemos facilmente para que serve a internet no nível IP e que problemas a arquitetura fim a fim resolve.
  O que a AWS ensina como networking “Well-Architected™” na verdade está mais para um culto à carga lucrativo, e leva a complexidade, labirintos de redes 10.x parecidas entre si, conflitos de endereços, proxies grosseiros quando se tenta fazer uma coisa falar com outra, menor segurança real e dependência de fornecedor. Complexidade é inimiga da segurança.

  • Também não faz sentido pegar um engenheiro sênior com expertise de domínio em resolver problemas de negócio e, graças à “nuvem”, fazê-lo virar DevOps/NetworkOps/SecOps e concluir, em Terraform, soluções de rede, firewall e cibersegurança para a aplicação.
    Não é como se os antigos administradores de sistemas recebessem metade ou um quarto da minha remuneração; normalmente uma pessoa gerenciava hardware suficiente para cobrir 100 desenvolvedores. O overhead para o restante das pessoas evitar esse aumento de escopo e esse dano cerebral era algo como 0,5%.
    Na AWS, está acontecendo de novo, literalmente, a morte da expertise.
  • A expressão “culto à carga lucrativo leva à complexidade” explica de forma elegante a maior parte do que se vê na indústria de tecnologia.
  • Acho que o Amazon Lightsail é meio que isso. Nunca usei de fato, mas pelo que sei ele abstrai a configuração de rede.
    E endereçamento global com firewall não é basicamente possível criando uma VPC só com sub-redes públicas e usando security groups como firewall? A prática recomendada é ter sub-redes públicas/privadas e NAT gateway, mas não me parece impossível depender apenas de security groups.
  • Talvez você esteja falando de um modelo como o do Google Cloud, em que a VPC é global e é possível criar sub-redes regionais por padrão.
    Isso também fica atrás de um IP anycast global.
  • Há aspectos ainda mais complexos que isso. As organizações de segurança de muitas empresas tentam trazer para a nuvem, sem adaptação, os conceitos de segurança que usavam on-premises, e os reguladores muitas vezes fazem o mesmo.
    É daí que vem boa parte da complexidade desnecessária que vemos em networking de nuvem.

• Acho que este mapa mental poderia ser ainda mais simplificado em alguns conceitos de rede
  Com isso, a maior parte das relações e setas desapareceria, e os conceitos da AWS poderiam ser mapeados também para outras nuvens ou para uma rede doméstica
  https://news.ycombinator.com/item?id=18925350 é um material que visualiza muito bem o básico. Se você começa pelo que é uma rede e pelo que é dentro e fora, o modelo mental fica muito mais fácil, e os recursos da AWS passam a fazer bastante sentido mesmo sem conhecer todos os detalhes

  • O diagrama original mostra os serviços oferecidos pela AWS do ponto de vista de quem os planeja diretamente, e, como resultado de um mapa mental, certamente deve ter ajudado o autor a entender a complexidade da AWS
    No fim, ele resumiu um sistema complexo de forma clara e concisa. É um material que vou consultar da próxima vez que precisar atravessar a floresta da AWS
  • Diagramas de rede para AWS basicamente sempre foram desenhados como retângulos aninhados
    Por exemplo, uma sub-rede dentro de um retângulo de zona de disponibilidade, uma VPC fora dele, e esse retângulo dentro de uma região. É mais ou menos assim, mas desenhado de forma mais bonita: https://images.edrawsoft.com/articles/aws-diagram-examples/e...

• Lembro dos tempos empolgantes do início da nuvem, quando a rede da AWS era simples
  Mesmo assim, eu sabia que isso viria. Para ser tudo para todos, no fim não há como escapar de replicar a loucura das redes de datacenter legadas em IPv4
  Recentemente, no Azure, tentei fazer algo conceitualmente simples: não deixar uma conta de armazenamento com backups de banco de dados exposta à internet para qualquer um ficar cutucando
  Achei que bastaria ativar o firewall, mas a lista de permissões só aceitava sub-redes, e ainda por cima era preciso adicionar cada sub-rede individualmente. Nada de rede virtual, e nada daquele “todas as minhas redes virtuais”, que funciona bem em outros lugares
  Também existe o recurso Private Endpoint, mas ele reduz o desempenho e tem custo adicional. Parece que mudar um endereço de “public” para “private” na configuração de uma rede definida por software deve ser difícil, então precisamos recompensar as fadinhas da nuvem
  Só que, na prática, não funciona. Como é preciso sobrescrever o DNS para que os clientes encontrem o serviço, conectei isso ao domínio AD, e aí os serviços PaaS não conseguiam acessar
  No fim, criei uma zona DNS privada, que custa mais, conectei-a à rede hub, adicionei o serviço DNS Resolver, que também custa mais, e passei uma semana configurando um monte de regras para o domínio AD continuar funcionando
  A ideia original era apenas impedir que um hacker russo acessasse os backups caso a chave de armazenamento vazasse. Na semana que vem talvez eu consiga atualizar o template da assinatura para reimplantar as redes virtuais com a configuração de DNS atualizada. Não é idempotente? Talvez saia em preview lá pelo ano que vem

  • Se você configurar um Private Endpoint na VNET e fizer o Azure DNS e o seu próprio DNS conversarem magicamente entre si, dá para fazer o que você quer
    Depois, para exposição pública, você pode usar um public gateway ou o Front Door. Não gosto disso, mas também não é como se antes não fosse extremamente complexo. A diferença é que agora desenvolvedores estão mais expostos ao manicômio insano das redes corporativas, que antes era estritamente trabalho da equipe de operações
    Chamo a configuração de DNS de mágica porque é uma parte em que não mexo diretamente. Especialmente com App Service e várias assinaturas, você não pode compartilhar sub-redes, e precisa planejar com antecedência para não ficar sem espaço de endereços IP ao usar slots de app
    O que não entendo no Azure é por que o padrão empresarial não é “nada na internet”. Você deveria abrir quando precisasse colocar algo na internet. De qualquer forma, é preciso fazer várias configurações, como load balancer, então o processo de publicar algo na internet já é complexo por natureza. No mínimo, em uma configuração empresarial, o padrão deveria ser fora da internet
    Talvez a Microsoft venda certificações de Azure e por isso precise tornar tudo difícil, mas não entendo por que, em 2023, temos que nos preocupar com essa complexidade desde os padrões iniciais. Tudo bem que seja altamente customizável

• Este material é muito legal. Sempre achei que a documentação do Google Cloud introduz esse tipo de complexidade relativamente bem conforme ela se torna necessária, mas nunca vi uma visão geral tão completa assim
  Dito isso, foi bem trabalhoso ver a imagem. Na página ela é pequena demais e nem dá para clicar; ao abrir em uma nova aba, vai para uma página inútil parecida com o imgur e continua pequena. No fim, tive que baixar a imagem para conseguir vê-la direito

• Este material é excelente. Mostra bem como mapas mentais e diagramas podem ser poderosos para aprender produtos de nuvem ou outros conceitos
  Usei muito isso quando estudava para certificações da AWS, e, mesmo escrevendo anotações longas, eu entendia muito melhor vendo os serviços conectados em um mapa do que vendo uma sequência de páginas. Claro que cada pessoa aprende de um jeito

• Não consigo entender todas as críticas neste thread. A maior parte dos sistemas de rede que a AWS oferece é para ser usada quando você precisa deles
  Não é elegante, mas resolve o problema. Além disso, muitos componentes específicos da AWS correspondem diretamente a conceitos reais de rede. AZ é cage, VPC é VLAN, PL é mais ou menos uma VPN P2P entre contas
  A maior parte do restante também são componentes de rede comuns que você veria em ambientes grandes típicos
  A empresa onde trabalho opera uma rede global bastante complexa e se conecta à AWS por DX em vários PoPs. Usamos tudo que aparece neste diagrama, e cada componente tem um propósito bem definido
  Se este diagrama parece excessivamente complexo, provavelmente é porque você não usa tudo isso, não usa para o propósito pretendido, ou então porque não é engenheiro de rede

• Alguém consegue realmente ler a imagem? Estou em um desktop e não consigo vê-la em uma resolução legível
  https://miparnisariblog.files.wordpress.com/2023/03/aws-netw... ainda é uma página web, e a imagem é maior, mas não fica mais fácil de ler

  • Está completamente quebrado. Cliquei em “abrir imagem em nova aba” e ficou desse jeito
    Ainda assim, se salvar, pelo menos funciona. Depois disso, você precisa de uma tela grande. O tamanho é 7.763 × 4.684 pixels
  • Sou o autor do post original; corrigi. Agradeceria se você me avisasse se agora aparece corretamente
  • No celular, tive que pressionar e segurar e depois abrir a imagem em uma nova aba

• Parece incrivelmente complexo. Entre os três grandes provedores de nuvem, só conheço o GCP; lá, networking também não é simples, mas ainda assim é relativamente intuitivo e consistente
  Seria bom se alguém com mais experiência multicloud comparasse, entre os três grandes, o quanto é fácil ou difícil configurar comunicação interna e externa

  • Nunca fiz um mapeamento direto, mas acho que quase todos os conceitos e módulos de networking da AWS têm algum equivalente mais ou menos direto no GCP
    Não é surpreendente, porque a maioria também tem equivalentes diretos nos próprios padrões de networking. No fundo, ambos são apenas formas de enxergar o mundo de redes definidas por software