A certificação CKAD - Certified Kubernetes Application Developer

A CKAD é uma das certificações de Kubernetes oferecidas pela Linux Foundation e CNCF - Cloud Native Computing Foundation. Como o próprio nome indica, o público dessa certificação são pessoas desenvolvedoras. Entretanto, o objetivo não é avaliar o desenvolvimento de aplicações propriamente dito, e sim o que uma pessoa desenvolvedora deve conhecer de Kubernetes para usar e operar uma aplicação que será executada nesse ambiente.

Segundo a página oficial da certificação, “o exame certifica que os candidatos podem projetar, construir e implantar aplicações cloud-native em Kubernetes”.

No escopo da prova, estão quase todos recursos do Kubernetes, o que é bastante coisa. Espere questões sobre Deployment, Pod, Service, Ingress, CronJob, Configmap, Secrets, containers, estratégias de deployment, Service Account, depreciação de APIs, Probes, etc. O conteúdo mais detalhado pode ser consultado no currículo da prova.

Uma característica importante do exame é que ele é totalmente prático, ao contrário da maioria das certificações, cujos exames são baseados em perguntas teóricas de múltipla escolha. Durante o exame, o candidato terá acesso remoto a ambientes Kubernetes onde deverá executar os comandos necessários para atingir os objetivos esperados de cada questão. Achei excelente esse modelo de exame, pois avalia a capacidade do candidato para resolver problemas na prática. Isso também ajuda você a saber se acertou ou não a questão, pois dá para validar na hora se o que foi feito gerou ou não o resultado esperado. Além disso, no ambiente remoto você também poderá consultar a documentação oficial do Kubernetes e de outras tecnologias se a pergunta exigir isso. No próprio enunciado da questão aparecem links para as documentações.

No meu caso, foram 16 questões, para um perído de 2 horas de duração da prova. Eu dividiria o nível de complexidade das questões em 3 com base na quantidade de tarefas exigidas de cada questão: simples (questões mais diretas), média complexidade (questões com um nível maior de tarefas para serem concluídas) e alta complexidade (questões com várias tarefas necessárias para serem concluídas). Em torno de 70% das questões foram de simples ou média complexidade, sendo os 30% restante as mais complexas. Cada questão é independente, ou seja, você não precisa concluir uma questão para conseguir responder outra. Mas dentro de uma questão, as tarefas que a compõem possuem dependência entre si na maior parte das vezes.

Essa é uma prova bem cara. Recentemente, houve um reajuste do preço e, no momento que escrevo esse post, ela está custando US$ 445. Vale a pena ficar de olho no site da Linux Foundation, pois em algumas épocas do ano eles costumam fazer promoções com 40% ou 50% de desconto, o que ajuda bastante. Nesse valor está incluso a possibilidade de um retake, ou seja, se você não passar na primeira tentativa, tem direito a uma segunda chance sem custo adicional. Também está incluso o acesso a duas sessões de um simulado (Exam Simulator) na plataforma Killer Shell. Uma vez iniciada uma das sessões do simulado, ela ficará disponível somente por 36 horas. Durante esse período, é possível fazer o simulado quantas vezes você quiser. No geral, achei que a dificuldade do simulado da CKAD foi um pouco maior do que a prova verdadeira. Então, se você for bem no simulado, é um bom indicativo de que está preparado para a prova. Se você quiser, também é possível adquirir esse simulado diretamente na plataforma Killer Shell, mas você terá que pagar por isso, além do custo da prova.

A CKAD tem validade de 2 anos e precisa de renovação se quiser ser mantida. Fiz a prova em Inglês (o Português não é uma opção de idioma disponível). A pontuação mínima para ser aprovado é de 66%. Essa prova só pode ser feita de forma on-line, não existindo ainda a opção de fazê-la centros de exames. Procuro evitar esse modelo de prova, pois não tive uma boa experiência quando fiz o exame da AWS Security Specialty. Como essa é a única opção, não teve jeito. Para meu alívio, não tive nenhuma surpresa desagradável e tanto o processo de check-in quanto o decorrer da prova foram bem tranquilos. Você precisa instalar um aplicativo da PSI em seu computador, que é a plataforma usada para a realização da prova.

Materiais de estudo

Utilizei os seguintes materiais para me preparar para a prova:

• curso Kubernetes Certified Application Developer (CKAD) with Tests - Udemy - de Mumshad Mannambeth: se você tiver que escolher uma única opção, este é o curso a ser escolhido. É bem completo e detalhado, explica os porquês de como algumas coisas são feitas e funcionam no Kubernetes. Além disso, você também ganha acesso a ambientes de laboratórias na plataforma KodeKloud, o que é muito importante, já que essa é uma prova prática. Se você for assinante da KodeKloud, esse curso já está incluso e não é necessário comprá-lo na Udemy.
• livro Kubernetes: Up and Running, 3rd Edition: apesar de não ser um livro voltado para a prova de certificação, com ele você ganhará conhecimentos gerais sobre Kubernetes.
• livro Certified Kubernetes Application Developer (CKAD) Study Guide, 2nd Edition: apesar de ser um livro voltado especificamente para o exame CKAD, não é tão completo e nem tão profundo quando o curso da Udemy que sugeri anteriormente. Se você for assinante da O’Reilly, poderá fazer os labs que são um complemento desse livro, disponíveis em Certified Kubernetes Application Developer (CKAD) Exam Prep Labs. Uma ótima oportunidade para exercitar o conhecimento, considerando que é um exame prático.

Dicas

Vamos às dicas:

• gestão do tempo: ponto crítico para o sucesso na prova, ainda mais por ser prática. Você tem que ter uma estratégia muito bem definida para gerenciar bem seu tempo. 2 horas é uma quantidade de tempo bem apertada para o número de questões. A estratégia que adotei, e que sugiro, é que sempre que você se deparar com uma questão que seja mais complexa ou que aborde um assunto que você não domine, marque a questão para revisão e vá para a próxima. Você tem que tomar essa decisão rapidamente. Não gaste tempo em questões que vão exigir mais tempo para serem resolvidas sem passar por todas questões antes. Resolva primeiro as questões mais simples ou de média complexidade dos temas que você conhece mais, e deixe as mais complexas e de assuntos que você não domina para o final. Com isso, você tem mais chance de pontuar nas questões de assuntos que tem mais domínio antes do tempo acabar. Quando tiver passado por todas questões, retorne para aquelas que você marcou para revisão, começando novamente por aquelas que você acha que tem mais chance de concluir ou que vai levar menos tempo dentre aquelas que restaram. Repita esse ciclo até conseguir responder todas ou até terminar o tempo. No meu caso, terminei a última questão faltando apenas 2 minutos para o tempo acabar.
• a maioria das questões é composta de mais de uma tarefa. Mesmo que não saiba responder completamente uma questão, faça as tarefas que souber, pois perguntas parcialmente respondidas também contribuem para a pontuação final.
• use todas técnicas disponíveis para ganhar tempo, como configuração de alias, atalhos, etc. Qualquer coisa que economize tempo ou que evite digitar teclas desnecessariamente faz diferença. Por exemplo, ao invés de digitar o comando kubectl, use o alias “k”, que já vem configurado no ambiente da prova. Assim, ao invés de digitar:

  kubectl get pod
  

  use

  k get pod
  

  Pode parecer uma coisa boba, mas se você lembrar que terá que digitar esse comando dezenas ou centenas de vezes, a cada vez você economiza 6 teclas digitadas, o que vai economizar muito tempo. Além disso, você pode criar seus próprios alias ou variáveis de ambiente. Eu, por exemplo, configurei o seguinte alias e variável de ambiente:

  alias ka="k apply -f"
  export dry="--dry-run=client -o yaml"
  

  que usava da seguinte forma

  # para gerar um template yaml de um comando
  k run pod --image=nginx $dry > pod.yaml
  
  # para aplicar um template yaml
  ka pod.yaml
  

  Esses são comandos bastante exigidos na prova e, se usados dessa maneira, ajudam a otimizar o tempo. Avalie outros comandos que você ache interessante usar essa estratégia. Já o comando abaixo configura um namespace padrão. Dessa forma, nas questões em que você tem que trabalhar com um namespace diferente do default, não é necessário ficar especificando o nome do namespace a cada comando, o que vai resultar em menos digitação e, consequentemente, menos tempo gasto:

  k config set-context --current --namespace <NOME_NAMESPACE>
  

• o ambiente remoto onde a prova é realizada é um ambiente Linux. Portanto, você deve saber usá-lo muito bem. Não é necessário que você seja um especialista em Linux, mas você tem que ficar bem a vontade usando-o. Além disso, certamente você precisará editar algum objeto do Kubernetes ou editar algum arquivo yaml durante a prova. Portanto, você tem que dominar o editor de texto. Se não tiver fluência no vim (como é o meu caso), use outro editor em que se sinta à vontade e no qual você seja mais produtivo. Eu utilizei o nano. Para mudar o editor de texto padrão usado para edição de objetos do Kubernetes, configure a variável de ambiente conforme abaixo. Dessa forma, sempre que você der o comando kubectl edit, será aberto o editor de texto configurado:

  export KUBE_EDITOR=nano
  

• apesar de ser uma prova com consulta liberada à documentação oficial do Kubernetes, use somente em último caso, pois isso consome tempo. Preferencialmente, você deve ter decorado os principais comandos dos principais objetos do Kubernetes. Se não decorou, use o help nativo do próprio kubectl, que normalmente vêm com exemplos que ajudam bastante. Se precisar de um arquivo yaml, prefira gerar através do kubectl, que é mais rápido (configure uma variável de ambiente para agilizar isso, conforme explicado anteriormente). Somente use a documentação do site para os objetos do Kubernetes que não podem ser criados ou gerado o yaml através do kubectl. Para isso, você precisa saber quais objetos do Kubernetes podem ser criados a partir do kubectl e quais só podem ser criados de forma declarativa (com arquivo yaml). Para os casos em que não houver outra alternativa a não ser consultar a documentação (por exemplo, para obter um exemplo de arquivo yaml de determinado objeto), saiba como chegar na documentação e conheça-a muito bem. A última coisa que você vai querer fazer durante a prova é buscar na documentação algo que você nunca pesquisou antes.
• pratique, pratique e pratique. Muito mesmo. Esteja bem afiado. Você só vai saber que tipo de tarefa vai levar mais ou menos tempo se praticar. Você só vai saber quais atalhos e alias serão mais úteis se praticar. Você só vai dominar o editor de texto e o mínimo necessário de Linux para a prova se praticar. Você só vai conhecer e saber quando usar a documentação do site ou não se praticar. Desenvolva essas habilidades e conhecimentos enquanto estiver estudando e praticando para a prova. Ter um ambiente onde você pode exercitar isso é obrigatório, seja no seu computador ou em algum laboratório remoto de alguma plataforma ou ambiente sandbox. Você tem que chegar na prova com essas técnicas dominadas.

Conclusão

A CKAD é uma prova exigente, para a qual a gestão do tempo é primordial. É exigido conhecimento de uma ampla quantidade de assuntos relacionados a Kubernetes. Praticar é a melhor maneira para se preparar para a prova. Espero que ajude!

Nos primeiros dias do ano, Mark Zuckerberg fez um anúncio bizarro sobre mudanças na moderação de conteúdo das redes sociais da Meta: Facebook, Instagram e Threads. Sob a desculpa de “diminuir a censura”, a Meta deixará de fazer checagem de fatos, que será substituído por um modelo de “notas de comunidade”, similar ao que ocorre no X/Twitter. Belo exemplo que a Meta pretende seguir: o X/Twitter, que virou uma terra sem lei depois que foi adquirido por Elon Musk! O problema é que as redes sociais da Meta têm um alcance muito maior que o X/Twitter e isso só vai servir para disseminar (ainda mais!) fake news, discurso de ódio, intolerância, preconceito, etc.

Ele também anunciou uma “parceria” com o governo de Donald Trump em nome da “liberdade de expressão” e contra a “censura” na Europa e na América Latina, que segundo ele, estariam dificultando a “inovação”. Claro que isso foi uma indireta para o Brasil, que é um dos países que tem tentado conter a atuação sem limites das redes sociais. É simplesmente um absurdo uma mega corporação privada de um outro país querer impor ao resto do mundo sua visão de “liberdade de expressão” (que para eles é poder mentir livremente). Aparentemente, para eles “inovar” é ter permissão para fazer o que quiser, mesmo que isso signifique desrespeitar as leis de outros países.

Mas a coisa só foi piorando. Nos dias seguintes, a Meta anunciou que vai terminar seu programa de diversidade, equidade e inclusão, eliminando a função de diretor de diversidade e encerrando as suas metas de contratação de diversidade que exigiam o emprego de um certo número de mulheres e minorias.

Além disso, a Meta também mudou sua política de discurso de ódio:

A nova política de moderação de conteúdo da Meta, já em vigor no Brasil, passou a permitir conteúdos considerados criminosos de acordo com a lei do país, como expressões de supremacia racial e de preconceito religioso. Frases como “os brancos são os melhores” e “eu odeio negros” estão entre as autorizadas a circular no Instagram e no Facebook.

Participando de um podcast e numa tentativa patética de se mostrar mais alinhado ao público apoiador de Trump, Zuckerberg disse que as empresas precisam de mais “energia masculina” (eu adoraria saber o que as mulheres que trabalham lá acham disso):

Mark Zuckerberg lamentou o aumento de empresas “culturalmente castradas” que buscaram se distanciar da “energia masculina”, acrescentando que é positivo se uma cultura “celebrar um pouco mais a agressividade”

Oligarcas da tecnologia

A verdadeira questão é que as Big Techs, principalmente as redes sociais da Meta, X/Twitter e Google, mas sem esquecer a Amazon, Apple, Microsoft e OpenAI, têm se sentido cada vez mais acuadas nos últimos tempos, pois vários países estão discutindo regulações para atuação delas.

A maioria das redes sociais atuais estão longe da ideia inicial de quando surgiram, que era de conectar as pessoas e permitir saber o que estava acontecendo em nossos círculos sociais. Atualmente, essas redes viraram disseminadoras de conteúdos de pessoas que muitas vezes nem conhecemos ou seguimos, mas que são recomendados por algoritmos que privilegiam assuntos “polêmicos” e extremistas, com o objetivo de aumentar o “engajamento” e, consequentemente, seus lucros. Na prática, essas empresas querem continuar ganhando muito dinheiro sem serem importunadas, sem se importarem ou serem cobradas pelas consequências e problemas sociais que elas causam. E agora, essas empresas têm como aliado Donald Trump. O novo presidente dos EUA e seus apoiadores são totalmente contrários a qualquer tipo de controle sobre o conteúdo propagado nas mídias sociais (desde que não seja conteúdo que os prejudique, é claro!), o que facilita a divulgação de mentiras, racismo, homofobia, xenofobia, misoginia, teorias da conspiração e conteúdos negacionistas, que beneficiam essa turma. Em outras palavras, juntou a fome com a vontade de comer.

O Brasil, há tempos, já sente o poder de influência dessas empresas agindo contra a regulação por todos os meios, alguns até um tanto anti-éticos. Basta lembrar que em 2023, quando o Projeto de Lei conhecido como PL das Fake News que visava regular as Big Techs estava para ser votado, o Google chegou a publicar explicitamente um link na página principal do seu sistema de buscas sobre “os perigos da PL das Fake News”, que levava para uma página contendo várias críticas ao projeto. Em 2024, o X/Twitter chegou a ficar inacessível no Brasil por descumprir a legislação brasileira. Agora em Janeiro de 2025, Google, X/Twitter, TikTok e Meta não enviaram representantes para a audiência pública promovida pela AGU - Advocacia Geral da União para discutir o assunto de regulação, demonstrando que não estão nem um pouco interessadas no assunto.

Zuckerberg e companhia possuem uma visão bem peculiar de “liberdade de expressão”. Eles supostamente defendem o direito das pessoas falarem o que quiserem (mesmo que seja algo criminoso), mas não toleram quando o que é publicado vai contra suas vontades ou interesses. O jornal The Whashington Post, cujo dono é Jeff Bezos, decidiu não publicar seu apoio na campanha para presidente dos EUA. Detalhe: o apoio seria dado a Kamala Harris, oponente de Trump na eleição, e foi vetado pelo próprio Bezos:

Um endosso a Harris havia sido redigido pelos funcionários da página editorial do Post, mas ainda não havia sido publicado, de acordo com duas pessoas que foram informadas sobre a sequência de eventos e que falaram sob condição de anonimato porque não estavam autorizadas a falar publicamente. A decisão de não mais publicar endossos presidenciais foi tomada pelo proprietário do The Post, o fundador da Amazon Jeff Bezos, de acordo com quatro pessoas que foram informadas sobre a decisão

Ann Telnaes, cartunista do jornal, decidiu então fazer a charge abaixo, que mostra Jeff Bezos, Mark Zuckerberger, Sam Altman (da OpenAI), Patrick Soon-Shiong (do jornal LA Times, que também vetou a publicação do apoio do jornal a Kamala Harris) e Mickey Mouse (representando Walt Dysney Company) curvando-se e oferecendo dinheiro para Trump.

A charge foi vetada e ela então decidiu deixar o jornal, com a seguinte justificativa:

Como cartunista editorial, meu trabalho é responsabilizar pessoas e instituições poderosas. Pela primeira vez, meu editor me impediu de fazer esse trabalho crítico. Então, decidi deixar o Post. Duvido que minha decisão cause muito rebuliço e que seja sentida porque sou apenas uma cartunista. Mas não vou parar de manter a verdade do poder por meio dos meus cartuns, porque, como dizem, “A democracia morre na escuridão”.

Essas empresas cresceram demais, tornaram-se mega corporações, muito ricas e poderosas. Elas formam uma oligarquia da tecnologia, ou seja, um governo de poucos, que influenciam a política e o governo de forma significativa. Oligopólios, em outras palavras. O Google comanda 90% do mercado de buscas. Sete em cada dez americanos usam o Facebook. Amazon, Microsoft e Google controlam dois terços das plataformas de Cloud. A Amazon detém 40% do mercado de e-commerce americano. Fonte: The tech oligarchy has been here for years. Os principais executivos dessas empresas sentaram-se em posição privilegiada durante a posse de Trump. E lembre-se que Elon Musk foi cabo eleitoral de Trump e vai trabalhar diretamente com ele. Um clube de bilionários patéticos.

Além de Mark Zuckerberg (da Meta), Jeff Bezos (da Amazon), Sundar Pichai (do Google) e Elon Musk (do X/Twitter), também estavam presentes na cerimônia de posse de Trump, Tim Cook (da Apple) e Sam Altman (da OpenAI).

A ausência ficou por conta de Satya Nadella, CEO da Microsoft, o que deve ter sido algo proposital, apesar da Microsoft também ter feito doações para Trump (assim como para presidentes dos EUA eleitos anteriormente). Coincidentemente, dias depois Bill Gates deu uma entrevista em que criticou Elon Musk, dizendo que é “loucura desastibilizar a política de outros países e apoiar a extrema-direita”, e que os “governos deveriam adotar medidas para garantir que os super-ricos não influenciem suas eleições”.

Se você ainda acha que estou exagerando, leia esse trecho do pronunciamento de despedida de Joe Biden:

Quero alertar o país sobre algumas coisas que me preocupam muito. E essa é a perigosa concentração de poder nas mãos de poucas pessoas ultra-ricas… Hoje, uma oligarquia está tomando forma na América de extrema riqueza, poder e influência que literalmente ameaça toda a nossa democracia, nossos direitos e liberdades básicos, e uma chance justa para todos progredirem…

O presidente Eisenhower falou sobre os perigos do complexo militar-industrial. Ele nos alertou sobre, e eu cito, “O potencial para o aumento desastroso do poder mal colocado”. Seis décadas depois, estou igualmente preocupado com o aumento potencial de um complexo tecnológico-industrial que pode representar perigos reais para o nosso país também

Amazon, Google, Meta, Microsoft, OpenAI e Apple doaram US$ 1 milhão cada para a cerimônia de posse de Trump, sendo que nas eleições anteriores os valores chegaram no máximo de US$ 500 mil.

E parece que todo esse apoio das Big Techs já está começando a render frutos: poucos dias após a posse de Trump, foi anunciado o projeto Stargate, nova empresa formada pela OpenAI, Oracle, SoftBank (Japão) e um fundo de investimentos do governo dos Emirados Árabes Unidos, que demandará US$ 500 bilhões e promete criar nos EUA a maior infraestrutura de Inteligência Artificial já existente.

Até entendo que grandes corporações queiram fazer média com os presidentes eleitos através de doações, independente do partido que ele faça parte, e isso acontece nos EUA, Brasil e em vários outros países. Mas o mais assustador e perigoso agora é que essas mega coporações estão dispostas a se submeterem e colocarem seu poder, alcance e influência à disposição para uso político de um governo com claras tendências fascistas, desde que isso signifique que elas possam continuar lucrando bilhões e bilhões de dólares, mesmo causando um mal muito grande.

Exagero? Veja o que Mark Lemley, advogado professor de Stanford que abandonou um caso onde representava a Meta devido aos últimos acontecimentos, tem a dizer:

Tenho lutado para saber como reagir à queda de Mark Zuckerberg e do Facebook na masculinidade tóxica e na loucura neonazista.

Desativei minha conta do Threads. A última coisa de que preciso é apoiar um site semelhante ao Twitter administrado por um aspirante a Musk.

E por falar em Musk… veio o gesto abaixo.

Isso não foi um comportamento isolado. Musk sabia muito bem o que estava fazendo. Desde que adiquiriu o Twitter, ele vem mostrando sua simpatia e apoiando pessoas e conteúdos nazifascistas. Recentemente, ele participou de uma live com a líder do AfD, partido alemão de extrema-direita e reduto de neonazistas. Ele já havia declarado seu apoio ao partido na próxima eleição alemã e também discursou num comício do partido. Em 2024, ele também chegou a incitar uma gerra civil no Reino Unido, devido à vários atos de violência que estavam ocorrendo contra muçulmanos. Se quiser ver outros casos, assista Musk has been backing neo-Nazi parties around the world. Ele também é um dos principais defensores do pró-natalismo, movimento do qual fazem partes vários ultra-ricos da área de tecnologia que defendem o aumento da taxa de natalidade. Mas não o nascimento de qualquer criança. Eles acreditam na “salvação da civilização” tendo crianças geneticamente superiores, que pertençam a uma determinada classe social e étnica. Qualquer semelhança com eugenia não é mera coincidência. Quando o homem mais rico do mundo e outros bilionários resolvem usar seu poder para influenciar o destino político e social de vários países com esse tipo de ideologia e sem nenhum escrúpulo, isso é algo muito preocupante.

Enfrentaremos tempos sombrios pela frente…

Diversos serviços e negócios ficaram indisponíveis, nos mais variados setores, como companhias aéreas e aeroportos, instituições financeiras, serviços de emergência, sistemas de saúde, empresas de telecomunicação, de varejo, etc, gerando transtornos nas vidas de milhões de pessoas. Os impactos sociais e econômicos certamente são de uma escala gigantesca. Nesse momento em que escrevo, muita gente ainda deve estar trabalhando para normalizar a situação, o que deve se estender nos próximos dias. A Microsoft estima que foram afetados em torno de 8,5 milhões de dispositivos Windows. Isso é menos de um por cento de todas as máquinas Windows do mundo, mas é um número absoluto muito grande.

Apesar de somente computadores com Windows terem sido afetados dessa vez, problemas semelhantes haviam ocorrido pouco meses antes com algumas distribuições Linux, obviamente sem o mesmo alcance que agora. Isso mostra que esse não foi um caso isolado, parecendo ser algo recorrente, o que gera uma série de questionamentos sobre (a falta de) práticas e testes da CrowdStrike para atualizações de seus softwares.

Você pode encontrar o pronunciamento oficial da CrowdStrike sobre o incidente e os passos necessários para a correção do problema em REMEDIATION AND GUIDANCE HUB: FALCON CONTENT UPDATE FOR WINDOWS HOSTS.

Podemos aproveitar acontecimentos como esse para refletir um pouco e tirar (ou relembrar) algumas lições importantes.

Não há somente um único culpado

Incidentes dessa magnitude não são culpa de uma pessoa somente. Claro que alguém programou o código que continha o bug, mas a responsabilidade não é somente dessa pessoa. Entre um código ser escrito e ser distribuído para uso, existe uma série de oportunidades e etapas nas quais problemas como esse deveriam ser identificados antes de serem liberados: revisão de código, ferramentas de análise de código, esteiras de CI/CD, testes dos mais variados tipos, estratégias de deployment progressivo (canary, blue/green, ring, etc), observabilidade, etc. A falha na identificação desse tipo de bug é resultado de um problema estrutural, da organização e da forma como ela opera, que falhou em utilizar práticas de engenharia de software para um componente tão crítico e que não possui os processos adequados. Bugs existem e vão continuar existindo, por melhor que seja o engenheiro de software e por mais bem intencionado que seja. Deve haver mecanismos para impedir ao máximo que esses bugs sejam liberados para produção. E quanto mais crítico o componente, maiores devem ser os cuidados.

Está tudo interconectado

Que temos uma dependência absurda da tecnologia no nosso dia-a-dia é claro para todos nós. Nossas vidas pessoal e profissional dependem de produtos e serviços tecnológicos e a tendência é que isso só aumente. Mas o que acabamos esquecendo (e que a maioria das pessoas leigas não sabem até que eventos como esse aconteçam), é como essa tecnologia é baseada em uma rede complexa de dependências de componentes críticos que, ao menor sinal de desestabilização, pode fazer tudo ruir como num castelo de cartas. A figura abaixo representa bem isso:

Softwares dependendo de frameworks e bibliotecas, open-source ou proprietários, que dependem de runtimes, que dependem de sistemas operacionais, que podem ser executados em uma infraestrutura de cloud de um outro fornecedor, que dependem de serviços que são acessados através de rede e que nem ao menos sabemos onde estão, que por sua vez dependem de outros e assim sucessivamente. Isso sem falar nas dependências e componentes de hardware. Camadas em cima de camadas, abstrações em cima de outras abstrações formam uma rede intrincada de componentes que ninguém (mesmo que seja profissional de TI) é capaz de mapear por completo e nem de saber a extensão do impacto que a falha em uma dessas peças pode causar.

Às vezes, dá a impressão de que tudo está preso por um barbante e prestes a desmoronar. E o mais incrível mesmo é que tudo isso funciona na maior parte do tempo. Chega a ser quase um “milagre” que um apagão desses não tenha acontecido antes. E algo me diz que esse não será o último.

Você é responsável pelo seu produto (mesmo que terceiros causem problemas)

Achei curioso a forma como algumas reportagens e boa parte das pessoas em redes sociais se referiram ao problema como sendo de responsabilidade da Microsoft, como se ela tivesse causado e como se ela devesse corrigi-lo. Claro, isso aconteceu porque é o Windows que apresentava a tela azul, então é natural que os usuários e leigos em geral acreditem que esse seja um “problema do Windows”. A imagem da Microsoft e do Windows também saiu um pouco arranhada, principalmente para quem não é da área de TI.

Isso pode ser injusto e nem pode parecer o correto, mas na prática é assim que funciona a percepção das pessoas pela opinião pública. Não importa que tecnicamente seu produto (no caso o Windows) teve problema por causa de terceiros (CrowdStrike). O fato é que ele ficou indisponível e o responsável pelo produto final será cobrado por isso. Essa regra se aplica para qualquer produto ou serviço prestado por empresas de qualquer ramo. Se o produto ou serviço ficar indisponível, seus clientes irão cobrá-lo, mesmo que a “culpa” do problema seja de terceiros. O fato é que seus clientes não estão conseguindo usar seu produto e você deveria ter pensado em formas para evitar isso.

Não tenho informações privilegiadas, mas aposto que no mesmo dia em que esse apagão aconteceu, o time do Windows na Microsoft já deve ter começado a pensar em mecanismos para melhorar a forma como gerenciar drivers de terceiros e mitigar problemas semelhantes a esses no futuro.

Não é novidade que custo é um assunto muito importante quando falamos de Cloud. A facilidade que uma plataforma de Cloud oferece para criarmos recursos rapidamente e escalar conforme a necessidade pode gerar descontrole e resultar em supresas nada agradáveis para o bolso quando a conta chegar. O tema é tão importante que até existe uma disciplina (FinOps) dedicada a como fazer uso de Cloud sem desperdícios financeiros, com o máximo de eficiência possível. É um trabalho contínuo, que exige acompanhamento e ajustes constantes.

A AWS também reconhece a importância do assunto. Tanto é que um dos pilares do AWS Well-Architected Framework é o de Otimização de Custos, que contém orientações e boas práticas de como utilizar os produtos da AWS de forma eficiente e com o menor custo possível.

Além disso, a AWS gosta bastante de divulgar que repassa para seus clientes reduções nos preços de seus produtos, reflexo de suas constantes melhorias em eficiência. E realmente é um histórico impressionante. Segundo dados de 2022 da própria AWS, já houve 115 reduções de preços desde quando ela começou em 2006. Inclusive, boa parte do histórico de anúncios de reduções de preços pode ser consultada.

Entretanto, no segundo semestre de 2023 a AWS fez alguns anúncios que vão impactar diretamente no custo de seus clientes em 2024, se não forem tomadas as devidas precauções. É uma nova cobrança e um novo “serviço” que poderão ser cobrados automaticamente caso não sejam tomadas ações.

Cobrança de endereços IPv4 públicos

A partir de 1º de Fevereiro de 2024, todos endereços IPv4 públicos em uso serão cobrados pela AWS. Isso NÃO se limita ao Elastic IP. Ou seja, uma instância EC2 (ou qualquer outro recurso) que tenha um endereço IPv4 público associado diretamente a ela, sem o uso do Elastic IP, passará a sofrer cobrança. Atualmente, somente Elastic IPs que não estão em uso são cobrados.

Essa é uma forma indireta da AWS “incentivar” a adoção de IPv6, já que segundo ela os preços de IPv4 aumentaram bastante nos últimos tempos devido à escassez. Portanto, é bom rever os recursos que estão em subnets públicas e se eles podem ser transferidos para subnets privadas ou então passarem a utilizar IPv6.

Mais informações sobre a nova cobrança você encontra em New – AWS Public IPv4 Address Charge + Public IP Insights

E para sugestões de como fazer melhor uso de endereços IPv4 públicos, você pode ler Identify and optimize public IPv4 address usage on AWS

Serviço de suporte estendido para EKS e RDS

Softwares comerciais e open source trabalham com ciclo de vida. Isso significa que quando uma nova versão é lançada, ela será suportada e receberá correções durante um determinado período. Até o término desse período, espera-se que o software seja atualizado para versões mais atualizadas. Caso isso não aconteça, o usuário desse software assume o risco de utilizar uma versão antiga, sujeita a bugs e vulnerabilidades de segurança.

A AWS anunciou o serviço de suporte estendido para EKS, o serviço gerenciado de Kubernetes da AWS, e para RDS, o serviço de banco de dados relacional da AWS. No caso do RDS, o suporte estendido será para MySQL e PostgreSQL, inclusive para Aurora. Com esse serviço, a AWS passará a fornecer suporte e correções de segurança para versões que não são mais suportadadas oficialmente pelas comunidades. E claro, isso terá um custo. O suporte estendido de EKS ainda está em preview e por enquanto não será cobrado, mas a previsão é que isso mude em algum momento do início de 2024*. Já para o MySQL, a cobrança começa em março de 2024, e para o PostegreSQL, em abril de 2024.

*Em 16/01/24, a AWS divulgou como vai ser a cobrança do suporte estendido do EKS. Será cobrado um valor por hora por cluster EKS a partir de abril de 2024. Mais detalhes em Amazon EKS extended support for Kubernetes versions pricing

Na prática, isso significa que quem estiver utilizando uma versão antiga de Kubernetes, MySQL e PostegreSQL, fora do período do suporte padrão, entrará automaticamente no suporte estendido da AWS. Ou seja, isso acarretará no aumento de custos automaticamente. Para evitar essa cobrança, os usuários precisarão atualizar os produtos para versões mais novas antes do término do período de suporte padrão.

Para saber mais informações sobre o serviço de suporte estendido, suas condições e restrições, leia:

• Amazon EKS extended support for Kubernetes versions available in preview
• Amazon EKS extended support for Kubernetes versions pricing
• Your MySQL 5.7 and PostgreSQL 11 databases will be automatically enrolled into Amazon RDS Extended Support

Avisos

O conteúdo abaixo refere-se à versão DOP-C02 da prova, que passou a valer em março/2023. Apesar de não estar prevista uma nova versão da prova, dependendo de quando estiver lendo esse post, pode ser que o conteúdo esteja desatualizado. Então, fique atento.

Para que fique claro: lembro que o que funcionou para mim talvez não funcione para você. Cada pessoa tem uma forma diferente de estudar e aprender, e não há certo e nem errado. É importante que cada um conheça o que funciona melhor para si e faça os ajustes necessários. Eu, particularmente, gosto de misturar os vários formatos de conteúdo. Apesar de eu ter uma preferência por leitura, também gosto de complementar com vídeos. Também gosto de balancear a parte teórica com a prática. Enfim, avalie o que se adapta melhor ao seu estilo.

Certificação vale a pena?

Certificação não é bala de prata e nem é perfeita. Mas ela oferece uma maneira estruturada de estudar um determinado campo do conhecimento. O valor da certificação não está no certificado propriamente dito, mas sim no processo de preparação e aprendizado. Nesse caso, passar na prova é uma consequência, e não o objetivo final. Se quiser saber mais o que penso sobre certificação valer a pena ou não, leia o que escrevi no post sobre a prova AWS Solutions Architect Professional.

A certificação AWS Certified DevOps Engineer - Professional

Segundo a AWS, essa certificação “demonstra a experiência técnica de indivíduos em relação ao provisionamento, operação e gerenciamento de sistemas de aplicações distribuídas na plataforma da AWS, fornecendo maior confiança e credibilidade com colegas, partes interessadas e clientes.”.

Como se trata de uma certificação do tipo Professional, espera-se um nível de dificuldade maior. Entretanto, não achei ela tão desgastante quanto a da AWS Solutions Architect Professional, que para mim continua sendo a mais exigente das provas que fiz até agora. Entretanto, isso não quer dizer que seja fácil, longe disso.

Principais pontos:

• escopo: possui um escopo mais limitado, ao contrário das provas de Solutions Architect (tanto Associate quanto Professional). Isso reflete em menos conteúdo para estudar. Por outro lado, é exigido um conhecimento mais detalhado de certos serviços da AWS. Se você já fez a prova de Solutions Architect Professional da AWS, conseguirá reaproveitar esse conhecimento. No meu caso, também consegui reaproveitar boa parte do conhecimento da prova AWS Certified Developer - Associate, que havia feito em setembro/23. Isso ajudou bastante também
• complexidade e tamanho das questões: achei o nível de complexidade das questões um pouco menor do que a prova AWS Solutions Architect Professional. A maioria das questões foram de tamanho médio ou grande e, algumas poucas, com tamanho pequeno. Entretanto, não eram cenários ultra complexos envolvendo a combinação de muitos produtos. Foram perguntas mais diretas, podemos dizer
• quantidade de perguntas e tempo da prova: são 75 questões de múltipla escolha ou múltiplas respostas, das quais 65 é que valem pontos. A duração é de 3 horas, mas para quem o Inglês não for o idioma nativo, é possível solicitar um tempo extra de 30 minutos. Na média, dá um pouco um pouco menos que 3 minutos por questão, o que pode ser pouco se não tomado o devido cuidado

Como toda prova, além do conhecimento técnico, também são validados sua capacidade de gestão de tempo e seu controle mental, para que fique no nível de atenção e foco adequados. Como sempre, algumas perguntas vão levar mais tempo para serem respondidas, e aí você precisa recuperar esse tempo gasto a mais nas perguntas que são menores e mais diretas.

A prova pode ser feita em vários idiomas, mas ela ainda não está disponível em Português. Fiz a minha em Inglês (com o tempo extra de 30 minutos citado anteriormente).

Essa não é uma certificação barata, já que é de um nível mais avançado. O preço dela é de US$ 300. Se você já possui alguma certificação AWS, tem como benefício um desconto de 50% em outra prova. Nesse caso, o valor vai para US$ 150, que ainda é relativamente caro considerando o valor do dólar atualmente, mas é melhor do que o preço cheio. Como todas as demais certificações da AWS, ela tem validade de 3 anos e precisa ser renovada para ser mantida

Essa prova pode ser feito de forma on-line ou em um centro de exames. Como não gostei da experiência quando fiz a prova on-line da AWS Security Specialty, preferi fazer em um centro de exames. Como já disse em outro post, só volto a fazer prova de certificação on-line se não houver outra alternativa.

Tempo de estudo

Estudei durante aproximadamente 45 dias, de 2 a 3 horas de estudo por dia. Lembrando que parte do conteúdo eu já conhecia por causa de outras provas da AWS, então para esses casos acabou sendo uma revisão. Pode ser que você precise de mais tempo caso esteja vendo o conteúdo pela primeira vez. Além disso, cada pessoa tem um ritmo e outros compromissos que acabam demandando tempo, então isso vai variar. O importante é manter a consistência e a disciplina.

Materiais de estudo

Como nas outras provas, a maior parte do material apresentado aqui é paga. Antes de sair comprando material, se você assina alguma plataforma de cursos ou livros, vale verificar se ela já não oferece algo relativo a essa certificação.

Leitura

Não encontrei livros da versão DOP-C02. Para essa prova, acabei focando nos white papers da AWS abaixo:

• AWS Multi-Region Fundamentals
• Disaster Recovery of Workloads on AWS: Recovery in the Cloud
• Introduction to DevOps on AWS
• Practicing Continuous Integration and Continuous Delivery on AWS
• Overview of Deployment Options on AWS
• Running Containerized Microservices on AWS

Vídeos

Atualmente, a maior parte dos materiais feitos para provas de certificação são cursos em vídeos. Assisti a dois cursos da Udemy. O do Zeal Vora achei muito repetitivo. Ele fazia uma aula teórica sobre o assunto e depois uma aula prática na qual repetia praticamente toda a parte teórica, o que acabou deixando o curso muito extenso desnecessariamente. Como já era de se esperar, o curso do Stephane Maarek é sem dúvidas o melhor e mais completo, com um nível de detalhamento muito bom. Se tivesse que escolher somente um curso para fazer, escolheria esse.

• AWS Certified DevOps Engineer Professional 2023 - DOP-C02 - Udemy - de Stephane Maarek
• AWS Certified DevOps Engineer - Professional 2024 - Udemy - de Zeal Vora

Simulados

Os simulados são importantes pois é a experiência mais próxima que você terá da prova real. Os simulados listados abaixo possuem uma explicação detalhada da resposta de cada questão, o que é fonte importante de conhecimento para aprender coisas novas. Além disso, é comum aparecerem alguns tópicos que não haviam sido abordados nos cursos, o que acaba complementando o conhecimento. Todos os simulados abaixo possuem o mesmo nível, com ótima qualidade, mas o simulado oficial da AWS me surpreendeu positivamente. Uma curiosidade é que, das provas que já fiz, essa foi aquela onde apareceram mais perguntas parecidas com as perguntas dos simulados, de todos eles. Pode ser uma coincidência e nada garante que vá acontecer com outras pessoas, mas reforço uma dica que já dei em outras provas: quanto mais simulados você fizer, melhor.

• Exam Prep Official Practice Exam: AWS Certified DevOps Engineer - Professional (DOP-C02 - English) - Oficial AWS
• AWS Certified DevOps Engineer Professional Practice Exams DOP-C02 2023 - Tutorials Dojo - de Jon Bonso
• Practice Exams | AWS Certified DevOps Engineer Professional - Udemy - de Stephane Maarek e Abhishek Singh
• AWS Certified DevOps Engineer Professional Practice Exams - Udemy - de Neal Davis

Principais assuntos

Apareceram assuntos bem distribuídos, que faziam parte do escopo das outras provas: Arquitetura, Desenvolvimento, SysOps e Segurança, só que sob uma perspectiva de DevOps. Isso é, sob a perspectiva de alguém que irá criar automações, plataformas e serviços para que outras pessoas possam consumir e utilizar a AWS de forma governada e padronizada. Prepare-se para responder sobre estratégias de deployment, serviços de pipelines de CI/CD (CodeCommit, CodeBuild, CodeDeploy, CodePipeline), cenários envolvendo multiregião, CloudFormation, AWS Organizations, Control Tower, Service Control Policy (SCP) e AWS Config. Além disso, os recursos mais básicos da AWS, como VPC, AZs, Subnet, Route Rable, Security Group, Network ACL, EC2, EBS, ELB, S3, IAM também serão exigidos de uma forma ou de outra, mas sem um nível muito grande de profundidade. No meu caso, também caíram muitas perguntas de EventBridge e Auto Scaling. Deixando claro que o conteúdo vai variar a cada prova. Não necessariamente você encontrará os mesmos tópicos e mesma proporção na sua prova.

Conclusão

Por se tratar de uma prova de nível Professional, é uma prova exigente mas não tão desgastante quando a de Solutions Architect Professional. Entretanto, é cobrado um nível de profundidade um pouco maior de alguns assuntos. A gestão do tempo é fundamental. Além disso, se você também fez outras provas da AWS, então irá reaproveitar muita do que estudou, o que é uma vantagem. Outro ponto que ajuda é experiência: se você trabalha com AWS há um tempo, provavelmente vai se deparar com perguntas de cenários pelos quais já passou no dia-a-dia. Deixando claro aqui que o que funcionou para mim não necessariamente vai funcionar para você. Espero ter ajudado. Boa sorte!

Em todos os exemplos, o recurso acessado sempre foi uma instância EC2. Ou seja, foi mostrado como acessar o terminal de uma instância EC2 e executar comandos remotamente. Entretanto, uma solução na AWS normalmente envolve muitos outros recursos além de instâncias EC2. Não seria bom se conseguíssemos acessar remotamente outros recursos disponíveis na VPC (por exemplo, um banco de dados RDS ou outros serviços da AWS), como se fossem recursos locais, de forma segura? Isso é possível e demonstrarei como fazer isso nesse artigo!

Acesso remoto via AWS Systems Manager Session Manager com Port Forwarding

O Port Forwarding (ou encaminhamento de porta) é uma funcionalidade do Session Manager que possibilita que o tráfego de rede destinado a uma porta local seja redirecionado para um destino remoto. Em outras palavras, uma porta é aberta no computador local e é estabelecido um túnel com um outro computador remoto. Todo tráfego enviado para a porta local é encaminhado para o computador remoto através do túnel. O princípio é o mesmo do SSH Port Forwarding (também conhecido como SSH Tunneling), com a vantagem de que com o uso do Session Manager não é preciso gerenciar pares de chaves públicas e privadas e nem expor a porta 22 do SSH para acesso.

O grande ganho dessa abordagem é que ela permite o uso de um recurso remoto como se fosse local. Um desenvolvedor poderia desenvolver, executar, testar e “debugar” uma aplicação localmente acessando recursos remotos em uma VPC na AWS (bancos de dados, servidores de cache, etc), sem a necessidade de ter todos os componentes da solução instalados no seu computador. Ou seja, o desenvolvedor acessa um endereço local que, através do port forwarding, encaminha o tráfego para o recurso remoto de forma transparente.

Além de recursos que são provisionados na VPC, também é possível acessar remotamente de forma privada serviços gerenciados da AWS que, a princípio, são públicos, como SQS, SNS, S3, etc. Ou seja, serviços que não são provisionados na VPC e que são difíceis de serem reproduzidos localmente. Isso é possível através do uso do Interface VPC Endpoint, que cria uma ENI (placa de rede virtual) na VPC, pela qual se tem acesso ao serviço gerenciado da AWS através do Private Link.

Para mais detalhes sobre Interface VPC Endpoint e PrivateLink, consulte Acessando serviços AWS de forma privada com Interface VPC Endpoint/PrivateLink

No exemplo desse post, será utilizado o Session Manager com Port Forwarding para acesso remoto a um banco de dados RDS (sem que ele precise ficar exposto para a Internet) e também a uma fila SQS com o tráfego passando pela VPC. Perceba que o RDS e SQS são somente exemplos. Ou seja, o acesso remoto poderia ser feito a qualquer outro recurso que fosse acessível a partir da VPC, como por exemplo, um cluster do ElastiCache, um servidor Web, um bucket S3 ou qualquer outro recurso que possua um endereço IP da VPC. O diagrama abaixo mostra o ambiente que será criado para essa demonstração:

Pontos importantes:

• no computador local há duas portas abertas (1212 e 1213) que mantêm um túnel com o Session Manager. O tráfego destinado a essas portas locais será redirecionado para o banco de dados RDS e para a fila SQS, respectivamente.
• existe uma instância EC2 na VPC que vai funcionar como um jump server. Isso significa que é essa instância EC2 que permitirá a conectividade com os recursos desejados da VPC, no caso, o banco de dados RDS e a fila SQS.
• tanto o jump server quando o banco de dados RDS estão em uma subnet privada, sem acesso a Internet. Na VPC não há nenhuma subnet pública.
• o acesso à fila SQS ocorre através da ENI (placa de rede virtual) criada na subnet, que consegue acessar o serviço do SQS de forma privada através do PrivateLink. Isso é necessário pois a VPC não possui acesso a Internet e, portanto, não possui acesso ao endpoint público do serviço.
• a comunicação do jump server com o Session Manager ocorre via SSM Agent, que é um software instalado na instância EC2. Para seu correto funcionamento, o SSM Agent precisa se comunicar com os serviços do Session Manager e do Systems Manager. Nesse cenário, a comunicação ocorre através das ENIs (placas de rede virtuais) criadas na subnet, que conseguem acessar o serviço do Session Manager e o serviço Systems Manager de forma privada através do PrivateLink. Para a instância EC2 é como se as APIs desses serviços estivessem na VPC. Isso é necessário pois não há acesso a Internet a partir da VPC. Além disso, o SSM Agent precisa ter as devidas permissões para se comunicar com esses serviços. Para isso, a instância EC2 deve ser configurada com uma IAM Role que dê essas permissões.
• Toda comunicação, tanto do usuário com o Session Manager, quanto da instância EC2 com o Session Manager, o serviço Systems Manager e o serviço SQS, ocorre via HTTPS.

Preparando o ambiente

Atenção: A AWS oferece um nível gratuito para experimentação de seus produtos (AWS Free Tier) que pode ser utilizado para implementação dos exemplos, mas o leitor deve ficar atento para eventuais custos que possam ser gerados.

Para demonstrar como isso funciona na prática, foi criado um template CloudFormation que provisiona um ambiente baseado no diagrama anterior. A stack é composta por:

• uma VPC;
• duas subnets privadas;
• uma instância EC2 que utiliza Amazon Linux 2023 (AMI baseada na região AWS de N. Virginia - us-east-1) e que fará papel do jump server;
• uma IAM Role e um Instance Profile, que serão utilizados na instância EC2 e com permissões para acessar o Session Manager;
• um banco de dados RDS MySql;
• uma fila SQS;
• dois Interface VPC Endpoints para acessar os endpoints do Session Manager. Como a EC2 ficará em uma subnet sem conectividade com a Internet, o acesso aos endpoints do Session Manager da AWS ocorrerá através desses Interface VPC Endpoints;
• um Interface VPC Endpoint para acessar o endepoint do SQS. Como a EC2 ficará em uma subnet sem conectividade com a Internet, o acesso ao endpoint do SQS ocorrerá através desse Interface VPC Endpoint;
• um security group a ser utilizado nos Interface VPC Endpoints, que permite tráfego de entrada na porta 443 (lembre-se que o acesso aos endpoints da AWS ocorre via HTTPS através das ENIs criadas);
• um security group a ser utilizado no jump server;
• um security group a ser utilizado no banco de dados RDS, que permite tráfego originado do jump server;

Após fazer o download do template CloudFormation para seu computador, acesse sua conta na AWS e, no painel de gerenciamento do CloudFormation, clique no botão “Create stack > With new resources (standard)”. Escolha a opção “Upload a template file” e faça o upload do arquivo de template CloudFormation.

Na página seguinte, em “Stack name” preencha com um nome que achar melhor (ex: myStack) e informe um nome para o usuário master e a respectiva senha para acesso ao banco de dados. Prossiga nas próximas páginas com os valores padrão, até iniciar a criação da stack. Após alguns minutos, a stack estará criada. Na aba Output da stack de CloudFormation estarão disponíveis alguns dados que serão utilizados nos próximos passos.

Utilizando Session Manager com Port Forwarding para acesso ao RDS

Agora será demonstrado como acessar os recursos remotamente pelo Session Manager. Para isso, é preciso ter instalado e configurado o AWS CLI e o Session Manager plugin for the AWS CLI. Acesse os respectivos links caso não os tenha instalados.

O exemplo a seguir será feito utilizando o Windows 10 ou superior. Entretanto, o mesmo pode ser reproduzido em outro sistema operacional. Abra o Windows Powershell ou o Command Prompt e execute o comando abaixo:

aws ssm start-session --target <JumpServerInstanceID> --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters host="<RDSEndpoint>",portNumber="3306",localPortNumber="1213"

Onde:

• JumpServerInstanceID é o identificador da instância EC2 que funcionará como jump server. Esse dado, pode ser obtido no Output da stack de CloudFormation criada anteriormente.
• host é o endereço do recurso que se quer acessar remotamente. Deve ser um nome ou endereço IP acessível pela VPC onde está o jump server. Nesse caso, é o endereço da instância RDS (RDSEndpoint), que pode ser obtido no Output da stack de CloudFormation criada anteriormente.
• portNumber é a porta do recurso remoto (host) que se quer acessar. Nesse caso, como se trata de um banco de dados MySql, a porta padrão é a 3306, mas esse valor varia dependendo do recurso remoto a ser acessado.
• localPortNumber é a porta que será aberta no computador local e através da qual o tráfego será recebido para ser encaminhado para o recurso remoto. Nesse exemplo está sendo utilizada a porta 1213, mas poderia ser qualquer porta disponível.

Em resumo, o que esse comando faz é abrir a porta 1213 no computador local, ficar escutando o tráfego que chega nela e estabelecer um túnel com o serviço Session Manager. Todo o tráfego que essa porta receber será encaminhado para o serviço Session Manager, que por sua vez utilizará a instância EC2 como ponte para chegar ao host remoto na porta 3306. Após a execução do comando, será apresentada a tela conforme abaixo. Deixe esse terminal aberto, pois o comando precisa estar em execução para que o acesso funcione.

Para demonstrar o acesso ao banco de dados, será utilizada o DBeaver, que é uma ferramenta gráfica para gerenciamento de banco de dados. Você pode utilizar qualquer outra ferramenta ou aplicação de sua preferência.

Abra o DBeaver e crie uma nova conexão, escolhendo MySql como banco de dados.

Na tela de configuração da conexão, em Server Host informe localhost e em Port coloque 1213 ou a porta local que você utilizou para fazer o port forwarding. Note que, do ponto de vista do DBeaver, o acesso será feito para o computador local (localhost) e o encaminhamento para o verdadeiro servidor de banco de dados será feito de forma transparente. Em Username e Password informe o nome do usuário master e a respectiva senha que foram utilizados na criação de stack de CloudFormation.

Ao finalizar a configuração da conexão com o banco de dados será possível acessá-lo através do DBeaver, como se estivéssemos trabalhando com ele localmente. Entretanto, esse banco de dados está em uma VPC na AWS.

Utilizando Session Manager com Port Forwarding para acesso ao SQS

Agora será demonstrado como acessar um fila SQS remotamente através da VPC. Abra uma nova janela do Windows Powershell ou do Command Prompt e execute o comando abaixo:

aws ssm start-session --target <JumpServerInstanceID> --document-name AWS-StartPortForwardingSessionToRemoteHost --parameters host="sqs.us-east-1.amazonaws.com",portNumber="443",localPortNumber="1313"

Onde:

• JumpServerInstanceID é o identificador da instância EC2 que funcionará como jump server. Esse dado, pode ser obtido no Output da stack de CloudFormation criada anteriormente. É o mesmo jump server utilizado para o acesso ao RDS.
• host é o endereço do recurso que se quer acessar remotamente. Deve ser um nome ou endereço IP acessível pela VPC onde está o jump server. Nesse caso, é o endereço do endpoint público do SQS na região de N. Virgínia (onde foi criada a fila SQS). Apesar de ser o endereço do endpoint público do SQS, o acesso ocorrerá por dentro da VPC, pois nela foi criado o Interface VPC Endpoint para SQS.
• portNumber é a porta do recurso remoto (host) que se quer acessar. Nesse caso, como o SQS é um serviço gerenciado da AWS, o acesso a suas APIs é via HTTPS e por isso a porta utilizada é a 443.
• localPortNumber é a porta que será aberta no computador local e através da qual o tráfego será recebido para ser encaminhado para o recurso remoto. Nesse exemplo está sendo utilizada a porta 1313, mas poderia ser qualquer porta disponível.

Resumidamente, o que esse comando faz é abrir a porta 1313 no computador local, ficar escutando o tráfego que chega nela e estabelecer um túnel com o serviço Session Manager. Todo o tráfego que essa porta receber será encaminhado para o serviço Session Manager, que por sua vez utilizará a instância EC2 como ponte para chegar ao serviço SQS na porta 443 através do Interface VPC Endpoint. Após a execução do comando, será apresentada a tela conforme abaixo. Deixe esse terminal aberto, pois o comando precisa estar em execução para que o acesso funcione.

Abra mais uma janela do Windows Powershell ou do Command Prompt e execute o comando abaixo da AWS CLI abaixo para enviar uma mensagem para a fila SQS:

aws sqs send-message --queue-url <SQSQueueURL> --message-body "Olá mundo!" --endpoint-url https://localhost:1313 --no-verify-ssl

Onde:

• SQSQueueURL é a URL da fila SQS para onde será enviada a mensagem e que pode ser encontrada no Output da stack de CloudFormation criada anteriormente.
• endpoint-url é o endereço do endpoint que será utilizado para fazer essa chamada de API. Nesse caso, a chamada será feita para o computador local (localhost) na porta que foi aberta anteriormente (1313).
• o parâmetro no-verify-ssl desabilita a validação do certificado digital utilizado no endepoint do serviço da AWS. Isso é necessário pois o endereço de endpoint que estamos acessando (localhost) é diferente do endereço que consta no certificado digital, que é o endereço público do serviço SQS (sqs.us-east-1.amazonaws.com). Caso essa validação do certificado digital não fosse desabilitada, a diferença entre os nomes provocaria um erro. Essa validação não deve ser desabilitada em cenários produtivos.

O comando acima enviará uma mensagem para a fila SQS criada anteriormente através de uma URL que aponta para o computador local (localhost) na porta 1313, ao invés da URL pública padrão do SQS. O resultado será algo parecido com a imagem abaixo. Note que é exibida uma mensagem de alerta sobre a desabilitação da validação do certificado digital.

Por fim, confirme o recebimento da mensagem na fila SQS. Na console da AWS, acesse o painel do SQS e selecione a FilaTeste. Clique em “Send and receive messages”, depois clique em “Poll for messages” e veja que aparece a mensagem. Clicando nela é exibido o corpo da mensagem com o texto que foi enviado pelo comando da AWS CLI:

Dessa forma, é possível se conectar a qualquer recurso acessível pela VPC de forma remota. Isso se aplica a produtos que são provisionados na VPC, como bancos de dados RDS, clusters de cache do ElastiCache, etc, e também a serviços gerenciados da AWS, que não ficam na VPC dos usuários, como S3, SQS, SNS, etc. Nesse caso, é necessário o uso de Interface VPC Endpoint para que o acesso seja feito pela VPC.

Esse tipo de abordagem facilita e agiliza bastante o desenvolvimento de aplicações, pois permite que recursos na Cloud possam ser acessados através de um endereço local, sem que esses recursos precisem ficar expostos e sem que seja necessário ter um ambiente local replicando todos os recursos que compõem a solução. Como foi mostrado, para cada recurso que se deseja acessar remotamente é necessário utilizar uma porta local diferente e estabelecer uma sessão com o Session Manager, que deve permanecer aberta enquanto o acesso for necessário.

Depois de finalizar os testes, para fechar as sessões, utilize Ctrl + C em cada uma delas. Além disso, não esqueça de apagar a stack de CloudFormation para que não ocorra cobranças desnecessárias.

Referências

• Use port forwarding in AWS Systems Manager Session Manager to connect to remote hosts
• Securely connect to an Amazon RDS or Amazon EC2 database instance remotely with your preferred GUI
• New – Port Forwarding Using AWS System Manager Session Manager
• Starting a session (port forwarding to remote host)
• SSH Tunneling
• SSH Tunneling: Examples, Command, Server Config
• Acessando serviços AWS de forma privada com Interface VPC Endpoint/PrivateLink

Avisos

O conteúdo abaixo refere-se à versão DVA-C02 da prova, que passou a valer em fevereiro/2023. Apesar de não estar prevista uma nova versão da prova, dependendo de quando estiver lendo esse post, pode ser que o conteúdo esteja desatualizado. Então, fique atento.

Quero lembrar que o que funcionou para mim talvez não funcione para você. Cada pessoa tem uma forma diferente de estudar e aprender, e não há certo e nem errado. É importante que cada um conheça o que funciona melhor para si e faça os ajustes necessários. Eu, particularmente, gosto de misturar os vários formatos de conteúdo. Apesar de eu ter uma preferência por leitura, também gosto de complementar com vídeos. Também gosto de balancear a parte teórica com a prática. Enfim, avalie o que se adapta melhor ao seu estilo.

Certificação vale a pena?

Já dei minha opinião sobre certificação valer a pena ou não no post sobre a prova AWS Solutions Architect Professional. Não vou ser repetitivo aqui, mas em resumo, certificação não é bala de prata e nem é perfeita. Entretanto, ela oferece uma maneira estruturada de estudar um determinado campo do conhecimento. O valor da certificação não está no certificado propriamente dito, mas sim no processo de preparação e aprendizado. Nesse caso, passar na prova é uma consequência, e não o objetivo final.

A certificação AWS Certified Developer - Associate

Segundo a AWS, essa certificação “demonstra conhecimento e compreensão dos principais produtos da AWS, usos e práticas recomendadas básicas de arquitetura da AWS e proficiência no desenvolvimento, implantação e debugging de aplicações baseadas em nuvem usando a AWS”.

Como se trata de uma certificação do tipo Associate, espera-se um nível de dificuldade médio. Assim, como é esperado, ela não é nem de perto tão desgastante quanto a da AWS Solutions Architect Professional e possui um nível de dificuldade um pouco menor que a AWS Security Specialty. Isso não significa que você não precisa se preparar.

Principais pontos:

• escopo: possui um escopo mais limitado, ao contrário das provas de Solutions Architect (tanto Associate quanto Professional), que cobrem uma infinidade de produtos e serviços da AWS. O foco acaba sendo um domínio de conhecimento específico, no caso, Desenvolvimento na AWS. Isso reflete em menos conteúdo para estudar. Por outro lado, é exigido um conhecimento mais detalhado de certos serviços da AWS que fazem sentido quando falamos de desenvolvedores. Se você já fez algumas das provas de Solutions Architect da AWS, conseguirá reaproveitar esse conhecimento, o que irá facilitar
• complexidade e tamanho das questões: no geral, classificaria o nível de complexidade das questões como intermediário. Não houve perguntas gigantes, que fosse necessário rolar a tela para conseguir ler por completo. A maioria das questões foram de tamanho médio e, algumas poucas, com tamanho pequeno. Fiquei surpreso com algumas perguntas que eram bem diretas e fáceis. Isso me causou desconfiança, pois pensei que pudesse ser algum tipo de “pegadinha”, mas relendo atentamente confirmei que eram perguntas simples mesmo. De todo modo, foram poucas perguntas assim
• quantidade de perguntas e tempo da prova: são 65 questões de múltipla escolha ou múltiplas respostas, para 2 horas e 10 minutos de duração da prova. Para quem o Inglês não for o idioma nativo, é possível solicitar um tempo extra de 30 minutos. Na média, dá um pouco mais que 2 minutos por questão.

Como toda prova, além do conhecimento técnico, também são validados sua capacidade de gestão de tempo e seu controle mental, para que fique no nível de atenção e foco adequados. Como sempre, algumas perguntas vão levar mais tempo para serem respondidas, e aí você precisa recuperar esse tempo gasto a mais nas perguntas que são menores e mais diretas.

A prova pode ser feita em vários idiomas, inclusive Português do Brasil. Fiz a minha em Inglês (com o tempo extra de 30 minutos citado anteriormente), pois todo material de estudo que utilizei foi em Inglês. Prefiri assim pois queria evitar qualquer surpresa que fizesse eu gastar tempo, por exemplo, tentando entender o que uma eventual tradução “estranha” de algum termo técnico queria dizer. Mas de qualquer modo, a prova pode ser feita em Português para quem não se sentir confortável com Inglês.

O preço dessa certificação é de US$ 150. Se você já possui alguma certificação AWS, tem como benefício um desconto de 50% em outra prova. Nesse caso, o valor vai para US$ 75, que é um valor médio. Como todas as demais certificações da AWS, ela tem validade de 3 anos e precisa ser renovada para ser mantida.

Essa prova pode ser feito de forma on-line ou em um centro de exames. Como não gostei da experiência quando fiz a prova on-line da AWS Security Specialty, preferi fazer em um centro de exames. Só volto a fazer prova de certificação on-line novamente se não houver outra alternativa.

Tempo de estudo

Estudei durante aproximadamente 45 dias, de 2 a 3 horas de estudo por dia. Lembrando que parte do conteúdo eu já conhecia por causa de outras provas da AWS, então para esses casos acabou sendo uma revisão. Pode ser que você precise de mais tempo caso esteja vendo o conteúdo pela primeira vez. Além disso, cada pessoa tem um ritmo e outros compromissos que acabam demandando tempo, então isso vai variar. O importante é manter a consistência e a disciplina.

Materiais de estudo

Como nas outras provas, a maior parte do material apresentado aqui é paga. Antes de sair comprando material, se você assina alguma plataforma de cursos ou livros, vale verificar se ela já não oferece algo relativo a essa certificação. No meu caso, por exemplo, assino a O’Reilly e A Cloud Guru, e acabei lendo livros e fazendo cursos que encontrei lá.

Leitura

Não encontrei livros da versão DVA-C02. Acabei lendo alguns capítulos de dois livros da versão DVA-C01 da prova (que estão disponíveis na O’Reilly). Como é um material de certa forma desatualizado, preferi focar em capítulos de assuntos que são mais cobrados na prova de AWS Developer Associate e que eu não dominava, de forma a não gastar muito tempo neles. O plano seria complementar e revisar esse conteúdo com os demais materiais, teoricamente mais atualizados.

Além disso, também li também alguns white papers da AWS.

Abaixo, a lista de materiais de leitura que utilizei:

• livro AWS Certified Developer Associate All-in-One Exam Guide (Exam DVA-C01)
• livro AWS Certified Developer Official Study Guide, Associate Exam
• White Papers
  • Practicing Continuous Integration and Continuous Delivery on AWS
  • Overview of Deployment Options on AWS
  • Running Containerized Microservices on AWS
  • Implementing Microservices on AWS
  • Optimizing Enterprise Economics with Serverless Architectures
  • Serverless Applications Lens AWS Well-Architected Framework

Vídeos

Atualmente, a maior parte dos materiais feitos para provas de certificação são cursos em vídeos. Assisti aos cursos do A Cloud Guru e da Udemy. O do A Cloud Guru e o do Neal Davis, da Udemy, achei superificiais em vários tópicos. O curso do Neal Davis foi o que mais me decepcionou, pois não manteve o nível de profundidade que eu já havia visto em outros cursos dele. Um reflexo disso é o tempo de duração desse treinamento, que é praticamente a metade dos outros dois. O do Stephane Maarek, também da Udemy, é sem dúvidas o melhor e mais completo, com um nível de detalhamento muito bom. Se tivesse que escolher somente um curso para fazer, escolheria esse.

• Ultimate AWS Certified Developer Associate 2023 NEW DVA-C02 - Udemy - de Stephane Maarek
• AWS Certified Developer Associate Exam Training DVA-C02 - Udemy - de Neal Davis
• AWS Certified Developer - Associate (DVA-C02) - A Cloud Guru - de Faye Ellis

Simulados

Os simulados são importantes pois é a experiência mais próxima que você terá da prova real. Os simulados listados abaixo possuem uma explicação detalhada da resposta de cada questão, o que é fonte importante de conhecimento para aprender coisas novas. Além disso, é comum aparecerem alguns tópicos que não haviam sido abordados nos cursos, o que acabava complementando o conhecimento. Os melhores simulados, na minha opinião, são do Jon Bonso (Tutorials Dojo) e do Stephane Maarek. Uma dica que dou é: quanto mais simulados você fizer, melhor.

• AWS Certified Developer Associate DVA-C02 Practice Exams 2023 - Tutorials Dojo - de Jon Bonso
• Practice Exams | AWS Certified Developer Associate 2023 - Udemy - de Stephane Maarek
• AWS Certified Developer Associate Practice Exam Questions - Udemy - de Neal Davis

Principais assuntos

Por se tratar de uma prova voltada para desenvolvedores, você tem que dominar temas relacionados a serviços de pipelines de CI/CD (CodeCommit, CodeBuild, CodeDeploy, CodePipeline) e estratégias de deployment, serviços serverless utilizados em desenvolvimento de aplicações (Lambda, DynamoDB, API Gateway, Cognito, SQS, SNS, Step Functions) e infraestrutura como código com CloudFormation. Também se prepare para responder sobre Kinesis, Elastic Beanstalk e X-Ray. Além disso, os recursos mais básicos da AWS, como VPC, AZs, Subnet, Route Rable, Security Group, Network ACL, EC2, EBS, ELB, S3, também serão exigidos de uma forma ou de outra, mas sem um nível muito grande de profundidade. No meu caso, caíram muitas perguntas de API Gateway e X-Ray. Para minha surpresa, não houve nenhuma questão pedindo para calcular o RCU ou WCU de uma tabela DynamoDB! Eu tinha “certeza” que haveria pelo menos uma pergunta dessas, mas a AWS deve ter mudado isso com a nova versão da prova, já que essa deveria ser uma das perguntas mais manjadas. Lembrando que isso vai variar a cada prova. Não necessariamente você encontrará os mesmos tópicos na sua prova.

Conclusão

Como expliquei antes, por se tratar de uma prova de nível Associate e com foco em Desenvolvimento na AWS, o escopo fica limitado em termos de quantidade de assuntos, resultando em menos conteúdo para estudar quando comparada com outras provas, principalmente as de Solutions Architect. Entretanto, é exigido um nível de profundidade um pouco maior dos assuntos. Além disso, se você também fez outras provas da AWS, então irá reaproveitar muita do que estudou, o que é uma vantagem. Deixando claro aqui que o que funcionou para mim não necessariamente vai funcionar para você. Espero que esse plano de estudo contribua na sua preparação. Boa prova!

No cenário demonstrado no post anterior, a comunicação às APIs dos serviços Session Manager e Systems Manager ocorria via endpoints públicos. Assim, a instância EC2 (que está em uma subnet privada) precisa de acesso de saída para Internet. Isso é fornecido através de um NAT Gateway na subnet pública, que por sua vez utiliza o Internet Gateway. Apesar da necessidade de saída para Internet, esse tráfego se mantém na rede da AWS, pois estão sendo acessados endpoints públicos da própria AWS.

Aqui há um ponto de atenção importante que pode gerar confusão: nesse cenário, apesar do acesso a endpoints públicos e do tráfego passar pelo Internet Gateway, a AWS afirma que o tráfego não deixa sua rede privada. Dessa forma, como a origem e o destino do acesso ficam na própria AWS, o tráfego não vai pela Internet, apesar do destino ser um endpoint público acessível pela Internet e apesar de passar pelo Internet Gateway. Isso pode parecer um pouco confuso e contraintuivo, já que seria natural supor que essa comunicação ocorreria pela Internet, mas em suas documentações a AWS afirma que isso não acontece na prática.

Isso pode não ser um problema caso a aplicação já precise ter conectividade com a Internet por outros motivos. Entretanto, caso a aplicação não tenha essa necessidade, seríamos obrigados a prover essa conectividade com a Internet (com Internet Gateway e com NAT Gateway) somente para acessar os endpoints públicos dos serviços da AWS. Para esses cenários, em que não há necessidade ou não se quer acessar os serviços da AWS através de seus endpoints públicos, existe a possibilidade de acessá-los de forma privada através de Interface VPC Endpoints.

Acesso remoto via AWS Systems Manager Session Manager com Interface VPC Endpoints

O Interface VPC Endpoint utiliza uma tecnologia da AWS chamada PrivateLink, que permite estabeler conectividade privada entre a VPC e os serviços da AWS suportados. Isso ocorre através da criação de uma ENI - Elastic Network Interface (uma placa de rede virtual) na subnet de uma VPC e que dá conectividade direta aos serviços. Na prática, é como se esses serviços da AWS estivessem na própria VPC. Dessa forma, a aplicação pode estar em uma VPC sem conectividade com a Internet e vai conseguir acessar o serviço AWS através do Interface VPC Endpoint, sem a necessidade de acesso ao endpoint público. O desenho de arquitetura a seguir representa como isso funciona no cenário de acesso remoto a uma instância EC2 através do Session Manager:

Pontos importantes:

• o servidor de aplicação (instância EC2) está em uma subnet privada, ou seja, sem acesso a Internet.
• a comunicação do servidor de aplicação com o Session Manager ocorre via SSM Agent, que é um software instalado na instância EC2. Para seu correto funcionamento, o SSM Agent precisa se comunicar com os serviços do Session Manager e do Systems Manager. Nesse cenário, a comunicação ocorre através da ENI (placa de rede virtual) criada na subnet, que consegue acessar o serviço do Session Manager e o serviço Systems Manager de forma privada através do PrivateLink. Para a instância EC2 é como se as APIs desses serviços estivessem na VPC. Além disso, o SSM Agent precisa ter as devidas permissões para se comunicar com esses serviços. Para isso, a instância EC2 deve ser configurada com uma IAM Role que dê essas permissões.
• Toda comunicação, tanto do usuário com o Session Manager, quanto da instância EC2 com o Session Manager e o serviço Systems Manager, ocorre via HTTPS.

Para mais detalhes sobre Interface VPC Endpoint e PrivateLink, consulte Acessando serviços AWS de forma privada com Interface VPC Endpoint/PrivateLink

Preparando o ambiente

Atenção: A AWS oferece um nível gratuito para experimentação de seus produtos (AWS Free Tier) que pode ser utilizado para implementação dos exemplos, mas o leitor deve ficar atento para eventuais custos que possam ser gerados.

Para demonstrar como isso funciona na prática, foi criado um template CloudFormation que provisiona um ambiente inicial baseado no diagrama anterior. A stack será composta por:

• uma VPC;
• uma subnet privada;
• um security goup a ser utilizado nos Interface VPC Endpoints, que permite tráfego de entrada na porta 443 (lembre-se que o acesso aos endpoints da AWS ocorre via HTTPS através da ENI criada);
• uma instância EC2 que utiliza Amazon Linux 2023 (AMI baseada na região AWS de N. Virginia - us-east-1);
• uma IAM Role e um Instance Profile, que serão utilizados na instância EC2 e com permissões para acessar o Session Manager;

A partir desse ambiente base, serão feitas as configurações necessárias para permitir o uso do Session Manager.

Após fazer o download do template CloudFormation para seu computador, acesse sua conta na AWS e, no painel de gerenciamento do CloudFormation, clique no botão “Create stack > With new resources (standard)”. Escolha a opção “Upload a template file” e faça o upload do arquivo de template CloudFormation. Na página seguinte, em “Stack name” preencha com um nome que achar melhor (ex: StackBase) e prossiga nas próximas páginas com os valores padrão, até iniciar a criação da stack. Após alguns minutos, a stack estará criada.

Criando Interface VPC Endpoints para Session Manager

Quando estiver disponível, a instância EC2 estará em uma subnet privada, sem conectividade com a Internet e, consequentemente, sem acesso ao Session Manager. Para confirmar isso, acesse o painel de EC2 na console AWS, em seguida vá para a opção de menu Instances no lado esquerdo da página, selecione a instância AppServer e clique em Connect na parte de cima da página. Em seguida, escolha a opção “Session Manager”. Como esperado, o botão Connect estará desabilitado e aparecerá uma mensagem informando que não é possível se conectar à instância:

Agora será criado o Interface VPC Endpoint para o serviço Systems Manager. Para isso, acesse o painel de VPC na console AWS. No menu do lado esquerdo, escolha a opção “Virtual Private Cloud > Endpoints”, clique no botão “Create endpoint” e informe os seguintes dados:

• Name: SSMInterfaceEndpoint
• Service Category: selecione AWS Services
• Service Name: selecione com.amazonaws.us-east-1.ssm
• VPC: selecione myVPC
• Availability Zone: selecione us-east-1a
• Subnet ID: escolha a opção mySubnet
• Security Groups: selecione VPCEndpointSecurityGroup
• Clique em “Create endpoint

Repita o procedimento para criar o Interfa VPC Endpoint para o serviço Session Manager e informe os seguintes dados:

• Name: SSMMessagesInterfaceEndpoint
• Service Category: selecione AWS Services
• Service Name: selecione com.amazonaws.us-east-1.ssmmessages
• VPC: selecione myVPC
• Availability Zone: selecione us-east-1a
• Subnet ID: escolha a opção mySubnet
• Security Groups: selecione VPCEndpointSecurityGroup
• Clique em “Create endpoint

Uma observação importante: esses são os Interface VPC Endpoints mínimos para poder utilizar o Session Manager. Dependendo do seu caso de uso, talvez sejam necessários outros Interface VPC Endpoints para uso de outras funcionalidades do Systems Manager. Para mais informações, consulte Creating VPC endpoints for Systems Manager e também How do I create VPC endpoints so that I can use Systems Manager to manage private EC2 instances without internet access?

Utilizando Session Manager via console AWS (browser)

Após o Interface VPC Endpoint ficar disponível, tente novamente acessar a instância EC2 pelo Session Manager. Para isso, acesse o painel de EC2 na console AWS, em seguida vá para a opção de menu Instances no lado esquerdo da página, selecione a instância AppServer e clique em Connect na parte de cima da página. Em seguida, escolha a opção “Session Manager”. Se tudo correu conforme o esperado, o botão Connect estará habilitado.

Talvez seja necessário aguardar de 5 a 10 minutos após a criação dos Interface VPC Endpoints para que a mensagem de erro na tela de acesso do Session Manager deixe de aparecer.

Clicando nno botão Connect, será aberta uma janela no browser simulando um terminal na instância EC2. Os comando digitados nesse terminal serão executados na instância EC2.

Para terminar a sessão, clique em Terminate.

Com essa configuração, também é possível acessar a instância EC2 através da linha de comando, utilizando o AWS CLI, como foi demonstrado em Acessando recursos remotamente em uma VPC na AWS - parte 3 - AWS Systems Manager Session Manager

Assim, além das vantagens citadas no post anterior (servidor de aplicação não precisar ficar exposto na Internet, uso de um serviço gerenciado da AWS que diminui a sobrecarga operacional, etc), o uso de Interface VPC Endpoint com o Session Manager faz com que a VPC não precise ter acesso a Internete para acessar as APIs da AWS. Assim, não é necessário ter o Internet Gateway e/ou NAT Gateway.

É importante destacar que o custo do Interface VPC Endpoint é calculado por hora em que ele está provisionado em cada AZ e pelo tráfego processado por ele. Mais informações em AWS PrivateLink Pricing. Dessa forma, depois de finalizar os testes, não esqueça de excluir os Interface VPC Endpoints e apagar a stack de CloudFormation com os demais recursos.

No próximo post serão mostradas outras funcionalidades que o Session Manager fornece.

Referências

• How do I create VPC endpoints so that I can use Systems Manager to manage private EC2 instances without internet access?
• Creating VPC endpoints for Systems Manager
• Acessando serviços AWS de forma privada com Interface VPC Endpoint/PrivateLink
• AWS Systems Manager Session Manager for Shell Access to EC2 Instances
• Connect to an Amazon EC2 instance by using Session Manager
• LAB 1: ELIMINATE BASTION HOSTS WITH SYSTEMS MANAGER
• AWS MANAGEMENT AND GOVERNANCE TOOLS WORKSHOP - SESSION MANAGER
• AWS Systems Manager Session Manager
• Start a session

Os endpoints são basicamente URLs e no geral seguem o padrão abaixo:

protocolo://[código-do-serviço].[código-da-região].amazonaws.com

Por exemplo, o endpoint do SQS da região N.Virginia da AWS é:

https://sqs.us-east-1.amazonaws.com

Mais informações em AWS service endpoints.

Aplicações que são executadas na AWS certamente precisam acessar um ou mais desses serviços da AWS. Como os endpoints por padrão são públicos, isso significa que as aplicações precisam estar em uma VPC que tenha conectividade com a Internet para conseguir acessar os endpoints e usar esses serviços. Na prática, isso se traduz na necessidade de se ter um Internet Gateway na VPC. Se a aplicação estiver em uma subnet privada, também será necessário um NAT Gateway. O diagrama abaixo representa esse cenário, em que a aplicação em uma instância EC2 em uma subnet privada precisa acessar uma fila SQS na AWS.

Aqui há um ponto de atenção importante que pode gerar confusão: nesse cenário, apesar do acesso a endpoints públicos e do tráfego passar pelo Internet Gateway, a AWS afirma que o tráfego não deixa sua rede privada. Dessa forma, como a origem e o destino do acesso ficam na própria AWS, o tráfego não vai pela Internet, apesar do destino ser um endpoint público acessível pela Internet e apesar de passar pelo Internet Gateway. Isso pode parecer um pouco confuso e contraintuivo, já que seria natural supor que essa comunicação ocorreria pela Internet, mas em suas documentações a AWS afirma que isso não acontece na prática.

Isso pode não ser um problema caso a aplicação já precise ter conectividade com a Internet por outros motivos. Entretanto, caso a aplicação não tenha essa necessidade, seríamos obrigados a prover essa conectividade com a Internet (com Internet Gateway e talvez com o NAT Gateway) somente para acessar os endpoints públicos dos serviços da AWS. Para esses cenários, em que não há necessidade ou não se quer acessar os serviços da AWS através de seus endpoints públicos, existe a possibilidade de acessá-los de forma privada através de VPC Endpoints.

VPC Endpoints

Existem três tipos de VPC Endpoints: o Gateway, o Gateway Load Balancer e o Interface. O Gateway VPC Endpoint suporta somente dois serviços da AWS (S3 e DynamoDB), funciona através da criação de regras na Route Table e é gratuito. Entretanto, esse tipo de VPC Endpoint não recebe mais evolução da AWS.

O Gateway Load Balancer VPC Endpoint serve para enviar tráfego de forma privada para appliances virtuais de terceiros, geralmente para inspeções de segurança ou outros serviços de rede. Ele também é configurado através da criação de regras na Route Table.

Os VPC Endpoints do tipo Gateway e Gateway Load Balancer não serão abordados nesse artigo. Mais informações sobre podem ser encontradas em Gateway endpoints e Access virtual appliances through AWS PrivateLink.

O Interface VPC Endpoint suporta uma gama muito maior de serviços da AWS (que são atualizados conforme novos produtos são lançados) e utiliza uma tecnologia da AWS chamada PrivateLink, que permite estabeler conectividade privada entre a VPC e os serviços da AWS suportados. Isso ocorre através da criação de uma ENI - Elastic Network Interface (uma placa de rede virtual) na subnet de uma VPC e que dá conectividade direta aos serviços. Na prática, é como se esses serviços da AWS estivessem na própria VPC. Dessa forma, a aplicação pode estar em uma VPC sem conectividade com a Internet e vai conseguir acessar o serviço AWS através do Interface VPC Endpoint, sem a necessidade de acesso ao endpoint público. O desenho de arquitetura a seguir representa como isso funciona considerando o mesmo exemplo anterior, ou seja, uma aplicação em uma instância EC2 em uma subnet privada acessando uma fila SQS na AWS:

É importante notar que:

• a aplicação está em uma subnet privada, ou seja, sem acesso a Internet.
• o acesso acontece através da ENI (placa de rede virtual) criada na subnet, que consegue acessar a fila SQS de forma privada através do PrivateLink. Para a aplicação é como se a fila SQS estivesse na VPC.
• o acesso ao serviço AWS pode ser feito através da mesma URL do endpoint público. Quando o Interface VPC Endpoint é criado, automaticamente é feita uma configuração no DNS que resolve a URL do endpoint público para o endereço IP privado da ENI na VPC ao invés do endereço IP público (essa é uma técnica chamada split-horizon DNS). Dessa forma, o uso do Interface VPC Endpoint é transparente para a aplicação, que não precisa ser alterada. Mais detalhes em DNS Resolution.

Preparando o ambiente

Atenção: A AWS oferece um nível gratuito para experimentação de seus produtos (AWS Free Tier) que pode ser utilizado para implementação dos exemplos, mas o leitor deve ficar atento para eventuais custos que possam ser gerados.

Para demonstrar como isso funciona na prática, foi criado um template CloudFormation que provisiona um ambiente inicial baseado no diagrama anterior. A stack será composta por:

• uma VPC;
• uma subnet privada;
• dois Interface VPC Endpoints para acessar os endpoints do Session Manager. Utilizaremos o Session Manager para ter acesso ao shell da EC2 para demonstrar o funcionamento do Interface VPC Endpoint. Como a EC2 ficará em uma subnet sem conectividade com a Internet, o acesso aos endpoints do Session Manager da AWS ocorrerá através desses Interface VPC Endpoints;
• um security goup a ser utilizado nos Interface VPC Endpoints, que permite tráfego de entrada na porta 443 (lembre-se que o acesso aos endpoints da AWS ocorre via HTTPS através da ENI criada);
• uma instância EC2 que utiliza Amazon Linux 2023 (AMI baseada na região AWS de N. Virginia - us-east-1);
• uma IAM Role e um Instance Profile, que serão utilizados na instância EC2 e com permissões para acessar o SQS e o Session Manager;
• uma fila SQS;

A partir desse ambiente base, serão feitas as configurações necessárias para permitir o acesso da EC2 à fila SQS de forma privada.

Faça o download do template CloudFormation para seu computador. Acesse sua conta na AWS e, no painel de gerenciamento do CloudFormation, clique no botão “Create stack > With new resources (standard)”. Escolha a opção “Upload a template file” e faça o upload do arquivo de template CloudFormation obtido anteriormente. Na página seguinte, em “Stack name” preencha com um nome que achar melhor (ex: StackBase) e prossiga nas próximas páginas com os valores padrão, até iniciar a criação da stack. Após alguns minutos, a stack estará criada.

Na aba Resources, encontre a fila SQS criada e anote o valor da coluna “Physical ID”, que contém a URL da fila SQS a ser utilizada posteriormente.

Utilizando Interface VPC Endpoint

Quando estiver disponível, a instância EC2 estará em uma subnet privada, sem conectividade com a Internet e nem com o SQS. Para confirmar isso, acesse o painel de EC2 na console AWS, em seguida vá para a opção de menu Instances no lado esquerdo da página, selecione a instância AppServer e clique em Connect na parte de cima da página. Em seguida, escolha a opção “Session Manager”. Se tudo correu conforme o esperado, o botão Connect estará habilitado e clicando nele será aberta uma janela no browser simulando um terminal na instância EC2.

Digite o comando abaixo para tentar acessar um site na Internet com um timeout de 15 segundos:

curl -I https://example.com --connect-timeout 15

Note que após 15 segundos, aparece uma mensagem de erro informando que não foi possível se conectar ao servidor. Isso confirma que a instância EC2 não consegue acessar a Internet. Agora, execute o comando da AWS CLI abaixo para tentar enviar uma mensagem para a fila SQS (substitua “URL da fila” pela URL gerada na criação da fila na stack de CloudFormation)

aws sqs send-message --queue-url <URL da fila> --message-body "Olá mundo!" 

Após um tempo, aparece uma mensagem de timeout indicando que não foi possível realizar a operação. Em seguida, execute o comando abaixo que deveria retornar o endereço IP do endpoint do serviço SQS na região de N. Virginia da AWS:

dig sqs.us-east-1.amazonaws.com +short

O endereço IP retornado é o público, e não um endereço IP privado da VPC. A figura abaixo mostra os resultados dos comandos apresentados:

Agora faremos a criação do Interface VPC Endpoint para o serviço SQS. Para isso, acesse o painel de VPC na console AWS. No menu do lado esquerdo, escolha a opção “Virtual Private Cloud > Endpoints”, clique no botão “Create endpoint” e informe os seguintes dados:

• Name: SQSVPCEndpoint
• Service Category: selecione AWS Services
• Service Name: selecione com.amazonaws.us-east-1.sqs
• VPC: selecione myVPC
• Availability Zone: selecione us-east-1a (use1-az4)
• Subnet ID: escolha a opção mySubnet
• Security Groups: selecione VPCEndpointSecurityGroup
• Clique em “Create endpoint

Após o Interface VPC Endpoint ficar disponível, selecione-o e na parte de baixo da página, na aba Subnets, role a tela para a direita até encontar o campo “Network Interface ID”. Clique no link para abrir a página onde é possível ver a ENI - Elastic Network Interface que foi criada na subnet, através da qual será possível acessar o endpoint do SQS de forma privada.

Volte para o terminal do Session Manager e reexecute os três comandos acima. O primeiro, que tenta acessar um site na Internet, continua a não funcionar. Esse é o comportamento esperado, pois a subnet continua sem conectividade com a Internet. Entretanto, os dois comandos seguintes, um que envia uma mensagem para a fila SQS e o outro que retorna o endereço IP do endpoint do serviço SQS agora funcionam. Note que o endereço IP retornado no último comando é um endereço IP privado da faixa de IPs da VPC, que é o mesmo endereço IP associado a ENI:

Por fim, confirme o recebimento da mensagem na fila SQS. Na console da AWS, acesse o painel do SQS e selecione a FilaTeste. Clique em “Send and receive messages”, depois clique em “Poll for messages” e veja que aparece a mensagem. Clicando nela é exibido o corpo da mensagem com o texto que foi enviado pelo comando da AWS CLI:

É importante destacar que o custo do Interface VPC Endpoint é baseado por hora em que ele está provisionado em cada AZ e pelo tráfego processado por ele. Mais informações em AWS PrivateLink Pricing. Dessa forma, depois de finalizar os testes, não esqueça de excluir o Interface VPC Endpoint para o SQS e apagar a stack de CloudFormation com os demais recursos.

Nesse artigo foi mostrado como é possível acessar serviços da AWS de forma privada, a partir de uma VPC que não tenha conectividade com a Internet. Outro ponto interessante é que esse modelo não se aplica somente aos serviços AWS. Ou seja, ele também pode ser utilizado para acessar serviços customizados ou de terceiros de forma privada através de VPC Endpoints Services, mas isso é assunto para um próximo post.

Referências

• What is AWS PrivateLink?
• Access AWS services through AWS PrivateLink
• Does traffic between Amazon EC2 and Amazon S3 really go over the internet?
• Does traffic go over the internet when two instances communicate using public IP addresses, or when instances communicate with a public AWS service endpoint?
• Reduce Cost and Increase Security with Amazon VPC Endpoints
• VPC Endpoint Workshop

Nesse post, será mostrado como o uso de um serviço gerenciado da AWS, o Session Manager, endereça esses problemas.

Acesso remoto via AWS Systems Manager Session Manager

O Session Manager é um serviço gerenciado da AWS que faz parte do “guarda-chuvas” do produto AWS Systems Manager. O Session Manager permite acessar os recursos de uma VPC remotamente sem a necessidade de um Bastion Host e sem que os recursos precisem ficar em uma subnet pública. O controle de acesso é integrado com o serviço de IAM da AWS, ou seja, o usuário se autentica com as mesmas credenciais de acesso à AWS, não sendo necessário o uso e gerenciamento de pares de chaves. Por ser um serviço gerenciado, não é preciso se preocupar e gastar esforço em manter uma infraestrutura adicional. Além disso, não há custos adicionais para uso do Session Manager em si, (mas há custo para a infraestrutura envolvida). O diagrama a seguir mostra o cenário de exemplo que será implementado.

Note que:

• O usuário acessa via Internet somente o Session Manager, que é o serviço gerenciado da AWS. Não há acesso direto à instância EC2. O acesso do usuário pode ser tanto via console de gerenciamento da AWS ou por linha de comando, conforme será mostrado adiante.
• A comunicação do servidor de aplicação com o Session Manager ocorre via SSM Agent, que é um software instalado na instância EC2. Para seu correto funcionamento, o SSM Agent precisa se comunicar com os serviços do Session Manager e do Systems Manager. Nesse cenário, a comunicação ocorre via endpoints públicos desses serviços. Além disso, o SSM Agent precisa ter as devidas permissões para se comunicar com esses serviços. Para isso, a instância EC2 deve ser configurada com uma IAM Role que dê essas permissões.
• A instância EC2 encontra-se em uma subnet privada. Como o SSM Agent necessita se comunicar com os serviços do Session Manager e do Systems Manager através de seus endpoints públicos, a instância EC2 precisa de acesso de saída para Internet. Isso é fornecido através de um NAT Gateway na subnet pública. Apesar da necessidade de saída para Internet, esse tráfego se mantém na rede da AWS, pois estão sendo acessados endpoints públicos da própria AWS. É sempre o SSM Agent que inicia a conexão com os serviços do Session Manager e do Systems Manager.
• Toda comunicação, tanto do usuário com o Session Manager, quanto da instância EC2 com o Session Manager e o serviço Systems Manager, ocorre via HTTPS.

Preparando o ambiente

Atenção: A AWS oferece um nível gratuito para experimentação de seus produtos (AWS Free Tier) que pode ser utilizado para implementação dos exemplos, mas o leitor deve ficar atento para eventuais custos que possam ser gerados.

Para implementar esse cenário, acesse sua conta AWS através da console. O primeiro passo é criar uma VPC, uma subnet pública, uma subnet privada e um NAT Gateway. A VPC padrão que toda conta AWS possui já vem com uma subnet pública e Internet Gateway configurados e é ela que iremos utilizar nesse exemplo. Caso queira, você pode começar do zero e criar uma nova VPC com uma nova subnet e configurar o Internet Gateway nela. Crie também uma subnet privada, ou seja, uma subnet cuja Route Table não possua roteamento para o Internet Gateway, mas com roteamento para o NAT Gateway. Essa Route Table e o NAT Gateway também deverão ser criados.

No painel de gerenciamento de VPC, acesse a opção NAT gateways no menu do lado esquerdo e depois clique no botão “Create NAT Gateway”. Preencha os campos com os seguintes valores:

• Name: MeuNATGateway
• Subnet: selecione uma subnet pública
• Elastic IP allocation ID: clique em “Allocate Elastic IP” para que um Elastic IP seja criado e depois selecione-o.
• Clique em “Create NAT Gateway”

No painel de gerenciamento de VPC, acesse a opção Route tables no menu do lado esquerdo e depois clique no botão “Create route table”. Preencha os campos com os seguintes valores:

• Name: PrivateRouteTable
• VPC: selecione a VPC que será utilizada
• Clique em “Create route table”

Quando uma Route Table é criada, por padrão ela só possui uma rota que realiza roteamento local para dentro da VPC. Para que o servidor de aplicação que será criado na subnet privada tenha saída para Internet, será necessário adicionar uma outra rota que direcione as conexões diferentes das locais para o NAT Gateway. Para isso, selecione a Route Table, clique em Routes e depois em “Edit routes”. Na página que se abre, clique em “Add route” e preencha:

• Destination: 0.0.0.0/0 para indicar qualquer conexão para um destino que não se enquadre nas demais regras de rotas
• Target: NAT Gateway > MeuNATGateway
• Clique em “Save changes”

Ainda no painel de gerenciamento de VPC, acesse o menu Subnets e depois clique no botão “Create subnet”, para criar a subnet privada com a seguinte configuração:

• VPC: escolha a VPC que será utilizada
• Subnet Name: Private Subnet
• Availability Zone: escolha uma zona de disponibilidade (AZ) onde a subnet será criada, de preferência, a mesma AZ onde foi criado o NAT Gateway
• IPv4 CIDR block: informe um bloco de endereços IP que seja válido na sua VPC
• Clique em “Create subnet”
• após a subnet ter sido criada, selecione-a e acesse a aba Route table no painel na parte debaixo da página. Perceba que a Route Table que essa subnet está utilizando é a main, que dá acesso a Internet. Temos que trocá-la pela Route Table que foi criada anteriormente. Para isso, clique no botão “Edit route table association”
• selecione a Route Table PrivateRouteTable e confirme a existência das rotas para roteamento local e para o NAT Gateway. Clique em Save

Agora será criada a IAM Role que depois vai ser configurada na instância EC2. Essa IAM Role deverá ter as políticas necessárias para o SSM Agent conseguir acessar os serviços do Session Manager e do Systems Manager. Vá para o painel de gerenciamento de IAM na console AWS, escolha a opção Access management > Roles no menu a esquerda e depois clique em “Create role”. Preencha os campos conforme a seguir:

• Trusted entity type: AWS Service
• Use case: EC2
• Clique em Next
• Na página de escolha da política, selecione a AmazonSSMManagedInstanceCore, que é uma política gerenciada da AWS já com as permissões necessárias. Clique em Next.
• Role Name: EC2_SSM_Role
• Clique em “Create Role”

O passo seguinte é criar uma instância EC2 que fará o papel do servidor de aplicação. Por se tratar de um cenário hipotético, será criada somente uma instância EC2, mas o mesmo procedimento poderia ser realizado mais vezes, caso houvesse mais de um servidor de aplicação. Vá para o painel de gerenciamento de EC2 na console da AWS, escolha a opção “Launch Instance” e informe as seguintes configurações:

• Name: AppServer
• Application and OS Images (Amazon Machine Image): Amazom Linux -Amazon Linux 2023 AMI. Essa AMI já possui o SSM Agent instalado por padrão. A lista de AMIs que possuem o SSM Agent instalado por padrão encontra-se em Amazon Machine Images (AMIs) with SSM Agent preinstalled.
• Instance type: t2.micro (esse tipo de instância é elegível ao free tier da AWS)
• Key pair (login): selecione a opção “Proceed without a key pair (Not recommended)”, pois o acesso à instância EC2 será através do Session Manager, que não necessita de par de chaves.
• Network Settings:
  • Nesse item, devemos configurar a subnet a ser utilizada. Clique em Edit
  • VPC: escolha a VPC que será utilizada
  • Subnet: escolha a subnet privada chamada Private Subnet criada anteriormente
  • Firewall (security groups)
    • Mantenha a opção pré-selecionada “Create security group”
    • Security group name: para facilitar a identificação, preencha com “AppServer Security Group”
    • Inbound Security Group Rules: perceba que por padrão, esse security group será criado com a porta 22 do SSH aberta para a Internet. Entretanto, não iremos utilizar SSH para acessar a instância, já que utilizaremos o Session Manager. Nesse caso, podemos clicar em Remove para remover essa regra. Dessa maneira, esse security group não terá nenhuma regra que permita exposição de qualquer porta.

      

• Advanced details:
  • IAM instance profile: escolha a opção EC2_SSM_Role, que é a IAM Role criada anteriormente e que contém as permissões necessárias para o SSM Agent conseguir se comunicar com os serviços Session Manager e Systems Manager.
• Deixe as demais configurações de EC2 com os valores padrão, pois não será necessário alterá-los para a demonstração que será feita. Clique em “Launch Instance” e aguarde a instância EC2 ficar disponível.

Utilizando Session Manager via console AWS (browser)

Agora é possível acessar a instância EC2 remotamente através do Session Manager. Primeiro, será desmonstrado como fazer isso pela console da AWS, ou seja, via browser. Há duas opções: através do painel de EC2 ou através do painel do Systems Manager.

Para iniciar uma sessão no Session Manager pelo painel de EC2 na console AWS, acesse a opção de menu Instances no lado esquerdo da página, selecione a instância AppServer e clique em Connect na parte de cima da página. Em seguida, escolha a opção “Session Manager”. Se tudo correu conforme o esperado, o botão Connect estará habilitado e clicando nele será aberta uma janela no browser simulando um terminal na instância EC2. Os comando digitados nesse terminal serão executados na instância EC2.

Para iniciar uma sessão no Session Manager pelo painel de Systems Manager na console AWS, acesse a opção de menu “Session Manager” no lado esquerdo da página. Será mostrada uma página com todas as sessões ativas no momento. Clique no botão “Start session”, selecione a instância AppServer, clique em Next duas vezes e em seguida em “Start session”. Novamente será aberta uma janela no browser simulando um terminal na instância EC2. Os comando digitados nesse terminal serão executados na instância EC2.

O painel do Systems Manager, além de mostrar as sessões do Session Manager ativas no momento, também permite consultar o histórico de todas as sessões já abertas, acessando a opção “Session history”.

Para terminar a sessão, clique em Terminate.

Utilizando Session Manager via linha de comando (AWS CLI)

Agora será demonstrado como acessar a instância EC2 remotamente pelo Session Manager através da linha de comando, utilizando o AWS CLI. Para isso, é preciso ter instalado e configurado o AWS CLI e o Session Manager plugin for the AWS CLI. Acesse os respectivos links caso não os tenha instalados.

O exemplo a seguir será feito utilizando o Windows 10 ou superior. Entretanto, o mesmo pode ser reproduzido em outro sistema operacional. Abra o Windows Powershell ou o Command Prompt e execute o comando abaixo:

aws ssm start-session --target instance-id

Onde:

• instance-id é o identificador da instância EC2 que se quer acessar. Para obter esse dado, acesse o painel de EC2 na console AWS (pelo browser) e veja o valor do campo “Instance ID” da instância EC2 desejada.

Se tudo estiver correto, você estará com um terminal Linux aberto no servidor remoto usando AWS CLI com o Session Manager. Todos os comandos que você digitar serão executados na instância EC2 remotamente. Perceba que a experiência de uso é praticamente a mesma da que se estivesse utilizando SSH, mas sem as desvantagens desse.

Note que as sessões do Session Manager abertas pela linha de comando também aparecem na lista de sessões ativas e no histórico de sessões no painel do Systems Manager, na console AWS (browser).

Para voltar para sua máquina local, digite exit e tecle ENTER ou então utilize o atalho Ctrl + D.

A opção apresentada possui uma série de vantagens em relação ao que havia sido mostrado nos posts anteriores:

• os servidores de aplicação não precisam ficar expostos na Internet.
• não é preciso ter Bastion Host. Isso diminui a superfície de ataque e diminui os custos da solução.
• o Session Manager é um serviço gerenciado da AWS, o que faz com que a responsabilidade de manutenção seja da AWS e não precisamos nos preocupar com isso.
• o controle de acesso é integrado com o IAM da AWS, não sendo necessário o uso e gerenciamento de pares de chaves.

Apesar de ser uma solução menos complexa, mais segura, com menor sobrecarga operacional e mais barata, ainda há pontos que podem ser melhorados. No próximo post será mostrado o que mais pode ser evoluído na solução.

Referências

• AWS Systems Manager Session Manager for Shell Access to EC2 Instances
• Connect to an Amazon EC2 instance by using Session Manager
• LAB 1: ELIMINATE BASTION HOSTS WITH SYSTEMS MANAGER
• AWS MANAGEMENT AND GOVERNANCE TOOLS WORKSHOP - SESSION MANAGER
• AWS Systems Manager Session Manager
• Start a session