AWS, na prática!

Sejam bem vindos ao treinamento AWS na Prática!

Nesta aula, conheceremos todos os módulos e objetivos de cada um deles. Apresentaremos também, como foi pensado o desenvolvimento deste treinamento para melhor absorversmos todos os conteúdos que serão apresentados ao decorrer de nosso treinamento.

Nesta aula, conheceremos quais são os pré-requisitos técnicos necessários para conseguirmos realizar este treinamento, extraindo ao máximo os conteúdos aqui apresentados.

Leia com atenção todos eles :)

Durante a gravação de nosso treinamento, chegando ao final do mesmo, a AWS divulgou seu novo layout Web (Console) em fase experimental de alguns serviços. Com isso, resolvi apresentar essas Notas de Gravações explorando todos esses itens que foram alterados.

Mas não se preocupem, essas mudanças não afetarão vocês em nada durante nosso treinamento ;)

Nesta primeira aula prática, iremos aprender passo-a-passo sobre a criação de uma nova conta AWS, detalhando todas as etapas até a conclusão, em especial, conhecendo um pouco a respeito do Free Tier, o nível de gratuidade que a AWS oferece para utilização.

Nesta aula, iremos fazer um pequeno overview sobre a console AWS que iremos trabalhar durante todo nosso treinamento. Principalmente para quem está tendo o primeiro contato com a AWS, é importante assistir à aula até o final para conseguir fazer o curso sem grandes dificuldades.

Boa aula a todos!

Um dos recursos mais importantes para mitigarmos problema referente a acessos não autorizados a uma conta AWS (utilizando a console Web) é a configuração do Multiple Factor Authenticator (Multíplo Fator de Autenticação - MFA). Nesta aula, exemplificaremos todo o conceito deste recurso, assim como sua implementação, em especial, na conta raíz (root), mas abordando toda a importância de sua aplicabilidade nas demais contas/usuários.

Nesta aula, veremos o processo de configuração de nossas respostas de segurança para recuperação de senhas do usuário root, e também sobre a importância da configuração de contatos de segurança em cada conta AWS.

Tudo que é realizado via console web AWS, basicamente são chamadas de API (Rest API) que por sua vez podem ser executadas através da linha de comando (AWS CLI). Nesta aula, conheceremos e instalaremos este recurso fantástico que já vem disponível por padrão, para que possamos explorá-lo ao decorrer de todo o nosso treinamento.

Uma das premissas da AWS, é não utilizar o usuário root para tarefas administrativas do dia-a-dia. Assim sendo, recomendamos sempre a criação de um usuário para podermos trabalhar. Nesta aula, veremos o processo, passo a passo de como criar o nosso primeiro usuário do IAM.

Lembre-se, mais adiante, teremos um módulo exclusivo sobre IAM :)

Continuando o assunto da aula passada sobre AWS CLI, nesta aula, abordaremos todo o processo de configuração do AWS CLI, incluindo a geração do Access_Key e Secret_Key, que são as credenciais de acesso destinadas a serem utilizadas através do AWS CLI.

Nesta aula, vamos conhecer um pouco da Infraestrutura Global da AWS, trazendo os principais conceitos que serão necessários entendimentos para avançarmos com o treinamento.

Atente-se aos detalhes e leia a documentação em anexo.

Abraços, e boa aula.

Muitas pessoas, ao iniciarem sua trajetória com a Cloud AWS, possuem muitas dúvidas a respeito da segurança do ambiente. Afinal, de quem é a responsabilidade sobre prover a segurança do ambiente? A reposta correta é: depende!

Nesta aula entenderemos todos estes detalhes e conheceremos o conceito conhecido como Responsabilidade Compartilhada.

O serviço Amazon EC2, é um dos serviços computacionais mais utilizados que a AWS disponibiliza. Este, geralmente, é um dos primeiros serviços a serem utilizados, onde conseguimos através do mesmo subir máquinas virtuais, criar ambiente de alta disponibilidade, escaláveis, entre outros.

Nesta aula, iremos fazer uma breve introdução a respeito deste serviço, exemplificando alguns de suas principais features que iremos explorar durante este módulo.

Dentro do serviço do Amazon EC2, temos a possibilidade de criar diversas Máquinas Virtuais que são conhecidas como instâncias EC2. Para trabalharmos com essas instâncias, existem uma infinidade de tipos que podemos utilizar, desde tipos focados em momória RAM, CPU, GPU, entre outros.

Nesta aula, iremos passear um pouco sobre as principais categorias de instâncias EC2 disponíveis dentro da AWS, entendendo assim cada modalidade, no qual serão de extrema importância para trabalharmos durante todo o treinamento.

A AWS disponibiliza basicamente duas modalidades de contrato para trabalharmos com instância EC2, sendo uma denominada Sob demanda (padrão), onde basicamente pagamos de acordo com o que utilizamos, e outra conhecida como Instâncias Reservadas, onde fazemos um contrato com a AWS (1 ou 3 anos) reservando uma determinada categoria de instância.

Nesta aula, exploraremos todos os detalhes dessas duas modalidades, abordando pós e contras sobre cada uma delas.

Na aula passada, conhecemos os quatro tipos de modelos de aquisições de instâncias do Amazon EC2. Nesta aula, iremos “simular” (sim, simular, afinal, não quero fazer nenhum contrato com AWS agora, srsr) o processo de contratação de um determinado modelo.

Muito cuidado para não concluir o processo. Sério, cuidado.

Agora que já conhecemos o que são instâncias do Amazon EC2, quais são seus tipos e quais as modalidades de aquisição podemos utilizar, chegou a hora de criarmos nossa primeira instância. Então, nesta aula, veremos todas as etapas para este processo, sem entrar em todos os detalhes, afinal, eles serão apresentados ao decorrer do módulo.

Importante: Esta foi uma aula de atualização criada alguns meses atrás. Entretanto, como a console e o processo não sofreram atualizações, não precisei regravar como as demais.

Boa aula a todos!

Toda instância EC2, possui um ciclo de vida, desde o processo de criação até o processo de término. É importante que conheçamos essas opções e que também, saibamos a configurar mecanismos de segurança contra alguns deles (acidentais).

Nesta aula, veremos tudo isso de forma teórica e prática.

Nesta aula, veremos os detalhes referentes as chaves de SSH utilizadas dentro da AWS para conexão em instâncias EC2 Linux. Para instâncias Microsoft Windows, essas são utilizadas para resgatar a senha do usuário administrador, e conceder então acesso a console Microsoft.

Veremos então um pouco de teoria e claro, o processo prático de criação das chaves através da console do Amazon EC2.

Na aula passada, estudamos um pouco sobre as chaves de SSH disponíveis dentro do Amazon EC2. Vimos um pouco de teoria e prática. Nesta aula, veremos as etapas para conexão em uma instância EC2 Linux e Windows utilizando essas chaves.

Então, caso nunca tenha realizado esse processo, fique de olho :)

A AWS nos permite realizarmos a criação de "clones" de nossas instâncias EC2 para serem utilizadas posteriormente como templates para determinadas tarefas/serviços, como Auto Scaling, que veremos mais adiante.

Nesta aula, conheceremos um pouco a respeito do serviço conhecido como Amazon Machine Image (AMI), entendendo um pouco sobre os principais conceitos e usabilidade so mesmo.

Nesta aula, abordaremos todo o processo passo a passo para criação de uma AMI, baseando-se em uma instância EC2 previamente criada. Então, se você possui disponibilidade, venha comigo nesta aula para aprendermos todos os detalhes.

AMI são recursos regionais e pertencentes a um único dono (owner account). Entretanto, pode-se haver necessidades de compartilharmos nossa AMI com outras regiões ou até mesmo outras contas AWS. Felizmente a AWS nos permite realizar tal ação. Entretanto, temos de seguir uma série de particularidades, nas quais iremos abranger nesta aula.

Importante: Evite AMI públicas, exceto caso seja necessário (última instância).

Praticamente todos os recursos da AWS são tarifados, se utilizarmos, é claro. As AMI funcionam da mesma forma. Uma AMI, basicamente é um "snapshot" no qual é armazenado em um Bucket S3 gerenciado pela própria AWS. Desta forma, ela também é tarifada. O que veremos nesta aula, é o processo de remover esta AMI caso não seja mais necessária. Este processo dentro da AWS é conhecido como desregistrar uma AMI.

Lembre-se, a remoção de itens não mais utilizados, é de extrema importância para que não sejamos tarifados de forma desnecessária ;)

Nas aulas anteriores, estudamos bastante sobre Amazon Machine Image (AMI). Vimos como elas funcionam, como criá-las, etc. Entretanto, todo o processo aprendido anteriormente foram realizados manualmente, o que no dia-a-dia não é interessante. Pensando nisso, a AWS lançou o AWS Image Builder, um serviço que permite gerenciar nossas AMI de forma automática através de pipelines. Além do processo de geração (criação), podemos configurar também o processo de deploy delas em produção, e até mesmo em grupos do serviço Auto Scaling/Loab Balancer (calma, veremos isso ainda).

Dito tudo isso, os objetivos desta aula é trazer um pouco dos principais conceitos sobre este tema, para podermos, a partir da próxima aula, criarmos alguns laboratórios sobre.

Agora que já sabemos o que é e para que serve o AWS Image Builder, vamos criar nosso primeiro pipeline. Lembrando que isso é apenas um modelo, um exemplo. No ambiente de vocês, provavelmente quase tudo irá mudar. Então analise, interprete e ajuste antes de colocar em seu ambiente.

Importante: Leia sempre para não ser enganado :)

Continuando a aula anterior...

Importante: Leia sempre para não ser enganado.

Um dos recursos mais fantásticos para gerenciamento, controle e automação dentro da AWS são as TAGs. Elas nos permite desde realizar um simples gerenciamento de nossos recurso, como também manter um control de nossos custos (Billing), assim como processo utilizados para automação, nos quais veremos mais adiante.

Nesta aula, começaremos a entender um pouco mais sobre as TAGs, analisando-as como elas funcionam e como podem de fato serem utilizadas.

Na aula passada aprendemos o que são as TAG no serviço do Amazon EC2 (e claro, dentro da AWS). Nesta aula, veremos alguns exemplos de como trabalhar com elas de forma prática.

Em anexo, deixei a documentação e também um guia de boas práticas. Se não for atrapalhar, gostaria desse uma olhada. Certamente irá ajudar :)

Em uma instância do Amazon EC2, podemos trabalhar com vários tipos de armazenamentos, sendo volumes EBS, compartilhamentos via EFS, FSx, entre outros. O objetivo desta aula é explanar um pouco sobre os armazenamentos permitidos do Amazon EC2, para que depois possamos entrar em detalhes sobre alguns deles, especialmente, volumes EBS.

Bons estudos!

Na aula passada, vimos que os volumes EBS (discos) são uma das possibilidades de armazenamento utilizados em instâncias do Amazon EC2. Nesta aula, iremos entrar um pouco mais afundo sobre esta modalidade, tendo em vista que são os mais utilizados atualmente.

Na aula passada conhecemos um pouco sobre volumes EBS. Entretanto, quando vamos trabalhar com esses volumes, temos de ter em mente qual o melhor tipo/categoria destinada para a nossa aplicação/serviço.

Nesta aula, iremos explorar e conhecer um pouco mais sobre as categorias de volumes EBS disponíveis para utilização, para que possamos saber a definir a melhor categoria que se enquadrará em nosso cenário, visando custo/benefício e o desempenho de seu ambiente.

Nesta aula, veremos na prática todas as etapdas necessárias para criarmos nosso volume EBS, e posteriormente, associarmos a uma determinada instância.

Na aula passada, realizamos a criação de um volume EBS novo para uma instância EC2. Nesta aula, iremos explorar o processo de associação (attach) do mesmo em uma instância EC2 Linux.

Lembrando que o objetivo é apresentarmos sobre o processo de associação dos volumes em uma instância, e não o seu gerenciamento interno no Sistema Operacional.

Assim como em ambiente On-primeses utilizando hypervisors como Vmware, Xen, Proxmox, entre outros, dentro da AWS temos também a possibilidade de criarmos snapshots de um determinado disco e/ou instância. O principal objetivo do mesmo, é mitigar problemas oriundos de configurações erradas, recuperação de disastre recovery, e até mesmo backup de seu ambiente.

Nesta aula, iremos realizar uma introdução sobre Snapshots, analisando todos os detalhes, para que possamos então, na próxima aula, vermos na prática como tudo isso funciona.

Na aula passada, conhecemos a teoria sobre o funcionamento dos Snapshots aqui dentro da AWS. Nesta aula, veremos na prática, todo o processo aprendido na aula anterior, realizando a criação de nosso primeiro Snapshot.

Durantes as aulas passadas, vimos um pouco sobre Amazon Snapshots de instâncias EC2. Vimos também que, temos a possibilidade de refinarmos suas permissões. Nesta aula, veremos um pouco sobre este processo, incluindo o compartilhamento entre contas AWS, o que em alguns casos (alguns) pode fazer total sentido.

Lembre-se, teste tudo em ambientes seguros e sem dados sensíveis em seus snapshots (por segurança).

Além do compartilhamento de snapshots entre contas AWS como vimos na aula passada, nesta iremos aprender a copiar snapshots entre regiões, o que pode ser completamente necessário dependendo do seu ambiente.

Então, mão na massa!

Antigamente na AWS, para criarmos rotinas de snapshots, tinhamos que trabalhar com API e/ou SDK desenvolvidos e automatizados através de agendadores como crontab (linux). Felizmente, de uns anos pra cá, a AWS desenvolveu o Lifecycle Snapshot, que é basicamente um agendador de rotinas para geração de Snapshot de forma automatizada, facilitando muito o dia-a-dia de um Sysadmin/SysOps.

No Lifecycle, podemos criar diferentes políticas de backups baseando-se em cada cenário/ambiente. Nesta aula, iremos explorar um pouco mais a respeito deste recurso e ver na prática como é o seu funcionamento.

Um recurso relativamente novo que temos dentro do Amazon EC2, são as lixeiras dos Snapshots de volumes EBS. Como é uma premissa, essa lixeira tem o objetivo de armazenar os Snapshots deletados (acidentalmente ou não) por um determinado período, pré-determinado.

Se não conhecia, veja agora em detalhes, ela pode de fato salvar seu emprego :)

Por padrão, quando criamos uma instância na AWS do tipo pública (com acessos expostos para Internet), ela vem associada com um endereço IP válido, porém dinâmico, ou seja, toda vez que desligarmos e/ou reiniciarmos nossa instância, existe uma enorme possibilidade deste endereço IP ser alterado, assim como geralmente possuimos em nossas casas.

Para cenários onde há real necessidades de mantermos os mesmos endereços IP públicos em uma instância (IP estático), devemos utilizar um recurso que chamamos de Elastic IP. Este recurso nos permite registrarmos um IP válido e fixo em uma instância. Entretanto, existem alguns aspectos de extrema importância que devemos nos atentar. Então, convido vocês a assistirem esta aula para entenderem todos os detalhes deste recurso.

Como vimos no início de nosso treinamento, a segurança de nossas instâncias EC2 (Sistemas Operacional, serviços, etc) é de nossa total responsabilidade. Baseando-se nisso, um dos recursos mais utilizados e de extrema importância são os Security Groups (SG). Os SG são Firewalls do tipo Statefull que nos permite controlar o tráfego de entrada/saída em uma ou mais intâncias EC2.

Nessa aula, faremos uma introdução aos principais conceitos deste recurso de extrema importância para qualquer ambiente AWS.

Um dos recursos mais facinantes e mais utilizados dentro da AWS é o Elastic Load Balance, conhecido comumente apenas como ELB. O ELB, atua basicamente como um frontend, fazendo o papel de um Proxy Reverso (assim como temos com nginx, apache) para suas aplicações, sejam através de protocolos HTTP/HTTPS, ou TPC/UDP, aplicando assim, o balanceamento do tráfego de entrada (INBOUND) para todos os seus Targets (destinos). Além disso, ele permite também ocultar o endereço IP de suas aplicações, criando uma camada a mais de segurança para o seu ambiente.

O ELB é dividido basicamente em três tipos (desconsiderando o CLB):

• Application Load Balances (ALB)

• Network Load Balancer (NLB)

• Gateway Load Balancer (GLW)

• Classic Load Balance (CLB) - Legado e não recomendado para utilização

  
  

Nesta aula, entenderemos cada um dessas modalidades, como que cada um funciona e quais os principais casos de uso de cada um deles. Então se você quer aprender um pouco mais sobre ELB, junte-se a esta aula ;)

Como visualizamos na aula passada, o ELB possui três modalidades diferentes (recomendadas), cada uma delas destinada a um determinado nicho de aplicações/serviços/ambiente.

Nesta aula iremos conhecer em detalhes cada um desses tipos, para podermos posteriormente, aplicarmos tudo, na prática.

Após aprendermos os principais conceitos sobre Elastic Load Balancer, podemos iniciar nossos laboratórios para visualizarmos na prática a teoria aprendida.

Nesta aula, iremos preparar nosso cenário que utilizaremos durante as próximas aulas, para a criação de um Application Load Balancer (ALB). Com este cenário, aprenderemos também sobre “EC2 User Data”, que permite customizar nossas instâncias durante sua criação, de forma automática.

É importante ressaltar que, isso é um laboratório, e que em seu ambiente, as configurações podem e devem ser alteradas. Fique atento a isto.

No mais, boa aula!

Para que um Elastic Load Balancer (ELB) funcione, independente de sua categoria, temos que criar um Target Group, que como já vimos, é um conjunto de instâncias, containers e/ou endereços IP que receberão requisições do ELB em questão.

Nesta aula, iremos criar nosso Target Group com nossas instâncias EC2 criada na aula passada. Este Target Group, será vinculado ao nosso ALB posteriormente.

Após a criação dos pré-requisitos, podemos partir para criação do nosso Application Load Balancer. Então, sem mais enrolações, vamos à prática.

Nesta aula, veremos alguns atributos disponíveis nas configurações de um Application Load Balancer. Esses atributos, são utilizados para customização do comportamento de um ALB. Desta forma, não iremos modificar as configurações, apenas conheceremos sobre cada uma dela, para que vocês possam customizar conforme suas necessidades.

Além dos atributos, também veremos uma feature conhecida como “Resource Map”, muito interessante para análises do ambiente, principalmente em casos de erros.

Para quem esta acostumado a trabalhar com proxy reverso, seja com Apache ou com Nginx, sabe-se que é possível realizar o roteamento das requisições baseados em:

• origem/destino

• server_name,  Nameserver

• cabeçalho HTTP

• Path

• Entre outros

Dentro do ELB, mais precisamente utilizando o Application Load Balancer, é possível aplicar todo esse roteamento da mesma forma, o que pode ser de extrema utilidade em seu dia-a-dia. Nesta aula, veremos na prática todos os detalhes sobre Roteamento Avançado com ALB.

Quando trabalhamos em um cluster, é comum as solicitações serem distribuídas igualmente entre os nós desse Cluster. Entretanto, em determinados momentos, de acordo com cada aplicação/serviço, pode ser que haja a necessidade de mantermos a requisição de um determinado cliente em um único nó.

Este recurso dentro do ELB, falando precisamente de ALB, é conhecido como Stick Session. Nesta aula, iremos entender como é o funcionamento deste recurso, e como ele pode impactar em seu ambiente.

Quando estamos trabalhando com Application Load Balancer, podemos configurar um certificado TLS para conexão segura com o site, utilizando protocolo HTTPS. Nesta aula, veremos como fazer esta configuração utilizando o serviço nativo e gratuito da AWS conhecido como ACM (AWS Certificate Manager).

Lembrando que, para esta configuração, você deve ter acesso a um domínio público para configuração de registros de DNS ou acesso ao e-mail configurado no domínio (método de validação). É importante ressaltar também que, as informações de criação dos registros de DNS, assim como sua teoria, não serão apresentados nesta aula, e sim no módulo sobre Route 53.

Nesta aula, montaremos um Network Load Balancer (privado), balanceando as conexões para dois servidores rodando MySQL. O objetivo aqui é apresentar o comportamento e quais as principais diferenças entre um ALB e NLB.

É importante ressaltar que, não serão apresentadas as configurações do MySQL, pois esta fora do escopo do treinamento. Além disso, você pode utilizar também, qualquer outro serviço. A escolha do MySQL foi baseada apenas na simplicidade e também em cenários do dia-a-dia.

Em tempos atuais, cada vez mais temos que nos preocupar com o escalonamento de nosso ambiente. Datas como Black Friday, Natal, entre outras, exigem, geralmente um acréscimo considerável de recursos computacionais no ambiente. Se tratando de um ambiente On-primese, costuma-se realizar esse processo dias antes e totalmente de forma manual (quem atua como Sysadmin sabe muito bem como é isso, rsr).

Felizmente, na AWS não precisamos mais virarmos noites configurando novos recursos em nosso ambiente. Tudo isso é graças ao processo automatizado de Auto Scaling.

Nesta aula, começaremos a entender como o mesmo funciona, e quais os benefícios do mesmo.

Para trabalharmos com Auto Scaling na AWS, temos de criar um template (pré requesito) determinando como será o comportamento e o que está instalado/configurado em nossas instâncias que pertencerão ao grupo de Auto Scaling. Este recurso, é conhecido como Launch Template.

Nesta aula, veremos como criar e configurar um Launch Template. Lembrando que, verem os um modelo. Você deve ajustar conforme suas necessidades.

Após a criação do Launch Template, temos que realizar a configuração de nosso Auto Scaling Group, que de fato é o que dá vida ao nosso processo de Auto Scaling.

Basicamente, este grupo será destinado por informar quantas instâncias, por exemplo, estarão rodando por default, qual o máximo que pode ser criada, entre outros.

Sem mais enrolações, bora para prática.

Umas das grandes vantagens de trabalhar com Auto Scaling, é os processos automatizados de Scaling Up e Scaling Down. Isso, sim, proporciona tranquilidades para o dia-a-dia de um SysOps.

Nesta aula, veremos a configuração de um Automatic Scaling, baseando-se em métricas do Cloudwatch através de políticas (calma, que ainda teremos um módulo sobre). Todo o processo será realizado gerando cargas excessivas (utilizando o binário stress do Linux) em um servidor, e analisando o comportamento do Auto Scaling Group, no qual irá criar novas instâncias conforme necessidades.

Uma das possibilidades de se trabalhar com Auto Scaling Group, é a integração com balanceadores de carga, como Application Load Balancer. O processo, basicamente, se resume em integrar as instâncias do grupo de Auto Scaling em um Target Group de um ELB.

Nesta aula, faremos a criação de um novo grupo de Auto Scaling, integrado com um Application Load Balancer. Após a integração, testaremos e analisaremos os destalhes do processo.

Fechando a sessão sobre Auto Scaling, vamos conhecer agora uma feature chamada de Instance Refresh. Esse recurso pode ser útil quando uma alteração na configuração exige que você substitua instâncias, especialmente se seu grupo de Auto Scaling contiver inúmeras instâncias.

Nesta aula, analisaremos na prática como funciona este recurso, e como podemos trabalhar com ele em cenários reais.

Dentro do Amazon EC2, recentemente, a AWS adicionou um novo recurso conhecido como Console to Code. O objetivo, é facilitar a criação de scripts para automatizar ações. Basicamente, tudo feito na console AWS é registrado em eventos (chamadas de API). A AWS criou este serviço para coletar essas informações e transcrever em chamadas de API utilizando o AWS CLI.

Além das linhas do AWS CLI apresentadas, é possível convertê-las em scripts, como Python e Java.

É importante ressaltar que, no ato da gravação desta aula, o recurso ainda se encontrava como preview. Dependendo de quanto estiver assistindo, pode ser que tenha mudado alguma coisa, principalmente layout (AWS adora fazer isso). Caso ocorra, não se desespere, leia tudo com calma que certamente conseguirá evoluir. E claro, se precisar de ajuda, conte comigo. Ah, e obviamente, as atualizações irão surgindo conforme necessidades.

AWS CloudShell é um shell pré-autenticado baseado em navegador que você pode iniciar diretamente da console AWS. Através dele, podemos enviar/receber arquivos, instalar pacotes, entre outros. Ele foi desenvolvido visando facilitar o processo de execução de pequenas automações e testes, sem a necessidade de utilizarmos uma instância EC2 ou qualquer outro recurso para isso. Vale muito a pena conferir.

PS: os amantes de Linux irão amar. Os amantes de Ruwindow$ irão perguntar: cadê o mouse, srsr

Um dos campeões: instâncias EC2 públicas.

Muitos lugares, ainda utilizam instâncias EC2 públicas dentro de seus ambientes, e, na maioria das vezes, não sabem outras formas de resolverem isso, principalmente no que tange os acessos remotos as mesmas.

Se você utilizar uma instância pública para armazenar seu site, devido a uma restrição financeira, OK, vida que segue. Entretanto, se você ainda utiliza a instância pública para realizar acesso remoto a ela, me desculpe, mas você esta colocando em risco o seu ambiente.

Nesta aula, nos veremos alguns pontos sobre a utilização de instâncias públicas dentro da AWS, e quais soluções podemos adotar para minimizar esses impactos.

Baseando-se na aula anterior, sobre acessos privados a instâncias EC2, vamos conhecer um pouco mais a fundo sobre as possibilidades de temos para realizarmos acesso de forma segura em nossas instâncias EC2. E para começar, vamos falar sobre o AWS Session Manager.

Nesta aula, veremos os principais conceitos sobre o serviço, para que nas próximas, apliquemos as configurações no ambiente.

No mais, bons estudos.

Agora que já temos conhecimentos sobre os principais conceitos do AWS Session Manager, vamos agora iniciar nossas configurações, que serão divididas em duas aula, visando um melhor aprendizado.

Continuando o setup do AWS Session Manager :)

Nesta aula, começaremos a conversar um pouco sobre os Metadados de Instâncias EC2. Entenderemos o que de fato é este recurso, como ele pode nos auxiliar no dia-a-dia, e também, como ele pode nos prejudicar, caso o mesmo seja negligenciado.

Em posse dos conhecimentos sobre Metadados de Instâncias EC2 apresentado na aula anterior, vamos agora entender uma das problemáticas existentes por trás disso.

Continuando a aula passada, vamos finalizar os testes sobre a problemática apresentada.

Agora que já vimos a problemática, como podemos mitigar, minimizar os riscos? Nesta aula veremos todos esses detalhes, de forma totalmente prática. Então abra a console AWS e me acompanhe :)

Nesta aula, trago algumas configurações globais do Amazon EC2 que certamente ajudará no dia-a-dia. A ideia dessas configurações é aplicar “políticas” que sobressaiam sobre algumas configurações, como criptografia de volumes EBS, AZs, experimentações de novas features, entre outros.

Lembre-se, é importante validar o que deseja aplicar no ambiente, e que essas configurações irão prevalecer sobre as demais.

Agora, sim, chegamos ao final de nosso módulo de EC2. Nesta aula, faremos uma revisão de alguns pontos apresentados durante o módulo.

Além disso, gostaria de reforçar que vocês devem limpar a bagunça criada até o momento, ou seja, remover tudo que foi criado durante as aulas passadas. Esta é uma etapa bem importante, e super recomendada, para que você não sejam tarifados indevidamente pela AWS.

Então corre, abre a console AWS, acesse o serviço EC2, e remova TODOS os recursos, a não ser, claro, que vocês continuem os estudos por conta própria. :)

Abraços, e até o próximo módulo.

Sejam bem vindos ao módulo do Amazon VPC!

Amazon VPC é o serviço responsável por prover toda a parte de conectividade (redes) dentro da AWS, para todo e qualquer serviço.  É na VPC onde atuamos com todo o escopo de rede (máscaras, bloco CIDR), VPNs, tabelas de roteamento, conectividade com a Internet, entre outros.

Nesta aula, iremos realizar uma introdução a respeito de VPC, no qual iremos trabalhar durante o restante de nosso módulo.

Ah, prestem atenção nos pré-requisitos, são fundamentais e indispensáveis.

Boa aula a todos.

Como visualizamos na aula passada, a AWS cria uma VPC padrão para todas as contas em todas as regiões. A ideia é facilitar a utilização de recursos que dependem de uma conectividade. Entretanto, existem algumas problemáticas, como a sobreposição de blocos CIDR.

Nesta aula, além de conhecer sobre esta VPC, vamos também, fazer um giro sobre a console do Amazon VPC.

PS: Não usem a VPC padrão em ambientes corporativos. Na verdade, minha recomendação é para não usar em nenhum lugar, rsrs.

Agora que já temos o embasamento sobre VPC, sabemos como funcionam e quais os pré-requisitos para sua utilização, podemos finalmente criar a nossa VPC que utilizaremos durante o módulo, afinal, como já foi informado, não é recomendado trabalharmos com a VPC padrão da AWS.

Lembrando que nesta aula, iremos criar a VPN manualmente, para posteriormente, iremos trabalhando na criação dos recursos isolados, para um melhor aproveitamento.

Boa aula a todos.

Comumente, pode haver a necessidade de criarmos novas subnets para separarmos por exemplo, zonas privadas de públicas.

Nesta aula, veremos em detalhes quais os passos necessários para realizarmos tais ações, e como podemos segmentar o ambiente de rede de nosso ambiente.

Dentro da AWS, existem basicamente duas formas de compartilharmos o acesso à Internet com uma instância EC2:

• Internet Gateway (IGW)

• NAT Gateway (NGW)

O IGW, permite que uma instância fique pública, “exposta” à Internet. Já o NGW, compartilha apenas acesso de saída (OUTBOUND) de uma instância com a Internet (ou até mesmo outra rede local), fazendo o que conhecemos de NAT (exatamente igual à forma que computadores/desktops utilizam a internet em uma empresa).

Nesta aula, iremos entender como cadas um desses recursos funcionam, e como podemos utilizá-los de acordo com nosso ambiente.

Lembrando que, existem outros Gateways que podem contribuir para este cenário, entretanto, por se tratarem de assuntos mais complexos, não iremos estudá-los em nosso treinamento (quem sabe no futuro).

Bom, agora que já temos o embasamento teórico sobre Internet e NAT Gateway, vamos nesta aula aprender a criar uma subnet pública, utilizada quando precisamos expor algum serviço diretamente para Internet, como servidores web, e afins.

Seguindo a mesma premissa da aula anterior, nesta iremos aprender a criar uma subnet privada, destinada a recursos computacionais que não precisam estar expostos para Internet, como servidores de banco de dados.

Ah, lembre-se que, para acessar recursos privados, podemos utilizar o AWS Session Manager, como vimos no módulo anterior :)

Após criarmos nossas subnets públicas e privadas, chegou a hora de testarmos, e validarmos se de fato estão funcionando corretamente, conforme desejado.

Em uma VPC/Subnet, temos uma configuração que permite adicionar ou não, endereços de DNS vinculados aos recursos (como EC2). Esses nomes de DNS podem ser públicos ou privados, a depender da configuração de sua subnet.

Além disso, temos também a possibilidade de configurarmos de forma automática a associação de endereços IP públicos para recursos, muito utilizado para subnets públicas.

Nesta aula, veremos esses dois itens, e como são recomendados para ambientes coorporativos.

Em diferentes casos, precisamos criar várias regras de security groups com destino/origem a mesma porta, ou então várias rotas em uma tabela de roteamento apontando para o mesmo gateway. Em um passado bem distante, precisávamos criar uma regra, ou uma rota para cada item. Entretanto, na prática, isso ficava insustentável de gerenciar.

Pensando nisso, a AWS criou um serviço conhecido como Prefix Lists. Este permite criar grupos gerenciáveis de endereços de rede e/ou endereços IP (conotação CIDR) para serem utilizados em outros lugares, como os citados acima.

Nesta aula, veremos como o mesmo funciona e como ele pode ser útil em nossos dias.

Assim como em um ambiente On-primises, na AWS podemos determinar as informações que serão entregues via serviço DHCP para os clientes de uma VPC. Por padrão, a AWS, com a Default VPC, cria uma estrutura de DHCP, entregando servidores de DNS, Netbios, sufixo DNS, entre outras informações para seus clientes.

Entretanto, caso haja necessidade de customizar tais informações, basta realizar a criação de um “escopo de DHCP”. Todos os detalhes para isso serão apresentados nesta aula.

Nesta aula, conheceremos um recurso de extrema importância para segurança de um ambiente AWS, o VPC Endpoint. Resumidamente, este recurso permite acessar os demais recursos da AWS (compatíveis) através de um link privado, sem conexão com a rede pública (Internet), trazendo maior segurança para o ambiente.

O objetivo aqui é explicar o funcionamento deste, para que vocês possam aplicar na prática, os conceitos aqui apresentados.

Recentemente, a AWS lançou um VPC Endpoint para instâncias do Amazon EC2. Este, é mais um recurso disponível, para acessarmos nossas instâncias privadamente, sem a necessidade de expô-las para Internet. Nesta aula, veremos as principais funcionalidades, e claro, o procedimento para configuração.

PS: Agora quero ver desculpas para usar instâncias de forma pública ao invés de privadas, hehehhehe :)

Em ambientes corporativos, é comum termos mais de uma Conta AWS e/ou mais de uma VPC. Apesar de não terem sido feitos para isso, em alguns momentos, precisamos prover a comunicação entre essas VPC/Contas.

Existe uma alguns recursos disponíveis para realizarmos tal ação. Entretanto, o mais conhecido e recomendado é o VPC Peering, no qual realiza uma interconexão entre duas VPCs distintas, estando ou não na mesma conta AWS.

Nesta aula, iremos entender os conceitos teóricos, para na próxima aulir, possamos colocar em prática :)

Depois da teoria, vem a prática.

Divirtam-se :)

Uma aula simples e objetiva para aprendermos a remover uma conexão de VPC Peering.

Na AWS, temos basicamente dois Firewalls Layer 3 e 4 (Camadas de rede e transporte do modelo de referência Ozzy... ops, OSI, srs): os Security Group que atua como Firewall Statefull e vimos no módulo passado, e o Network ACL, que atua como Firewall Stateless, que iremos analisar a partir de agora.

Nesta aula, iremos conhecer suas principais diferenças e entender, como as ACLs funcionam dentro da AWS, e como podemos utilizá-las para agregar segurança em nosso ambiente.

Certamente, você já deve ter recebido uma solicitação para bloquear determinados domínios de DNS de serem acessados em seu ambiente. Na AWS, podemos utilizar o DNS Firewall para realizar esta ação.

O DNS Firewall utiliza o Route 53 Resolver e permite que você crie “listas de bloqueios” para domínios com os quais não deseja que seus recursos de VPC se comuniquem via DNS. Você também pode adotar uma abordagem de isolamento mais rigorosa, criando “listas de permissão” que permitem consultas DNS de saída apenas para domínios especificados.

Nesta aula, veremos todos os detalhes sobre esse serviço, e como ele pode agregar segurança para seu ambiente.

Inevitavelmente, temos de conectar nossa VPC com ambientes externos, seja ele um ambiente on-premises, outro provedor de nuvem, ou até mesmo outra conta/VPC AWS. Pensando nisso, criei esta aula para ilustrar as principais possibilidades que temos para realizar essas comunicações.

Lembrando que, o objetivo aqui, é apenas trazer para vocês o famoso caminho das pedras, para que, através das documentações disponíveis, vocês possam evoluir de acordo com suas necessidades.

No mais, boa aula a todos!

Inevitavelmente, quem trabalha como Sysops, ou o bom e velho Sysadmin, já precisou prover a comunicação entre dois ou mais ambientes, seja eles qual for. Na AWS, isso também pode ocorrer (e vai, cedo ou tarde). Para isso, um dos caminhos mais recomendados, é através de um túnel de VPN do tipo IPSec, implementando uma comunicação Site-to-Site.

Nesta aula, faremos uma simulação de implementação de uma VPN IPSec, onde aprenderemos a realizar todas as etapas do lado da AWS. Infelizmente, por razões meio óbvias, não iremos implementar na outra ponta, pois, além de fugir do escopo do treinamento, não temos apenas um cenário. Pode ser desde um provedor de nuvem e/ou um ambiente on-premises, com um Mikrotik (só lamento, srsrsr).

No mais, boa aula a todos e leiam a documentação em anexo :)