/blog

Muitas novidades: CloudTrail, cópia cofre, custos, LBs, RIs e agendador!

 

Segurança: melhoria na integração com CloudTrail

O Cloud8 atualmente integra diversos eventos reportados pelo AWS CloudTrail, principalmente os que dizem respeito à segurança: logins no console, mudanças IAM, chaves de acesso, roles, entre outros.

Continuamos a capturar mais e mais eventos técnicos e traduzi-los em linguagem de negócios. Isto é, por meio da auditoria você pode entender o que acontece no seu cloud com uma terminologia mais acessível e não restrita aos nomes das APIs utilizadas nos eventos.

Os novos eventos mapeados são os que apagam componentes: servidores, buckets S3, load balancers, discos, snapshots e imagens. No log você encontra informação de qual credencial realizou a remoção, mesmo que tenha sido externa ao Cloud8.

Esperamos trazer muito mais visibilidade do que ocorre no seu Cloud. Ao longo das próximas semanas devemos sempre incluir novos eventos.

Segurança: cópia cofre para todos os tipos de servidores

Em um post anterior,  havíamos anunciado o recurso de copia-cofre: cópiar um backup para uma outra conta AWS com credenciais super seguras para fins de business continuity. Dada a ótima receptividade incluimos suporte a todos os tipos de servidores, além de Linux e RDS que inicialmente eram suportados: Windows, Redhat, Suse e produtos do MarketPlace.

Agora não há mais poréns para não ter uma estratégia de business continuity!

Novos relatórios de custos

Melhoramos a visibilidade da evolução diária do custo do seu cloud.

Há serviços que o AWS só publica os custos em D+1 ou D+2. Por exemplo, backup, pois é necessário aguardar o término dos processos. Com isto, mostrando somente a foto do dia atual e do dia anterior distorcem-se tendências e análise.

Assim publicamos o histórico de 5 dias no relatóriopor email. Veja um exemplo:


As tendências ficam muito mais claras e facilita a análise.

Se você possui várias contas AWS, o relatório consolidado de custos também traz melhorias como ordenar pelos que tiveram maior variação de custos.

Agendador: busca e performance

Novidades aguardadas pelos clientes:

  • busca de eventos: busca pelo nome do agendamento que destaca os eventos:

  • performance: a criação de eventos recorrentes demora apenas alguns segundos e não há mais necessidade de aguardar;
  • múltiplas tarefas de conexão e desconexão de Load Balancers ficam mais claras dentro do Workflow;
  • suporte a 15 tarefas dentro de um workflow;

Consumo de RIs mais claro

Alinhamos novamente o Cloud8 com a evolução do modelo de RI (instâncias reservadas) do AWS. Caso um servidor (EC2 ou RDS) esteja consumindo horas de instância reservada, mostramos na coluna ‘Info’ como está o consumo no mês.

O consumo é representado por um medidor que informa a porcentagem de horas utilizada.

É possível fazer buscas por servidores que não possuem RI ou cujo consumo seja menor 25%, 50% e 75% ou que ainda esteja consumindo 100%.

Se precisar de um relatório mais detalhado para verificar o consumo geral, no menu esquerdo há a aplicação “Controle de RIs”. Este relatório ganhou uma forma simplificada de verificar todas as RIs e visualizar um resumo detalhado de como as horas são consumidas. Também colocamos mais uma coluna para dizer se a RI é do tipo “Standard” ou “Convertible”.

Melhoria no suporte a Load Balancer

O Cloud8 suporta Load Balancers Clássico e Application. Confiram as melhorias:

  • healthcheck: mostra se há algum servidor com problema – com a visão unificada multi-conta e multi-região fica muito mais imediato diagnosticar e tirar relatórios sobre custos, LBs sem uso, LBs com problema e assim por diante;
  • healthcheck: indica se é problema no LB ou em algum servidor associado a ele;
  • melhor identificação na lista quando é Classic vs Application;
  • exportação para inventário contém target groups (application) e servidores;
  • sincronização imediata – ao clicar em “Forçar imediatamente”, o Cloud8 verifica os provedores selecionados e atualiza todos os dados; LBs, Target Groups, instâncias conectadas, Health Checks, indicadores;
  • possibilidade de destruir um LB pelo painel do Cloud8;

Mais novidades

Continuamos a implementar novas melhorias em todas as funcionalidades do Cloud8.

  • Billing: suporte a AWS Cost Explorer, Cloud HSM, CodeDeploy;
  • Workflow: execução de script SSM agora tem time-out de 10 minutos se a opção for síncrona;
  • Aurora PostgreSQL: ajustes;
  • Backup report: não traz servidores que fazem parte de Auto Scaling, evitando falso-positivo;
  • Perfil read-only permite download do inventário dos componentes;
  • Filtro de snapshots sem política de retenção atrelada e portanto não serão apagados pelo Cloud8
  • Auditoria: stop de servidor inclui parâmetro indicando se foi parado à força;
  • Informação de servidor mostra quais discos são encriptados (já mostrava em discos);
  • Suporte a novo formato de ID (https://aws.amazon.com/about-aws/whats-new/2018/02/longer-format-resource-ids-are-now-available-in-amazon-ec2/) do AWS;
  • RDS: alerta de performance_schema corrompido;
  • Retenção de backups/imagens e snapshots seja por tempo ou GFS fica mais transparente nas listas de componentes.

Boas festas, novidades, tags/untagged, top 10 custos, manutenções AWS

Boas festas e expectativas para 2018

O Cloud8 (https://www.cloud8.com.br) faz 5 anos. Agradeço a todos os clientes pela confiança em nossos serviços ao longo desta jornada. A empresa que começou com o intuito de ajudar na gestão de Cloud, hoje é missão crítica para centenas de empresas de todos os portes. Sentimos muito orgulho de ajudar na economia de custos em um país com tantos desafios, melhorar a gestão de segurança e a continuidade de negócios.

Em 2018, esperamos fazer muito mais. Temos diversas novidades a serem lançadas no 1 trimestre que vão expandir escopo e beneficiar ainda mais os parceiros. Convido a todos a enviarem sugestões para nosso roadmap!

Boas festas e uma ótima passagem de ano!
Renato Weiner
CIO/Founder


Custos – componentes sem tags (Untagged)

As tags dos componentes tem sido cada vez mais usadas para controlar a alocação de custos. Se ainda não está utilizando ou quer melhorar o controle, seguem algumas dicas antes de falarmos de Untagged.

Dicas de uso de Tags

  • uma tag é definida por um par “Nome” e “Valor”. Ex: Nome -> Departamento. Possíveis valores: “Marketing”, “Financeiro”, “TI”, etc;
  • tenha uma política/processo de taggear tudo: servidores, RDS, discos e load balancers, etc -> tudo mesmo 🙂
  • defina como taggear sempre que um recurso novo é criado: Servidor, Disco, RDS, LB, etc
  • escolha as tags de acordo com o seu negócio: se trabalham por projeto, por cliente, por departamento, por centro de custos, por ambiente (producao/desenvolvimento), por equipe de devops, etc.
  • sugestões de “Nomes” de tags: ‘Ambiente’, ‘Aplicacao’, ‘Cliente’, ‘Custo’, ‘Empresa’, ‘Produto’, ‘Responsavel’, ‘Servico’, ‘CentroDeCusto’, ‘Stack’, ‘Tecnologia’, ‘Departamento’, etc
  • dá para usar múltiplas tags (não economizem 🙂 )
  • pode usar tags técnicas tb: Sistema Operacional, Banco de dados, NoSQL, WebFront, Cache, Tier, etc…

Limitações de uso:

  • o AWS não consegue pegar as tags de forma retroativa, então se mudar no meio do mês, ela começa zerada e no fim do mês vai ter uma parcial. Por isto é bom fechar de vez o conjunto de nomes e tentar mudar pouco;
  • não são todos os produtos que suportam tags. Ex: instâncias reservadas. Mas está melhorando a cada mês – o Cloud8 vai mostrar o que é taggeável e o que não é (ver Untagged abaixo)
  • maiúsculo, minúsculo: não misture maiúsculo e minúsculo, espaços em branco, acentos. Os nomes das tags são sensíveis aos caracteres e são tratadas de forma independente. Ex: “Cliente” e “cliente” são considerados tags diferentes.

Untagged – acompanhar o que não está taggeado

Criamos uma aplicação nova em “Análise de Custos”, aba “All – Untagged”. A idéia é mostrar todos os componentes que não possuem tags e que aparecem nos custos.

Veja algumas características da aplicação:

  • Pesquisar por tags – selecione uma ou mais tags e o relatório trará os componentes que não a possuem;
  • Dividimos em 2 partes: os serviços que o AWS não suporta cost allocation (ou seja, nem adianta perder muito tempo além de saber quais são) e os produtos em que há componentes sem tags – listamos os IDs;
  • à medida que vão arrumando as tags, o relatório de “IDs” deve diminuir. A edição de novas tags pode ser feita pelo console ou pelo próprio Cloud8 (nos componentes suportados por enquanto);
  • exportar os componentes que não possuem tags no formato CSV;
  • por default o Cloud8 vai trazer todos os componentes que não tiverem sido taggeados por vocês (isto é, ignoramos tags que começam com “aws:” e “rds:” que são tags que o AWS inclui automaticamente);
  • agendar o recebimento de um relatório diário (ou com a frequência que quiser) dos componentes que não possuem tags. Basta ir no agendador, e no combo “Componentes”, escolher “Relatórios”. Lá encontrarão o “Relatório: Recursos com ID não taggeados”.


Idéia de processo simples:

  • configurar o relatório com frequencia de 2 em 2 dias;
  • à medida que receber o email, taggear os componentes;
  • identificar algum cenário de provisionamento, auto-scaling que cria componentes sem tags e arrumar;
  • usar o relatório completo de tags (Dashboard -> Ícone relatórios -> Tags) para extrair o rateio de custos;

Tags + Perfis de acesso

É possível delegar a gestão das tags para outro time, como o financeiro, sem que eles tenham permissão para alterar a infraestrutura.

Dentro dos perfis de usuários, há ações que permitem a edição de tags.

Para criar um perfil financeiro + edição de tags, façam o seguinte para deixar mais organizado e flexível para o futuro:

  • no menu “Perfil de acesso”, crie um perfil “Finance” – com acesso a tudo ou somente um ou mais “Provedores” à escolha;
  • perfil “Servidores (Ações e Workflow)” conforme imagem acima;
  • perfil “DNS (Custom)” com as ações:”Editar Tags”, “Visualizar custos detalhados”;
  • perfil “Banco de dados (Ações)” com as ações: “Editar Tags”, “Visualizar custos detalhados”;
  • criar um usuário novo, associem os 4 perfis: Finance + Servidores + DNS + Banco de dados.

Análise top 10

Outra aplicação que criamos dentro de “Custos – Analytics”, chamamos de “top 10”. Inclui:

  • top 10 mais caros;
  • top 10 variações dos períodos selecionados (por default mês atual e mês anterior)

O objetivo é saber quais custos/uso que mais variam entre períodos. Há casos em que o aumento de um serviço é compensado pela diminuição em outro. Isto pode mascarar tendências e o entendimento dos custos que mais sofreram variações ajuda a um melhor controle.

A dinâmica funciona assim:

  • selecione a aba Top 10;
  • o top 10 variações mostra as variações do primeiro nível: produtos AWS ou tags nome/valor, etc;
  • baseado no que variou mais, pode expandir o nó da direita e reselecioná-lo em seguida – o top 10 é atualizado automaticamente;
  • avalie o top 10 mais caro, as variações e repitam a operação para detalhar a análise

Há opções de mudar entre “Custo” e “Uso” e o valor – por default colocamos 0.5 para tirar as variações enormes que podem ocorrer com serviços que estão próximos de zero. Mas nada impede de setarem o valor em 100 por exemplo, para pegar os maiores valores e assim por diante.

Filtro de manutenções AWS

O AWS enviou literalmente uma enxurrada de manutenções de servidores para as próximas semanas.

Para identificar se possui algum servidor nesta condição, pode usar um novo filtro da coluna “Info” da lista de servidores -> “Manutenção agendada”. Os servidores que tiverem manutenção aparecem com ícone de relógio . Ao passar o mouse, verá os detalhes de quando ela será realizada pelo AWS.

Caso queira antecipar esta manutenção – recomendado – basta realizar um stop/start da instância (ou mesmo reboot em alguns casos) que ela deve sumir. Pode ser feito manualmente (console ou Cloud8) ou usando as tarefas do agendador. Não esqueça de fazer backup antes!

Mais novidades

Continuamos a implementar novas melhorias em todas as funcionalidades do Cloud8.

  • Billing: suporte a Pinpoint, Cloud Directory, AWS Glue, Macie, Guard Duty, Comprehend, SageMaker, MQ, Alexa for Business e ECS;
  • Novos tipos EC2: g3, f1, x1e, x1, m5, c5 e h1;
  • Suporte a Aurora PostgreSQL;
  • Suporte a nova região de Paris (eu-west-3);
  • Billing: análise mostra SQS com IDs e tags, já que AWS agora suporta;
  • Métricas: suporte as dimensões CPUCreditUsage e CPUCreditBalance para tipos t2;
  • RIs: alerta de expiração de RI de Redshift;
  • IAMs: melhoria no relatório de IAMs com exportação melhor organizada e diagramada;
  • IAMs: inclusão de campo de MFA e busca por usuários que não usam;
  • Agendador mostra fim de semana com outra cor;
  • Cópia cofre: retenção com uso de GFS e opção de ‘não apagar’.

Obrigado!
Equipe Cloud8

AWS re:Invent 2017 – resumo e curiosidades

AWS re:Invent 2017

Fomos ao AWS re:Invent e novamente trazemos as impressões e curiosidades. Este ano, segundo o AWS, foram mais de 40k participantes e 1.000 sessões técnicas.

Para os anos anteriores, confira: 2013 , 2014, 2015 e 2016.

Detalhes das informações técnicas podem ser encontradas no AWS – https://aws.amazon.com/new/reinvent/ e canal no Youtube – https://www.youtube.com/user/AmazonWebServices/videos

Disclaimer: os comentários abaixo foram criados pelo Cloud8 e não representam qualquer posição do AWS.

Resumo estratégico

Em termos de inovação, este re:Invent escolheu focar em Inteligência Artificial – para ser mais correto e preciso, em Machine Learning – e evangelizar Serverless. Destaques ainda para banco de dados e preenchimento de lacunas de funcionalidades de diversos produtos além de integração global (multi-região).

Os keynotes foram bem interessantes. O Andy Jassy sempre ressaltando a liderança do AWS com gráficos do Gartner, ritmo de inovação, números gigantescos e os novos lançamentos. Este ano ele fez uma analogia dos ‘builders’ (desenvolvedores) com os músicos e explorou temas como totalidade de funcionalidades, inovação, liberdade, etc com um tema musical para ponto ressaltado. Casos de sucesso como Expedia, Goldman Sachs estão com estratégia ‘All-In’. Interessante notar que instituições bancárias estão migrando 100% para Cloud.

Já o Werner focou em evangelizar o uso do Lambda e do Alexa. Contou sobre a evolução dos serviços e que o AWS não impõe uma forma de desenvolver e sim, possui diversas ferramentas para se criar do modo que for melhor dentro da sua cultura. Frisou que a realidade atual do mundo corporativo é a ‘digitalização’ com o exemplo clássico da General Electric (GE) – era uma empresa de manufatura e um dia acordaram uma empresa de software e o mesmo ocorre com o Goldman Sachs, onde 1 em 4 funcionários é um engenheiro desenvolvedor. Em mundo onde os recursos estão disponíveis para todos (pelo menos em termos técnicos e não financeiros), o diferencial é a estratégia e execução – o ‘como’ usar estes recursos. Outro ponto realmente válido é que hoje as interfaces são centradas em dispositivos (machine-centric) e quando migram para human-centric, o seu apelo é muito maior e mais abrangente. Pessoas que não possuem acesso digital, especialmente nos lugares mais pobres do planeta, teriam muito
mais acesso a serviços por meio da interação por voz. Um caso de uso entre agricultores de arroz das Filipinas foi mostrado onde após a adoção de aplicação de voz, o sistema de escolha de ajuda no plantio foi realmente utilizado e os objetivos do governo finalmente alcançados. O Alexa é a implementação desta visão e agora vem com a versão business: Alexa for business. Ou seja, investimento pesado no Alexa e consequentemente um ciclo virtuoso: automação corporativa e caseira que puxa IOT, que puxa EC2 e Lambda, banco de dados, analytics e assim gira o AWS.

Na área de IA e Machine Learning, o AWS excedeu expectativas novamente. Dado que para o estado da arte de ML são necessários conhecimento e experiência profundos, o AWS procura popularizar e massificar o seu uso. Por meio do lançamento do SageMaker e ML Labs, basta (teoricamente) possuir uma massa de dados de boa qualidade, o AWS ajuda a definir e treinar o modelo preditivo de redes neurais, dinamicamente avaliando e melhorando a parametrização. Particularmente acredito que deva funcionar na grande maioria dos casos, mas a aplicação específica de frameworks e algoritmos pré-definidos pode não representar o ponto ótimo – mas enfim, se você tem a capacidade de mexer em nível mais aprofundado ou um parceiro especializado, talvez o SageMaker não precise estar no seu radar. A polêmica sobre esta ‘terceirização’ de AI já começou a gerar bastante discussão.

Cobrindo alguns gaps de outros recursos de inteligência artificial, foram lançados ainda produtos para transcrição, tradução e compreensão de textos, bem como reconhecimento de vídeo. Agora está nivelado com as APIs que o Google já possui (apesar de o suporte a línguas ainda não contemplar nosso português). Dado o histórico de integração com outros produtos, imagine o que a automação de tarefas de linguagem poderá fazer quando for integrada ao serviço de Call Center (Connect) ou com a criação de bots?

O que particularmente impressionou foi na área de banco de dados e o Andy Jassy não podia deixar de fazer suas tradicionais piadas sobre a Oracle e o Larry Elisson… Esta motivação de destronar a Oracle, está trazendo uma gama enorme de novas funcionalidades para o Aurora e o DynamoDB. Pois bem, lançaram o Aurora Multi Master e em breve o Aurora Serverless (mais detalhes nos destaques). O DynamoDB vem replicação multi-região (global) e backup – não podemos esquecer do Cloud Spanner do Google e o do CosmosDB do Azure que já são globais. Vai dar pra fazer query (select) no S3 e acreditem… no Glacier! Nem GraphQL escapou – novo produto Amazon Neptune. Enfim, banco de dados está realmente bem servido no AWS.

Serverless, anunciado no fim de 2014, teve um salto no suporte e casos de uso. Já começa a ficar mais robusto e definido. Lambda é utilizado em funções simples de negócios, analytics, processamento de dados (imagens, textos, etc), mapeamento em APIs, devops e diversos outros tópicos. O suporte a linguagens foi estendido com a adição de .NET 2.0 Core e Go. Várias outras melhorias foram incorporadas, desde um novo ambiente de desenvolvimento online – Cloud9 (perguntem ao George Harrison e não a mim o porquê do nome 🙂 ), refatoração do console, SAM local, etc (mais detalhes neste newsletter). Enfim, facilitadores para a adoção do desenvolvimento. Entretanto, por mais claro que sejam os benefícios, Lambda não é solução para tudo – muito pelo contrário, sistemas com regras de negócios complexos e interações com banco de dados SQL, baixa latência por conta destas regras, legados, etc tem que ser estudados
cuidadosamente para implantar Lambda – possivelmente alguns processos, mas dificilmente o sistema inteiro. Por fim, há a questão do ‘Lock in’. Se existe a intenção de continuar com liberdade, deve-se avaliar usar funções que possam ser executadas em um Lambda e em um servidor independente. Logicamente há muito espaço para discussões e polêmicas sobre prós e contras, mas este não é o lugar – talvez em um futuro newsletter.

Destaques e lançamentos

Muitos serviços e melhorias. Veja a lista oficial completa. Abaixo, nosso resumo e comentários.

  • EC2 Compute. Lançamento de novos tipos – c5, m5, h1, i3m (bare metal). Novo placement: ‘spread placement’ – garante que 2 ou mais VMs não caiam no mesmo servidor físico e assim evitar uma pane geral em caso de falha. Launch templates – pré-configurações de instâncias EC2 com todos os parâmetros possíveis e ainda permissionamento para usuários IAM de autorizar ou não o uso – simplifica muito o processo de gestão de criação dos servidores. Apesar de todo o hype em torno de Lambda, EC2 ainda é o principal serviço e o investimento continua. Os novos tipos rodam em cima de um novo
    hypervisor e são muito mais performáticos em termos de rede e latência – em um mundo de microserviços e arquitetura distribuída, uma rede rápida é requisito básico. Estes tipos novos com ENA (Elastic Network Adapter) resolvem um problema de latência de rede e jitter e faz o AWS novamente competitivo frente a rede do Google;
  • T2 Unlimited. o AWS resolveu um problema que os usuários de instâncias T2 podem sofrer: servidor pode não funcionar bem uma vez que os créditos de CPU são consumidos. Para evitar que isto ocorra, agora você marcar uma instância T2 como ‘unlimited’. Se houver mais uso do que o permitido, AWS irá cobrar um ‘extra’ – logicamente ainda é necessário dimensionar o servidor. Um t2.nano com ‘unlimited’ usando picos o tempo todo, ficaria muito mais caro que um t2.medium por exemplo;
  • EC2 Spot. o AWS facilitou a utilização do EC2 Spot Market – criar instâncias em um mercado de preço variável baseado na disponibilidade de computação. Já dá para lançar um novo servidor sincronamente sem especificar o preço e o AWS irá utilizar o melhor custo para você. Como é o AWS quem escolhe o preço, ele pode hibernar a instância no lugar de terminá-la (novidade!) a qualquer momento (a variação do preço do Spot também deve mudar para ficar menos sujeita a grandes variações – novidade também!). O efeito desta popularização do spot é que o preço médio do mercado já subiu… veja o histórico de uma instância c4.large em Virgínia pelo console. Os usuários pesados de Spots no modelo antigo não vão ficar muito felizes;
  • Aurora Multi Master. o Aurora é um dos serviços que cresceu mais rapidamente dentro do AWS. Compatível com MySQL ou PostgreSQL, suporta qualquer software que faz uso destes bancos. A novidade é retirar da topologia atual o ponto único de falha (ainda que se tenha Multi-AZ e o chaveamento de falha leve alguns segundos) introduzindo o Multi Master – espalhar servidores que aceitam transações em diversas zonas de disponibilidade acabando com este problema. Estamos ansiosos para usar a versão global – multi-região – que deve vir em 2018;
  • Aurora Serverless: versão do Aurora que escala automaticamente dependendo da quantidade de transações/requisições. O modelo é bem parecido com o DynamoDB, onde é definido a capacidade por ‘unidades’ e o AWS faz o auto-scaling automático. Será interessante testar como a escalabilidade acontecerá, já que a contrário de um Auto-Scaling de servidores onde a criação de novas instâncias pode levar alguns segundos, um pico de banco de dados tem que ser tratado de imediato, em milisegundos, caso contrário, a aplicação pode se perder;
  • DynamoDB Global Tables e backup/restore: como o próprio nome já diz, as tabelas DynamoDB podem ser configuradas para serem globais (multi-região), não só read-only, mas transacional. O fim da replicação “manual”!. O benefício imediato é alta disponibilidade entre regiões e latência minimizada. O AWS preenche uma lacuna e não fica mais atrás do Cosmos DB da Microsoft e o do Cloud Spanner do Google (se bem que este último tem SQL, mas com o Aurora Multi-Master entre regiões, isto também deve ser resolvido). E finalmente, o imprescindível lançamento do backup/restore de tabelas – difícil imaginar como demorou tanto e como as empresas lidavam com suas soluções caseiras… – mas enfim, ponto extremamente positivo!
  • S3 e Glacier Select. Capacidade de fazer queries dentro de objetos do S3 e do Glacier. Não é necessario acessar objeto por objeto e inspecionar o conteúdo. Com linguagem SQL, você pode encontrar dados mais facilmente. Imagine a quantidade de casos de uso que podem ser criados com esta função;
  • Neptune e App-Sync. Suporte a GraphQL. Mais uma forma de manipular dados, especialmente mobile. Ajuda quando se tem vários “data sources” (banco de dados) e no push real-time de atualizações para diversos dispositivos;
  • SageMaker: quem já experimentou criar modelos de Machine Learning ou análise preditiva, sabe que como é difícil, demorado e frustrante encontrar a parametrização com melhores resultados. Como mencionado na parte de ‘Estratégia’, o SageMaker procura resolver este ciclo treinando a massa de dados fornecida e criando o melhor modelo automaticamente. Acredito que seja interessante testar e dependendo do resultado e aprendizado, buscar descer um nível, compreender os frameworks e algoritmos ou buscar um parceiro para avançar no modelamento;
  • IA: Translate, Transcribe e Comprehend: mais um conjunto de serviços para preencher a lacuna de linguagem natural. O AWS já possuia serviços de reconhecimento de voz e construção de bots (Lex) e agora fica mais completo, se igualando ao Google. Como o próprio nome indica são serviços de tradução, transcrição de voz para texto e compreensão (para não deixar muito aberto, o foco aparentemente é análise de sentimento, mas também há mapeamento de palavras chaves e entidades). O grande ponto pendente ainda é o suporte a Português que ainda não há previsão infelizmente;
  • IA: Video Rekognition: reconhecimento de padrões dentro de vídeo. Como bem apontado pelo Matt Wood, reconhecimento dentro de vídeo é bem mais complexo do que imagem estática e a ideia é trazer os labels e as taxas de confiabilidade ao longo do tempo do vídeo. E dado que vídeo pode gerar um stream de dados realtime com muita informação, lançaram o Kinesis Video Stream para facilitar. Combinado com o Transcribe e Comprehend para análise de sentimento dá para pensar em muitos casos de uso. Aliás, fico imaginando se o Amazon Go não utiliza exatamente esta combinação de serviços e desta forma estaria viabilizando a implementação de clones…;
    * Fargate: gestão automática dos containers. Retira a liberdade de se usar os tipos de instâncias que pode usar, mas se ganha escalabilidade automática. Também faz cobrança por segundo como no modelo de controle das tarefas com instâncias EC2. É perfeitamente possível ter um ambiente com tarefas/containers gerenciados via ECS e outro por Fargate;
  • Kubernetes: um dos anúncios mais comemorados foi o lançamento de gerenciamento de Kubernetes – o AWS gerencia, atualiza e escala automaticamente clusters de containers com Kubernetes. Segundo o AWS, como já rodam mais Kubernetes que qualquer outro provedor, é natural que façam a gestão. Na sessão ‘Deep dive in Kubernetes’, ficou claro que ainda há muito trabalho a fazer: melhor integração com rede, suporte a Windows, upgrades major, Multi-region, híbrido, etc, mas a sinalização de ter um componente a menos para gerenciar já deixou a comunidade animada. Vai ser integrado ao AWS Fargate;
  • VPC Peering global: capacidade de fazer peering, isto é interconectar, VPC de diversas regiões e integrá-las sem a necessidade de roteamento para IPs públicos e outros componentes como gateways, NATs, que aumentam a complexidade e inserem pontos de falha na topologia de rede;
  • Alexa for business: Utilização do Alexa em ambiente de negócios. Casos de uso principal é um assistente pessoal para o dia a dia: reuniões, calendário, alertas. Integrado a aplicativos como Office 365, G-Suite, Exchange, Salesforce, etc. Procura resolver o desafio que é sempre se juntar a um conference call – PINs, URLs, softwares, etc. O vídeo exemplo mostrou que este processo é transparente no momento da reunião. Não funciona com português e não foi passado nenhum horizonte quanto ao suporte;
  • Private Link: ideia interessante de conectar produtos de parceiros – SalesForce, Twilio, etc – dentro da sua VPC privada, sem precisar sair para internet com IPs públicos, ainda que o tráfego seja encriptado. Expande radicalmente o conceito dos Private Endpoints para os serviços AWS. Com o AWS já suportando peering global entre VPCs (ainda não suporta para São Paulo), será interessante testar se seremos capazes de chegar em um private link diretamente do Brasil!
  • Guard Duty: serviço de detecção de anomalias de segurança. A ideia é por meio de diversos logs gerados pelo AWS – VPC flows, CloudTrail, DNS, etc verificar possíveis ameaças e alertar o administrador. Vale verificar os custos antes de usar;
  • Snapshots: em uma sessão de melhores práticas de snapshots, o gerente de produtos do AWS mostrou que existe uma possibilidade de falha de 0,1-0,2% nos discos – https://aws.amazon.com/ebs/details/ – ou seja, é imprescíndivel ter backups períodicos pois o AWS não se responsabiliza por perda de de dados;
  • CloudFormation: melhoria apontadas – CF pode ser configurado para não remover componentes quando o stack é destruido, stacksets para representar pedaços da arquitetura, multi-account e multi-região, suporte a quase todos os produtos (inclui IOT, Lambda e ECS), policies em vários níveis (stack, resource level), checagem de mudanças antes do commit, integração com AWS Config. O melhor foi o anúncio para 2018, do que foi chamado de ‘Drift detections’, quando será lançado a detecção de mudanças no stack comparado ao ambiente que está sendo executado. Muito útil para manter o template atualizado e controlado;
  • AWS Amplify: framework em javascript que funciona com React e o novo App-Sync (GraphQL) para criação de aplicações web/mobile. O demo mostrou que é muito poderoso e de fácil uso. Para conferir – https://github.com/aws/aws-amplify;
  • Governança e Complaince: tópicos menos populares mas mais importantes em geral. AWS sempre fala sobre o ferramental: Service Catalog, SSM + Parameter Store (interessante – vale conferir para guardar parametros como senhas encriptados com KMS e centralizados em um repositório para reuso), CloudFormation, AWS Config, Inventory, CloudTrail. Gestão não pode ficar em segundo plano comparado ao desenvolvimento;
  • Serverless: lançamentos de suporte a .NET 2.0 Core e Go. Cloud9 – IDE de desenvolvimento web. Aumento de memória para 3GB e melhorias no console. Dead queue process (se Lambda falhar, joga para uma fila SQS). Criação de um repositório de lambdas onde se pode reutilizar ou aprender com o código de terceiros, uma espécie de MarketPlace;
  • IOT: evolução dos serviços com lançamento de diversas melhorias: 1-Click, Device Management, Device Defender (sobre segurança em dispositivos, evitar os famosos DDOS feitos por ‘torradeiras’…), Analytics. O ponto alto foi o lançamento de uma versão do FreeRTOS – sistema operacional de dispositivos que possuem um microcontrolador – com suporte direto aos serviços AWS. Isto amplia enormemente as possibilidades de conexão de dispositivos ao AWS;
  • VMWare e Hyper-V: a integração continua acontecendo, com a disponibilização do VMWare na região de Virgínia. Também foi anunciado que o serviço de migração de VMs suporta Hyper-V ;
  • HPC: anunciado bibliotecas MPI otimizadas para arquitetura AWS;
  • Lightsail: Load Balancer com preço definido para LightSail – infelizmente ainda não há LightSail na região do Brasil;
  • Time Sync Service: novo serviço de NTP (chrony) para sincronizar relógio de máquinas. Acessível via VPC e não precisa rotear para a internet, diminuindo complexidade de rede e aumentando segurança;
  • MarketPlace: no evento de parceiros, foram anunciadas algumas novidades para o MarketPlace – suporte a produtos com múltiplos AMIs, preços privados (isto é, com desconto para quando se tem escala), bem como um SAAS Factory a ser anunciado em 2018 que pretende ajudar a levar softwares para a nuvem em modelo multi-tenant;
  • AWS Elemental. Conjunto de funcionalidades para trabalhar com vídeo. Novidades e criação de uma camada de gerenciamento no topo de produtos já existentes (Transcoder, S3, etc);
  • Siemens Mindsphere: a Siemens anunciou uma parceira com o AWS para IOT. Para quem trabalha com manufatura e IOT vale avaliar;
  • Integração com Office 365: é fato consumado a relevância e importância do Office 365. Para evitar que os clientes usem o AD do Azure, o AWS investe em integração. Uma palestra discorreu sobre os passos de conexão e também sugeriu um tutorial. Notem que é longe de ser trivial, mas é possível. Na sessão ficou claro que ainda há muito o que fazer e a idéia é facilitar o trabalho conjunto;
  • Múltiplas contas. Em diversas apresentações o uso de múltiplas contas no AWS para uma mesma empresa ou parceiro, já é tratado com bastante naturalidade. A funcionalidade de organização permite criar contas facilmente com o billing já consolidado. Exemplos de contas foram desde as tradicionais contas de ‘produção’ e ‘desenvolvimento’, a conta exclusivas para rodar Active Directory, Banco de dados, etc. Sempre com a ideia de segmentação de ambientes por equipe, segurança, custos, facilidade de gerenciamento, controle de custos, cópias cofre. Se ainda não tentou trabalhar desta forma, faça um teste;
  • Anti-patterns: uma das melhores formas de aprender é procurar entender o que não fazer e aprender com os erros – casos de sucesso são interessantes, mas podem não contar toda uma estória. Assisti uma sessão (GPSTEC302) sobre problemas frequentes muito interessante. Foram listados 4 anti-patterns: perda de controle (quando credenciais se espalham, há riscos de segurança e eventual disrupção de algum serviço – daí a importância de fazer cópias cofre para outras contas AWS), controle de atualizações (pode ser mitigado pelo AWS Config e por ferramentas terceiras), DR automatizado (CloudFormation é uma excelente alternativa e minimizar o uso do console para mudanças manuais – sim… o engenheiro do AWS falou para não usar o console 🙂 ), teste de backups (o seu backup só é válido depois que testar, enquanto isto, não dá para afirmar se funcionou). Particularmente, ficamos muito orgulhosos por entender que o Cloud8 ajuda em todos os 4 anti-patterns e que corrobora o nosso roadmap de lançamentos!
  • AWS Well Architected: melhores práticas de arquitetura no AWS. É uma coleção de dicas ou ‘musts’ se preferir, sobre como usar melhor o AWS – operational excelence, security, reliability, performance efficiency e cost optimization. Vários tópicos podem ser encontrados no treinamento online e gratuito.

Curiosidades

Como não podia deixar de ser, uma enorme quantidade de curiosidades foi dita ao longo do evento. Selecionei algumas interessantes:

  • Novo hypervisor: O AWS não usa mais o Xen e passou a usar KVM. Mas ao que tudo indica desenvolveram o próprio, com codinome Nitro, que é uma camada mínima entre kernel, VM e hardware. Rede, por exemplo, acessa diretamente o hardware, sem subsistemas virtualizados – algo parecido com o Andromeda 2.1 do Google (só hypervisor, sem contar protocolos privados de rede e hardware próprios);
  • Cloud9. o AWS adquiriu uma empresa que possui uma IDE online – www.c9.io e integrou ao Lambda e ao CodeStar com todo o ferramental de ALM, CI/CD. O nome se deve, provavelmente, a um disco do George Harrison ou a expressão de ‘felicidade extrema’. Cloud8 foi escolhido por conta do número 8, em alusão ao símbolo matemático de infinito para indicar múltiplas funcionalides e integrações;
  • Segurança é responsabilidade de todos: o Werner insistiu na co-responsabilidade de todos em relação a segurança. Como infra, devops e desenvolvimento ficam estrelaçados, a responsabilidade por pensar e agir de forma segura não pode ser desacoplada para uma equipe dedicada;
  • Diversidade. Muito gratificante ver o AWS trazendo várias mulheres para palestrar e divulgar o seu trabalho. O Brasil também foi representado pelo Danilo Araujo em uma sessão sobre diversidade, apresentando o seu trabalho no AWS Meetup de São Paulo e Cloud Girls São Paulo;
  • Matt Wood, responsável agora pelo linha de inteligência artificial, mostrou um artigo de Machine Learning, onde um dos autores era a Kristen Stewart, a Bella do Crepúsculo (sic);
  • DeepLens – é uma nova câmera com capacidade de rodar modelos de machine learning embutidos (Greengrass ML Inference) em seu hardware e se conectando ao SageMaker. O Matt Wood mostrou a arquitetura de hardware e ideias para casos de uso – percebeu algo, dispara um Lambda. Quem diria que a Amazon atropelaria Google e Apple em Home Automation. Em pré-sale no amazon.com ;
  • Neural Style Translator: aplicar redes neurais com o estilo de um autor a uma imagem – https://deepart.io/ – muito bacana! Para referência de um projeto open source com TensorFlow – https://github.com/anishathalye/neural-style;
  • ML Labs: AWS lançou um Lab para quem quiser submeter casos de uso de IA. A ideia é ajudar a desenvolver o modelo e soluções em conjunto;
  • MapBox: descobrimos quem foi o primeiro cliente do SnowMobile (lembram do caminhão com dezenas de SnowBalls?) – MapBox. Eles moveram 100 PB de dados para o AWS;
  • Esportes: 2 cases de aplicação de inteligência artificial em esportes. Vídeos: NFL Next Gen Stats e UFC (simulação de luta ao vivo bem bacana!). E claro também tem para futebol – HUDL ;
  • Quotes:
    + “We are responsible for the security of the cloud.” – Werner Vogels, CTO do AWS;
    + “Dance like no one is watching, Encrypt like everyone is” – Werner Vogels;
    + “Security is everyone’s job” – Werner Vogels;
    + “Chaos doesn’t cause problems, it reveals them”. – Nora Jones, Netflix Engineer
    + “There’s no compression algorythm for experience” – Andy Jassy, CEO do AWS – antiga, mas ele sempre repete…;

Enfim, novas oportunidades foram criadas e mais desafios para o dia a dia de todos.

Contem com o Cloud8 para ajudá-los neste ônus administrativo e de automação, bem como tirar vantagem da atualização constante da nossa plataforma!

Fiquem à vontade para compartilhar! Dúvidas, críticas ou sugestões, entre em contato.

Obrigado
Renato
CIO/Founder

Novidade: continuidade de negócio / Cópia cofre

Novidade: + Continuidade de negócios / cópia cofre

Dados são tecnicamente a parte mais importante do seu negócio. Processos, proteções, contingências são termos de ordem responsável e vitais. Não é simples desenhar estes processos e contingências, mas estar em um Cloud como o AWS facilita e viabiliza tudo isto.

O Cloud8 já suporta diversos aspectos que ajudam na continuidade do seu negócio:

  • inventário de componentes;
  • auditoria e documentação de configurações de infraestrutura;
  • backups e snapshots;
  • cópias para outras regiões para fins de Disaster Recovery;
  • execução automática de scripts em servidores;
  • monitoração de acessos e mudanças;

Entretanto, mesmo que tenha cobertura técnica e de processos em sua totalidade, ainda há o risco de segurança ao se manter tudo em uma única conta – imagine que apesar de todos os processos e esforços que realize, um login ou uma credencial seja perdida e um acesso indevido é feito ao seu Cloud. Com má intenção, haveria a possibilidade de destruição de todos os componentes e dados….

Nota importante: este risco deve ser mitigado com melhores práticas de segurança: políticas e trocas constantes de senhas e chaves de acesso, uso preferencial de IAM Role, MFA habilitado, não usar conta Root, VPC gateways, monitoração de acessos e mudanças, etc.

Com estas premissas em mente, lançamos a cópia de segurança de backups (cópia cofre) para outras contas AWS.

O princípio é simples: realizar a cópia de um backup EC2 e/ou RDS para outra conta AWS de forma manual e/ou automatizada/agendada.

Esta outra conta AWS deve ter políticas e processos de segurança ainda mais restritos que as contas principais. Por exemplo: senhas restritas a poucos profissionais, política de retenção com mais dias, acessos de pontos ultra seguros, monitoração contínua e por aí vai.

Esta funcionalidade já está habilitada em todas as contas no Cloud8, sem custo adicional. Tanto para EC2 e RDS. O requisito para usá-la é possuir uma outra conta AWS, de preferência criada para ser utilizada exclusivamente como ‘cofre’.

É muito fácil criar esta conta no AWS – na opção ‘Organization’ do console AWS, crie uma conta AWS nova. Depois sincronize com o Cloud8 (na lista de ‘Provedores’, clique em ‘Novo’).

Após a criação da nova conta AWS e sincronização no Cloud8, é necessário habilitar as permissões de segurança:

  • na conta onde são realizados os backups: ec2:ModifyImageAttribute, ec2:ModifySnapshotAttribute, rds:ModifyDBSnapshotAttribute e rds:ModifyDBClusterSnapshotAttribute
  • na conta nova, destino da cópia de segurança: ec2:CopyImage, rds:CopyDBSnapshot, rds:CopyDBClusterSnapshot

A criação dos agendamentos também é simples. Pode criar novos ou editar um agendamento de backup existente e incluir uma nova tarefa “Cópia de segurança” no fim deste workflow.

Com a cópia armazenada na outra conta, pode recriar servidores e ainda recuperar os dados caso sua organização precise.

Planejamos diversas outras funcionalidades para copiar dados de uma conta AWS a outra. Aguardem!

Suporte a ALB, novos perfis, tags, relatórios de gestão

Suporte a ALB

O AWS lançou a nova geração do seu Load Balancer, o Application Load Balancer – ALB. A sua principal característica é o roteamento de tráfego na camada de URL/Domínio – na prática, rotear as requisições dos clientes para grupos de servidores respeitando regras, como “/application”, “/images” e/ou “dominio.com.br”, “dominionovo.com.br”. Estas novas rotas e regras são mapeadas por ‘Target Groups’ que determinam um ‘de-para’: chegou uma requisição, aplicam-se regras e esta é entregue para um dos servidores conectados ao Target Group. Um ALB pode ter múltiplos Target Groups e assim rotear tráfego de URLs distintas para endpoints distintos e especializados.

O antigo, Clássico, roteia somente para “portas”, como 80 (HTTP) e/ou 443 (HTTPS).

Dado o ganho de flexibilidade e escalabilidade, o uso do ALB se tornou bem popular e agora o Cloud8 já o suporta assim como já suportávamos o Load Balancer clássico.

Veja o que já é possível fazer:

  • visualizar os detalhes: Target Groups, servidores conectados, zonas de disponibilidade e VPC subnets;
  • conectar e desconectar servidores a um Target Group específico;
  • alertas se há problemas com Connection Draining e/ou política de SSL escolhida;
  • edição de tags (veja próximo tópico sobre as tags);
  • visualização dos grupos de segurança aos quais o LB está conectado no gerenciamento de SGs;
  • visualizar e analisar os custos detalhadamente;
  • agendamentos de conexão e desconexão.

Confira os agendamentos para ALB:

Há diversos casos de uso para se usar agendamentos com Load Balancers:

  • otimização/economia de recursos ao consolidar o tráfego para menos servidores em um determinado horário;
  • orquestração para upgrade/downgrade de servidores. Workflow: desconectar do LB -> parar servidor -> (que tal um backup assíncrono?) -> upgrade/downgrade -> ligar servidor -> conectar ao LB. Repetir para o segundo servidor apos 15 minutos e assim por diante;
  • integração contínua com execução de EC2 Commands e conexão/desconexão a LBs em um workflow programado toda a noite;
  • o seu caso de uso!

Perfis: novas ações

Já havíamos anunciado anteriormente o suporte a perfis com ações do agendador para servidores EC2. Agora já suportamos para ações de RDS como parar/iniciar – delegue a gestão da economia para os times e/ou responsáveis.

Além disto, criamos mais ações por perfis e auditáveis no log:

  • edição de tags dos componentes;
  • edição de grupos de segurança conectados a servidores – somente grupos que estejam conectados a servidores à sua escolha;
  • visualização de discos conectados aos servidores com permissão;

Caso de uso interessante: temos clientes que criaram usuários que combinam perfil ‘financeiro’ (com permissão de análise de custos) e com perfis de edição de tags de todos os componentes. Com esta configuração, o próprio pessoal do financeiro pode gerenciar a alocação das tags sem onerar tempo e recursos de TI.

Nota: se utilizar o Cloud8 na forma WhiteLabel (https://painel.cloud ou URL própria), pode produtizar o agendador e oferecer mais funcionalidades para o seu cliente final. É possível combinar este perfil com outros como gerenciar DNS, Banco de dados, métricas, etc – customize um painel de controle por usuário/cliente!

Tags: Load Balancer e Route53

Uma das melhores práticas recomendadas pelo AWS é o uso de tags em todos os componentes. Seja para fazer o rateio ou para acompanhar o custo e consumo de um determinado recurso.

O Cloud8 passa a suporte a edição de tags nos Load Balancers (seja Clássico ou Application LB) e nas zonas de DNS do Route53 – este último é particularmente difícil de fazer pelo console AWS (sic – deveria ser simples, mas não é…) e que geralmente é deixado de lado na maioria dos clientes que encontramos. Não deixa de usar tags nos domínios!

Novos relatórios de gestão

O Cloud8 lançou recentemente relatórios de gestão que permitem o acompanhamento em forma de resumo e dados de gestão de diversos cenários:

  • Backup status – quem está sem backup;
  • Tempo ligado dos servidores – habilitado a pedido;
  • Inventário de backups/snapshots por período;
  • Resumo dos custos de todas as contas AWS e estimativas;
  • Rateio do próprio Cloud8 para fins de multi provedor- habilitado a pedido;
  • Servidores parados há muito tempo;

Nesta nova versão, habilitamos mais 2 relatórios:

  • Agendamentos executados por período – pode optar por receber todos ou somente que apresentaram erro no AWS ou algum tipo de alerta;
  • Componentes sem tags – mais detalhes no próximo post!

Precisa de mais algum relatório? Fale conosco!

Outros

Seguem outras melhorias e correções que merecem destaque:

  • Suporte a nova zona de disponibilidade em EUA-Virgínia – us-east-1f;
  • Suporte a nova zona de disponibilidade na Alemanha – eu-central-1c;
  • Custos: análise de custos para AWS Lambda mostra custos e uso quebrado por região e nome da função chamada;
  • Custos: análise de custos para ElastiCache mostra custos e uso quebrado por região e nome do cluster;
  • Custos: suporte a Chime Dialin;
  • Dashboard de componentes não utilizados mostra o custo acumulado do quanto pode ser economizado;
  • Refactoring da aplicação de custos (Custos EC2/RDS) para ficar mais rápida e com melhor controle sobre os filtros;
  • RDS: suporte a mais eventos de erro como falha de option groups, instalação de Oracle em tipo não compatível. migração para Aurora com falhas, falta de capacidade no AWS para upgrade/downgrade;

Dúvidas, críticas, sugestões? Entre em contato!

Att
Equipe Cloud8

Novidade: Suporte a start/stop de RDS. Muito mais economia!

Uma das principais vantagens do Cloud Computing é pagar somente pelo recurso que utiliza.

No caso de servidores EC2, instância ligada é cobrada as horas de uso, desligada não. E para gerar este tipo de economia deve-ser ter uma forma de sempre de desligar e ligar a infraestrutura. Pode se fazer de forma manual, com scripts internos ou então utilizar um produto focado em trazer economia como o Cloud8.

Desde o começo de nossa operação, temos trazido esta economia com workflows agendados de ligar e desligar servidores EC2 (bem como upgrade/downgrade) e, no RDS, com upgrade/downgrade e ativação/desativação de MultiAZ. Confira o histórico:

https://www.cloud8.com.br/blog/como-economizar-na-nuvem-aws-da-amazon-usando-o-agendador-do-cloud8/

https://www.cloud8.com.br/blog/rds-economia-com-upgradedowngrade-automatizado-nova-regiao-frankfurt/

Quem passou a usar esta estratégia, imediatamente passou a economizar e diminuir os custos. Mas sempre ficou uma pergunta no ar… será que não dava para parar RDS também? Pois bem, o AWS acaba de lançar a funcionalidade de stop/start de RDS e já suportamos!

Aproveite os fins de semana e horários não comerciais, pare suas instâncias RDS e economize.

Desligando aos fins de semana (sexta 19:50 as seg 07:05): > 30%
Desligando aos fins de semana (sexta 19:50 a seg 07:05) + horário comercial (19:50 as 07:05): > 55%!

Suportamos de forma manual e agendada dentro de um workflow. Veja como ficou a lista de tarefas para montar o seu workflow agendado de RDS:

A configuração é imediata: entre no agendador, mude a visualização de componentes para ‘Banco de dados’ e selecione os servidores que deseja parar/iniciar.

Nota: só é possível parar um banco configurado como SingleAZ. Neste cenário, monte o seu workflow com uma primeira tarefa de Upgrade/Downgrade desmarcando o MultiAZ e logo em seguida uma tarefa de parar o banco de dados.

Não perca tempo e esforço desenvolvendo scripts, monitoração, auditoria, acompanhando atualizações de APIs e fazendo tratamento de erros inesperados!

Att,
Equipe Cloud8

PS. Se você utiliza uma credencial IAM customizada para o Cloud8, insira 2 permissões:
rds:StopDBInstances
rds:StartDBInstances

O Cloud8 cobra R$0,019/h (1,9 centavos/h) para uma instância RDS ligada. Para RDS desligado, cobramos R$0,009/h (0,9 centavos/h). Ou seja, usando o Cloud8 para economizar no AWS, também economiza no próprio!
Ainda não é cliente do Cloud? Faça um trial gratuito e completo sem compromisso!

Perfil workflow, tags/rateio de Snapshots, família de RIs, Queue Length

Instâncias Reservadas: suporte a família de instâncias

O AWS sempre tem evoluído e melhorado o seu modelo de instâncias reservadas. No começo era necessário comprar uma RI escolhendo, entre outros parâmetros, tipo e zona de disponibilidade. Flexibilizou-se então a alocação genérica dentro da região e mais recentemente o modelo passou a valer para qualquer tamanho dentro do tipo de família – entenda-se por família, o grupo que a instância faz parte, por exemplo, família T2: t2.nano, t2.micro, t2.small, t2.medium, etc.

Para mais detalhes do modelo técnico, veja o post oficial sobre as RIs. É importante notar a questão dos pontos/peso por tipo de servidor.

Com esta mudança o que é importante avaliar?

  • além de verificar o tipo de instância, cheque se possui outros tipos dentro da mesma família – pode ganhar com otimização de custos usando ‘famílias’;
  • está mais tranquilo comprar uma RI. Se precisar fazer um upgrade (dentro da mesma família) a RI ainda consumirá horas parciais sem perder o investimento;
  • entendimento da alocação: conceito de horas parciais – uma instância pode consumir 0,5 hora de RI e 0,5 hora sob demanda;
  • nem sempre comprar instância reservada pode ser vantajoso – verifique se uma estratégia de parar/iniciar servidores (ou mesmo upgrade/downgrade – especialmente se trocar a família) não fica mais em conta.

O Cloud8 pode ajudá-lo a entender como o AWS aloca as horas: quais são os servidores utilizados e como o AWS distribui horas/pontos dentro das famílias e regiões. Veja como ficou a aplicação de ‘Controle de RIs’.

Neste cenário, 2 instâncias m3.medium equivalente a 1488 horas no mês ou 2976 pontos (medium = 2 pontos) foram compradas. O AWS distrubuiu o uso em 5 servidores, sendo um deles m3.large que consumiu 100h de m3.medium (50 horas cheias de m3.large na prática). Notem que não há critério em como o AWS alocou as horas, mas é importante ver que o uso foi 100%, sem desperdício!

Também agrupamos o relatório por Auto Scaling Groups no lugar de mostrar instâncias individuais. Isto facilita o entendimento e a leitura de como as instâncias vão sendo alocadas (se não fosse este agrupamento, poderia haver dezenas de servidores com tempo de vida de poucas horas poluindo a interpretação).

Caso tenha usado tags nas instâncias, o custo e uso das RIs também será mostrado nos relatórios de tags.

Perfis: suporte ao agendador de workflows

Atendendo a inúmeros pedidos, implementamos o perfil ‘agendador de workflows’ – na prática as ações do agendador ficam dentro do perfil de ‘Servidores’.

A ideia aqui é criar um perfil no qual o usuário possa utilizar o agendador e realizar tarefas do tipo ligar/desligar/backup/upgrade/downgrade/etc em servidores à escolha ou contas AWS.

Alguns cenários de uso – fique à vontade para implementar o seu próprio caso de uso!

  • delegar a gestão dos agendamentos de economia, backups, etc para uma pessoa da equipe;
  • se possuir diversas contas AWS, abrir os agendamentos de uma ou mais para outros usuários;
  • se utilizar o Cloud8 na forma WhiteLabel (https://painel.cloud ou URL própria), produtizar o agendador e oferecer mais funcionalidades para o seu cliente final;
  • é possível combinar este perfil com outros como gerenciar DNS, Banco de dados, métricas, etc – customize um painel de controle por usuário/cliente!

Veja as ações implementadas até o momento. Tendo alguma necessidade de outro agendamento, avise-nos!

Custos: rateio e tags de Backups/Snapshots, Lambda, +melhorias

Um dos maiores pedidos pendentes com AWS, em termos de custos, era o rateio de backup. Até então, o AWS publicava uma única linha de custos de backup/snapshot por região:

$0.05 per GB-Month of snapshot data stored – US East (Northern Virginia) US$24.49 Uso: 489.87 GB

Ou seja, não era possível saber o quanto cada servidor gastou de backup e ratear o custo por tag.

Finalmente, este cenário foi resolvido e o Cloud8 já o suporta. Para consultar os dados detalhados dos backups, pode fazer de 2 formas:

  • análise de custos individual de cada servidor – clique no link de custos na lista de servidores e em seguida na aba ‘Tabelas’. Verá o custo de snapshot de cada disco e o espaço ocupado;
  • análise geral – clicando no relatório de Tags e expandindo até o produto “EC2/Backups”. Lembre-se ainda que pode criar alertas de custo e uso, relatórios e estimativas em quaisquer combinações de dados;

Lambda: o Cloud8 mostra as funções Lambda que foram invocadas – nome, número de vezes, segundos utilizados, por tags, etc – de forma que possa fazer rateio e analisar os custos. No relatório de Produtos, expanda o produto “AWS Lambda” e logo após “Regiões” já verá o ID das funções invocadas e os seus detalhes de uso e custo.

Sobre as tags – importante: Para que acompanhe a alocação de custos pelas tags dos snapshots, é necessário, logicamente, que crie as tags nos snapshots. Tendo em vista que o AWS não faz isto automaticamente, o Cloud8 assume a responsabilidade de propagar as tags marcadas para a gestão dos custos até os seus respectivos backups e snapshots quando o agendamento de backup é feito dentro do agendador de workflows.

Além de tudo isto, ainda criamos um botão de download em CSV dos dados detalhados que se encontra na visão “Tabelas”. Com este CSV baixado, pode manipular os dados da forma com que precisar.

Métricas: Queue Length

Incluímos uma métrica muito importante para a análise de desempenho dos seus servidores EC2 e RDS: tamanho da fila de I/O nos discos.

Geralmente, para fins de dimensionamento de um servidor, foca-se em demasiado na análise do consumo de CPU – caso o uso de CPU chegue perto de 100%, a conclusão pode ser a necessidade de um upgrade e vice-versa. Isto nem sempre pode ser verdade.

A fila de I/O de disco indica se a escrita e leitura de dados estão sendo executadas de forma performática. Se houver fila, há um gargalo no disco. Este gargalo, por sua vez, pode contingenciar processos no sistema operacional que aumentam o uso de CPU. Desta forma, juntamente com a CPU, vale analisar o Queue Length. A conclusão pode ser que é necessário uma mudança do disco: trocar a família de instâncias para uma com mais performance de I/O, de magnético para SSD, aumentar o tamanho do SSD (+ IOPS) ou até mesmo usar IOPS provisionado (veja esta apresentação – a partir do slide 41 – Queue Length até 8 estaria OK)

No Cloud8, você pode plotar as métricas de CPU e Queue Length de uma única vez. Selecione o(s) servidor/disco/banco de dados e escolha CPU + Queue Length. É possível ainda adicionar o Queue Length de cada disco que o servidor possuir e depois gravar um relatório (ícone do ‘Filtro’) para acesso mais tarde.

Outros

Seguem outras melhorias e correções que merecem destaque:

  • Custos: suporte a custos de Chime, Connect e Lex;
  • Custos: atualização dos preços das instâncias M4;
  • RDS: alerta de promoção de Aurora read-only para master, alerta de erro de conversão de InnoDB na migração para Aurora, alerta para Performance Insights desabilitado, patch aplicado que não precisou de reboot;
  • Perfis: ação de ver ‘Backup status’ e ‘Acessar servidor’ no perfil tipo ‘servidores customizados’;
  • Segurança: alerta se CloudTrail parar de logar eventos;
  • Agendador: quebra das notificações em 2 emails – sucesso e erro e não mais um único email para os dois cenários;
  • Relatórios agendados: novo relatório de servidores há muito tempo desligados – útil para entender se pode transformar este servidor em AMI e portanto, economizar;
  • Catálogo de componentes: possibilidade de fazer o download em CSV de todos os Load Balancers e IP Elásticos;
  • Sincronização: opção de não receber avisos de servidores criados por Auto Scaling, Beanstalk – eles continuam aparecendo na lista de servidores e todas as análises de custos e métricas ainda são válidas;
  • Sincronização: o email de aviso de criação de novos servidores marca quando o servidor é do tipo Auto Scaling;

Dúvidas, críticas, sugestões? Entre em contato!

Att
Equipe Cloud8

Lançamento: relatórios gerenciais, segurança com IAM Role, GFS flexível, +secgroups

Lançamento: Relatório gerenciais agendados

Iniciamos uma abordagem nova com o lançamento dos relatórios gerenciais. Confira em ‘Componentes’ do agendador:


Nesta nova visão do agendador, os componentes são as contas AWS e as tarefas os relatórios gerenciais. Também há uma opção de “Todos os provedores” para consolidar os relatórios. Você pode agendar um relatório da mesma forma que agenda uma automação (parar/iniciar, upgrade, backup, EC2 Command, etc): +1 de uma tarefa/relatório, recorrência (diário, semanal, mensal), data limite de término, notificação a determinados emails, etc.

Os relatórios obedecem os logotipos cadastrados e portanto toda a comunicação visual que escolher. Para os parceiros e revendas AWS, fiquem à vontade para produtizar os relatórios e repassar o benefício para os clientes finais.

Para inaugurar já incluímos alguns tipos:

  • Relatório Backup status: servidores EC2 e RDS que não possuem backup há X dias – equivalente à informação no dashboard mas de forma automatizada;
  • Relatório Lista de backups/snapshots: auditoria de todos os backups realizados nos últimos dias – gerado em CSV;
  • Relatório Custos Resumidos: se você possui diversas contas AWS e só quer receber um único email com os custos do dia, este relatório pode atendê-lo. Incluímos custo até o dia, estimativa e comparação com o mês anterior;
  • Relatório Rateio do Cloud8: se precisar ratear o custo do Cloud8 e repassar para os clientes finais, este relatório pode ser gerado uma vez ao mês no dia 1 (abra um chamado para pedir para habilitá-lo)

A idéia é acrescentar quaisquer tipos de relatórios que vocês necessitem! (pretendemos incluir relatórios de quaisquer produtos e que contenham informações técnicas ou de negócios)

Precisa de algum? Fale conosco!

Segurança: autenticação por IAM Role

O Cloud8 passou a suportar a sincronização por meio de um IAM Role. Veja as opções quando cadastra uma nova conta AWS:

A principal vantagem do IAM Role é de não precisar fazer rotação de chave de acesso. Esta configuração também pode atender a mais requisitos de segurança.

Lembramos que não é necessário que um IAM Role ou chave de acesso possua permissão de administração. Você pode determinar o nível que desejar. Confira as documentações:

Política de segurança mínima (https://www.cloud8.com.br/ajuda/avancado/utilizando-o-cloud8-com-uma-credencial-customizada-de-seguranca/)
Como utilizar um IAM Role (https://www.cloud8.com.br/ajuda/avancado/como-usar-iam-role-para-integrar-a-sua-seguranca-com-o-cloud8/)

Nota: é possível mudar o método de autenticação de qualquer conta AWS dentro do Cloud8. Basta “Editar” o provedor e trocar o método para “IAM Role”. Não é necessário apagar e reimportar a conta AWS – mantenha seu histórico, agendamentos, métricas e auditoria!

Grupos de seguranca: melhorias

A gestão dos grupos de segurança foi uma das primeiras implementações que fizemos a pedido dos clientes. Confira as extensões que o Cloud8 criou:

  • alerta de mudança de regras – inclusão, modificação e remoção;
  • alerta de mudança de associação de servidores EC2/VPC – inclusão ou remoção dispara um aviso;
  • tags/descrição por regra – muito usado para documentação dos grupos. Ex: IPs/CIDRs de redes específicas (operadores, bancos, topologia interna), IPs customizados (plantonistas, permissões de exceção);
  • customização do alerta somente se for aberta a rede (0.0.0.0/0) e se mudança ocorrer fora de determinados CIDRs (ex: não avisar mudanças dentro de 10.1.10.0/24 pois seria a rede “local”);

Avançamos no roadmap e agora incluímos novas funcionalidades:

  • na lista de administração dos grupos de segurança mostramos quais servidores EC2 e RDS (novo!) estão associados, ou seja, agora possui uma visão de múltiplos produtos;
  • nos alertas de grupos, caso a regra modificada seja do tipo inclusão ou remoção de outro grupo, mostramos o nome do grupo para melhor interpretação;

Retenção de backup GFS: flexibilidade de mensal e semanal

Flexibilizamos a política GFS para que os periodos semanal e mensal não sejam mais obrigatórios. Como o número de políticas GFS já era ilimitado, esta flexibilidade permite que crie diversas novas regras de negócios para reter os backups.

Ao deixar habilitado somente a retenção diária, você cria o equivalente a uma nova “política por tempo”.

Outros

Seguem outras melhorias e correções que merecem destaque:

  • Custos: suporte a custos de Chef OpsWorks, CodeBuild, AWS X-Ray;
  • Custos: na análise, melhoramos a comparação de meses distintos, mostrando porcentagem de variação e médias diárias;
  • Custos: estimativas mais precisas já que consideramos até 28 dias e não mais 7 dias;
  • Custos: drilldown de RDS Discos/Backups vai ao nível de região e de detalhe de uso e custo;
  • RDS: alertas de promoção de réplica para Master no Aurora, alerta de erro de instalação de aplicativos (OEM_AGENT) no Oracle, reinício de MySQL por problema no binlog;
  • Suporte a novos tipos I3 e db.t2.small para Aurora;
  • Agendador: melhoria na checagem dos parâmetros de um EC2 Command;
  • Paginação de logs aumentada para até 500 itens;
  • Sincronização: se houver a sincronização de uma conta, não bloqueamos mais o acesso de todos os usuários, somente do usuário que realizou o pedido, até que a ação termine;

Dúvidas, críticas, sugestões? Entre em contato!

Att
Equipe Cloud8

Uso de componentes, backup assíncrono, GFS + DR, multi-lingua

Relatório de uso de componentes

O relatório de Backup Status foi muito bem recebido nos últimos meses. Por meio dele, sabe-se quais servidores EC2 e RDS estão sem backup há X dias. E para evitar falso-positivo de s
ervidores que não precisam de backup, pode-se marcar somente os “favoritos”.

Ao lado deste importante diagnóstico, acrescentamos mais 3 novas checagens que visam a ajudar a não gastar com componentes não utilizados:

  • Discos sem uso;
  • IPs elásticos não conectados a instâncias;
  • Load Balancers sem servidores conectados

Esta aplicação está localizada no dashboard. Veja um exemplo:

report-usage

Uso dos componentes – todas as contas e todas as regiões

 

Precisa de algum item novo? Mande para nós – já temos diversos outros mapeados!

Para facilitar a visualização do uso e do “não uso” dos IPs Elásticos, incluimos uma visão unificada de todas as regiões e contas AWS no mesmo nível dos demais componentes:

elasticip-list

A partir desta lista, pode realizar ações como conectar, desconectar o IP de um servidor, destruir e criar um novo IP. Todas as ações são auditadas.

Backup assíncrono

O uso do EC2 Command em conjunto com a criação de backups para fins de melhorar a consistência se popularizou muito depois que lançamos o suporte a execução de scripts.

É comum criar um workflow agendado com a sequêcia de tarefas:

  • execução de EC2 Command para colocar filesystem em modo freeze ou banco de dados em “Backup mode”;
  • execução do backup – que pode ser assíncrono!
  • execução de EC2 Command para descongelar o filesystem ou desligar “Backup mode”;

Com o suporte assíncrono não é mais necessário aguardar o fim do backup para ir para a próxima tarefa.

backup-async

Suporte oficial a multi-língua

Oficializamos o suporte a inglês, com escopo e configuração por conta AWS:

  • língua;
  • fuso horário do provedor;
  • formato de data do provedor (dd/mm/YYYY ou mm/dd/YYYY);
  • usuários e perfis com permissões customizadas com acesso a componentes e funcionalidades dos provedores;

Além disto, é possível configurar o Cloud8 como white label, conforme um dos últimos comunicados:

  • logotipo por conta AWS – será colocado no cabeçalho nos comunicados via email deste provedor e no painel de controle;
  • usuário SMTP – o usuário ‘From’ que envia os comunicados;

GFS: customização para retenção de cópias

Incluimos nas políticas de retenção GFS a opção de apagar uma cópia em outra região com dias exclusivamente configurado para esta ação.

No GFS, escolhe-se o número de dias para reter backups diários, semanais e mensais. Com a nova opção, uma cópia de um backup para outra região pode ser apagada em menos dias – já que a cópia, para fins de disaster recovery, não precisaria ficar retida por vários dias, dado que uma recuperação com dados antigos não faz muito sentido.

Auditoria e remoção de backup

A auditoria mostra o motivo detalhado do porquê um backup ou snapshot foi removido e qual política de retenção e regra aplicadas. Exemplos:

  • Remoção por Tempo configurada: mais antigo que 5 dias, criado por meio deste sistema;
  • Remoção por Tempo configurada: mais antigo que 37 dias, não criado por meio deste sistema;
  • Remoção por GFS ‘Nova politica de retencao’, regra diaria (5 dias);
  • Remoção por GFS ‘Nova politica de retencao’, regra para copia (2 dias);

Métricas: suporte a histórico de 15 meses

Recentemente o AWS anunciou o suporte a guardar todas as métricas por 15 meses. O Cloud8 também passa a suportar este período. Com a aplicação de métricas é possível:

  • Métricas mais comuns de EC2, RDS e EBS;
  • Gráficos customizados por período, intervalo, tipo de métrica;
  • Combinação de métricas de vários serviços. Ex: CPUs de servidores de aplicação + CPU do RDS associado + I/O disco do EBS – facilita a análise e correlação;
  • Gravação de filtros/atalhos dos relatórios;
  • Exportação dos gráficos em imagem ou PDF ou dos dados em CSV;

Lista de preços EC2/RDS

Com o objetivo de facilitar a busca dos preços EC2 e RDS, criamos uma lista em que se busca o preço sob demanda por tipo de instância, região e plataforma (Linux ou Windows). Basta clicar em “Preços EC2/RDS” no menu esquerdo.

O perfil de usuário ‘finance’ (usuários que acessam o Cloud8 para fazer análise de custos) também pode ser configurado com a opção de se liberar ou não permissão de acesso a esta nova funcionalidade.

Outros

Seguem outras melhorias e correções que merecem destaque:

  • Discos: na criação de um novo disco, pode-se escolher um dos 5 tipos de EBS disponíveis;
  • Restore de snapshot para criar um novo disco, também pode se escolher um dos 5 tipos de EBS disponíveis;
  • Suporte as regiões do Canadá e Londres;
  • Alarmes de custos para contas consolidadas;
  • RDS: alertas de aplicação de patch no Aurora, failover de Aurora e crash no binlog de replicação;
  • Custos: suporte a análise de novos produtos – Budgets, QuickSight, Rekognition, GameLift, Step Functions, Polly, Athena, LightSail;
  • RIs: alerta se estiver usando instâncias reservadas com escopo de zona de disponibilidade – a melhor prática é usar como ‘região’;
  • Suporte a novos tipos t2.xlarge e t2.2xlarge;
  • Suporte a novos tipos R4;
  • Agendador: filtro de busca de componentes funciona com o ID;
  • Agendador: separação das tarefas de execução de script Web e script EC2 Command para ficar mais claro;
  • Paginação de componentes aumentada para até 300;
  • Mudar a classificação de um backup/imagem e sua política de retenção pode ser feito em massa, selecionando-se vários backups ou snapshots ao mesmo tempo;
  • LoadBalancers: opção de forçar a sincronização com o AWS caso um novo LB seja adicionado ou removido e não se quer aguardar a sincronização automática;
  • Diversas melhorias de performance.

Comentários, críticas, sugestões? Manda para nós!

Equipe Cloud8

10 resoluções de ano novo para o seu cloud AWS

Aproveitando a onda das resoluções, levantamos 10 pontos interessantes, dos quais muitos não demandam grande esforço, que trazem um imenso benefício!

  1. Habilitar o CloudTrail em todas as regiões (write events pelo menos!);
  2. Revisar todos os grupos de segurança e ACLs das VPCs alterando, eliminando e documentando as regras inbound e outbound;
  3. Entender os custos detalhados todos os componentes. E não se esqueça de criar um processo interno de para criar Tags de monitoração de custos! (sugestões: “CentroCustos” – ABC, XYZ; “Ambiente” – produção, testes; “Produto” – CRM, ERP; “Departamento” – Marketing, TI;
  4. Migrar todas as instâncias do EC2 Clássico para VPC e usar os tipos novos mais performáticos e baratos;
  5. Estudar o CloudWatch de todas as instâncias (EC2, RDS, ElastiCache, etc) em termos de CPU, I/O de disco, rede e redimensionar para o tipo com melhor custo/benefício;
  6. Migrar “aquele” banco de dados que roda em uma instância EC2 e que precisa gerenciar manual para o RDS (estudar o custo antes!);
  7. Revisar todos os componentes não utilizados – discos, IPs, backups antigos, etc;
  8. Economizar com upgrade/downgrade. Se você já para/inicia instâncias para economizar, lembre-se que é possível fazer upgrade de EC2 e RDS que pode trazer uma economia extra;
  9. Separar ambientes de produção, staging, testes, DR em diversas contas AWS e agregar a conta em uma conta consolidada a parte;
  10. Backup! Tenha certeza que todos os servidores EC2 e RDS possuam backups/snapshots na frequência certa e estejam sendo limpos para não incorrer em custos desnecessários.

Bônus: Aprender algo novo! Que tal Machine Learning, Lambda, EC2 Commands?

O Cloud8 pode ajudá-lo em diversas destas resoluções. Faça um trial gratuito!