Forem: Isaque Alcantara

Arara Watch: a serverless global disaster monitor, developed with technology from Google Gemini, AWS, OpenWeather and NASA.

Isaque Alcantara — Mon, 20 Apr 2026 04:24:53 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

For this Earth Day Challenge, I wanted to build something that bridges the gap between raw climate data and actionable human insight. When extreme weather events occur, raw numbers (like humidity percentages or temperature drops) aren't enough. People need context.

I built Arara Watch, a Global Disaster Monitor. It takes real-time climate and satellite data and transforms it into an actionable Threat Matrix for natural disasters (wildfires, floods, extreme heat/cold, landslides).

To celebrate Earth Day, the system doesn't just look at the dangers; it also generates an AI-powered Ecological Overview of any selected region on Earth, highlighting its vegetation type, natural attractions, and overall ecosystem conservation status.

Demo

🔗 Live Application: Arara Watch

Code

💻 GitHub Repository: isaque21/dev_earth_day_challenge

How I Built It

To ensure the application could handle sudden spikes in traffic (like during an actual natural disaster) without costing a fortune, I designed a 100% Serverless architecture deployed via Terraform.

The Serverless Foundation

Frontend: Vanilla HTML/CSS/JS hosted on an Amazon S3 Bucket and distributed globally via CloudFront. I used a Glassmorphism UI design over a high-resolution nature background to fit the Earth Day theme.
Backend: An Amazon API Gateway routing requests to an AWS Lambda function (Python 3.12).
Data Ingestion: The Lambda function fetches real-time weather from the OpenWeather API and active fire hotspots from NASA's FIRMS satellite data.

The Core Challenge: Rate Limiting & Latency

Integrating Large Language Models in real-time mapping applications usually leads to API rate limits (like the 429 Too Many Requests error).

To solve this, I implemented a Proximity Caching Strategy using Amazon DynamoDB. When a user clicks on the map, the Lambda function rounds the coordinates to two decimal places (creating a "coverage radius" of roughly 1.1km) and uses it as a Global Secondary Index (GSI) key.

If another user checked that same neighborhood in the last 30 minutes, the API bypasses the external requests and returns the cached analysis instantly. This dropped my API calls by over 80% and reduced response times from 8 seconds to just 200 milliseconds for cached locations! 🚀

Prize Categories

I am submitting this project for the Best Use of Google Gemini category.

Instead of using the AI just for chatbot-style text generation, I utilized Google Gemini 2.5 Flash as a structured backend microservice.

By using strict prompt engineering, I instructed Gemini to act as both a Civil Defense Analyst and an Ecological Expert. The prompt feeds the raw NASA and OpenWeather data into the model and forces it to return a strictly formatted JSON response. This allows the Vanilla JS frontend to seamlessly map the AI's cognitive output directly into the DOM to render the colored Threat Matrix and the Ecological Overview cards without any parsing errors.

Amazon S3 Files: Tudo o que Você Precisa Saber Sobre o Novo Armazenamento de Arquivos

Isaque Alcantara — Fri, 17 Apr 2026 14:32:42 +0000

Sumário

Introdução: O Fim da Escolha Binária entre Objeto e Arquivo
O Paradigma Histórico: Por que isso era um problema?
O que é o Amazon S3 Files? Uma visão geral do novo serviço
Mergulho na Arquitetura: Como o S3 Files Funciona por Baixo dos Panos
- 1. Camada de Metadados com Latência Submilissegundo
- 2. Tiering Inteligente e Cache
- 3. Modelo “Stage and Commit” com Sincronização Bidirecional
Casos de Uso: Onde o S3 Files se Destaca
- Preparação de Dados para Machine Learning e IA
- Agentes de IA e Pipelines Colaborativos (Agentic AI)
- Modernização de Aplicações (Lift-and-Shift)
- Computação de Alto Desempenho (HPC) e Genômica
- AWS Lambda e Processamento Serverless de Arquivos Grandes
Comparação Detalhada: S3 Files vs. Outros Serviços de Armazenamento da AWS
- S3 Files vs. Amazon S3 Standard (API HTTP)
- S3 Files vs. Amazon EFS (Elastic File System)
- S3 Files vs. Amazon EBS (Elastic Block Store)
- S3 Files vs. Amazon FSx (Lustre, Windows, NetApp, OpenZFS)
Governança, Segurança e Conformidade
Como Iniciar e Integrar com Seus Workloads
Conclusão: O Futuro do Armazenamento de Dados na Nuvem

Introdução: O Fim da Escolha Binária entre Objeto e Arquivo

O mundo da computação em nuvem acaba de presenciar um dos seus marcos mais importantes dos últimos anos. Em 7 de abril de 2026, a Amazon Web Services anunciou o lançamento do Amazon S3 Files, um produto inovador que promete revolucionar a forma como arquitetos de software, engenheiros de dados, equipes de Inteligência Artificial e desenvolvedores interagem com seus sistemas de armazenamento na nuvem.

Por quase duas décadas, o ecossistema de TI foi obrigado a fazer uma escolha binária que, muitas vezes, acabava sendo limitante. De um lado da equação estava o armazenamento de objetos, como o Amazon S3, que oferecia uma durabilidade incomparável de 11 noves (99,999999999%), custo extremamente baixo, escalabilidade praticamente infinita e ampla integração com o mundo web por meio de APIs REST.

Do outro lado, tínhamos o armazenamento baseado em sistemas de arquivos (como NFS): suporte nativo ao padrão POSIX, operações interativas com baixa latência, controle de bloqueio de arquivos e compatibilidade com aplicações legadas e ferramentas de linha de comando.

Até agora, se fosse necessário aproveitar os benefícios de ambos, era preciso construir arquiteturas complexas. Com a chegada do Amazon S3 Files, essa dicotomia histórica chega ao fim. A AWS criou uma ponte que permite tratar buckets do S3 como sistemas de arquivos completos.

O Paradigma Histórico: Por que isso era um problema?

Para entender a importância desse lançamento, é preciso olhar para as dores que as equipes de engenharia enfrentam no dia a dia. Aplicações modernas e ferramentas de Machine Learning frequentemente dependem da semântica de sistemas de arquivos. Uma simples linha como open('/data/dataset.csv', 'r') em Python pressupõe que será possível interagir de forma transparente com bibliotecas de processamento de dados. Conseguir listar diretórios com comandos como ls ou inspecionar metadados com stat também é um comportamento esperado.

Como o Amazon S3 é um serviço de armazenamento de objetos baseado em operações HTTP (PUT, GET, DELETE), ele não oferecia esse tipo de funcionalidade de forma nativa. Com o tempo, desenvolvedores passaram a depender de três abordagens principais como solução alternativa:

Processo de Download/Upload: Os dados permaneciam no S3, mas sempre que era necessário processá-los, os arquivos precisavam ser baixados para um armazenamento local (ou para serviços como o Amazon EFS), processados com ferramentas baseadas em arquivos e, depois, enviados novamente ao S3. Isso gerava duplicação de armazenamento, custos adicionais de transferência e atrasos significativos devido à movimentação de dados.
FUSE (Filesystem in Userspace): Ferramentas como s3fs ou AWS Mountpoint for S3 tentavam fazer o S3 se comportar como um disco. Embora o Mountpoint tenha melhorado o desempenho, essas soluções apresentavam limitações importantes, como otimização principalmente para leitura ou suporte apenas a gravações sequenciais, sem oferecer suporte completo a operações atômicas ou ao bloqueio de arquivos no estilo POSIX.
Pagamento Premium por Sistemas de Arquivos: Em alguns casos, organizações evitavam o S3 completamente para dados acessados com frequência e mantinham tudo em sistemas baseados em arquivos, como o Amazon EFS ou o Amazon FSx. Isso garantia compatibilidade, mas com um custo por gigabyte significativamente mais alto.

O S3 Files resolve esses três desafios de uma só vez — eliminando a necessidade de movimentação de dados, dispensando conectores complexos de terceiros e melhorando a eficiência de custos em larga escala.

O que é o Amazon S3 Files? Uma visão geral do novo serviço

Em termos simples, o Amazon S3 Files transforma seus buckets do Amazon S3 em sistemas de arquivos compartilhados ao conectar diretamente qualquer recurso de computação da AWS aos dados armazenados nesses buckets. Ele expõe uma interface de Network File System (NFS versão 4.1) diretamente sobre os dados que já estão no bucket.

Sem que os dados precisem sair do S3, o serviço traduz de forma inteligente as operações padrão de sistemas de arquivos em requisições eficientes da API do S3 nos bastidores. Na prática, o S3 passa a funcionar como um “disco compartilhado”. Quando uma aplicação altera algum dado por meio do mount NFS, essa alteração é automaticamente refletida no objeto subjacente no S3.

As equipes não precisam fazer nenhuma modificação no código de aplicações baseadas em sistemas de arquivos. Utilitários padrão de linha de comando do Linux, frameworks legados de Machine Learning, agentes de IA e sistemas analíticos podem ler e gravar dados como fariam em um disco local, enquanto o S3 atua como a fonte principal dos dados (System of Record).

Mergulho na Arquitetura: Como o S3 Files Funciona por Baixo dos Panos

A AWS não construiu o Amazon S3 Files do zero. Internamente, o serviço se apoia na tecnologia já consolidada do Amazon Elastic File System para lidar com conexões e camadas de desempenho. Seu design segue uma abordagem de dupla camada, pensada para resolver um dos maiores desafios técnicos: a latência de metadados em armazenamento de objetos.

1. Camada de Metadados com Latência Submilissegundo

Quando se executa um comando ls em um diretório com milhares de arquivos, um sistema de arquivos tradicional responde quase instantaneamente. Em contraste, buckets de armazenamento de objetos podem levar mais tempo devido à paginação nas listagens. O S3 Files resolve isso mantendo uma camada dedicada e extremamente rápida de metadados. Essa camada mantém uma visão em tempo real dos objetos no bucket, permitindo que operações como stat, navegação em diretórios e verificação de permissões ocorram com latência mínima — sem a necessidade de consultar constantemente a API do Amazon S3.

2. Tiering Inteligente e Cache

Para entregar alto desempenho em diferentes tipos de workload, o S3 Files utiliza uma estratégia de armazenamento em camadas (tiering) inteligente. Arquivos menores e dados “quentes”, que se beneficiam de acesso rápido e aleatório, são mantidos em uma camada de cache de alta performance. Já para leituras sequenciais de grande volume — como carregar um dataset de 100 GB para treinamento de IA — o sistema ignora o cache e faz streaming direto do S3, atingindo um throughput agregado extremamente alto, que pode chegar a múltiplos terabytes por segundo.

3. Modelo “Stage and Commit” com Sincronização Bidirecional

O S3 Files conecta a semântica de sistemas de arquivos com a de armazenamento de objetos por meio de um modelo de “stage and commit”. Alterações feitas pela interface NFS são primeiro processadas na camada de alta performance e, em seguida, sincronizadas de forma assíncrona com o S3 como atualizações completas de objetos. Esse processo funciona nos dois sentidos: se uma função serverless grava um novo objeto diretamente pela API do S3 (por exemplo, usando um SDK em Python), esse arquivo se torna visível quase imediatamente no sistema de arquivos montado para qualquer instância EC2 que esteja acessando o bucket.

Casos de Uso: Onde o S3 Files se Destaca

A introdução do Amazon S3 Files abre uma ampla gama de possibilidades, especialmente em cenários que antes sofriam com a lacuna entre armazenamento de objetos e sistemas de arquivos tradicionais.

Preparação de Dados para Machine Learning e IA

Cientistas de dados frequentemente gastam muito tempo limpando e preparando datasets brutos. No passado, isso exigia a construção de pipelines complexos e caros para mover dados do Amazon S3 para o Amazon Elastic File System, executar o pré-processamento com ferramentas como Pandas ou NumPy e, depois, enviar os resultados de volta ao S3. Com o S3 Files, o bucket pode simplesmente ser montado em uma instância de treinamento (ou no Amazon SageMaker), permitindo que scripts de preparação trabalhem diretamente com os dados no S3.

Agentes de IA e Pipelines Colaborativos (Agentic AI)

Agentes de IA modernos precisam de espaços de trabalho persistentes e estado de sessão. Agentes que geram código, compilam projetos ou analisam documentos podem agora usar o S3 Files como um diretório raiz compartilhado. Um agente pode escrever saídas intermediárias, e outro — rodando em um contêiner diferente — pode acessá-las imediatamente usando semântica POSIX. Isso possibilita colaboração em larga escala entre agentes de IA sem depender de bancos de dados intermediários complexos.

Modernização de Aplicações (Lift-and-Shift)

Muitas organizações ainda operam sistemas legados on-premises, como ERPs, servidores de mídia ou processadores de documentos, que esperam caminhos de arquivo como //storage/data/. Migrar esses sistemas para a nuvem sempre foi um desafio, pois o S3 não oferecia compatibilidade nativa com sistemas de arquivos, enquanto o EFS pode ser caro para armazenamento de longo prazo. O S3 Files permite uma abordagem de lift-and-shift mais simples: as aplicações continuam funcionando normalmente, enquanto os dados são armazenados no S3 com alta escalabilidade.

Computação de Alto Desempenho (HPC) e Genômica

Áreas como pesquisa biomédica, meteorologia e física frequentemente dependem de ferramentas científicas antigas baseadas no padrão POSIX. Com o S3 Files, clusters de computação podem acessar diretamente grandes volumes de dados — como bibliotecas genômicas — armazenados de forma econômica no S3, enquanto ainda se beneficiam de suporte completo ao NFS v4.1 e leituras paralelas de alto throughput.

AWS Lambda e Processamento Serverless de Arquivos Grandes

Funções do AWS Lambda possuem limites rígidos de armazenamento local (até 10 GB em /tmp). Processar arquivos muito grandes — como um vídeo de 50 GB — sempre foi um desafio em arquiteturas serverless. Com o S3 Files, funções Lambda podem montar grandes volumes de dados como se fossem um sistema de arquivos local, permitindo o processamento contínuo e nativo de arquivos em larga escala.

Comparação Detalhada: S3 Files vs. Outros Serviços de Armazenamento da AWS

Para tomar decisões arquitetônicas mais acertadas, é essencial entender como o Amazon S3 Files se posiciona em relação às soluções já existentes no ecossistema AWS.

S3 Files vs. Amazon S3 Standard (API HTTP)

Acesso: O S3 Standard exige o uso de APIs ou SDKs (como PUT e GET) e trabalha com objetos imutáveis. Já o S3 Files apresenta esses mesmos dados como arquivos e diretórios acessíveis via NFS.
Mutações: No S3 tradicional, não é possível alterar apenas uma parte de um objeto — qualquer modificação exige a reescrita completa. O S3 Files resolve isso ao permitir alterações parciais no nível de blocos, abstraindo toda a complexidade internamente.
Uso ideal: APIs do S3 continuam sendo a melhor escolha para aplicações cloud-native. Já o S3 Files é mais adequado quando há necessidade de semântica de sistema de arquivos.

S3 Files vs. Amazon EFS (Elastic File System)

Foco: O EFS é um sistema de arquivos elástico voltado para uso geral. O S3 Files, embora utilize tecnologia do EFS internamente, tem o S3 como camada principal de persistência.
Escala e custo: Armazenar grandes volumes no EFS pode ser caro. O S3 Files mantém os dados no S3 (muito mais econômico) e usa uma camada adicional para performance interativa. Enquanto o EFS é ideal para arquivos sensíveis à latência (como diretórios de sistema), o S3 Files se destaca em dados massivos, analytics e datalakes.

S3 Files vs. Amazon EBS (Elastic Block Store)

Compartilhamento: Volumes EBS geralmente são anexados a uma única instância por vez (com exceções limitadas). O S3 Files, por outro lado, é nativamente compartilhado — múltiplas instâncias, containers ou funções Lambda podem acessar os mesmos dados simultaneamente.
Persistência: O EBS é vinculado a zonas de disponibilidade específicas. Já o S3 (e o S3 Files) é multi-AZ por natureza, oferecendo maior resiliência regional.

S3 Files vs. Amazon FSx (Lustre, Windows, NetApp, OpenZFS)

Especialização: O FSx é voltado para cenários altamente específicos. Por exemplo, o FSx for Lustre é otimizado para HPC e pode integrar com S3, mas exige provisionamento dedicado, maior custo e mais gestão.
Posicionamento: O S3 Files é totalmente gerenciado, pronto para uso geral via NFS 4.1, e atende a uma ampla gama de casos empresariais. Na prática, ele se posiciona como a opção padrão para integrar armazenamento de objetos com experiência de sistema de arquivos.

Governança, Segurança e Conformidade

Ao introduzir uma ponte tão poderosa para um repositório principal de dados, a segurança naturalmente se torna uma das maiores preocupações para qualquer CISO. A Amazon Web Services projetou o Amazon S3 Files para manter a segurança centralizada e consistente.

Identity and Access Management (IAM): Todo o controle de acesso é gerenciado por meio do AWS Identity and Access Management. Políticas baseadas em recursos e em identidade podem ser usadas para definir quem pode montar e acessar o sistema de arquivos, respeitando também as permissões granulares já configuradas no Amazon S3.
Permissões POSIX: Além do IAM, o S3 Files oferece suporte às permissões padrão do Linux (User ID e Group ID). Esses valores de UID/GID são armazenados como metadados nos objetos do S3, garantindo que operações como chmod, realizadas em um sistema montado, sejam aplicadas corretamente na camada de armazenamento.
Criptografia: Os dados em trânsito entre recursos computacionais e o S3 Files são criptografados utilizando TLS 1.3. Já os dados em repouso são protegidos por chaves gerenciadas automaticamente pelo S3 (SSE-S3) ou por chaves gerenciadas pelo cliente através do AWS Key Management Service.
Auditoria (Audit Logging): Todos os eventos de gerenciamento são registrados por meio do AWS CloudTrail, permitindo rastreabilidade completa e ajudando organizações a atender requisitos de conformidade ao monitorar quem acessou ou tentou modificar o sistema de arquivos.

Como Iniciar e Integrar com Seus Workloads

A implementação do Amazon S3 Files foi pensada para gerar o mínimo de atrito para qualquer engenheiro já familiarizado com a AWS:

Configuração: Por meio do console da AWS, ou utilizando ferramentas como AWS CLI ou Terraform, é possível criar um recurso de interface do S3 Files e apontá-lo para o bucket (ou prefixo/diretório dentro dele) que se deseja expor no Amazon S3.
Instalação do Driver: Nos recursos de computação (como instâncias EC2 ou containers no EKS), é necessário garantir que o pacote amazon-efs-utils esteja instalado. Como o serviço utiliza a infraestrutura do Amazon Elastic File System por baixo dos panos, esse é o único requisito do lado do cliente.
Montagem Simples: Com um comando Linux simples, como:

mount -t s3files file-system-id /mnt/meu-datalake

A partir desse ponto, o diretório /mnt/meu-datalake passa a funcionar como um sistema de arquivos de alta capacidade, com todo o conteúdo do S3 disponível para acesso imediato.

Conclusão: O Futuro do Armazenamento de Dados na Nuvem

Com o lançamento do Amazon S3 Files, a Amazon Web Services não está apenas adicionando mais uma ferramenta ao seu vasto portfólio — está resolvendo um desafio arquitetônico antigo. A proposta dos Data Lakes sempre foi centralizar a fonte de verdade das organizações. No entanto, isso frequentemente era comprometido quando equipes de IA e operações precisavam duplicar e isolar dados para torná-los compatíveis com ferramentas baseadas em sistemas de arquivos.

Ao eliminar essa necessidade de movimentação e duplicação, o S3 Files reduz significativamente a complexidade das arquiteturas modernas, corta custos associados à redundância de dados, aumenta a produtividade de cientistas e engenheiros e posiciona o armazenamento de objetos como o núcleo central de todas as cargas de trabalho.

Seja viabilizando o lift-and-shift de aplicações legadas ou permitindo o treinamento de novas gerações de IA com petabytes de dados acessados nativamente, o Amazon S3 deixa de ser apenas a base da “internet dos dados” e passa a atuar também como um verdadeiro disco rígido infinito e compartilhado.

Referências

Obter tempo de disponibilidade de instâncias EC2 na AWS

Isaque Alcantara — Thu, 13 Jul 2023 11:44:15 +0000

Introdução

Este artigo descreve a primeira parte do desenvolvimento de um sistema web para obter e visualizar o tempo de disponibilidade e indisponibilidade de instâncias EC2 na AWS.

O sistema consiste em duas partes: um backend onde utilizaremos um script em python para obter e tratar os dados necessários para gerar os relatórios e um frontend composto por uma página simples que utilizará HTML, Javascript e CSS, para fornecer um dashboard com gráficos e insights sobre as instâncias EC2 de todas as regiões da conta.

Arquitetura proposta

Com esta arquitetura, teremos uma Função Lambda que fará a coleta de métricas de StatusCheckFailed vindas do CloudWatch para todas as instâncias da conta. Após coletá-las, o Lambda irá tratá-las e armazenar os resultados em um Bucket S3. O Bucket armazenará esses resultados em arquivos .csv juntamente com os arquivos HTML, Javascript e CSS que irão compor o sistema. Utilizaremos o CloudFront para distribuir o conteúdo e também proteger os acessos para somente usuários autorizados.

Com isso teremos um Dashboard com o total, em horas, de tempo disponível e indisponível de todas as instâncias EC2. Também será possível baixar esse relatório em formato CSV para melhor administração.

Métricas de Status Check

As métricas de status check na AWS são uma forma de monitorar a saúde e o desempenho das instâncias do Amazon EC2 (Elastic Compute Cloud) em uma região específica. Essas métricas fornecem informações sobre a integridade dos componentes da instância, como a camada de virtualização, a conectividade de rede e o sistema operacional.

Vamos passar rapidamente sobre o papel de cada uma:

StatusCheckFailed: Essa métrica relata se a instância passou tanto na verificação de status da instância quanto na verificação de status do sistema no último minuto. Ela tem um valor binário, onde 0 significa que passou e 1 significa que falhou. Por padrão, essa métrica está disponível gratuitamente a cada um minuto. As unidades dessa métrica são contagem.
StatusCheckFailed_Instance: Essa métrica informa se a instância passou na verificação de status da instância no último minuto. Similar à métrica anterior, ela possui um valor binário de 0 (passou) ou 1 (falhou). Também está disponível gratuitamente a cada um minuto e suas unidades são contagem.
StatusCheckFailed_System: Essa métrica indica se a instância passou na verificação de status do sistema no último minuto. Mais uma vez, ela possui um valor binário de 0 (passou) ou 1 (falhou). A disponibilidade gratuita e a frequência de um minuto também se aplicam a essa métrica, e suas unidades são contagem.

Ao acompanhar essas métricas, é possível identificar problemas e tomar medidas corretivas quando ocorrerem falhas nos status checks.

Com base nas métricas de status check registradas no CloudWatch, podemos calcular o tempo de disponibilidade das instâncias. Ao monitorar as falhas nos status checks e calcular o tempo em que as instâncias estão passando nesses checks, é possível ter uma estimativa do tempo em que as instâncias estiveram disponíveis.

No entanto, é importante destacar que essa abordagem é uma estimativa e depende de vários fatores, como a frequência de verificação das métricas, por exemplo. Além disso, existem outros fatores que podem afetar a disponibilidade das instâncias, como atualizações de sistema operacional, manutenção programada, eventos de força maior, entre outros.

Calculando o tempo de Downtime e Uptime

Para calcular o tempo de disponibilidade das instâncias, utilizaremos um código em Python para rodar em uma função Lambda, que tem como propósito principal gerar um relatório de disponibilidade das instâncias do Amazon EC2 em várias regiões da AWS. Ele utiliza a biblioteca boto3 para interagir com os serviços da AWS, como o CloudWatch e o S3.

O código itera sobre cada região configurada e, em seguida, obtém informações sobre as instâncias EC2 presentes em cada região. Para cada instância, são coletadas métricas de falha de status usando o CloudWatch. Com base nessas métricas, o código calcula o tempo de disponibilidade e indisponibilidade de cada instância.

Após processar todas as regiões e instâncias, os dados são armazenados em uma lista e, em seguida, enviados como um arquivo CSV para um bucket S3 especificado. O relatório contém informações como ID da instância, nome, tipo, plataforma, tempo de disponibilidade, tempo de indisponibilidade e porcentagem de disponibilidade.

Baixe o código neste repositório.

Hora de colocar a mão na massa. Vamos lá!

1 - Criar bucket S3

Acesse o console do Amazon S3 e clique em Create bucket. Dê um nome para seu bucket e escolha a região de sua preferência.

Deixe o restante das opções como padrão e clique em Create bucket.

2 - Criar uma função do IAM

No console do IAM, clique em Policies no menu lateral esquerdo e depois em Create policy. Clique na guia JSON e substitua o código JSON por este:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": "arn:aws:s3:::your-bucket-name-123456/*"
        }
    ]
}

Desta forma, a função Lambda que usará essa IAM role terá acesso restrito somente ao bucket em questão.

Substitua o nome do bucket na linha "Resource": "arn:aws:s3:::your-bucket-name-123456/*" pelo nome do bucket que você criou anteriormente. Avance para a parte de Review para dar um nome à sua Policy e depois clique em Create Policy.

Vamos então criar uma Role e atachar a Policy criada junto com outras necessárias para o funcionamento do script. Clique em Roles no menu lateral esquerdo e depois em Create Role.

Em Trusted entity type escolha AWS service, marque o serviço Lambda e avance para atachar as policies necessárias.

Em Add permissions pesquise pela policy que você criou anteriormente e marque a caixa ao lado do nome para selecioná-la. Faça o mesmo processo para as seguintes policies:

CloudWatchLogsReadOnlyAccess
AmazonEC2ReadOnlyAccess

Avance para escolher um nome para sua Role e revise as Policies atachadas. Feito isso, clique em Create role.

3 - Criar função Lambda

Acesse o console do Lambda e clique em Create function. Escolha a opção Author from scratch para iniciar com um exemplo de código. Dê um nome para sua Função Lambda e escolha o Runtime Python 3.10.

Em Change default execution role escolha Use an existing role e selecione a Role que você criou no passo anterior. Feito isso clique em Create function.

Agora que você criou a Função, substitua o código de exemplo pelo código que está neste repositório. Após inserir o código, clique em Deploy para Salvar as alterações.

Feito isso, vá para a aba Configuration e mude o Timeout para 2 minutos (configure um tempo maior ou menor de acordo com a quantidade de instâncias do ambiente).

Lembre-se de alterar as regiões, o nome do bucket e o nome do arquivo no script.

Vá para a aba Test para configurar um novo teste. Dê um nome ao evento e clique em Save.

Após salvar, execute um teste. Se tudo correr bem você verá uma saída como a imagem abaixo.

3 - Configurar EventBridge

Na parte superior da página da função, em Function Overview, clique em Add trigger.

Em Trigger configuration selecione EventBridge (CloudWatch Events). Crie uma nova regra, dê um nome para a regra e em seguida selecione Schedule expression para inserir uma Cron.
Aqui você pode configurar uma expressão que melhor atende a sua necessidade. Neste exemplo usei uma expressão que chamará a função Lambda de 30 em 30 minutos.

cron(0/30 * * * ? *)

Após inserir o valor clique em Add.

4 - Baixe o relatório gerado

Volte ao bucket criado, navegue até a pasta “data/” e faça download do arquivo .csv gerado pelo script.

As primeiras colunas do arquivo dizem respeito às especificações das instâncias como ID, nome, tamanho e sistema operacional.

As informações sobre disponibilidade estão nas colunas uptime_hours, downtime_hours e hours_used.

uptime_hours: tempo em que a instância ficou disponível e operante.
downtime_hours: tempo em que a instância ficou indisponível e não operante (devido a alguma falha detectada pelas métricas de status check).
hours_used: tempo total em que a instância permaneceu ligada, independente de estar operante ou não operante.

Por fim, temos as colunas start_date e end_date que representam o período em que o relatório se baseia. Por configuração do script, o relatório sempre começará no primeiro dia do mês às 00:00 horas e terminará no último horário de execução da função lambda, segmentando cada relatório por mês atual.

Conclusão

Concluímos a primeira parte de nosso sistema. Com isso, temos um backend que nos traz um relatório de tempo de disponibilidade e indisponibilidade das instâncias EC2 da conta.

Na parte 2 deste artigo, vamos criar um frontend utilizando HTML, Javascript e CSS para poder exibir esse relatório de forma mais apreciativa, e claro, vamos utilizar dos serviços da AWS que são próprios para isso, visando o mínimo custo possível. Até lá!

Verificar rotinas de Snapshots via Lambda

Isaque Alcantara — Sat, 11 Feb 2023 16:05:52 +0000

Introdução

O backup é peça chave nas operações de qualquer ambiente e deixar de realizar alguma rotina pode resultar em surpresas desagradáveis em algum procedimento de recuperação.

Existem diversas formas de realizar backups dos seus recursos e serviços na AWS. Quando se trata de Instâncias EC2 e RDS, a AWS oferece ferramentas como o AWS Backup ou serviço de backup integrado no próprio recurso, como é o caso do RDS por exemplo.

Apesar da facilidade em manter seus backups em dia, sabemos que sempre tem aquela exceção(zinha) que foge à regra e com o tempo pode acabar no limbo. Pensando nisso, elaborei este script em Python para poder verificar se os volumes de suas contas estão com o snapshot em dia. 🙂

Vamos aos passos

1 - Criar uma função do IAM para o Lambda

Acesse o console do IAM, no menu lateral esquerdo clique em Roles e depois clique no botão Create role.

Em Select trusted entity selecione AWS service, Lambda e clique em Next.

Clique no botão Create policy. Uma nova guia será aberta para criação da policy. Vá na guia JSON do editor, cole o seguinte código abaixo e depois clique em Next para avançar para a parte de Review policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "cloudwatch:PutMetricData",
                "ec2:DescribeInstances",
                "ec2:DescribeVolumeStatus",
                "ec2:DescribeSnapshotAttribute",
                "ec2:DescribeRegions",
                "ec2:DescribeVolumes",
                "ec2:DescribeVolumesModifications",
                "ec2:DescribeSnapshots",
                "ec2:DescribeVolumeAttribute"
            ],
            "Resource": [
                "*"
            ],
            "Effect": "Allow"
        },
        {
            "Action": [
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": [
                "arn:aws:logs:*:*:*"
            ],
            "Effect": "Allow"
        }
    ]
}

Dê um nome para sua Policy e clique em Create policy.

Volte para a guia da criação da Role em seu navegador e atualize a lista de policies. Pesquise pela policy criada anteriormente, selecione-a e clique em Next.

Dê um nome para sua Role e clique em Create role. Pronto, sua Role está criada.

2 - Criar função Lambda

Abra o console do Lambda, no menu lateral esquerdo clique em Functions e depois no botão Create function.

Selecione Author from scratch, dê um nome para sua função e escolha o Runtime Python 3.9.

Em Permissions, selecione o item Use an existing role e no campo de seleção escolha a Role criada anteriormente. Feito isso clique em Create function.

Com isso sua função está criada. Agora vamos substituir o código de exemplo da função pelo código deste repositório.

Este código seleciona todos os volumes da conta e verifica se cada um deles possui ou não algum snapshot realizado.

Caso NÃO possua algum snapshot realizado, será impresso a seguinte mensagem nos logs de execução:

[ALERT] The Volume-ID: vol-a1b2c3d4e5f6g7 does not have a Snapshot.

Se o volume possuir algum snapshot mas esse for mais antigo do que a quantidade de dias inserida na constante de verificação DAYS = x será impresso a mensagem:

[ALERT] The last Snapshot of Volume-ID: vol-a1b2c3d4e5f6g7 was in 2022-09-23 01:33:04.596000+00:00.

Se por algum motivo você quiser excluir algum volume da verificação, basta adicionar a tag snapshot:false no volume desejado. Então verá na saída de logs a mensagem:

[WARNING] Volume-ID: vol-a1b2c3d4e5f6g7 excluded from snapshot routine.

Por padrão, o código verifica se os snapshots mais recentes possuem mais de 3 dias, mas você pode alterar esse valor na constante DAYS = x no início do código.

Caso a saída do código não retorne nada significa que seus volumes estão com o snapshot em dia.

Após substituir o código, clique em Deploy para salvar.

Após salvar o código, vá até a guia Configuration e clique em Edit.

Altere o Timeout para 1 minuto e 30 segundos (pode ser necessário um tempo maior dependendo da quantidade de volumes na conta) e depois clique em Save.

Volte na guia Code, clique em Test para configurar um novo evento de teste.

Dê um nome ao evento, mantenha o restante das configurações padrão e clique em Save.

Após salvar o Evento, clique no botão Test novamente para executar sua função Lambda.

3 - Analisando os Logs

Após executar a função, você verá uma saída parecida com esta abaixo:

Para uma visualização mais completa, vamos analisar essa saída no Log Groups do CloudWatch. Para isso clique na guia Monitor e depois em View CloudWatch logs.

Com isso você será redirecionado para o Grupo de logs da função Lambda que você criou. Clique no Log stream mais recente para visualizar a saída completa da Função.

Dessa forma você pode ter uma visão completa, o que dependendo do seu ambiente pode ser bem extensa.

Conclusão

A partir dos logs no CloudWatch podemos criar alarmes com base em filtros de métricas e assim termos uma monitoria de backup de todos os volumes da conta, mas isso é um assunto para um próximo post.

Vou ficando por aqui e qualquer feedback só deixar nos comentários.

Gerando relatório de Rightsizing de Instâncias via Lambda

Isaque Alcantara — Sun, 29 Jan 2023 12:40:44 +0000

Introdução

Ainda na pegada de otimização de custos na AWS, este post complementa o post anterior onde geramos um relatório de preços de reservas das instâncias do seu ambiente através de um script em Python executado via Lambda.

Neste post utilizaremos a mesma abordagem, porém com o script um pouco mais “turbinado”, onde adicionamos alguns recursos do AWS Compute Optimizer na jogada.

Com isso, será gerado um outro relatório com recomendações de rightsizing para suas instâncias EC2 juntamente com os preços sob demanda e de reservas como no relatório anterior. O relatório traz também uma comparação de utilização de CPU e memória da família atual com uma estimativa de uso da família recomendada pelo Compute Optimizer.

O AWS Compute Optimizer

O AWS Compute Optimizer ajuda você a evitar o provisionamento excessivo ou insuficiente de alguns recursos da AWS. Acesse a documentação neste link para saber mais.

Alguns casos de uso do AWS Compute Optimizer:

Avalie as oportunidades estimadas de economia e melhoria de performance no nível da conta para recursos do Amazon EC2, Amazon EBS e AWS Lambda.
Obtenha recomendações aprimoradas para otimizar instâncias do EC2 e grupos do Auto Scaling usando três meses de dados históricos.
Encontre as workloads do EC2 que fornecerão o maior retorno pelo menor esforço de migração em uma mudança para CPUs AWS Graviton.
Aumente a economia e o reconhecimento da performance configurando métricas de terceiros a partir de suas ferramentas de Monitoramento de performance de aplicações (APM).

É importante ressaltar que a opção padrão do Compute Optimizer analisa as métricas do Amazon CloudWatch durante os últimos 14 dias para fornecer recomendações. Caso você queira estender esse período por até 3 meses, é necessário ativar as métricas de infraestrutura avançadas do Compute Optimizer, que é um recurso pago. Entenda a definição de preços aqui.

Bora pro trampo!

1 - Criar bucket

O primeiro ponto será a criação do nosso bucket onde ficarão os arquivos que serão gerados pelo script.

Acesse o console do Amazon S3 e clique em Create bucket. Dê um nome para seu bucket e escolha a região de sua preferência. Deixe o restante das opções como padrão e clique em Create bucket.

O nome do bucket é globalmente exclusivo, portanto use um nome diferente do meu e anote. Vamos usar esse nome na política que criaremos na próxima etapa.

2 - Criar uma função do IAM

No console do IAM, clique em Policies no menu lateral esquerdo e depois em Create policy. Clique na guia JSON e substitua o código JSON por este:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": "arn:aws:s3:::ec2-recommendations-reports/*"
        }
    ]
}

Substitua o nome do bucket na linha "Resource": "arn:aws:s3:::ec2-recommendations-reports/*" pelo nome do bucket que você criou anteriormente. Avance para a parte de Review para dar um nome à sua Policy e depois clique em Create Policy.

Vamos então criar uma Role e atachar a Policy criada junto com outras necessárias para o funcionamento do script. Clique em Roles no menu lateral esquerdo e depois em Create Role. Em Trusted entity type escolha AWS service, marque o serviço Lambda e avance para atachar as policies necessárias.

Em Add permissions pesquise pela policy que você criou anteriormente e marque a caixa ao lado do nome para selecioná-la. Faça o mesmo processo para as seguintes policies:

AWSPriceListServiceFullAccess
ComputeOptimizerReadOnlyAccess
AmazonEC2ReadOnlyAccess
AmazonSSMReadOnlyAccess
AWSLambdaBasicExecutionRole

Avance para escolher um nome para sua Role e revise as Policies atachadas.

3 - Criar função Lambda

Acesse o console do Lambda e clique em Create function. Escolha a opção Author from scratch para iniciar com um exemplo de código. Dê um nome para sua Função Lambda e escolha o Runtime Python 3.9 ou superior.

Em Change default execution role escolha Use an existing role e selecione a Role que você criou no passo anterior. Feito isso clique em Create function.

Agora que você criou a Função, substitua o código de exemplo pelo código que está neste repositório. Após inserir o código, clique em Deploy para Salvar as alterações.

Feito isso, vá para a aba Configuration e mude o Timeout para 2 minutos (configure um tempo maior ou menor de acordo com a quantidade de instâncias do ambiente).

Vá para a aba Test para configurar um novo teste. Dê um nome ao evento e clique em Save.

4 - Configuração do script

Volte para a aba Code. Vamos analisar algumas linhas do código que precisam ser alteradas:

Região dos recursos na AWS

Escolha as regiões onde suas instâncias estão. O script verifica todas instâncias EC2 nas regiões setadas na variável AWS_REGIONS e adiciona todas no mesmo arquivo csv.

# Define AWS Region
AWS_REGIONS = ['us-east-1', 'sa-east-1']

Região do endpoint da API de preços

Conforme dito anteriormente, a API de preços da AWS fornece dois endpoints com duas regiões diferentes. Aqui usaremos a região da Virgínia, mas você pode trabalhar com outra se preferir.

# Define AWS Pricing Rregion (us-east-1 or ap-south-1)
AWS_PRICING_REGION = 'us-east-1'

Tipo de reserva que será utilizada no relatório

Você pode trabalhar com o tipo de reservas padrão ou conversível. Para entender a diferença entre os dois, consulte este link.

# Define reservation type (standard or convertible)
OFFERING_CLASS = 'standard'

Nome do bucket onde serão armazenados os arquivos csv do relatório

Altere esta opção e insira o nome do bucket que você criou. Como o bucket é globalmente exclusivo, você terá que mudar de qualquer jeito.

# Enter your BUCKET name, e.g 'mybucket'
BUCKET = 'mybucket'

Nome do arquivo CSV que será criado pelo script

Defina um nome para o arquivo de relatório que será gerado pelo script.

# KEY path, e.g.'myec2report'
KEY = 'myec2report'

Obs.: esse nome será concatenado com o tipo de reserva e uma hash de identificação única para não haver sobreposição do arquivo ao executar a função novamente.

Ex: myec2report_standard_1684081195342122923.csv

Após executar a função Lambda, seu bucket S3 deverá estar parecido com esse:

Podemos ver o arquivo que foi gerado pelo script (com uma sequência numérica no final).

O arquivo de relatório gerado nos traz os mesmos tipos de preços sob demanda e de reservas para todas as instâncias da região inserida no código, porém desta vez os preços são para a família de instâncias recomendadas pelo Compute Optimizer. Também é possível ver uma comparação de utilização de CPU e memória da família atual com uma estimativa de uso da família recomendada pelo Compute Optimizer.

A coluna Fiding fornece um status dos seus recursos durante o período analisado, podendo ser Under-provisioned, Over-provisioned ou Optimized. Entenda cada um desses status aqui.

Considerações

O script lista as recomendações de instâncias baseado na arquitetura atual da instância (Intel, AMD e Arm). Para alterar esta configuração, adicione o parâmetro "cpuVendorArchitectures": [ "string" ] na chamada da API em COMPUTE_OPTIMIZER.get_ec2_instance_recommendations(). Veja a documentação aqui.

Em alguns casos, o Compute Optimizer recomenda a troca de família mesmo a instância estando como Optimized, pois a geração recomendada é mais nova que a atual e isso gera uma redução de uso da capacidade computacional e até mesmo de custo.

Outro ponto importante é que para a obtenção de métricas de memória, é necessário ter o CloudWatch Agent instalado nas instâncias. Caso contrário, tanto a coluna de métricas de memória atual quanto a estimada serão preenchidas com "Not available".

Em algumas ocasiões o Compute Optimizer necessita que as instâncias permaneçam ligadas por um período mínimo de tempo. Em meus testes de laboratório, foi preciso mantê-las ligadas por no mínimo 24 horas sem interrupções.

Conclusão

Novamente, é IMPORTANTE sempre validar os preços gerados pelo script com os valores da calculadora de preços da AWS.

Isso é tudo por hoje!
Se tiver dúvidas ou quer mandar um feedback fique a vontade para comentar.
Abraços!

Gerando relatório de preços de reservas de Instâncias via Lambda

Isaque Alcantara — Sat, 21 Jan 2023 16:13:13 +0000

Introdução

Talvez você já tenha se deparado com a necessidade de avaliar preços para possíveis reservas de instâncias para o seu ambiente e dependendo da quantidade de instâncias, esta pode não ser uma tarefa muito agradável.

Em um ambiente que contém dezenas ou talvez centenas de instâncias em uso, gerar relatório de preço de reserva para cada uma pode levar dias se feito de forma manual, cuja tarefa seria: verificar a família da instância, ir até a calculadora da AWS, coletar os preços para as diferentes modalidades (de reservas e pagamento) e incluir todas essas informações em uma planilha. Suado, viu…

Pensando em uma forma de automatizar este processo, elaborei um script em Python para rodar em uma função Lambda e gerar esse lindo relatório para nós. 😀

Este script utiliza a API de preços da AWS para preencher um arquivo em CSV com os preços Sob Demanda e de Reservas com as diferentes modalidades de pagamento (sem pagamento adiantado, parcialmente adiantado e totalmente adiantado) para 1 e 3 anos. Também é possível escolher entre os tipos de reservas padrão e conversível, para melhor atender a sua necessidade.

Sobre a API de preços da AWS

A AWS oferece duas APIs que você pode usar para consultar preços. Você pode consultar a documentação neste link, mas em resumo:

Com a API Price List Bulk da AWS, você pode consultar os preços de serviços da AWS em massa. Essa API retorna um arquivo JSON ou CSV. A API em massa retém todas as versões históricas da lista de preços.
Com a API Price List Query da AWS, é possível consultar informações específicas sobre serviços, produtos e preços da AWS usando um AWS SDK ou a AWS CLI. Essa API é capaz de recuperar informações sobre determinados produtos ou preços, em vez de recuperar preços em massa. Isso permite obter informações de preços em ambientes que talvez não consigam processar uma lista de preços em massa, como em aplicações móveis ou baseadas em navegador da Web. Por exemplo, é possível utilizar a API de consulta para buscar informações de preços de instâncias do Amazon EC2 com 64 vCPUs, 256 GiB de memória e o SQL Server Enterprise pré-instalado na região Ásia-Pacífico (Mumbai). A API de consulta retorna os preços atuais e não retém preços históricos.

Para esse script será utilizada a segunda opção nas APIs descritas acima. Passando alguns atributos das instâncias que compõem o seu ambiente como parâmetros na chamada dessa API, ela nos retornará os preços da instância em questão.

A API Price List Query da AWS fornece os dois endpoints a seguir:

Mão na massa!

1 - Criar bucket

O primeiro ponto será a criação do nosso bucket onde ficarão os arquivos que serão gerados pelo script.

Acesse o console do Amazon S3 e clique em Create bucket. Dê um nome para seu bucket e escolha a região de sua preferência. Deixe o restante das opções como padrão e clique em Create bucket.

O nome do bucket é globalmente exclusivo, portanto use um nome diferente do meu e anote. Vamos usar esse nome na política que criaremos na próxima etapa.

2 - Criar uma função do IAM

No console do IAM, clique em Policies no menu lateral esquerdo e depois em Create policy. Clique na guia JSON e substitua o código JSON por este:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": "arn:aws:s3:::ec2-princing-reports/*"
        }
    ]
}

Substitua o nome do bucket na linha "Resource": "arn:aws:s3:::ec2-princing-reports/*" pelo nome do bucket que você criou anteriormente. Avance para a parte de Review para dar um nome à sua Policy e depois clique em Create Policy.

Em Add permissions pesquise pela policy que você criou anteriormente e marque a caixa ao lado do nome para selecioná-la. Faça o mesmo processo para as seguintes policies:

AWSPriceListServiceFullAccess
AmazonEC2ReadOnlyAccess
AmazonSSMReadOnlyAccess
AWSLambdaBasicExecutionRole

Avance para escolher um nome para sua Role e revise as Policies atachadas. As permissões da sua Role devem se parecer com esta:

3 - Criar função Lambda

Em Change default execution role escolha Use an existing role e selecione a Role que você criou no passo anterior. Feito isso clique em Create function.

Agora que você criou a Função, substitua o código de exemplo pelo código que está neste repositório. Após inserir o código, clique em Deploy para Salvar as alterações.

Feito isso, vá para a aba Configuration e mude o Timeout para 2 minutos (configure um tempo maior ou menor de acordo com a quantidade de instâncias do ambiente).

Vá para a aba Test para configurar um novo teste. Dê um nome ao evento e clique em Save.

4 - Configuração do script

Volte para a aba Code. Vamos analisar algumas linhas do código que precisam ser alteradas:

Região dos recursos na AWS

Escolha as regiões onde suas instâncias estão. O script verifica todas instâncias EC2 nas regiões setadas na variável AWS_REGIONS e adiciona todas no mesmo arquivo csv.

# Define AWS Region
AWS_REGIONS = ['us-east-1', 'sa-east-1']

Região do endpoint da API de preços

Conforme dito anteriormente, a API de preços da AWS fornece dois endpoints com duas regiões diferentes. Aqui usaremos a região da Virgínia, mas você pode trabalhar com outra se preferir.

# Define AWS Pricing Rregion (us-east-1 or ap-south-1)
AWS_PRICING_REGION = 'us-east-1'

Tipo de reserva que será utilizada no relatório

Você pode trabalhar com o tipo de reservas padrão ou conversível. Para entender a diferença entre os dois, consulte este link.

# Define reservation type (standard or convertible)
OFFERING_CLASS = 'standard'

Nome do bucket onde serão armazenados os arquivos csv do relatório

Altere esta opção e insira o nome do bucket que você criou. Como o bucket é globalmente exclusivo, você terá que mudar de qualquer jeito.

# Enter your BUCKET name, e.g 'mybucket'
BUCKET = 'mybucket'

Nome do arquivo CSV que será criado pelo script

Defina um nome para o arquivo de relatório que será gerado pelo script.

# KEY path, e.g.'myec2report'
KEY = 'myec2report'

Obs.: esse nome será concatenado com o tipo de reserva e uma hash de identificação única para não haver sobreposição do arquivo ao executar a função novamente.

Ex: myec2report_standard_1684081195342122923.csv

5 - Entendendo o filtro

Para que a API retorne os preços correspondentes à nossa instância é preciso passar alguns parâmetros como filtro. Esse filtro é aplicado na seção “product” do arquivo JSON que é retornado pela API. Veja um exemplo abaixo:

"product": {
       "productFamily": "Compute Instance",
       "attributes": {
           "enhancedNetworkingSupported": "No",
           "intelTurboAvailable": "Yes",
           "memory": "1 GiB",
           "dedicatedEbsThroughput": "Up to 2085 Mbps",
           "vcpu": "2",
           "classicnetworkingsupport": "false",
           "capacitystatus": "Used",
           "locationType": "AWS Region",
           "storage": "EBS only",
           "instanceFamily": "General purpose",
           "operatingSystem": "Linux",
           "intelAvx2Available": "Yes",
           "regionCode": "us-east-1",
           "physicalProcessor": "Intel Skylake E5 2686 v5",
           "clockSpeed": "3.1 GHz",
           "ecu": "Variable",
           "networkPerformance": "Up to 5 Gigabit",
           "servicename": "Amazon Elastic Compute Cloud",
           "vpcnetworkingsupport": "true",
           "instanceType": "t3.micro",
           "tenancy": "Shared",
           "usagetype": "BoxUsage:t3.micro",
           "normalizationSizeFactor": "0.5",
           "intelAvxAvailable": "Yes",
           "processorFeatures": "AVX; AVX2; Intel AVX; Intel AVX2; Intel AVX512; Intel Turbo",
           "servicecode": "AmazonEC2",
           "licenseModel": "No License required",
           "currentGeneration": "Yes",
           "preInstalledSw": "NA",
           "location": "US East (N. Virginia)",
           "processorArchitecture": "64-bit",
           "marketoption": "OnDemand",
           "operation": "RunInstances",
           "availabilityzone": "NA"
       },
       "sku": "CRAJUW7BTXFMT2UJ"
   },

As chaves principais da seção “products” são:

tenancy
preInstalledSw
operatingSystem
licenseModel
capacitystatus

Para refinar ainda mais nosso filtro, passamos mais alguns parâmetros, como:

location
instanceType

Observe o trecho do código que contém os parâmetros do filtro:

Filters=[
           {
               'Type': 'TERM_MATCH',
               'Field': 'location',
               'Value': region
           },
           {
               'Type': 'TERM_MATCH',
               'Field': 'capacitystatus',
               'Value': 'Used'
           },
           {
               'Type': 'TERM_MATCH',
               'Field': 'tenancy',
               'Value': 'Shared'
           },
           {
               'Type': 'TERM_MATCH',
               'Field': 'instanceType',
               'Value': typeEc2
           },
           {
               'Type': 'TERM_MATCH',
               'Field': 'preInstalledSw',
               'Value': preInstalledSw
           },
           {
               'Type': 'TERM_MATCH',
               'Field': 'operatingSystem',
               'Value': operatingSystem
           },
           {
               'Type': 'TERM_MATCH',
               'Field': 'licenseModel',
               'Value': 'No License required'
           }
       ],

6 - Executando a Função

Feito as alterações necessárias no código, faça um novo Deploy para salvar e depois clique no botão Test. Se tudo correu bem, o resultado do teste será parecido com este:

Volte ao bucket e veja que um novo arquivo (com uma sequência numérica no final) foi gerado.

Abrindo o arquivo podemos ver que o conteúdo é um lindo relatório com os preços Sob Demanda e de Reservas para todas as Instâncias da região inserida no código. Além dos preços, podemos conferir outros atributos como ID, nome, AZ, tipo, memória, vCPU e outros.

Conclusão

Espero que este script possa te ajudar a poupar tempo e esforço coletando esses dados manualmente, assim como tem me ajudado.

Importante: SEMPRE valide os valores do relatório gerado com os valores da calculadora de preços da AWS. Não posso garantir que não haja nenhuma divergência, embora seja muito difícil.

E por falar em calculadora da AWS, se você observar a planilha de exemplo acima, verá que contém alguns campos com o valor “not available” para a modalidade de preço “no upfront”. Experimente validar esses valores lá na calculadora da AWS. No momento em que escrevo este post, ao selecionar a família da instância e a modalidade de reserva e preço, por não ter disponível, a caixa de preços de instâncias reservadas desaparece e só volta se você atualizar a página. 😀

Isso é tudo por hoje!
Se tiver dúvidas ou quer mandar um feedback fique a vontade para comentar.
Abraços!

Implantar rotinas periódicas de Start/Stop em Instâncias EC2 via Lambda

Isaque Alcantara — Sat, 14 Jan 2023 15:36:18 +0000

Este é meu primeiro post para o DEV e venho trazer uma solução simples, embora muito útil. Mostrarei uma abordagem para gerenciar rotinas de start e stop com a possibilidade de configurar diferentes períodos de dias e horários para uma determinada Instância EC2 através do AWS Lambda.

Introdução

Suponha que você tenha um Lambda que faz o start/stop de várias instâncias em seu ambiente filtrando-as através de Tags. Se todas as instâncias funcionarem no mesmo período (dias da semana, hora que liga e hora que desliga) tudo bem. Bastaria apenas uma configuração no EventBridge para cuidar do acionamento.
Agora, e se você precisar que apenas algumas instâncias específicas funcionem em um período diferente? Faria outra função com outro EventBridge? E se você tivesse 100 instâncias, cada uma com um período de funcionamento diferente da outra? Já pensou como seria?

Objetivo

O objetivo desse Lambda é oferecer uma maneira de gerenciar o Start/Stop de suas instâncias EC2 em diferentes períodos de dias e horários, além de reduzir seus custos na AWS para ambientes onde você possa interromper esses recursos, como ambiente de DEV, homologação e outros usados para testes. Usaremos uma única função Lambda que irá filtrar as EC2 através de tags, sendo acionada de tempos em tempos conforme agendamento no EventBridge.

Vamos aos passos:

1 - Criar função IAM com permissões para a Função do Lambda.

A primeira parte será dar as devidas permissões para a execução da Função Lambda. Para isso, abra o console do IAM e clique em Roles no menu lateral esquerdo e depois em Create role.

Selecione AWS service, em seguida selecione Lambda e depois clique em Next.
Clique em Create policy. Uma nova guia será aberta, não feche a anterior. Clique na aba JSON da nova guia aberta e cole o seguinte código:

{ 
  "Version": "2012-10-17", 
  "Statement": [  
    { 
      "Effect": "Allow", 
      "Action": [ 
            "ec2:DescribeInstances",
            "ec2:DescribeTags",
            "ec2:DescribeInstanceTypes",
            "ec2:DescribeInstanceStatus",
            "ec2:StartInstances",
            "ec2:StopInstances"
      ], 
      "Resource": "*" 
    } 
  ] 
}

Clique em Next e avance para dar um nome para a Policy e depois clique em Create policy.

Volte na guia anterior, clique no botão de refresh e pesquise pela policy criada. Marque a caixa ao lado do nome da policy e selecione também a seguinte policy:

CloudWatchFullAccessV2

Dê um nome para sua Role e clique em Create role.
Mais detalhes sobre como criar uma Role, acesse esse link.

2 - Criar Função Lambda

Em Change default execution role escolha Use an existing role e selecione a Role que você criou no passo anterior. Feito isso clique em Create function.

Agora que você criou a Função, substitua o código de exemplo pelo código que está neste repositório.

Após inserir o código, clique em Deploy para Salvar as alterações.
Feito isso, vá para a aba Configuration e mude o Timeout para 30 segundos (pode ser necessário um tempo maior de acordo com a quantidade de instâncias do ambiente).

Ainda em Configuration, configure as variáveis de ambientes conforme a imagem a seguir:

ALARMS_MANAGER

Define se os alarmes do CloudWatch referente as instâncias serão habilitados/desabilitados junto com a ação de start/stop.

O valor chave True define que a fução irá alterar o status dos alarmes. Caso não queira alterar o status dos alarmes, altere o valor para False.

REGIONS

Define as regiões que a função irá percorrer e listar as instâncias.

O valor deve estar como uma lista de regiões da AWS, separadas por vírgulas (por exemplo: us-east-1,sa-east-1).

3 - Configurar EventBridge

Na parte superior da página da função, em Function Overview, clique em Add trigger.

Em Trigger configuration selecione EventBridge (CloudWatch Events). Crie uma nova regra, dê um nome para a regra e em seguida selecione Schedule expression para inserir uma Cron.
Aqui você pode configurar uma expressão que melhor atende a sua necessidade. Neste exemplo usei uma expressão que chamará a função Lambda de 5 em 5 minutos.

cron(0/5 * * * ? *)

Após inserir o valor clique em Add.

Para mais detalhes sobre Cron Expressions consulte este link.

4 - Adicionando Tags

Para incluir suas instâncias na rotina de Start/Stop é necessário adicionar Tags que definem o acionamento e os períodos em que serão executadas.

No console de gerenciamento do EC2, no menu lateral esquerdo selecione Instances. Selecione a instância que deseja incluir na rotina de Start/Stop, vá até a aba Tags e clique em Manage tags. Adicione as seguintes tags (alterando o período e os horários de acordo com sua necessidade) e clique em Save.

Scheduled      : Active
Period-1       : Monday-Friday
ScheduleStart-1: 08:00
ScheduleStop-1 : 18:00

A função tentará filtrar as instâncias que contêm uma Tag chamada 'Scheduled' definida como 'Active'.

A função utiliza um período de dias da semana para comparar a tag 'Period-x' e verifica se o dia atual está dentro do período. Se esta condição for atendida, a função irá comparar a hora atual (H:M) com um valor das tags adicionais que definem o gatilho 'ScheduleStop-x' ou 'ScheduleStart-x'.

IMPORTANTE!!!

As tags devem seguir a nomenclatura em inglês e são case-sensitive;
O período começa no domingo e termina no sábado;
O valor 'Period-x' deve estar no seguinte formato 'Sunday-Saturday';
O valor de 'ScheduleStop-x' ou 'ScheduleStart-x' deve estar no seguinte formato 'H:M';
O valor de ‘x' das tags 'ScheduleStop-x' e 'ScheduleStart-x' devem corresponder ao mesmo valor do 'period-x’;
Não há limite de períodos a serem adicionados;
Para acionar esta função, certifique-se de configurar o EventBridge para que seja executado em um intervalo de sua escolha (a cada 5 minutos é recomendado);
Esta função está configurada para funcionar com horário local (UTC-3).

current_time = datetime.now()-timedelta(hours=3)

Caso queira retirar uma instância da rotina, basta alterar a tag ‘Scheduled’ para ‘Inactive’.

Exemplos de tags de instância do EC2

Scheduled       : Active

Period-1        : Monday-Friday
ScheduleStart-1 : 06:00
ScheduleStop-1  : 18:00

Period-2        : Saturday
ScheduleStart-2 : 09:00

Period-3        : Sunday
ScheduleStop-3  : 02:00

Conclusão

Espero que este artigo possa ajudar a implantar uma rotina de Start/Stop de recursos de forma centralizada e simplificada.
Feedbacks são bem-vindos ;)