22 publicações com a etiqueta "AWS"

No dia 7 de abril de 2026, a AWS lançou um novo recurso que aproxima o armazenamento de objetos e o armazenamento de arquivos: o Amazon S3 Files.

Até antes do seu lançamento, as aplicações que precisavam acessar arquivos armazenados no Amazon S3 frequentemente dependiam de outras soluções, aumentando custos e complexidade. Agora, o Amazon S3 Files muda esse cenário ao permitir que buckets sejam acessados como sistemas de arquivos via NFS.

Neste artigo, vamos entender o que é o S3 Files, por que ele é tão importante e ainda como utilizá-lo em uma demonstração com ECS Fargate e Terraform.

Bora lá?

A vida antes do S3 Files​

Por anos, arquitetos e outros profissionais da nuvem precisavam escolher entre armazenamento de objetos e armazenamento de arquivos. Na AWS, isso se resumia, na maioria dos casos, aos serviços:

• Amazon S3: é um dos serviços mais antigos da AWS, lançado em 2006. É escalável, durável, barato, mas sem semântica de sistema de arquivos;
• Amazon EFS: sistema de arquivos compatível com POSIX/NFS, porém mais caro e com outro modelo de uso;
• Amazon EBS: armazenamento em bloco de alto desempenho e baixa latência;
• Amazon FsX: família de sistemas de arquivos gerenciados, com opções para Windows File Server, Lustre, NetApp ONTAP, entre outras.

Para fazer com que os dados trafegassem pelos sistemas, eles eram copiados de um lado para o outro: do S3 para o EFS, do S3 para o EBS, do S3 para FsX, depois copiar tudo de volta e por aí vai. Todo esse processo gerava custos adicionais de armazenamento; complexidade de configuração e sincronização dos dados; duplicação do armazenamento; entre outros.

Mas agora, com o S3 Files, muitos desses problemas podem ser eliminados ou significativamente reduzidos...

O que é o Amazon S3 Files​

O Amazon S3 Files é um recurso que permite acessar dados armazenados no Amazon S3 como se fossem um sistema de arquivos tradicional. Na prática, ele conecta os recursos de computação da AWS (tais como EC2, ECS/EKS, Fargate e funções Lambda) aos dados do S3, por meio do protocolo padrão NFS, apresentando-os como diretórios e arquivos navegáveis. Dessa forma, aplicações podem ler e gravar arquivos sem a necessidade de copiá-los para outro serviço de armazenamento, enquanto os dados continuam sendo armazenados nativamente como objetos no Amazon S3.

Um ponto importante é que internamente o S3 Files compartilha a camada NFS com o EFS. Para isso, ele mantém apenas os dados usados ativamente armazenados em uma camada de cache de alto desempenho. Os arquivos que permanecem sem acesso por um período configurável (1 a 365 dias, sendo 30 dias o padrão) são removidos automaticamente do cache, permanecendo disponíveis no bucket. Ou seja, os dados continuam armazenados no S3, o que pode reduzir consideravelmente os custos se comparado à duplicação dos dados entre sistemas de arquivos e armazenamento de objetos.

E veja bem um detalhe aqui: não se trata exatamente de um novo serviço de armazenamento, mas uma nova forma de acessar os dados existentes no S3.

Principais casos de uso​

• Substituição de servidores SFTP gerenciados: Empresas que recebem arquivos de parceiros podem disponibilizar acesso direto aos dados armazenados no S3;
• Machine Learning (ML): Elimina a necessidade de criar cópias temporárias dos dados do S3 em discos locais antes do treinamento, pois datasets podem ser acessados diretamente durante treinamento e inferência;
• Agentes de Inteligência artificial: Múltiplos agentes podem compartilhar arquivos, logs e estados persistentes;
• Aplicações legadas: aplicações que esperam um sistema de arquivos tradicional podem operar diretamente sobre dados armazenados no S3;
• Espaços de trabalho colaborativos: Equipes podem compartilhar conjuntos de arquivos sem necessidade de múltiplas cópias.

S3 Files x Amazon EFS​

Uma dúvida comum é se o S3 Files substitui completamente o Amazon EFS. A resposta é: depende da carga de trabalho.

No quadro abaixo, temos uma breve comparação que ajude a entender sobre quando usar um ou outro:

Veja que entre o S3 Files e o EFS não existe um vencedor absoluto, pois eles atendem necessidades diferentes. Enquanto o S3 Files permite que aplicações acessem dados já armazenados no Amazon S3 através de uma interface de sistema de arquivos, o EFS continua sendo a melhor escolha para workloads que exigem baixa latência, consistência imediata e acesso compartilhado contínuo entre múltiplas instâncias.

Em resumo, podemos dizer que o S3 Files não substitui o Amazon EFS; ele resolve um problema diferente: permitir que aplicações que esperam um sistema de arquivos trabalhem diretamente sobre dados armazenados no Amazon S3.

Demonstração: implementando ECS Fargate com S3 Files via Terraform​

Para este laboratório, vamos subir uma task no ECS Fargate, que é o serviço serveless da AWS voltado para execução e orquestração de containers Docker. Com ele, podemos executar os containers sem a necessidade de provisionar, configurar ou gerenciar clusters de máquinas EC2. Dessa forma, a escolha pelo Fargate se deu a fim de abstrairmos o gerenciamento da infraestrutura para o exemplo deste artigo, e também aproveitarmos o modelo de cobrança baseado nos recursos alocados para cada task (CPU e memória).

Além disso, para fins de praticidade, a estrutura será provisionada com Terraform, utilizando os módulos da AWS mantidos pela comunidade para acelerar o desenvolvimento.

Outro ponto importante é que, neste laboratório, usaremos como ponto de montagem apenas um prefixo do bucket S3, e não o bucket inteiro. Essa é uma prática recomendada, pois reduz a quantidade de metadados importados durante a criação do sistema de arquivos, acelera a montagem inicial e minimiza o impacto de operações como movimentação e renomeação de diretórios, que no Amazon S3 são implementadas por meio de operações de cópia e exclusão de objetos.

Arquitetura​

O lab provisiona, via Terraform, tudo que é necessário para conectar um container no ECS Fargate a um bucket S3 via S3 Files: uma VPC com subnets privadas em duas zonas de disponibilidade, um bucket S3 com versionamento habilitado (pré-requisito do serviço), o file system do S3 Files com um mount target por AZ, as roles IAM para o serviço e para a task, e o próprio cluster ECS com o serviço Fargate configurado para montar o prefixo lab/ do bucket em /mnt.

Na demonstração proposta, o nosso container roda no ECS Fargate e enxerga o prefixo lab/ do bucket como se fosse uma pasta local, montada em /mnt. Conforme mencionado anteriormente, essa é uma prática recomendada, ao invés de montarmos o bucket inteiro. Por baixo dos panos, o Fargate configura um proxy NFS na própria interface de rede da task. Quando o container escreve um arquivo, o S3 Files sincroniza esse dado com o bucket S3 em segundo plano, geralmente em menos de um minuto. Para a aplicação, é só uma escrita em disco como qualquer outra.

Para verificar o funcionamento, usamos uma imagem Docker customizada, baseada no Alpine, com um script de entrada que confirma o mount NFS, exibe o espaço disponível e escreve um arquivo no prefixo montado. Mas vale deixar claro: qualquer imagem funcionaria com o S3 Files. O mount acontece na plataforma Fargate, antes de o container iniciar, independente do que está dentro da imagem. A imagem customizada existe apenas para tornar a validação mais visível com os logs, pois sem ela, precisaríamos conectar manualmente ao container para confirmar que o nosso volume realmente está lá.

Pré-requisitos

• Conta AWS
• Terraform >= 1.8
• AWS CLI configurado
• Docker instalado
• Permissões para criar:
  • VPC
  • ECS
  • IAM
  • S3
  • S3 Files

Passo 1 - Clonar o repositório

Para iniciar o laboratório, clone o repositório do GitHub que contém os arquivos Terraform:

git clone https://github.com/ludsilva/aws-s3files-ecs.git
cd aws-s3files-ecs

Dentro do diretório, você encontrará os arquivos Terraform necessários para provisionar a infraestrutura.

Passo 2 - Provisionar a infraestrutura

Execute os comandos:

terraform init
terraform apply

O Terraform sobe VPC, S3, S3 Files, IAM e o ECS Service. O polling dos mount targets já acontece aqui, o apply só irá terminar quando os volumes estiverem disponíveis.

Passo 3 - Acompanhar os logs

Após os recursos serem provisionados, o ECS Fargate sobe a task e executa o script de entrada. Para acompanhar os logs, você pode acessar a console AWS ou usar o comando:

aws logs tail /ecs/app-s3-files --follow

Saída esperada: [OK] Lab completed.

Passo 4 - Checar a sincronização com o S3 Files Caso queira verificar se o arquivo foi realmente gravado no bucket S3, você pode ir até o console do S3 ou usar o comando:

aws s3 ls s3://my-blog-s3-files-demo/lab/test/

O arquivo result.txt deve aparecer no bucket após ~60s da escrita.

Passo 5 - Teste de persistência dos arquivos

Por fim, vamos validar a persistência dos arquivos gravados no S3 Files. Para isso, vamos parar a task manualmente (ou com o comando aws ecs stop-task) e aguardar o ECS subir uma nova automaticamente.

Após subir a nova task, você pode acompanhar os logs novamente e verá que o script de entrada será executado novamente, gerando um novo arquivo result.txt com timestamp diferente.

No bucket, confirmamos que o arquivo result.txt anterior ainda está lá, e um novo arquivo com timestamp diferente foi criado. Isso demonstra que a persistência dos arquivos gravados no S3 Files independe do ciclo de vida do container.

OBS: Como a nossa imagem customizada gera um arquivo com timestamp, você verá que o conteúdo do arquivo será diferente a cada execução, mas o arquivo em si permanecerá no bucket. Caso queira, você pode testar a persistência com outra imagem Docker e escrever no diretório montado.

Passo 6 - Apagar o ambiente Para não ter surpresas desnecessárias na sua fatura no fim do mês, lembre-se de apagar o ambiente criado. Para isso, execute:

terraform destroy

Custos estimados do laboratório​

Apenas a título de curiosidade, a implementação desta arquitetura custou aproximadamente $41.30 dólares por mês, mas como aplicamos somente em poucas horas, o custo real do laboratório foi de apenas alguns centavos.

Abaixo, segue uma estimativa dos custos mensais:

Observação: Os valores apresentados são apenas uma estimativa para este laboratório e podem variar conforme a região da AWS, o tempo de execução da aplicação, a quantidade de dados armazenados e o volume de requisições realizadas ao Amazon S3 Files e ao bucket S3.

Observações importantes​

Embora o Amazon S3 Files simplifique o acesso aos dados armazenados no Amazon S3 por meio de uma interface de sistema de arquivos, é importante compreender algumas características antes de utilizá-lo:

• O S3 Files não substitui todos os tipos de armazenamento: conforme dito antes, embora ele utilize NFS como interface de acesso, o armazenamento continua sendo o Amazon S3 (por isso ele herda as características de latência do S3). Isso significa que workloads extremamente sensíveis à latência ou que exigem alto volume de IOPS, como bancos de dados, o Amazon EBS ou Amazon EFS ainda continuam sendo opções mais adequadas;
• A sincronização entre NFS e S3 é assíncrona: Isto significa que as alterações realizadas pelo sistema de arquivos e pela API do Amazon S3 não são refletidas instantaneamente entre as duas interfaces. Se uma aplicação exige consistência imediata entre múltiplos consumidores ou acessa simultaneamente os mesmos arquivos pelo sistema de arquivos e pela API do S3, esse comportamento deve ser considerado;
• Evite escrita concorrente: Uma boa prática é definir uma única interface responsável pela escrita dos dados. Quando um mesmo arquivo é modificado simultaneamente pelo sistema de arquivos e pela API do Amazon S3, podem ocorrer conflitos. Nesses casos, a versão armazenada no S3 é preservada e a versão conflitante é movida automaticamente para o diretório S3.lost+found;
• Operações de renomeação podem ser custosas: Ao contrário de sistemas de arquivos tradicionais, o Amazon S3 não possui uma operação nativa de rename. Com isso, renomear ou mover diretórios exige que o serviço copie todos os objetos envolvidos e remova os originais posteriormente. Em grandes volumes de dados, esse comportamento pode aumentar significativamente o tempo de execução e o custo da operação.
• Monte apenas o prefixo necessário: Sempre que possível, monte apenas o prefixo do bucket utilizado pela aplicação, em vez do bucket inteiro. Essa prática reduz a quantidade de metadados carregados durante a montagem, acelera a inicialização da aplicação e diminui o impacto de operações envolvendo diretórios.

Conclusão​

O Amazon S3 Files representa uma mudança importante na forma como aplicações podem consumir dados armazenados no Amazon S3. Ao permitir acesso através de uma interface de sistema de arquivos, ele reduz a necessidade de múltiplas camadas de armazenamento e simplifica arquiteturas que anteriormente dependiam de serviços como Amazon EFS apenas para compartilhar arquivos.

Embora não substitua completamente o EFS em todos os cenários, o recurso abre novas possibilidades para workloads em ECS, EKS, EC2, Machine Learning e Inteligência Artificial, especialmente quando o objetivo é reduzir custos e simplificar a gestão de dados e a arquitetura.

Mais do que um novo recurso, o Amazon S3 Files é uma oportunidade para repensar aplicações na AWS. Como toda novidade, porém, sua adoção deve considerar cuidadosamente os requisitos de latência, consistência e padrão de acesso da aplicação. Em outras palavras, o Amazon S3 Files não elimina a necessidade de boas decisões arquiteturais; ele amplia as possibilidades para projetar soluções mais simples, econômicas e aderentes ao comportamento real das aplicações.

Referências​

• Documentação: Amazon S3 Files
• Documentação: Working with Amazon S3 Files
• Documentação: Configuring S3 Files for Amazon ECS
• Artigo: Getting Started with Amazon S3 Files: Mounting S3 Buckets as File Systems
• Artigo: AWS S3 Files — 13x Cheaper Than EFS (But Read This First)

A partir do dia 31 de março de 2026, o LocalStack deixou de disponibilizar a versão Community, movendo diversos serviços core para planos pagos. Na prática, isso impacta diretamente aqueles que utilizavam a ferramenta para testes sem custo.

Mas se tem algo interessante na comunidade open source é que se uma porta fecha, outras várias são abertas. Por isso, resolvi reunir algumas opções open source para quem quer continuar desenvolvendo e testando localmente, com foco em AWS, mas sem estourar o orçamento no fim do mês.

Ah, além de falar brevemente dessas soluções, vamos fazer alguns testes rápidos. Por isso, certifique-se de ter o Docker e AWS CLI instalados.

Bora lá?

Floci​

Eu encontrei o Floci em um post no LinkedIn escrito pelo Fabiano Moura, e achei a proposta muito válida: ser acessível e open source desde o início.

Atualmente, o Floci emula 22 serviços da AWS, desde o S3 ao CloudFormation. Ainda há serviços core da AWS não disponíveis, mas ele consegue cobrir diversos casos de estudo e testes.

Rodando em Docker com uma imagem bem leve, o Floci usa a mesma porta (a 4566) e mesmo protocolos e chamadas AWS SDK que o LocalStack, o que facilita a curva de aprendizado.

Instalando e testando o Floci​

Para instalar o Floci, vamos usar o padrão com um container Docker. Para isso, execute o comando abaixo:

# Rodar o container em segundo plano
docker run --rm -d -p 4566:4566 hectorvent/floci:latest

Depois, vamos configurar a AWS CLI com o export das credenciais fake:

export AWS_ENDPOINT=http://localhost:4566
export AWS_DEFAULT_REGION=us-east-1
export AWS_ACCESS_KEY_ID=test
export AWS_SECRET_ACCESS_KEY=test

Por fim, fazer alguns testes criando um Bucket S3, subindo um arquivo .txt e listando os objetos do bucket:

# Criando um bucket S3 
aws s3 mb s3://my-bucket --endpoint-url $AWS_ENDPOINT

# Subindo um arquivo .txt
echo "hello floci" | aws s3 cp - s3://my-bucket/hello.txt --endpoint-url $AWS_ENDPOINT

# Listando os objetos do bucket criado
aws s3 ls s3://my-bucket --endpoint-url $AWS_ENDPOINT

Resultado:

Imagem: Saída do terminal (CLI) exibindo o comando aws s3 ls mostrando o arquivo hello.txt dentro do bucket my-bucket, confirmando que o upload foi realizado com sucesso no Floci.

Ministack​

O Ministack apareceu para mim após uma postagem do Thiago Augusto Ozores no LinkedIn, e já virou um dos meus favoritos.

Ele permite emular 33 serviços da AWS, e se diferencia por executar contêineres reais para serviços críticos, tais como RDS, ElastiCache, Docker via ECS e consultas SQL com DuckDB (Athena), em vez de apenas simular as chamadas de API.

O Ministack é leve e rápido, com uma imagem de cerca de 150MB. Assim como o Floci e o LocalStack, ele também usa a porta 4566, e isso facilita o uso porque basta apenas mudar o endpoint dos laboratórios e ambientes.

Instalando e testando o Ministack​

Assim como fizemos com o Floci, vamos subir um container do Ministack com o comando:

# Rodar o container em segundo plano
docker run -d -p 4566:4566 nahuelnucera/ministack

Vamos criar um Bucket S3 de teste com o comando:

# Criando um bucket S3 no ministack
aws s3 mb s3://my-local-bucket \
  --endpoint-url http://localhost:4566 \
  --region us-east-1

Resultado:

Imagem: Saída do terminal (CLI) exibindo o comando aws s3 mb indicando “make_bucket: my-local-bucket”, confirmando que o bucket foi criado com sucesso no ambiente do Ministack.

kumo​

Por último, mais não menos importante, temos o kumo, que conheci por uma postagem do Everton Marques (também no LinkedIn!).

Escrito em Go, ele suporta 71 serviços da AWS! O kumo oferece um conjunto enxuto de funcionalidades, incluindo: execução sem autenticação, suporte a Docker, baixo consumo de recursos e inicialização rápida.

Assim como os outros colegas, o kumo também utiliza a porta 4566. Então, basta apenas mudar o endpoint para utilizar nos seus projetos.

Sem mais delongas, vamos fazer um teste rápido do kumo também!

Instalando e testando o kumo​

# Rodar o container em segundo plano
docker run -d -p 4566:4566 ghcr.io/sivchari/kumo:latest

E lá vamos nós para mais um teste de bucket S3 rsrs:

# Criando um bucket S3 no kumo
aws s3 mb s3://my-kumo-bucket \
  --endpoint-url http://localhost:4566 \
  --region us-east-1

Resultado:

Imagem: Saída do terminal (CLI) exibindo o comando aws s3 mb indicando “make_bucket: my-kumo-bucket”, confirmando que o bucket foi criado com sucesso no Kumo.

Considerações finais​

O fim da versão gratuita do LocalStack pode parecer um problema à primeira vista, mas hoje aprendemos que ele abriu espaço para novas ferramentas. Isso nos permite testar alternativas e repensar o fluxo de desenvolvimento local focado em AWS.

Mas me conta aí, você já testou alguma dessas opções? Usa outra alternativa? Ou ainda segue utilizando o LocalStack firme e forte?

Até mais e bons estudos!

Referências​

• Floci
• Ministack
• kumo
• The Road Ahead for LocalStack: Upcoming Changes to the Delivery of Our AWS Cloud Emulators

Voltando com nossos tutoriais da AWS, hoje vamos abordar uma solução de compartilhamento de arquivos entre instâncias EC2.

O que é um fileserver​

No ambiente on premises, utilizamos fileservers quando queremos compartilhar arquivos via rede para usuários ou aplicações.

Um fileserver (ou servidor de arquivos) nada mais é que um sistema criado para armazenar, gerenciar e compartilhar arquivos em uma rede. Através do fileserver, os usuários podem acessar documentos, imagens, vídeos e outros tipos de arquivos de forma centralizada, o que facilita a colaboração.

Normalmente, os servidores de arquivos operam com protocolos como SMB (Windows) e NFS (Linux), exigindo administração para gerenciamento de permissões, espaço em disco e desempenho.

O que é o EFS​

O Amazon Elastic File System (EFS) é um serviço de armazenamento de arquivos gerenciado e escalável. Ele permite criar e compartilhar sistemas de arquivos entre várias instâncias da AWS, como EC2, containers e funções Lambda, de forma simples e segura.

Diferente dos servidores de arquivos tradicionais, o EFS não exige provisionamento de capacidade em disco, pois ele é escalável. Além disso, oferece alta disponibilidade com replicação automática entre zonas de disponibilidade (AZs). Cabe ressaltar que ele utiliza o protocolo NFS, portanto, é usado em Linux.

Em cenários em que é necessário armazenar arquivos e compartilhar com várias instâncias, ou que o volume de dados pode variar significativamente, a solução mais indicada é fazer uso do EFS - ao invés de um Elastic Block Store (EBS) por exemplo.

Até o presente momento em que este tutorial foi preparado, a AWS oferece 12 meses gratuitos de armazenamento com o EFS, com 5GB de espaço.

Agora que já sabemos o que é o EFS, vamos colocar as mãos na massa!

Passo a passo: servidor de arquivos com o EFS​

1) Crie Grupos de Segurança​

Primeiramente, vamos criar dois Grupos de Segurança. Para isso, temos que:

• Acessar a console AWS ->ir em EC2 -> Grupos de Segurança -> clicar em Criar grupo de segurança

Para esse primeiro grupo, forneça um nome e uma descrição. Ele será o SG que vai permitir acessarmos a instância EC2 via SSH, mas limitando esse acesso ao IP da sua máquina local. Portanto, em Regras de Entrada:

• Clique em Adicionar regra -> em Origem selecione Meu IP -> clique em Criar grupo de segurança

O segundo grupo será para o EFS liberar para a instância o protocolo NFS. Para isso, crie um novo grupo de segurança:

Adicione uma regra de entrada com as informações:

• Tipo NFS, Origem Personalizado -> busque pelo Grupo de segurança criado para a EC2 e selecione o grupo -> e clique em Criar grupo de segurança

2) Criando o EFS​

Agora vamos efetivamente criar o EFS:

• Pesquise por EFS na console -> clique em Criar sistema de arquivos

Uma janela pop-up será aberta para criar o EFS, mas vamos selecionar a opção Personalizar para criarmos nosso sistema de arquivos:

Na janela de configuração do EFS, vamos definir as seguintes informações:

• Nome do sistema de arquivos
• Tipo de sistema de arquivos: marque Regional
• Desmarque a caixa Habilitar backups automáticos

Mais abaixo, em Configurações de performance, deixe:

• Modo de taxa de Transferência: Avançado
• Marque o Elastic (Recomendado)
• Modo de desempenho: Uso geral

Por fim, clique em Próximo.

Em Acesso à rede, como estou usando a VPC padrão da AWS - no Norte da Virgínia, o EFS vai listar todas as zonas de disponibilidade disponíveis para esta VPC. Nós vamos remover 4 delas, e deixar apenas a us-east-1a e us-east-1b.

Além disso, você deve remover os grupos de segurança padrão e selecionar o grupo criado para o EFS, conforme imagem:

Na página seguinte, não é necessário marcar nada em _Política do sistema de arquivos. Clique em Próximo_.

Você será direcionado para uma página para revisar as informações e criar o EFS. Desça até o final da página e clique em Criar.

Se tudo ocorrer com o esperado, o EFS será criado e em poucos segundos estará disponível:

Agora, clique no EFS para acessá-lo. Em seguida, clique no botão Anexar

Deixe marcada a opção Montar via DNS e copie os códigos das opções: Usando o assistente de montagem do EFS e o Usando o cliente do NFS. Guarde esses códigos em um bloco de notas, pois vamos precisar deles depois.

3) Provisionando as instâncias EC2​

Iremos criar duas instâncias com sistemas operacionais ligeiramente diferentes, uma instância Ubuntu e outra Amazon Linux.

Portanto, acesse o EC2 para criar as instâncias. A primeira deve ser as seguintes configurações:

• Nome: ec2-fileserver-1
• Imagem de máquina da Amazon: Ubuntu 24.04
• Tipo de instância: t2.micro
• Par de chaves (login): Criar novo par de chaves
• Configurações de rede -> clique em Editar -> selecione a VPC padrão da AWS e a sub-rede disponível na região us-east-1a
• Firewall (Grupos de segurança): Selecionar grupo de segurança existente
• Grupos de segurança comuns: escolha o grupo que criamos para as EC2 no começo deste tutorial

• Em "Configurar armazenamento", mantenha o padrão de 1 volume com 8 GiB.

Já a segunda instância deve ser as seguintes configurações:

• Nome: ec2-fileserver-1
• Imagem de máquina da Amazon: Amazon Linux
• Tipo de instância: t2.micro
• Criar par de chaves: selecionar par de chaves (escolha o mesmo par de chaves criado para a instância Ubuntu)
• Configurações de rede -> clique em Editar -> selecione a VPC padrão da AWS e a sub-rede disponível na região us-east-1b
• Firewall (Grupos de segurança): Selecionar grupo de segurança existente
• Grupos de segurança comuns: escolha o grupo que criamos para as EC2

Prontinho! Instâncias criadas:

4) Acessando as instâncias e montando o EFS​

Agora, vamos acessar a instância por SSH. Eu não irei me delongar nesse passo, mas caso tenha dúvidas de como fazer, acesse o tutorial Criando uma instância EC2 na AWS

Primeiro vamos acessar a instância Ubuntu (ec2-fileserver-1) e rodar os seguintes comandos:

sudo apt update
sudo apt install nfs-common -y
sudo mkdir efs

## Aqui vamos colar o segundo comando copiado lá no EFS
sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-0eb35cc770df5b760.efs.us-east-1.amazonaws.com:/ efs

df -h

• Primeiro, atualizamos a lista de pacotes disponíveis nos repositórios configurados com o sudo apt update
• Depois, instalamos o pacote nfs-common para permitir montar e acessar sistemas de arquivos NFS com o comando sudo apt install nfs-common -y
• Criamos um diretório chamado 'efs' com o comando sudo mkdir efs
• Em seguida, colamos o segundo comando que copiamos lá no EFS - para lembrar, olha ele aqui:

• Por fim, listamos o espaço em disco e os sistemas montados com o comando df -h. Veja que nosso EFS já aparece montado:

Em seguida, vamos acessar o diretório do EFS e criar um arquivo nele. Para isso, execute os comandos:

cd efs
sudo touch teste.txt
ls -lha

O arquivo vai aparecer listado no diretório efs:

Agora, vamos acessar a instância Amazon Linux, e rodar os comandos:

sudo yum install -y amazon-efs-utils
sudo mkdir efs

## Aqui vamos colar o primeiro comando copiado lá no EFS
sudo mount -t efs -o tls fs-0eb35cc770df5b760:/ efs

df -h

Veja que nosso diretório aparece montado:

Agora, vamos acessar o diretório compartilhado, listar os arquivos e criar mais um arquivo a partir da instância Amazon Linux:

cd efs
ls -lha
sudo touch teste2.txt

Por fim, vamos voltar na instância Ubuntu (ec2-fileserver-1) depois de criar o arquivo teste2.txt e rodar o comando ls -lha para listar os arquivos do diretório:

Veja que o teste2.txt criado na outra instância já aparece aqui. É isso, você agora tem um sistema de compartilhamento de arquivos altamente disponível e escalável na AWS!

5) Limpando o ambiente​

Para limpar o seu ambiente desse tutorial, basta:

• Encerrar as duas instâncias criadas

• Selecionar e excluir o EFS

• Caso queira, pode excluir os Grupos de Segurança e o par de chaves criados também, mas isso é opcional.

É isso, bons estudos!

Referências​

• O que é o Amazon Elastic File System? - Documentação da AWS
• Usar o Amazon EFS com instâncias do Linux do EC2 - Documentação da AWS
• Criando uma instância EC2 na AWS - link interno

Depois de colocarmos a mão na massa em alguns dos principais serviços da AWS, nada melhor que colocar tudo isso em um projeto. Sim, tudo junto e misturado!

Como a ideia é manter tudo da forma mais simples possível, mas abarcando conceitos e serviços importantes, o projeto se trata de hospedar um website estático na AWS, com SSL e um domínio (este último é importante, mas opcional).

Um website estático é um site que usa somente arquivos estáticos, tais como arquivos HTML, CSS, JavaScript, imagens e vídeos. Ele não precisa de um servidor backend ou de interagir constantemente com um banco de dados. Com isso, as páginas de um site estáticos são carregadas de forma sempre igual, independente do que você fizer ou clicar. Esse tipo de site é comumente usado para páginas de portfólio, páginas de produtos, blogs simples ou páginas de documentação.

Agora que já temos uma ideia do que é um site estático, vamos seguir para as características do projeto.

Requisitos​

Os requisitos do projeto são:

• Um website estático hospedado na AWS com armazenamento durável;
• Ter segurança e aceitar conexões HTTPS;
• Aceitar requisições do tipo GET e HEAD;
• Melhor desempenho e entrega para os usuários utilizando rede de entrega de conteúdo.

Arquitetura​

O diagrama de arquitetura de implantação do sistema nos ajuda a visualizar como tudo funciona.

Os arquivos do site estão hospedados em um bucket no Amazon S3. O Route 53 faz o serviço de gerenciamento de DNS para o domínio do site. Além disso, temos um certificado SSL gerado com o Amazon Certificate Manager (ACM), a fim de garantir a segurança e criptografia através de requisições HTTPS. E o CloudFront para a entrega rápida dos conteúdos utilizando os Pontos de Presença (Edge Locations) da AWS.

Basicamente, o usuário digita a URL no navegador e a requisição passa pela Zona de DNS do domínio, que está sob responsabilidade do Route 53. Ele faz o redirecionamento para o Amazon CloudFront, que é responsável por fazer a entrega de conteúdo com base na localização geográfica do usuário, na origem da página e também no servidor de entrega do conteúdo - realizando essa entrega com baixa latência e trazendo a sensação de “alta velocidade” por parte do usuário. O CloudFront está conectado com o Bucket S3, onde os arquivos do website estão armazenados. Todo esse acesso ao site é seguro e criptografado, através do certificado SSL gerado no Certificate Manager.

Ferramentas e serviços utilizados​

• Amazon Simple Storage Service (Amazon S3)
• CloudFront
• AWS Certificate Manager
• Route 53

Custos​

Os custos deste projeto vão depender se você pretende comprar um domínio ou hospedar um domínio já existente na AWS. Esses passos são opcionais, mas mesmo assim é válido elencar os preços.

• Registro de domínio: para registros .br, o custo é R$ 40,00 caso você registre no Registro BR. Para domínios com outras extensões, pode variar entre $3,00 a $5,00 (dólares), caso compre no Namecheap ou pela própria AWS.
• Utilizar a Zona Hospedada da AWS: $ 0.50 (dólares) por mês.

💡

Caso você queira registrar um domínio nacional (.br), você pode registrar na Umbler por R$ 36,00 - e olha que não estou ganhando nada por indicar, hein!

Então, mãos a obra!

1) Utilizar um domínio registrado​

Para este projeto, foi utilizado o domínio cloudtutorials.click, registrado na AWS - cujo passo a passo está aqui neste tutorial. O registro deste domínio custou $ 3.oo dólares (na verdade, 3.50 com as taxas), o que não passou de 20 reais considerando o valor do dólar no momento de registro.

Outro local em que você pode registrar domínios com um bom preço é no Namecheap. Eu também fiz um tutorial registrando o domínio cloudtutorials.site e me custou $ 1.16 dólares.

Também existe uma forma de registrar um domínio gratuitamente no Tech Domains ou Name.com por um ano, uma oferta para quem tem o Github Student Developer Pack. Isso mesmo!

Para ser elegível ao Github Student Pack você precisa ser estudante matriculado em um curso superior ou curso que conceda um diploma, tal como ensino médio, ensino secundário, faculdade, universidade. Você pode consultar as condições e ver o passo a passo de como se inscrever aqui.

Após ter se registrado e conseguido o Student Pack, basta acessar o Github Education, logar na sua conta e procurar a oferta:

Depois, você poderá registrar um domínio gratuitamente por um ano. Eu não vou me delongar nesse passo a passo, mas vou deixar um vídeo do YouTube para ilustrar o processo:

Com o domínio registrado em mãos, vamos seguir para a próxima etapa.

2) Criar uma zona hospedada (hosted zone) no Route 53​

Se você optar por registrar seu domínio na AWS, a sua zona hospedada é criada automaticamente. Nesse caso, você não precisa fazer nada.

Caso você utilize um domínio registrado fora da AWS, vai precisar criar uma Zona Hospedada (Hosted zone).

Nesse caso, acesse a console AWS

• Procure por Route 53
• No painel, entre na opção Zonas hospedadas -> clique em Criar zona hospedada

• Insira o domínio no campo Nome do domínio e deixe a opção Zona hospedada pública marcada. Clique em Criar zona hospedada

• A zona será criada com dois registros DNS. Pegue os valores dos registros do tipo NS, copie e salve em um bloco de notas para facilitar o processo. No painel DNS do seu domínio, ou seja, onde você registrou você deverá configurar os registros NS para os da AWS.

3) Subindo um Website estático no S3​

Agora que já temos um domínio em mãos, vamos começar a criar a estrutura de hospedagem do site. Para isso, você deve acessar a console AWS e buscar pelo S3.

No S3, você deverá criar um Bucket S3 para subir os arquivos do website. Para isso, clique no botão "Criar bucket" e preencha as informações:

• Nome do bucket: defina um nome para o seu bucket
• Região AWS: Norte da Virgínia (us-east-1)
• Tipo de Bucket: Propósito geral
• Ao criar o Bucket, desmarque a opção "Bloquear todo o acesso público" para que ele fique disponível na internet. Depois, desça até o final da página e clique em Criar bucket

• Acesse o bucket e clique em Carregar para subir os arquivos do website

• Em seguida, vá para -> Permissões e vá até Política do bucket. Clique em editar e cole a seguinte política* e clique em Salvar alterações:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::Nome-do-Bucket/*"
            ]
        }
    ]
}

• Lembre-se de mudar Nome-do-Bucket para o nome do seu bucket S3. Clique em Salvar alterações

• Por fim, vá até Propriedades -> desça até a opção Hospedagem de site estático -> clique em editar. Habilite a opção de hospedagem de site estático e aponte a página index.html como documento de índice. Clique em Editar hospedagem de site estático

• Marque a opção Ativar; em Tipo de hospedagem marque Hospedar um site estático; em Documento de índice indique o index.html
• Salve as configurações e acesse o endpoint gerado

Ao colar o endpoint no navegador, já podemos ter uma prévia do site.

4) Criando um certificado SSL no AWS Certificate Manager​

Um dos requisitos do nosso projeto é que ele suporte requisições seguras via HTTPS. Para permitir isso, primeiro devemos emitir um certificado SSL/TLS via AWS Certificate Manager.

O Certificate Manager é um serviço que permite a criação, gerenciamento e renovação de certificados SSL/TLS.

• Pesquise por Certificate Manager na console AWS
• Verifique se a sua localização esteja em Norte da Virgínia (us-east-1). Se não estiver, altere para ela
• Clique em Solicitar um certificado
• Em tipo de certificado, deverá estar marcada a opção Solicitar um certificado público. Clique em "Próximo".

• Em Nomes de domínio forneça o nome do seu domínio

• Em Método de validação: escolha o método de validação por DNS

• Mantenha o algoritmo chave como RSA 2048. Clique em Solicitar

Como ele é um domínio registrado na AWS, haverá a opção Criar registros no Route53 - clique nela. Selecione o seu domínio e, em seguida, clique em "Criar registros". Se tudo ocorreu bem, você terá uma mensagem de registro criado com êxito.

5) Criando uma distribuição do CloudFront​

Agora, vamos criar nossa distribuição de conteúdo (CND) no CloudFront.

• Acesse a console AWS e busque pelo CloudFront. Clique em Criar distribuição (Create distribution)

• Em Origin domain, você vai escolher o Bucket S3 em que os arquivos do Website - o CloudFront vai sugerir que você indique o endpoint do website, mas não faça isso
• Em Origin access, marque a opção Origin access control settings, e depois clique no botão Criar nova OAC
• Um pop-up vai abrir para configurar o controle de acesso, apenas clique em Criar (create)
• Em Viewer marque Redirect HTTP to HTTPS (Redirecionar HTTP para HTTPS)
• Em Allowed HTTP methods, deixe marcado "GET, HEAD"
• Em Cache policy and origin request policy (recommended): selecione CachingDisabled

• Mais abaixo, em Web Application Firewall (WAF), marque a opção para Não habilitar nenhuma proteção de segurança (Do not enable security protections)

• Em Settings -> na opção Alternate domain name, escolha Add item e preencha com seu domínio (no meu caso, é cloudtutorials.click)
• Em Custom SSL certificate, escolha o certificado SSL criado no passo anterior
• Na opção Default root object (Objeto raiz padrão), digite index.html
• Crie a distribuição.

Você verá que ao criar a distribuição, uma política de S3 será criada também. Copie a política, e substitua a que está no seu bucket por esta nova.

Assim que a distribuição estiver criada, conseguimos acessar o site pela URL gerada no CloudFront:

6) Apontar o domínio para o Bucket S3​

A peça final do nosso projeto é criar um registro DNS que vai redirecionar o tráfego do domínio para a distribuição do CloudFront.

• No Route 53, acesse a Zona hospedada e clique em “Criar registro”
• Em Tipo de registro, selecione o tipo A e marque a opção "Alias" - os registros do tipo alias permitem rotear o tráfego para serviços internos que provisionamos na AWS
• Em seguida, em Rotear o tráfego para selecione "Alias para distribuição do CloudFront". Vai aparecer a distribuição que criamos na lista.
• No campo da política de roteamento, mantenha o “Roteamento simples” - No Roteamento simples, nós encaminhamos o tráfego para um único recurso
• Clique em “ Criar registros”.

Agora, basta aguardar a propagação dos registros DNS. Não deve demorar muito. Em poucos minutos, você já consegue acessar o site pelo domínio:

7) Registrar seu processo e limpar o ambiente​

É muito importante que você registre o seu processo. Anote, tire prints, crie um vídeo... Use e abuse das formas de reter conhecimento. Depois disso, compartilhe seus resultados com grupos ou no LinkedIn.

Por fim, não esqueça de limpar o seu ambiente:

• Desabilitar e deletar a distribuição CloudFront
• Deletar o certificado SSL criado no Certificate Manager
• Apagar os registros DNS e remover a Zona Hospedada do domínio no Route 53
• Esvaziar o bucket S3 e deletá-lo.

Fim! Espero que esse tutorial possa contribuir com a sua jornada de aprendizados na AWS.

Referências​

• Configurar um site estático usando um domínio personalizado registrado no Route 53
• Tutorial: Subindo um website estático no Amazon S3
• Tutorial: Distribuição de conteúdo com o Amazon CloudFront
• Tutorial: Registrando um domínio no Route 53
• Tutorial: Como configurar o Route 53 como serviço de DNS de um domínio

Este projeto também se encontra no GitHub.

Esse é um tutorial complementar ao de como registrar um domínio no Amazon Route 53.

Aqui vamos pensar em casos em que você já possui um domínio registrado ou quer registrá-lo em outro local, mas pretende usar o Route 53 como zona DNS do seu domínio para centralizar o gerenciamento.

Então, bora para o hands-on!

1) Registrando um domínio (opcional)​

Primeiro, precisamos de um domínio registrado. Se você já tem um domínio, pode pular para a etapa 2 deste tutorial.

Caso não tenha, então vamos fazer o passo a passo do registro de um domínio. Eu particularmente gosto bastante de usar o Namecheap para registrar domínios para fins de testes.

Geralmente, há domínios bem baratos e em preços promocionais - o que fica caro mesmo é o valor da renovação dos domínios. Como eu não renovo esses domínios de testes, o registro por um ano atende bem. A única ressalva é que você vai precisar de um cartão de crédito para fazer o registro.

• Acesse o Namecheap
• Na aba de pesquisa, digite o nome de domínio desejado. Eu irei registrar o cloudtutorials
• Uma lista de extensões vai aparecer (.com, .net, entre outros). Vamos selecionar a extensão .site. O domínio selecionado possui o valor de registro de 1,78 dólares, é o que aparece em retail e que vai ser cobrado. Então, se atente a isso.
• Aqui é importante ressaltar também que o valor de renovação do domínio, isto é, o valor quando expirar, é de $ 23.48 doletas.

• Selecione o domínio e clique em Checkout

• Na página seguinte, está a especificação dos valores. Isso inclui a taxa da ICANN, que é a entidade que gerencia a distribuição de endereços IP e o Sistema de nomes de domínio (DNS).

• Revise os valores - o registro será por somente um ano e a opção Auto-renew deve estar desativada. Cuidado para não contratar nenhum outro serviço extra. Clique em Confirm Order
• Você será direcionado para uma página de login ou então criar uma nova conta. Caso você não tenha uma conta, crie-a com os dados de usuário, senha, nome e e-mail. Um e-mail de confirmação chegará na sua caixa de entrada.
• Após fazer o login, seremos direcionados para a página de pagamento. Há as opções de pagamento (aceitam cartões Visa, MasterCard, Discover, American Express e também pagamento via Paypal). Vou selecionar a opção Secure Card Payment para cartão de crédito e preencher os dados

• Após preencher os dados do cartão, basta clicar em Continue

• Para finalizar o pedido, há uma página de revisão. Fique de olho para não contratar nada que não seja o registro do domínio (há também o serviço de privacidade dos dados no Whois, que é gratuito).

• Clique em Pay Now... E pronto! Em poucos minutos o domínio estará registrado. Você receberá uma mensagem de confirmação na sua caixa de entrada de e-mail.

💡

Caso você seja estudante, você pode registrar um domínio gratuito pelo GitHub usando o GitHub Student Developer Pack - dá uma olhada lá!

2) Criando a Zona hospedada na AWS​

Acesse a console AWS -> busque pelo Route 53 -> e entre na opção Zonas hospedadas. Clique em Criar zona hospedada

Insira o domínio no campo Nome do domínio e deixe a opção Zona hospedada pública marcada. Clique em Criar zona hospedada

A zona será criada com dois registros DNS. Pegue os valores dos registros do tipo NS, copie e salve em um bloco de notas para facilitar o processo:

3) Configurando o DNS​

Logue na sua conta do Namecheap. Na aba lateral esquerda, clique em Domain List

Clique no botão Manage na opção do domínio desejado

Em Domain, vá até a opção Nameservers e selecione Custom DNS

Nos campos em branco, cole os 4 nameservers copiados da Zona hospedada do Route 53:

Após inserir, clique no sinal de "checked" (o "v" verde"). Teremos uma mensagem dizendo que a propagação do DNS pode levar até 48 horas:

4) Testando com uma instância EC2 (opcional)​

Essa parte funciona corretamente após a propagação completa de DNS. No entanto, pode acontecer de funcionar bem antes.

Como o AWS cobra pela zona hospedada, essa etapa será apenas para ilustrar o acesso de uma instância EC2 pelo domínio.

Antes de começar este tutorial, eu deixei uma instância EC2 rodando. Esta parte é opcional, mas você pode criar uma instância - e caso tenha dúvidas em como criar uma instância EC2, você pode seguir este tutorial.

Assim que tiver criado sua instância, copie o IP público.

• Acesse a Zona hospedada do domínio no Route 53

• Clique no botão Criar registro

Insira os seguintes valores:

• Nome do registro: deixe em branco
• Valor: IP público da sua EC2
• TTL: 300
• Política de roteamento: Roteamento simples

5) Limpe o ambiente​

• Encerre a instância EC2 - caso você tenha criado uma

• No Route 53, selecione o registro A e clique em Excluir registro. Em seguida, delete a Zona hospedada

• Volte os Nameservers do seu domínio para o padrão do seu provedor. No caso do Namecheap, deixe em Namecheap BasicDNS

Documentação​

• Tornar o Route 53 o serviço de DNS para um domínio que está em uso

Hoje vamos abordar o Amazon Route 53, um serviço da AWS que atua como DNS e que encaminha a solicitações dos usuários par aplicativos na web.

Porém, primeiro precisamos esclarecer alguns conceitos:

• O que é como funciona o DNS
• O que é um Domínio (ou nome de domínio)
• E que é o Route 53 da AWS

O que é e como funciona o DNS​

A comunicação em redes ocorre, principalmente, por meio de endereços IPs. O IP é um número binário de 32 bits (IPv4) ou 128 bits (IPv6), que deve ser único na comunicação. De forma bem geral, podemos dizer que desde as nossas máquinas pessoais até os servidores que hospedam serviços e sites que acessamos na internet, todos possuem endereços IPs que permitem seu acesso, gerenciamento e comunicação.

Agora imagine que para acessar o Google, tivéssemos que digitar sempre o IP 142.251.128.238 no navegador? Saber um é fácil, mas decorar os IPs de todos os sites que acessamos no dia a dia seria um imenso trabalho. Uma forma de facilitar a comunicação na web se dá pelo DNS.

O Domain Name System (Sistema de nome de domínio), ou simplesmente DNS, é um sistema que traduz "nomes" para endereços IP. Ele funciona quase como uma agenda telefônica do celular, por exemplo, em que temos vários nomes atrelados a uma sequência de números. Isso possibilita acessar os recursos na web sem a necessidade de ficar memorizando IPs.

Não vamos adentrar aqui na estrutura do DNS, mas essa introdução é importante para pensarmos sobre seu funcionamento básico: traduzir nomes de domínio.

O que é um domínio​

Um domínio (domain name) é um nome que identifica um site na internet. Esse nome é composto de uma ou mais extensões, tais como o .com, .br, .org, entre outros. Esse final do domínio é conhecido como top level domain (TDL), ou domínio de primeiro nível.

No caso do domínio deste site - lu.dev.br - o "lu" seria o nome, o ".dev" é uma categoria, também chamada de second level domain (STL) e o ".br" é o TDL.

Os domínios são registrados e organizados em hierarquias. Para que você tenha um domínio, é necessário registrá-lo. Geralmente, o período de vigência de um domínio é 1 ano, depois desse prazo você deverá renová-lo (mas geralmente, os registros e renovações são feitos com durações maiores que um ano). Isso ocorre porque caso uma pessoa ou organização esqueçam de renovar o domínio a tempo, ele voltará ao mercado para ser registrado novamente.

Agora que já sabemos o que é um domínio, podemos entender de modo simples como funciona o fluxo do DNS: você digita o domínio no seu navegador → é realizada uma requisição para o servidor DNS que responde com o IP para o navegador. Voilá, página acessada e carregada.

O que é o Route 53​

E finalmente chegamos nele: o Amazon Route 53!

O Route 53 é um serviço de DNS altamente disponível e escalável, que oferece registro de domínios, resolução de DNS e roteamento de tráfego.

Ele permite:

• Registrar domínios, criar e gerenciar registros DNS;
• Distribuir o tráfego de forma otimizada, baseado em várias políticas de roteamento;
• Integrar-se a outros serviços da AWS;
• Configurar verificações de integridade dos recursos, tais como instâncias EC2 ou Load Balancers. Dessa forma, o Route 53 "desvia" o tráfego de recursos não saudáveis.

Bora para o hands-on!

⚠️

ATENÇÃO: neste tutorial há custos envolvidos💸 Existem taxas para registro e renovação de domínios - seja na AWS ou qualquer outro registrador de domínios - além de outras cobranças de serviços. Portanto, use este tutorial como um guia em relação ao serviço do Route 53.

Passo a passo​

1) Registrando um domínio no Route 53​

Acesse a console AWS e busque pelo Route 53

Na aba lateral esquerda, clique em Domínios registrados

Em seguida, clique no botão Registrar domínios

Para este tutorial, vamos registrar o domínio cloudtutorialscom o TDL .click. Isso porque é o mais barato rsrs... 3,00 dólares ao ano. É só pesquisar pelo domínio no campo Pesquisar domínio

Em seguida, clique em Selecionar e no botão Prosseguir para check-out

Na página seguinte, temos opções de preço, tempo de registro e renovação automática. Você pode aumentar a duração do registro por mais anos se desejar, o que não é nosso caso.

Nós vamos manter por um ano e desativar a opção de renovação automática. Clique em Próximo

Na próxima página, devemos preencher as informações de contato:

• Tipo de contato (se é pessoa, empresa, etc),
• nome,
• telefone,
• e-mail,
• Entre outros dados.

Esses dados ficam visíveis no WHOIS, que é um protocolo que armazena e fornece informações sobre um domínio e seus proprietários.

Por padrão, a proteção de privacidade dos contatos para o domínio já vem ativa (e sem nenhum custo extra, ao contrário do que ocorre com outros registradores de domínio).

Inclusive, se você abrir o terminal e digitar whois cloudtutorials.click, vai ver que está tudo privado:

Continuando: clique em Próximo

Na página Analisar e enviar estará um resumo e o valor total do registro do domínio.

Um detalhe importante é que há uma informação sobre a Taxa de gerenciamento de DNS, na qual falaremos dela mais adiante.

Mais ao final da página, estarão os _Termos e condições. Selecione a caixa para aceitar os termos e clique em _Enviar

A partir disso, a solicitação de registro de domínio estará em análise / andamento.

Em alguns minutos, o domínio é registrado:

2) Verificando a zona hospedada​

No painel do Route 53, clique em Zonas hospedadas

Você vai ver que foi criada a Zona hospedada para o domínio que acabamos de registrar. Podemos dizer que a Zona hospedada (ou Zona DNS) permite centralizar o controle de um domínio, inserindo registros de recursos DNS - que especificam a função e o tipo de roteamento.

Quando registramos um domínio na AWS, o Route 53 automaticamente cria a zona hospedada, e com ela você pode especificar para onde deseja que o tráfego do domínio seja roteado, entre outras configurações.

Como a zona hospedada possui uma taxa cobrada por mês, nós iremos excluí-la a fim de evitar essa cobrança.

Lembrando que para fins de testes, uma zona hospedada que for excluída no Route 53 em até 12 horas após sua criação não é cobrada.

Por hoje é só, pessoal!

Bons estudos!

Documentação​

• O que é o Amazon Route 53?
• Como registrar um nome de domínio com o Amazon Route 53
• Tipos de registro de DNS com suporte - AWS

O desenvolvimento e a manutenção de aplicações modernas exigem rapidez no provisionamento, gerenciamento e entrega da infraestrutura necessária para atender às demandas. Nesse contexto, a infraestrutura tradicional, com processos manuais e demorados para criar ambientes de desenvolvimento, testes e produção, não atende mais aos requisitos dessas aplicações. Assim, a Infraestrutura como Código (IaC - Infrastructure as Code) surge como uma solução para responder ao dinamismo, complexidade e velocidade dos negócios atuais.

Na IaC, a configuração, provisionamento e administração da infraestrutura estão codificados em arquivos de texto, que podem ser versionados em sistemas de controle de versão, como o Git. Em vez de realizar essas atividades manualmente, a IaC permite um processo automatizado e controlado.

Na AWS, o serviço que possibilita criar e replicar uma infraestrutura a partir de um código é o Amazon CloudFormation. Ele permite que a infraestrutura seja replicada várias vezes, oferecendo um serviço gratuito, em que o pagamento ocorre apenas pelos recursos provisionados.

Dois conceitos importantes do CloudFormation são:

• Template: No AWS CloudFormation, um template é um arquivo em formato JSON ou YAML que descreve a infraestrutura desejada, incluindo recursos como instâncias EC2, redes e permissões, de forma declarativa e reutilizável.
• Stack: A partir do template, uma stack é criada, representando a implementação prática dos recursos definidos. Em outras palavras, a stack é o conjunto dos recursos ativos gerenciados em conjunto.

Podemos dizer, de forma resumida, que o CloudFormation possibilita a criação, atualização e exclusão de infraestrutura de forma automatizada, garantindo consistência e controle na nuvem.

Depois dessa breve introdução, vamos colocar a mão na massa!

Hands-on​

1) Criando o template​

Abra um editor de texto (VsCode, Notepad, Sublime Text, ou outro de sua preferência) e copie o trecho abaixo. Salve em formato .yaml

Resources:
  TesteBucketS3:
    Type: AWS::S3::Bucket
    Properties:
      AccessControl: Private
      BucketName: `<nome_do_bucket>`

Se preferir, você pode baixar o arquivo também:

Download

Nesse template, temos as seguintes partes:

• Resources - indica que serão especificados os recursos da infraestrutura na AWS;
• TesteBucketS3 - é o indicador lógico do recurso, um nome único para referenciar esse recurso dentro do template caso fosse necessário - poderia ser qualquer outro nome;
• Type - define o tipo do recurso que será criado;
• AWS::S3::Bucket - é o nome do recurso, no caso é o Bucket S3;
• Properties - define as configurações específicas (propriedades) do Bucket S3;
• AccessControl - é uma das propriedades do bucket, que define o acesso somente por usuários autenticados e com permissão para tal;
• BucketName - é o nome do bucket que será criado.

Ah, em BucketName lembre-se de trocar o <nome_do_bucket> para um nome de sua preferência. E também lembre que o nome para um Bucket S3 deve ser único e global na AWS.

Continuando...

2) Criar uma stack​

Acesse a console AWS e procure por CloudFormation

Clique em Criar pilha

Para criar a pilha (stack), vamos selecionar a opção Escolher de um modelo existente, e especificar esse modelo marcando a opção Fazer upload de um arquivo de modelo

Em seguida, vamos escolher o arquivo .yaml e fazer upload. Veja que será criado outro Bucket S3 para armazenar o modelo do CloudFormation:

Clique em Próximo. Em seguida, dê um nome para a pilha e clique em Próximo novamente.

Clique em Próximo até chegar na página Revisar e Criar

Desça até ao final da página e clique em Enviar. Não tem muito segredo, o CloudFormation vai apresentar os eventos da criação da Stack e fazer o rollbak (reverter) caso ocorra algum problema.

Se tudo der certo, vai aparecer o status CREATE_COMPLETE

Para conferir se o Bucket foi criado, você pode acessar a Pilha -> Recursos

3) Limpando o ambiente​

Para limpar o ambiente, você precisa selecionar e exluir a pilha

Confirme a exclusão. Em seguida, acesse o S3 e exclua o bucket criado para armazenar o modelo. Antes de excluir, você vai receber um alerta para esvaziar o bucket. Confirme e exclua tudo.

Prontinho, ambiente limpo 🧹

Bons estudos!

Documentação​

• O que é o AWS CloudFormation?
• O que é infraestrutura como código?

Os bancos de dados não relacionais são bancos que armazenam os dados em um formato diferente das tabelas relacionais. A construção desse tipo de banco de dados permite criar aplicações modernas com mais flexibilidade e liberdade, realizando consultas e pesquisas mais rápidas.

Entre os tipos de NoSQL mais comuns estão os bancos de documentos como o MongoDB; de colunas, como o Cassandra; de grafos, como Neo4j; e de chave-valor como o Redis.

Exemplo de estrutura de dados em JSON, comumente usado no MongoDB, Firebase, entre outros

Nesse tutorial, vamos conhecer um pouco do Amazon DynamoDB, um serviço de banco de dados não relacional (NoSQL) rápido, com escalabilidade e baixa latência.

O DynamoDB é serveless, o que significa que você não precisa gerenciar a infraestrutura subjacente a ele. É gerenciado pela AWS, ou seja, a AWS cuida dos aspectos operacionais e da infraestrutura, e você somente precisa se ocupar dos seus dados e o desenvolvimento da sua aplicação.

No DynamoDB, os dados são armazenados no modelo de chave-valor, em que é necessário indicar uma _chave primária, utilizada para identificar um item na tabela. Você também pode especificar uma chave secundária_, fornecendo flexibilidade na consulta dos dados.

Passo a passo​

1) Criando uma tabela​

Acesse a console AWS e busque por DynamoDB. Clique em Criar tabela

Nas configurações da tabela, insira:

• Nome da tabela: Clientes
• Chave primária (Chave de partição): id_cliente (formato String)

Vá até ao final da página e clique em Criar tabela

2) Inserindo dados na tabela​

Assim que a tabela for criada, clique em cima dela para acessá-la:

Em seguida, clique em Explorar itens da tabela

Mais abaixo, clique em Criar item

Clique em Adicionar novo atributo e escolha o formato String

Insira o valor 1 para o atributo id_cliente. E crie os seguintes itens, todos no formato String, com os valores que você preferir:

• nome
• sobrenome
• cidade
• estado

Assim que tiver completado os itens, clique no botão Criar item.

Veja que o item foi criado com sucesso:

Agora, crie mais outro item com os mesmos campos e id_cliente com valor 2, como na imagem:

Veja agora que temos dois itens criados:

3) Lendo os dados da tabela​

Na mesma página da tabela, em Verificar ou consultar itens, selecione o campo Consulta, insira o valor 2 em id_cliente (Chave de partição), e clique em Executar

Veja que somente o item 2, da cliente Maria, foi retornado:

O legal é que você pode realizar diversas operações com o banco de dados e as tabelas do DynamoDB via CLI ou SKD.

4) Limpe o ambiente​

Para limpar seu ambiente, basta selecionar a tabela e clicar em Excluir. Confirme a exclusão e pronto, tudo limpo!

Bons estudos!

Documentação​

• O que é o Amazon DynamoDB?
• O que é NoSQL?
• AWS Command Line Interface
• O que é um SDK?

Um banco de dados relacional é um sistema que gerencia dados organizados em tabelas, facilitando a relação entre essas informações. As tabelas são compostas por linhas e colunas, onde as linhas representam registros únicos e as colunas representam atributos dos dados.

Fonte: https://logap.com.br/blog/banco-de-dados-relacional/

Bancos de dados relacionais utilizam a linguagem SQL (Structured Query Language) para manipulação e consulta de dados. Além disso, existem sistemas de gerenciamento de banco de dados (SGBDs) que permitem acessar e manipular dados por meio de uma interface ou software. Os SGBDs mais populares são:

• MySQL
• SQLServer
• PostgreSQL
• Microsoft SQL Server
• Oracle Database

Na AWS, temos o Amazon RDS (Relational Database Service), que é um serviço de banco de dados relacional com recursos de escalabilidade, automatização de patches, provisionamento de hardware e backup na Nuvem AWS. O Amazon RDS utiliza instâncias gerenciadas pela AWS e permite criar bancos de dados com os seguintes mecanismos:

• PostgreSQL
• MySQL
• MariaDB
• Oracle
• SQL Server
• Aurora (AWS)

Outro ponto interessante é que o Amazon RDS permite a criação de "Read Replicas" — cópias de leitura do banco de dados com replicação assíncrona. Esse recurso é útil, por exemplo, para aplicações com alta carga de leitura de dados, pois permite reduzir a carga do banco de dados principal, transferindo essas consultas para a réplica de leitura. Essa é uma estratégia muito eficaz de Alta Disponibilidade (High Availability).

Sem mais delongas, vamos para o nosso hands-on!

Passo a Passo​

1) Criando a instância RDS​

Acesse a console AWS e busque pelo RDS

Clique no botão Criar banco de dados

Na página seguinte, deixe marcado o método de Criação padrão e em Opções do mecanismo, selecione MySQL

Mais abaixo, em Modelos, selecione o Nível gratuito - afinal, não queremos nenhuma cobrança indesejada.

Em Configurações, especifique:

• Identificador da instância de banco de dados: é o nome da sua instância. Deixei como database-1
• Nome do usuário principal: admin
• Gerenciamento de credenciais: marque autogerenciada
• Senha principal: crie uma senha (da qual você possa se lembrar) com no mínimo 8 caracteres

Desça até a aba Conectividade, e em Acesso público marque Sim

(P.S.: Essa não é a configuração ideal para acessarmos um banco de dados externamente, mas para fins didáticos ela vai nos atender no momento)

Um pouco mais abaixo, ainda em Conectividade, marque Criar novo para criar um novo Grupo de Segurança e dê um nome a esse grupo.

Desça até ao final da página e clique em Criar banco de dados.

2) Verificando a instância​

Pode levar alguns minutos até que a instância RDS esteja disponível. Assim que estiver, clique na instância.

Assim como ocorre no EC2, você vai se deparar com uma série de informações sobre a instância. O que nos interessa aqui é o Endpoint, que é o ponto de conectividade da nossa instância.

Em Segurança e conexão, copie o Endpoint

3) Testando a conexão no MySQL Workbench​

Agora, vamos usar o MySQL Workbench apenas para testar a conexão externa com a instância. Eu escolhi o Workbench, mas você pode usar outro software como o DBeaver, por exemplo.

Caso não tenha o Workbench instalado, você pode baixá-lo aqui.

Abra o Workbench e clique no + para criar uma nova conexão:

Na janela que abrir, insira as informações:

• Connection Name: dê um nome para sua conexão
• Connection Method: deixe marcado como Standard (TCP/IP)
• Hostname: cole o endpoint da sua instância
• Username: admin (ou outro, caso você tenha alterado ao criar a instância RDS)
• Password: clique em Store in Vault e insira a senha do banco de dados

Depois que preencher os campos, clique em Test Connection

Se tudo der certo, você vai receber uma mensagem de que a conexão foi realizada com sucesso. Clique em "OK".

Você pode abrir a conexão com o RDS e se divertir criando tabelas, inserido dados, fazendo consultas, etc. O céu é o limite (na verdade, o Free Tier é o limite).

Ah, lembre-se de limpar o seu ambiente, ou seja, de excluir sua instância RDS.

Bons estudos!

Documentação​

• O que é o Amazon RDS
• Amazon RDS para MySQL
• Réplicas de leitura do Amazon RDS

As Redes de Distribuição de Conteúdo (Content delivery network - CDN) são compostas por servidores espalhados geograficamente que geralmente armazenam conteúdo da web em cache e distribuem esse conteúdo para os usuários. As CDNs permitem que o usuário acesse o conteúdo a partir do servidor mais próximo a ele, tornando a experiência mais aprazível, por assim dizer - já que haverá baixa latência e maior velocidade de carregamento dos dados.

A AWS também possui um serviço de CDN, chamado de Amazon CloudFront, utilizado inclusive pela Netflix. Esse serviço permite distribuir conteúdos estáticos e dinâmicos na web (websites, imagens, vídeos, dados, entre outros). Para isso, o CloudFront faz uso das Edge Locations (Pontos de Presença), que atuam como servidores de cache espalhados pelo mundo, acelerando a entrega dos conteúdos e melhorando a experiência dos usuários.

No CloudFront, a entrega do conteúdo se baseia na localização geográfica do usuário, na origem da página e também na localização do servidor de entrega do conteúdo.

Além disso, o CloudFront:

• Trabalha em conjunto com outros serviços - S3, WAF, Shield, Route 53 e Certificate Manager;
• Emite um certificado SSL/TLS público;
• Mantém o acesso seguro e criptografado;
• Redireciona o tráfego HTTP para HTTPS;
• Pode restringir o acesso do conteúdo por meio de vários recursos;
• Entre outras funções.

Sem mais delongas, vamos para o hands-on! Ah, esse tutorial é uma continuação do post "Subindo um website estático no Amazon S3" - caso você não tenha um bucket S3 configurado para servir um site estático, dá uma olhadinha no post.

Passo a Passo​

1) Criando a distribuição do CloudFront​

• Acesse a console AWS e busque pelo CloudFront. Clique em Criar distribuição (Create distribution)

• Em Origin domain, você vai escolher o Bucket S3 em que os arquivos do Website - o CloudFront vai sugerir que você indique o endpoint do website, mas para este tutorial queremos que somente o CloudFront tenha acesso ao bucket (e, por consequência, iremos alterar a política de acesso do S3).
• Em Origin acess, marque a opção Origin access control settings, e depois clique no botão Criar nova OAC

• Um pop-up vai abrir para configurarmos esse controle de acesso, apenas clique em Criar (create)

Inclusive, vai aparecer um aviso dizendo que temos que atualizar a políca do Bucket... O que faremos depois.

• Agora, desça a página até a opção Web Application Firewall (WAF). Deixe o WAF desabilitado.

• Mais abaixo, em Configurações (Settings), especifique a página index.html como objeto raiz para que o CloudFront saiba qual objeto do S3 ele deve responder

• Desça até ao final da página e clique em Criar distribuição

2) Modificando a política do bucket S3​

Após criar a distribuição, uma mensagem irá aparecer na tela, indicando que você deve copiar e alterar a política (policy) do Bucket. Copie a política:

Acesse o bucket do seu site, vá em Permissões -> Política do Bucket -> e clique em Editar

Remova a política que estava anteriormente - na qual configuramos no tutorial de Website estático no S3 - e cole a nova política de acesso. Clique em Salvar alterações

Volte lá no CloudFront, clique na distribuição e copie o nome de domínio (domain name). Cole no navegador e dê enter:

Agora, o site está acessível pelo domínio do CloudFront. Se você tentar acessá-lo com a URL gerada pelo S3, não vai conseguir:

3. Limpando o ambiente

Para limpar o seu ambiente, você precisa:

• Desabilitar a Distribuição no CloudFront - desabilite e aguarde alguns minutos. Somente depois que a opção Deletar estará disponível para ele ser excluído

• Você também pode excluir os arquivos e o bucket S3, caso queira. Mas é opcional.

Bons estudos!

Documentação​

• O que é o Amazon CloudFront?
• Pontos de presença