DEV Community: Isaque Alcantara

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 ;)