2 publicações com a etiqueta "Terraform"

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)

Uma das principais dores de quem está estudando Cloud AWS é não conseguir aplicar o conteúdo na prática. É fato que nem sempre podemos ter uma conta da AWS com um cartão de crédito disponível, ou mesmo ter recursos financeiros para subir uma infraestrutura com os serviços necessários. E a gente sabe que não há nada melhor do que aplicar o conteúdo, experimentar, "quebrar" as coisas e entender como tudo funciona. Porém, fica o dilema de não ter acesso ou de praticar correndo o risco de ter infelizes surpresas na fatura do cartão no fim do mês.

Para resolver esse problema, existe uma ferramenta muito legal e que tem sido muito útil nos meus labs, permitindo emular alguns dos principais serviços da AWS e interagir através da linha de comando (CLI), SDKs e IaC: o LocalStack.

O objetivo deste artigo é apresentar o LocalStack e como ele pode ser utilizado junto com o Terraform para ambientes de estudo mais próximos dos cenários reais, mas sem pesar no bolso.

Então, bora lá conhecer essa ferramenta sensacional?

O que é e como funciona o LocalStack?​

O LocalStack é uma ferramenta gratuita que emula serviços da AWS de forma local, rodando em um container Docker. Isso permite interagir e testar serviços como EC2, S3, VPC, CloudWatch, SQS, Route 53, ACM, entre outros. Com ele, podemos criar ambientes de teste com a mesma estrutura (inclusive de código!) que faríamos caso estivéssemos usando a própria AWS.

Com ele, fazemos com que a API do LocalStack responda no lugar da API da AWS, permitindo realizar testes de Infraestrutura como Código (IaC), validar pipelines CI/CD, scripts de automação, etc. Não é massa?

Agora que já temos um overview sobre o LocalStack, vamos partir para a instalação.

Instalando o LocalStack​

Para utilizar o LocalStack, você precisa ter instalado:

• Docker
• AWS CLI

Para não deixar este artigo muito longo, optei por não detalhar a instalação dos pré-requisitos. Um ponto importante é que vamos usar a AWS CLI, e por isso precisamos configurar com as credenciais para o LocalStack.

Para isso, após instalar a AWS CLI, rode o comando aws configure e preencha com as seguintes informações:

• AWS Access Key ID: test
• AWS Secret Access Key: test
• Default region name: us-east-1
• Default output format: json

AWS configure - exemplo do comando preenchido com Key Id, secret acess key, default region e output format

Feito isso, vamos seguir com a instalação, porém, há um detalhe importante: a partir de março de 2026, o LocalStack vai deixar de manter uma versão Community realmente ativa e vai exigir autenticação (login/token) para usar a imagem principal (localstack/localstack:latest).

Portanto, antes de realmente instalar, é necessário:

1. Criar uma conta usando e-mail ou autenticação via Google ou GitHub;

2. Clicar no link de ativação, enviado por email

3. Preencher os dados para iniciar uma versão de testes do Pro durante 15 dias (sem necessidade de cadastrar o cartão de crédito):

Tela de login do LocalStack para iniciar a versão trial - com campos para preencher o nome e botão "Start Trial"

Após preencher, seremos direcionados para as instruções de download, instalação e configuração do LocalStack:

Página com as instruções de instalação, configuração e deploy do Localstack

Nesse tutorial, vou seguir com o padrão Linux, então, copiei o link do binário e segui com os comandos:

## Baixando o binário

curl --output localstack-cli-4.13.1-linux-amd64-onefile.tar.gz \
    --location https://github.com/localstack/localstack-cli/releases/download/v4.13.1/localstack-cli-4.13.1-linux-amd64-onefile.tar.gz

## Extrair o binário para /usr/local/bin
sudo tar xvzf localstack-cli-4.13.1-linux-*-onefile.tar.gz -C /usr/local/bin

## Validar a versão
localstack --version

## Configurar o token (está no passo 2 da página Getting Started)
localstack auth set-token `<use_seu_token_aqui>`

Com tudo ok, vamos dar um start no LocalStack com o comando:

## Rodar o LocalStack em segundo plano
localstack start -d

O comando acima vai iniciar uma instância do Localstack no localhost, utilizando a porta 4566, dessa forma aqui:

Exemplo do Localstack startado, com a informação de que está "running"

Para testar se tudo deu certo mesmo, vamos simular a criação de um Bucket S3:

## Setar LocalStack Endpoint URL:
export LOCALSTACK_ENDPOINT=http://localhost:4566

## Criar o Bucket
aws --endpoint-url=$LOCALSTACK_ENDPOINT s3 mb s3://meu-primeiro-bucket

## Listar o Bucket
aws --endpoint-url=$LOCALSTACK_ENDPOINT s3 ls

E veja ele aí, Bucker criado e listado:

Exemplo com a saída do comando para listar o Bucket, retornando o meu-primeiro-bucket como saída do comando

Acessando o dashboard​

Além de verificar e interagir com os recursos via CLI, também podemos usar uma interface gráfica (GUI) que nos ajuda a ter uma percepção mais "real" do que estamos construindo.

Para acessar esse dashboard, vá para a mesma página em que criamos a conta e pegamos os dados do token, clique na aba lateral esquerda, em Instances... E voilá! Os recursos disponíveis estão todos aí:

Página principal do dashboard do LocalStack, com UI com mais de 20 serviços listados, desde serviços de App Integration (API Gateway, SQS, MQ, entre outros), Compute (EC2, Lambda, ECS, entre outros), Storage (S3, Backup, entre outros) e diversos outros serviços AWS.

Agora que fizemos e acontecemos no LocalStack, você acha que acabou? Segura aí, que ainda tem mais mão na massa: vamos subir um website estático usando o Terraform!

Criando a infra LocalStack com Terraform​

Primeiro, é necessário ter o Terraform instalado. Então, vou deixar aqui a documentação do Terraform para seguirem com a instalação, conforme o seu sistema operacional. Após instalação, use o comando terraform --version para validar a versão instalada. Feito isso, indico criar um diretório a parte para começarmos com esse projeto.

Dentro do diretório, crie os arquivos index.html e error.html, que serão as páginas dos website. Caso você não tenha arquivos para subir, pode usar o conteúdo os arquivos a seguir:

index.html

`<!DOCTYPE html>`
`<html lang="pt-br">`
`<head>`
    `<meta charset="UTF-8">`
    `<title>`Site estático com Terraform + LocalStack`</title>`
`</head>`
`<body style="margin:0; font-family: Arial, Helvetica, sans-serif; background-color:#0f172a; color:#f1f5f9; display:flex; align-items:center; justify-content:center; height:100vh;">`

    `<div style="text-align:center; background-color:#1e293b; padding:40px; border-radius:12px; box-shadow:0 10px 25px rgba(0,0,0,0.3); max-width:600px;">`
        `<h1 style="color:#38bdf8; margin-bottom:20px;">`
            Chegaaaa mais... Deploy realizado com sucesso!
        `</h1>`

        `<p style="font-size:18px; line-height:1.6;">`
            Este site estático foi provisionado utilizando 
            `<strong>`Terraform`</strong>` para criar um bucket S3 
            e publicado localmente com `<strong>`LocalStack`</strong>`.
        `</p>`

        `<p style="margin-top:20px; font-size:16px; color:#94a3b8;">`
            Infraestrutura como Código + Ambiente AWS Local = 
            desenvolvimento mais rápido, seguro e econômico. Show, né?
        `</p>`

        `<div style="margin-top:30px; padding:10px; background-color:#0ea5e9; border-radius:8px; font-weight:bold;">`
            🌍 Ambiente: LocalStack (AWS Emulator)
        `</div>`
    `</div>`

`</body>`
`</html>`

error.html

`<!DOCTYPE html>`
`<html lang="pt-br">`
  `<head>`
    `<meta charset="utf-8">`
    `<title>`404`</title>`
  `</head>`
  `<body style="margin:0; font-family: Arial, Helvetica, sans-serif; background: linear-gradient(135deg, #1e293b, #0f172a); color:#f1f5f9; display:flex; align-items:center; justify-content:center; height:100vh;">`

    `<div style="text-align:center; background-color:#1e293b; padding:40px; border-radius:12px; box-shadow:0 10px 25px rgba(0,0,0,0.4); max-width:400px; width:90%;">`

      `<h1 style="margin:0 0 20px 0; font-size:48px; color:#f86538;">`
        Ops... Deu ruim!
      `</h1>`

      `<p style="font-size:18px; margin:0; color:#cbd5e1;">`
        404. Algo de errado não está certo.
      `</p>`

    `</div>`

  `</body>`
`</html>`

Em seguida, vamos criar um arquivo chamado providers.tf, com o seguinte conteúdo:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  access_key = "test"
  secret_key = "test"
  region     = "us-east-1"

  s3_use_path_style           = false
  skip_credentials_validation = true
  skip_metadata_api_check     = true

  endpoints {
    s3      = "http://s3.localhost.localstack.cloud:4566"
    iam     = "http://localhost:4566"
    sts     = "http://localhost:4566"
  }
}

Aqui, estamos informando ao Terraform qual versão do provider AWS que ele deve usar, setando a versão como 5.x.; e que ele deve se conectar com o LocalStack, e não para a AWS real. Setamos também credenciais fictícias para facilitar a conexão com o ambiente do simulador.

Em seguida, vamos criar as variáveis reutilizáveis que serão utilizadas no projeto, através do arquivo variables.tf, com o seguinte conteúdo:

variable "bucket_name" {
  description = "Name of the s3 bucket"
  type        = string
  default     = "mywebsites3"
}

variable "tags" {
  description = "Tags to set on the bucket"
  type        = map(string)
  default     = {}
}

Basicamente, definimos que podemos alterar tanto o nome do Bucket quanto as tags, tornando esse mini projeto mais organizado e flexível. No bucket_name, foi definido um parâmetro default para o nome do Bucket, apenas para facilitar o processo. O ideal

Agora, vamos criar um outro arquivo main.tf que vai ser responsável pela criação dos recursos, ou seja, do Bucket S3, das configurações de website estático, da policy e fazer o upload dos arquivos HTML.

## Criar o bucket
resource "aws_s3_bucket" "s3_bucket_tf" {
  bucket = var.bucket_name
  tags = merge(
    var.tags, {
      Name = "${var.bucket_name}-static-website"
    }
  )
}

## Configurar o bucket para hospedar um site estático
resource "aws_s3_bucket_website_configuration" "s3_static_website_config" {
  bucket = aws_s3_bucket.s3_bucket_tf.id

  index_document {
    suffix = "index.html"
  }

  error_document {
    key = "error.html"
  }
}

## Bucket policy e ACL
resource "aws_s3_bucket_acl" "s3_bucket_acl" {
  bucket = aws_s3_bucket.s3_bucket_tf.id
  acl    = "public-read"
}

resource "aws_s3_bucket_policy" "s3_bucket" {
  bucket = aws_s3_bucket.s3_bucket_tf.id

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid       = "PublicReadGetObject"
        Effect    = "Allow"
        Principal = "*"
        Action    = "s3:GetObject"
        Resource = [
          aws_s3_bucket.s3_bucket_tf.arn,
          "${aws_s3_bucket.s3_bucket_tf.arn}/*",
        ]
      },
    ]
  })
}

## Upload dos arquivos para o bucket
resource "aws_s3_object" "object_www" {
  depends_on   = [aws_s3_bucket.s3_bucket_tf]
  for_each     = fileset("${path.root}", "*.html")
  bucket       = var.bucket_name
  key          = basename(each.value)
  source       = each.value
  etag         = filemd5("${each.value}")
  content_type = "text/html"
  acl          = "public-read"
}

Sobre os blocos de recursos, o bloco aws_s3_object usa a função fileset para mapear os arquivos HTML que estiverem na pasta raiz do projeto. Por isso, lembre-se de mantê-los no mesmo diretório que os arquivos do Terraform. Além disso, o parâmetro etag garante que o Terraform detecte mudanças no conteúdo dos arquivos.

E por fim, vamos criar um arquivo chamado outputs.tf que vai conter informações de saída, tais como o ARN do Bucket e o endpoint do website.

output "arn" {
  description = "ARN of the bucket"
  value       = aws_s3_bucket.s3_bucket_tf.arn
}

output "bucket_name" {
  description = "Name (id) of the bucket"
  value       = aws_s3_bucket.s3_bucket_tf.id
}

output "website_endpoint" {
  value = aws_s3_bucket_website_configuration.s3_static_website_config.website_endpoint
}

Agora, execute os comandos:

## Inicializar o projeto
terraform init

## Formatar os arquivos
terraform fmt

## Validar a sintaxe e configurações
terraform validate

## Mostar o plano de execução
terraform plan

## Aplicar as mudanças 
terraform apply -- auto-approve

Após o apply, acesse o endpoint no navegador, usando esta URL: http://mywebsites3.s3-website.localhost.localstack.cloud:4566/

E olha ele aí!

Página principal com mensagem de sucesso. Fundo escuro, com título escrito "Chegaaaa mais... Deploy realizado com sucesso!"

Inclusive, com a página de erro também:

Página com erro 404. Fundo escuro, com título em vermelhor escrito "Ops.. Deu ruim!". Subtítulo em cor branca, escrito "404. Algo de errado não está certo."

Massa demais, não é? Para finalizar, vamos limpar o nosso ambiente, removendo os recursos usando o comando terraform destroy --auto-approve

Simples assim.

Extra: como usar o LocalStack for Students​

Na versão free do LocalStack, há 30 serviços disponíveis para brincar à vontade. No entanto, a medida em que os estudos e projetos vão ficando cada vez mais complexos, isso pode não ser o bastante. A mão de subir um EKS chega até a arder...

Infelizmente, a questão financeira pode ser uma pequena barreira aqui, mas há uma luz no fim do túnel: o LocalStack for Students!

Caso você tenha uma conta do GitHub Student Developer Pack, você tem acesso a diversos recursos para além da licença free. Os recursos incluem: AWS Glue, EMR, Lake Formation, Amazon MQ, Cost Explorer, Elastic Beanstalk, ECS, EKS, entre outros. Tem muita coisa mesmo.!Além disso, você tem 1.000 créditos mensais em CI/CD para integrar e implantar continuamente desenvolvimentos locais.

Não é massa? Caso tenha alguma dúvida sobre como configurar o GitHub Student Developer Pack, escrevi aqui um artigo para auxiliar.

Palavras finais​

Com este artigo, quis mostrar para vocês uma pequena parte do que é possível fazer com o LocalStack, aliado a outras ferramentas, tais como o Terraform.

Por motivos didáticos, resolvi não utilizar o tflocal e o awslocal, que são wrappers que automatizam apontamento dos endpoints para o ambiente local. Optei pela configuração manual para entendermos melhor como a comunicação entre as ferramentas funciona.

Espero que este pequeno guia ajude você a praticar Cloud sem medo e sem receio de custos inesperados.

Bons estudos e até a próxima!

Referências​

• LocalStack
• LocalStack for Students
• GitHub Student Developer Pack
• LocalStack Doc - Licensing & Tiers
• Terraform Documentation
• Simulando AWS com LocalStack e Terraform: Guia completo - vídeo do Jeferson Fernando da LinuxTips
• Repositório terraform-101 - feito a partir da live com o Jeferson e Gomex pela LinuxTips
• Host a static website locally using Simple Storage Service (S3) and Terraform with LocalStack