Iniciando sua trajetória na nuvem de forma descomplicada

Por Marilia Brito, Technical Trainer na AWS

Quando começamos a falar de nuvem, pensamos automaticamente nas vantagens que iremos desfrutar aderindo a este modelo de operação, onde eu não cuido mais da administração de data centers, e sim foco em construir uma arquitetura que atenda as necessidades do meu negócio.

Em um espaço onde você pode contar com cerca de 175 serviços, uma ideia pode ser colocada em prática com apenas alguns cliques, em qualquer uma das 24 regiões que compõem a infraestrutura global da AWS. A console é como uma tela em branco esperando pela sua obra prima ser criada.

Mas, como iniciar na nuvem da AWS? Qual seria um bom caminho? Nesse artigo, nosso objetivo é lançar um web server, sempre pensando em seguir boas práticas. Vamos percorrer todos os passos necessários não focando somente nos aspectos técnicos que envolvem essa tarefa.

Começando com o pé direito

Para dar início a essa jornada na nuvem, vamos pensar desde já em seguir boas práticas. Quando penso em boas práticas dentro da AWS, eu posso contar com diretrizes de design do Well Architected Framework, um guia que irá te ajudar a criar e adequar infraestruturas seguras, resilientes, eficientes e de alta performance. O Well Architected Framework é composto por 5 pilares: Excelência Operacional, Segurança, Confiabilidade, Eficiência de Performance e Otimização de Custos.

Além disso é interessante desde já, ter em mente qual a região que você irá construir a sua arquitetura. Regiões são áreas geográficas separadas onde mantemos nossos data centers. Esses data centers são agrupados logicamente em Zonas de Disponibilidades. A AWS possuí 77 Zonas de Disponibilidade e cada uma contém um ou mais data centers.

Você, como cliente detém o total controle sobre qual região irá inserir seus dados. Então é interessante considerar fatores como compliance e governança, proximidade dos clientes e custos ao escolher uma região. Se possível adote uma estratégia multi-região para trabalhar com maior redundância de recursos tornando sua arquitetura até mesmo tolerante a falhas.

Quer conhecer melhor a infraestrutura global da AWS? Esse link te leva a um site totalmente interativo para você “viajar” pelas regiões e pontos de presença (onde moram os serviços globais) da AWS.

Figura 1 – Infraestrutura Global da AWS, disponível no site https://infrastructure.aws

Você acabou de criar sua conta, então vamos já pensar em segurança. Segurança é a prioridade máxima da AWS e vem antes de tudo e será a nossa também! Então vamos proteger essa conta recém-criada?

Root User – “com grandes poderes, vem grandes responsabilidades”

Quando você acessa a console da AWS utilizando seu email e senha de criação da conta, você está utilizando o usuário root. O usuário root possui poderes ilimitados. Qualquer recurso que ele quiser utilizar dentro da conta, ele poderá, e um de seus poderes pode causar um grande transtorno. O poder de deletar sua conta AWS e consequentemente os seus recursos que foram provisionados dentro dela. Para não ter de arcar com esse tipo de problema, nós iremos performar as seguintes ações que podem ser visualizadas no dashboard do serviço de controle de identidades e acessos, o AWS IAM.

Delete your root access Keys – as chaves de acesso do usuário root (access key e secret key) não devem ser utilizadas, porque seu uso irá prover acesso irrestrito a todos os seus recursos da AWS. Então, não iremos utilizar essas chaves para interagir com os endpoints e APIs da AWS. Veja aqui como deleta-las.

Activate MFA on your root account – adicione uma camada de segurança a mais para efetuar sua autenticação durante o login. Confira a lista de mecanismos disponíveis.

Create individual IAM users – crie usuários com políticas de acesso que contenham o mínimo privilégio possível, ou seja um usuário só deve ter permissões de acesso que sejam relativas estritamente aos serviços que ele deverá utilizar e somente com as ações que deverá executar. Também é possível ter políticas que neguem o acesso a um determinado recurso.

Vamos criar nosso primeiro usuário! O usuário Admin. O usuário Admin ou Administrador que iremos criar é um usuário que possui plenos poderes na sua conta, porém não possui o poder de deletar essa conta. É muito fácil criar esse ou qualquer outro usuário, basta definir as formas de interação que ele irá ter com os serviços da AWS (programática ou pela console), selecionar as políticas que esse usuário irá possuir, baixar as chaves de acesso e pronto! No caso do usuário Admin iremos utilizar uma política gerenciada pela AWS chamada Administrator Access.

Políticas no IAM podem ser gerenciadas pela AWS ou podem ser criadas pelo próprio usuário manualmente ou utilizando um gerador de políticas, que pode ser utilizado clicando em “Create Policy”. Então, mesmo que você não saiba criar políticas do zero usando a formatação JSON, você será capaz de criar suas próprias políticas customizadas através de um editor visual.

Muito fácil, não é mesmo? Caso você queira atrelar permissões de visualização do faturamente da sua conta e gerenciamento de custos, insira uma política gerenciada chamada Billing.

A partir de agora você não irá mais acessar a console pelo seu root user e sim através do usuário Admin, utilizando seu nome de usuário + senha por um link como o abaixo:

https://<númerocontaaws>.signin.thinkwithwp.com/console

Para criar seus usuários que irão utilizar essa conta, uma boa prática é a criação de grupos, para definir as permissões de acessos referentes a cada um desses grupos e inserir os usuários que farão parte de cada um deles. Fazendo isso, um usuário dentro de um grupo irá herdar as políticas que o grupo possui. Isso é muito mais prático e mais seguro do que vincular políticas diretamente a um usuário.

Root user seguro, grupos e usuários definidos, é hora de usar o nosso primeiro serviço na nuvem AWS.

Começando de forma descomplicada com o Amazon S3

O Amazon Simple Storage Service, como o próprio nome já diz, é simples de ser utilizado, é o serviço de armazenamento para a internet. O Amazon S3 armazena qualquer tipo de arquivo como um objeto. Um objeto é um arquivo e todos os metadados opcionais que o descrevem. Objetos devem ter no máximo 5 TB para serem armazenados pelo serviço e desfrutar dos 11 9’s de durabilidade (99,999999999%) que o S3 oferece.

O Amazon S3 é perfeito para você armazenar qualquer volume de dados, por ele ser dotado de um armazenamento ilimitado. Totalmente serverless, totalmente gerenciado, pode ser usado para diferentes casos de uso, como backups, data lake, podendo ser até mesmo usado como estrutura para servir um site estático.

Crie seu bucket, definindo um nome único global para ele, defina a região e comece a inserir seus objetos.

Quando um bucket é criado, somente quem o criou terá acesso a este bucket. Para disponibilizar o acesso aos objetos que estão ali armazenados, é necessária a criação de políticas que permitam isso.

O Amazon S3 possui diversas classes de armazenamento, que vão desde acesso frequente (S3 Standard) até arquivamento de dados para longa retenção com um custo baixo , usando o AWS Glacier.

Estamos precisando de poder computacional para colocar uma aplicação no ar. Mas, antes disso vamos fazer as configurações prévias antes de iniciar esse passo.

Se você faz parte da equipe de infraestrutura, esse é o seu momento! Se você não sabe absolutamente nada sobre redes, vamos entender de forma simplificada o que é necessário configurar na nossa rede privada na AWS, para poder lançar nossas instâncias EC2.

Amazon VPC – sua rede virtual na nuvem

Não importa se você é time IPV4 ou do time IPV6, utilizando a VPC, você pode escolher somente trabalhar com IPV4 ou optar por ambos! Na nossa arquitetura iremos focar em IPV4.

Antes de iniciar a construção da nossa VPC, vamos fazer a alocação de um Elastic IP, seguindo as instruções da documentação. Iremos precisar deste IP estático!

O wizard da VPC irá facilitar a criação e configuração da rede que precisamos para lançar nossos recursos! Vamos seguir as boas práticas e selecionar a opção de criação que contém uma subnet pública e uma privada para poder isolar os recursos que não queremos que se comuniquem com a internet de forma direta. Subnets moram dentro de uma Zona de Disponibilidade e neste primeiro momento vamos trabalhar utilizando uma única AZ.

Hora de dar um nome para a sua VPC e usar aquele Elastic IP, previamente criado.

VPC criada! Vamos explorar as rotas que o wizard criou para cada uma das nossas subnets. Começando pela Subnet Pública

Todos os recursos que forem inseridos na Subnet Pública terão acesso à internet, pois a tabela de rotas associada possui roteamento para o gateway que possibilita a comunicação da sua VPC com a internet. Mas, que gateway é esse? É o Internet Gateway, um recurso totalmente serverless e totalmente gerenciado pela AWS. Quando uma VPC é criada manualmente sem o auxílio do wizard, a criação e o ato de anexar um IGW à sua VPC teria que ser realizado de formal manual pelo cliente, pois por padrão uma VPC é totalmente privada e somente os recursos que ali residem podem se comunicar nativamente.

Já na tabela de rotas da Subnet Privada, podemos verificar que não existe uma rota definida para o Internet Gateway.

Mas, é possível verificar uma rota com destino a internet (0.0.0.0/0) indicando como alvo o nat-<iddonatgateway>. Foi para esse recurso que criamos aquele Elastic IP. O NAT gateway encaminha o tráfego da subnet privada para a internet, sem expor o IPs desses recursos e sim o IP elástico e estático que alocamos para ele. O NAT é posicionado na Subnet Pública, pois como vimos na imagem anterior, a subnet em questão, possui uma tabela de rotas que proporciona acesso à internet, através da comunicação com o IGW.

É hora de subir o nosso web server!

Amazon EC2 – um “cardápio” a ser explorado

O que eu mais gosto em relação as instâncias EC2 é a possibilidade de poder fazer diversas escolhas erradas e não ser penalizada por isso, tendo que lidar com aquele hardware juntando pó no meu data center, ou executando a minha aplicação sem alcançar exatamente a performance desejada, devido a uma compra baseada em uma estimativa um tanto quanto incorreta. Sorria, você está na nuvem e aqui os recursos são totalmente descartáveis. É um espaço para você explorar, experimentar e até mesmo falhar! Sim, porque é só encerrar aquele recurso e recomeçar com outro que faça mais sentido para o seu caso de uso.

As instâncias EC2 são separadas por famílias e cada família tem uma finalidade específica, como por exemplo General Purpose, Compute Optimized e Memory Optimized. Além disso instâncias possuem tamanho. Vamos pegar como exemplo a instância r5.large da família Memory Optimized.

Conforme eu vou aumentando o tamanho da minha instância, ou seja large>xlarge>2xlarge e assim por diante, mais poderosa ela irá se tornar. Portanto escalar uma instância verticalmente é aumentar seu tamanho, consequentemente aumentando a quantidade de vCPU, memória e todos os outros atributos.

Você também pode desfrutar da instância da família General Purpose, a t2.micro que oferece 750 horas de poder computacional por mês, durante 12 meses de forma gratuita através do AWS Free Tier. Alguns serviços possuem um nível de free tier que não se restringe há 12 meses. Confira em nossa página AWS Free Tier.

Lançar uma instância é muito fácil mesmo! Com apenas alguns cliques, sua instância já estará disponível para você dar início a construção da sua aplicação.

Toda instância EC2, nasce a partir de uma AMI (Amazon Machine Image), essa AMI pode ser uma disponibilizada pela AWS com sistemas operacionais open source ou com licenciamento incluso e pode conter algumas aplicações e pacotes já previamente instalados. Você também pode criar sua própria imagem contendo tudo que sua aplicação precisa para subir, ou utilizar uma imagem do AWS Marketplace com soluções de terceiros já prontinhas para você utilizar.

Após fazer essa seleção e definir qual será a família e tamanho de sua instância, vamos selecionar em qual rede e sub rede essa instância será provisionada.

Estamos lançando um web server, portanto ele irá residir na Subnet Pública. Para isso, habilitamos o IP público. Posso adicionar também alguma ação que deverá ser executada no momento que essa instância for lançada, como por exemplo iniciar um Apache Web Server. Estamos falando do user data da instância EC2. É só expandir Advanced Details e inserir como texto, arquivo ou base64.

Temos poder computacional, escolhemos a rede na qual ele será provisionado, mas ainda precisamos definir o dispositivo de armazenamento para esta instância.

Armazenamento de blocos persistente, altamente disponível para diversos casos de uso

O Amazon EBS é quem provê o armazenamento de blocos para a nossa instância EC2.  Ele é persistente, pois pode ser independente do ciclo de vida da instância. É altamente disponível, porque nativamente é replicado dentro da zona de disponibilidade na qual foi criado. Existem 5 tipos de discos entre opções SSD (mais performático para IOPS) e HDD (perfeito para aplicações que dependem primariamente de performance de throughput).

Figura 2 – Tipos de volumes do Amazon EBS, disponível no site https://docs.thinkwithwp.com/AWSEC2/latest/UserGuide/ebs-volume-types.html

Escolha seu disco do volume root e adicione mais volumes do EBS, caso seja necessário. Quando sua instância estiver rodando, lembre-se de manter uma rotina de backups regular dos seus discos do EBS, fazendo snapshots.

No início do nosso texto, falamos sobre priorizar segurança e a colocar em primeiro lugar, agora não será diferente. Nosso web server contará com um firewall virtual para protege-lo.

Security Group – controle o tráfego que será recebido por seus recursos

Security Group é um firewall com regras especificadas pelo usuário, referente às possíveis formas de interação através da rede, que estarão permitidas com o recurso que está sendo protegido por ele. Por padrão, todas as permissões concedidas no inbound, serão automaticamente herdadas no outbound. Trata-se de um recurso stateful.

Em nosso web server, será possível acessar a instância através de SSH pela porta 22, desde que o IP de origem seja o descrito de forma explícita na regra. Ele irá também aceitar tráfego com origem da internet na porta 80.

Caso não houvesse nenhuma regra explícita no security group, a instância não iria aceitar nenhum tipo de comunicação.

Só falta mais um passo! Selecione uma key pair já existente ou crie uma nova. Você irá armazenar a chave privada desse key pair para poder se conectar de forma remota à sua instância.

Sucesso! Nosso web server já está no ar!

O web server está pronto para receber seus arquivos e exibir isso para toda a web. Confira abaixo a arquitetura que construímos:

Na parte 2 desse artigo, iremos lançar um servidor de aplicação, um banco de dados e tornar essa arquitetura altamente disponível!

Sobre a autora

Marilia Brito é Technical Trainer da AWS e faz parte da equipe de Training and Certification Latam. Iniciou na AWS em um programa de formação de arquitetos de soluções e hoje ela ensina de forma leve e descomplicada desde o cliente que está iniciando sua jornada na nuvem, até aqueles que já estão em um estágio mais avançado de conhecimento.

Sobre os revisores

Bruno Lopes é Technical Trainer no time da AWS Brasil. Trabalha com soluções de TI há mais de 12 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes. Como Trainer, já está há mais de 6 anos dedicando seus dias a ensinar tecnologias de ponta aos clientes da América Latina.

Vinicius Alves é Technical Trainer da AWS na equipe de Training and Certification Latam. Com formação em Engenharia Mecânica pela FEI (São Bernardo do Campo), iniciou na AWS em um programa de formação de arquitetos de soluções e agora foca em ensinar todos os conceitos aprendidos para facilitar a jornada de clientes para o a nuvem.