AWS Certification: Solutions Architect Associate Parte 2

AWS Snowball, Storage Gateway e CloudFront - Introdução

Pronto para começar a Parte 2 do Solutions Architect? Já reviu toda a Parte 1? Fez bem as práticas? Então, vamos continuar!

A ideia é que nós vejamos, de novo, ferramentas, logicamente, novas tecnologias, mas, nessa Parte 2 vamos dar um enfoque especial num tema bastante importante para a prova, que é baseado numa tecnologia, uma das principais da AWS, que é a parte do EC2, então, vai ter bastante laboratório, muito detalhamento desse serviço.

Outros, nós iremos dar um overview e nos principais, como temos feito até aqui, vamos fazer o aprofundamento.

Vamos começar falando de algumas outras ferramentas, só para darmos o start.

Snowball, o que é isso? Esse nome Snowball dentro da AWS? Imagina o seguinte cenário: você vai fazer um projeto e você precisa migrar grandes quantidades de dados para a AWS. "Ah, Ricardo. Eu posso criar um S3, fazer tudo o que já aprendemos?"

Pode fazer isso. Só que isso vai, logicamente, custar um tempo. Você imagina volumes consideráveis de dados.

Uma solução que, logicamente, é cobrada em provas e você tem que conhecer essa tecnologia, é o Snowball. O Snowball se resume numa maleta, ou seja, um superdisco físico, para você poder migrar, de uma forma mais simples, para a AWS.

Tem um link que é bem legal; na tela estão fotos das maletas e vou pegar o link nelas;

São super maletas low, ou seja, é um storage embarcado numa maleta. E tem esses dois tipos das fotos, mas, vamos para o link que tem um detalhamento melhor.

Vou botar o documento em português para facilitar: 'Diferenças entre os dispositivos Snowball'. No documento tem as fotos que eu tirei a referência, tem o Snowball e o Snowball Edge e tem as referências de cada um.

Para a prova, é importante entender que existem esses dois modelos e, logicamente, você dá uma passada nesse documento.

Tem o detalhamento.

No Snowball a capacidade de armazenamento é até 50 TB e 80 TB. E a super maleta, que é a cinza, ela já tem uma capacidade bem maior, 100 TB, ou seja, é um negócio realmente violento.

E a aplicação é isso: você tem um projeto, se tiver alguma pergunta, algum cenário onde seja questionado como levar uma grande quantidade de dados para a AWS, essa é a solução, por essa maleta que você vai contratar e vai fazer a migração dos dados.

Snowball, mais uma lida, ver esses pontos para entender as diferenças dessas duas maletas e vamos seguir.

Vamos avançar os slides e ver as Notas para fecharmos o tema do Snowball.

Olha que dados importantes e o pessoal fala assim: 'Ah, a prova da AWS tem as pegadinhas'.

As pegadinhas, na verdade, são perguntas relacionadas ao detalhe do serviço. Por isso, como eu tenho sempre falado aqui, tem que conhecer em detalhes cada serviço e eu estou sempre trazendo os pontos principais para você lembrar.

O que eu quero mostrar? A questão do Snowball você já sabe: para transferir quantidades grandes de dados.

Mas, olha o que diz: se você for transferir menos de 10 TB, talvez o Snowball não seja economicamente viável. Então, você já tem um parâmetro.

Lembrando que todo texto eu tiro, exclusivamente, da documentação da AWS. Por isso que está tudo em inglês, é cópia e peixe do Manual e dos pontos relevantes. Não tem nada que seja interpretação minha, é o conteúdo original da AWS, que é o que você vai encontrar na prova.

Então, menos de 10 TB não é uma escolha economicamente viável. Preste atenção nisso.

Outro ponto importante: o Snowball não faz o envio dessas maletas para fora dos Estados Unidos. Não faz isso.

Você tem que dar uma olhada na documentação sobre essas restrições, como você procede, como poderia proceder para fazer essas transferências.

Então, na documentação diz que fora dos Estados Unidos, nós não conseguimos fazer esse envio das maletas.

Fechou o Snowball? Faça uma revisão e no próximo vídeo continuamos com o novo tema.

AWS Snowball, Storage Gateway e CloudFront - Storage Gateway

Chegou a hora de falarmos do Storage Gateway. Esse serviço é bem interessante, eu já tive a oportunidade de colocar em produção.

É um recurso muito interessante que, basicamente, ele faz o quê? Você usa a estrutura do S3 como se fosse um disco adicional dentro da tua rede on-premises. "Como assim, Ricardo?"

Imagine que você queira expandir o seu Storage? Você pode usar, exatamente, esse recurso. Eu crio esse Storage lá na AWS e mapeio dentro do meu on-premises, dentro do meu cliente, eu mapeio essa extensão.

Ou seja, quando eu fizer a gravação nesse meu Storage, localmente, vai parecer que eu estou fazendo gravação num disco local. Mas, na verdade, ele está fazendo isso na Nuvem, usando todos aqueles recursos que já vimos quando estudamos o S3.

A ideia do Storage Gateway é, exatamente, essa. Ele se baseia em três modelos: o file-based, volume-based e o tape-based.

Vou caminhar com você por esses três pontos. Vamos lá!

Vamos pegar essas visões, vamos para o console para entendermos como é a mecânica desses storages.

Vamos olhar o primeiro, ele chama de File Gateway. Qual é a ideia? Isso é bem fácil de você entender.

O Customer Premises, você está on-premises, está no cliente, está localmente. O que acontece? Eu vou criar uma máquina virtual e, tem um detalhe interessante aí, eu vou criar dentro de uma máquina virtual, eu vou instalar a minha aplicação do Storage Gateway.

Então, localmente, eu estou apontando para esse Storage Gateway e ele que vai fazer a interface com o mundo da AWS.

O Storage Gateway tem duas visões, ou seja, ele tem duas formas de implementar. Você pode pegar; deixa eu abrir a documentação da AWS para você entender; dentro do link na parte de Storage, clique em Storage Gateway, olha que interessante. Na página que abrir, clique no botão azul "Get started", no meio da tela, e aparecem três maneiras, que são questões de prova.

File gateway, Volume gateway e Tape gateway. Tem que saber sobre eles.

Selecionando a opção File gateway, vamos avançar clicando no botão "Next". O que ele faz? Está lembrado do desenho no slide? Eu vou criar uma máquina on-premise e essa máquina suporta as plataformas que estão exibidas na tela. Tem que estar atento a isso.

O VMware ESXI, o Microsoft Hyper-V, tem o Appliance dedicado. Você pode comprar junto à Amazon, a questão da AWS e é um servidor baseado em Storage; é ao contrário, um Storage baseado num servidor; a máquina que você espeta e coloca no seu rack, é essa opção da Hardware Appliance.

Tem o Linux KVM também, podemos ter todas as imagens. E você pode perguntar assim: Ricardo, um EC2? Como assim um EC2?

O EC2 não está local, o EC2 está na AWS. Então, espera aí. Vamos olhar o desenho do slide.

A ideia não é ter uma máquina local? Sim! A ideia é ter uma máquina local, mas, se você não quiser provisionar localmente essa máquina, você tem o recurso de criar uma instância EC2, instalar o software lá, o Storage Gateway dentro dele, e mapear localmente essa máquina EC2.

Na visão do cliente, na visão do usuário, está tudo acontecendo localmente, mas, esse host do Storage Gateway não está on-premises, ele está rodando na Nuvem.

É uma opção, também. E sempre lembrando, você começa a usar aquela questão de serviço. Você não está preocupado em botar uma máquina, instalar um AVM, rodar o serviço...não. Você já fez isso. Até isso você já fez na nuvem.

Agora, isso vale, fique atento, para o File Gateway. Vamos bater as opções mostradas na tela, para não ficar nenhuma dúvida.

No File Gateway, resumindo, eu tenho todas as opções de VM listadas na tela (VMware ESXI, Microsoft Hyper-V, Linux KVM, Amazon EC2 e Hardware Appliance), inclusive um Hardware físico, onde eu instalo a minha imagem e uso ela como uma extensão.

Uma extensão do S3. O que eu estiver gravando nele, na verdade, estou usando o S3 como armazenamento. Esse é o conceito.

Só que vamos voltar um pouco na documentação; eu tenho outros tipos. Eu tenho o Volume Gateway. Para qual aplicação está destinado o Volume Gateway?

O Volume Gateway é; o mesmo conceito, eu vou ter uma máquina para fazer a interface com o S3, só que com a visão de backup. Ele vai montar essa estrutura como um Volume e ele usa; deixa eu pegar a documentação; no link do Volume Gateway explica que ele vai montar o seu volume como se fosse uma interface, isso é importante, iSCSI.

Quem está acostumado a montar unidades, montar volumes para fazer backups, o termo iSCSI já é mais comum. Mas, isso é uma característica que você tem que entender; ele monta o volume como se fosse um iSCSI.

Na verdade, você está mapeando dentro dessa tecnologia localmente e ele está jogando para a nuvem.

Temos o Gateway de volumes na tela, que em inglês ele vai chamar de Volume Gateway. Mas, ainda tem uns detalhes que eu queria chamar a sua atenção, vamos voltar para o console.

Estou na console, já vimos o File Gateway. Vamos ver o Volume gateway; ele tem dois subtítulos. Eu tenho a opção de 'Cached volumes' e tenho a opção de 'Stored volumes'. A opção de 'Cached', como o próprio nome diz, é para agilizar o meu processo. O que acontece se eu usar o Volume gateway na opção de 'Cached' e avançar clicando no botão 'Next'?

As máquinas virtuais, eu tenho o Appliance físico, a VMware ESXI, Linux KVM, Hiper-V e, também, continuo tendo o EC2. Esse Cached pode ser uma máquina virtual, uma instância EC2, rodando na AWS. Fique atento a isso.

Se eu usar um Storage Volume no Volume gateway, se essa for a minha proposta e eu avançar na tela, clicando no botão "Next", a opção do EC2 não existe mais.

Isso acaba virando uma pegada, uma questão; 'Ah, eu posso ter uma instância EC2 associada à um Volume gateway', se for na categoria de Storage, você não pode; agora, na categoria de Cached, você consegue ter isso.

E o final dele é a terceira opção, o Tape gateway. Vamos avançar clicando no botão "Next". Nele, já dá opção, também, de uma instância EC2.

A ideia do Tape gateway, para a galera mais antiga, para quem usava backup em fita, ele vai simular um ambiente virtual de fita para você fazer o armazenamento na nuvem.

Então, são esses 3 tipos de Storage gateway que temos. Não vamos fazer um laboratório desse Storage gateway pelo motivo que, na prova, esse detalhamento da implementação do laboratório não é cobrado.

Em outras provas vão te cobrar isso, como na de SISOP, que é o System Operator, é outra categoria de prova e já entram nesse detalhe. Mais na frente nós vemos esse recurso.

O importante é você entender que temos três tipos; vou deixar no slide para facilitar o teu estudo; estão no slides os desenhos: File gateway, o Volume gateway tem a versão de Cached e a versão de Storage, as duas, e tem o Tape gateway. Então, são os três tipos e alguns deles, o segundo, tem essas subcategorias.

Essa ideia do Storage é você aumentar a tua capacidade de armazenamento, aumentar a tua capacidade de backup usando o S3, através dessa interface do Storage gateway, certo?

Dá uma revisada, principalmente, na documentação, o link está na tela para ver esses tipos, essas características citadas nesta aula. Tem muitas coisas, por exemplo, como vimos a questão do iSCSI.

Esses termos citados, se aparecer alguma pergunta com eles, você já vai estar pronto para responder.

Próximo vídeo continuamos e vamos começar uma parte prática, que é a parte legal de fazermos as simulações dentro da console da AWS.

AWS Snowball, Storage Gateway e CloudFront - CloudFront

Vamos falar agora do CloudFront.

CloudFront nada mais é do que o serviço de CDN da AWD. Como CDN, a função dele, a proposta dele nada mais é do que acelerar o acesso ao seu conteúdo.

Vamos ver a descrição oficial no site da AWS. Diz lá: 'um serviço para acelerar a distribuição de conteúdo estático e dinâmico'. Isso é importante, lembre-se disso na hora da prova e tudo mais 'conteúdo estático e dinâmico'.

Como estrutura, o CloudFront vai usar, principalmente, os edge locations. Toda aquela infra da AWS de edge location para ter pontos mais próximos dos teus clientes e, logicamente, facilitar o acesso. Botar Cached e todos os recursos que um CDN oferece.

Então, essa é a ideia do CDN. Guarde essas palavras mágicas: 'baixa latência para entrega de conteúdo', sempre visando a questão da performance.

Essa é a ideia do serviço, vamos ver com mais detalhes.

A infraestrutura...os desenhos mostrados no slide são interessantes porque trazem à memória questões de infraestrutura, em especial, da AWS.

Nessa figura, nós vemos o mapa de distribuição dos edge locations. E eles tem os pontos azuis que são os edge locations, os múltiplos edge locations estão concentrados, tem pontos isolados e regiões, também, de edge locations.

A ideia é, e isso faz menção à estrutura, você sempre tem que lembrar de uma figura, que é a seguinte: mais edge locations, depois zonas de disponibilidade e depois, regiões. Sempre nessa ordem, em termos de quantidade.

Como é que funciona o CDN? A ideia é a seguinte: o teu usuário vai acessar o domínio, o exemplo.com. Esse domínio, logicamente, está hospedado, estão referenciados os serviços da AWS.

Ele digitou a URL, digitou o que ele quer e o CDN vai fazer um get. Esse get vai bater aonde? Vai bater no ponto mais próximo dele, no ponto de distribuição mais próximo dele.

Se esse conteúdo; vamos partir do princípio que é a primeira vez que o usuário está acessando; esse conteúdo existe no edge location? Não existe. O que o CDN faz? Ele vai no teu servidor, ou seja, no S3, na máquina EC2, vai aonde está hospedado o objeto, que retorna para o edge location, é feito um Cached e esse objeto, a partir de então, é entregue para o seu usuário.

Segundo acesso, terceiro acesso dentro das regras que forem configuradas, respiração e tudo o mais, o teu usuário não vem mais dentro do seu S3 ou do seu servidor. Ele pega o conteúdo direto do edge location, logicamente, garantindo um acesso mais rápido.

Essa é a ideia, que é servir conteúdo.

Vamos dar uma olhada no seguinte, alguns pontos importantes para memorizar: lá na documentação da AWS, no tópico do CloudFront, na página do serviço fala de CDN para você fazer associação.

O que eu queria destacar é o seguinte; além, lógico, desse conteúdo, e sempre nos referimos à isso com a questão de sites, de objeto, de imagem; é importante saber que o CloudFront funciona, ele pode ser associado, também, com serviços como o Shield para mitigação DDoS, S3, Load Balancing, EC2, aplicações de Lambda (vamos ver isso mais para frente); tudo isso você pode associar ao teu CDN, o CloudFront.

E na AWS Management Console, vamos mostrar rápido um detalhe importante, algumas particularidades. No meio da tela, vamos clicar no link azul "CloudFront", e na página que abrir vamos criar uma distribuição, clicando no botão "Create Distribuition".

Duas coisas legais: ele agora (isso é relativamente novo) a parte de objeto, diz na página, para conteúdo dinâmico, por exemplo, HTML, CSS, PHP e tudo o mais; e na parte de RTMP diz que o CloudFront vai ser descontinuado. Antigamente usava o RTMP para fazer o conteúdo de string e na verdade, agora, o CloudFront vai concentrar tudo na Web, criando distribuições.

Vamos seguir, vamos iniciar clicando no botão "Get Started", você vai criar uma distribuição. Vou chamar o nome escrevendo 'rmerceslabs.com' no campo "Origin Domain Name" e vamos preencher os campos. A ideia é só uma ilustração, não precisamos criar, nesse momento, o CDN. É importante você só entender alguns parâmetros.

Por exemplo, a questão de segurança, quais as versões de TLS que ele trabalha, protocolo se é só HTTP ou se é também HTTPS e coisas do tipo.

Tem toda a parte de tempo, Timeout, todas essas definições, métodos que você pode definir.

E no final da página, vamos rodar a tela até embaixo, em Distribution Settings, logicamente, como todos os serviços tem a questão de preço e isso está ligado, diretamente, em como você vai fazer a distribuição.

Eu posso fazer a distribuição (isso é importante para a prova), por todos os meus edge locations, toda a infraestrutura de edge locations da AWS.

Eu tenho a opção, também, de usar essa função de uma forma regionalizada; só nos Estados Unidos, Canadá e Europa e, na outra opção, ele abrange outros territórios, como também na Ásia, África e tudo o mais. E na opção default, que já mencionamos, para usar toda a infraestrutura da AWS. Sempre lembre que isso pode ser uma questão de prova.

O resto é detalhe de config, protocolo já falamos. E clicando no botão azul, no canto inferior no final da página, você cria a sua distribuição.

Aí, vai fazer o processo. Demora um tempo para ser habilitado e, a partir daí, dentro dessa distribuição, conseguimos criar algumas regras de exceção.

Por exemplo, tenho o meu site e em um determinado tipo de arquivo eu não quero que ele faça Cached. Eu crio essas regras dentro da distribuição.

É interessante dar uma passada no tópico. Não vejo necessidade de você criar na que acabamos de fazer, pelo menos, para esse tipo de prova. Mas, entender quais são esses parâmetros, dar uma lida com calma nessa documentação.

Eu vou terminar a distribuição que criamos, vou desabilitar ela e depois eu vou apagar. E é só eu excluir a minha sessão.

Simples. A forma de criar é rápida.

Na sequência, vamos pro assunto principal, que é estudar sobre o EC2.

Leia essa documentação, relembre esses pontos principais para passar para o próximo vídeo.

Sobre o curso AWS Certification: Solutions Architect Associate Parte 2

O curso AWS Certification: Solutions Architect Associate Parte 2 possui 176 minutos de vídeos, em um total de 34 atividades. Gostou? Conheça nossos outros cursos de AWS em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• AWS Snowball, Storage Gateway e CloudFront
• EC2: Elastic Compute Cloud
• EBS: Amazon Elastic Block Store
• EFS: Amazon Elastic File System2
• FSX, Lustre, Placement Groups