Como realmente criar uma arquitetura de nuvem da AWS segura e confiável sem perder a cabeça

Introdução

Se você já tentou projetar uma arquitetura de nuvem na AWS a partir do zero, provavelmente já sabe: é um processo que envolve liberdade e caos em partes iguais. Há mil maneiras de criar algo e o mesmo número de maneiras de estragar tudo.

Uma breve olhada na documentação da AWS pode fazer com que você pense: "Legal, vamos simplesmente observar as práticas de primeira linha". No entanto, em ambientes internacionais reais, as práticas de primeira linha não costumam estar em contato direto com as necessidades reais da empresa comercial, com os limites da faixa de preço ou com o erro humano. É por isso que trabalhar com profissionais como a perfsys desde o início pode evitar que, mais tarde, você se depare com falhas de proteção e complicações de dimensionamento.

O objetivo não é apenas obter algo que funcione. O objetivo é criar um sistema que não caia quando o tráfego aumentar ou quando uma região ficar sem sinal - e que não deixe a porta da frente aberta para a Internet.

Vamos começar pelo óbvio: a AWS é uma fera

Você pode criar praticamente qualquer coisa com a AWS. De startups com duas pessoas a plataformas corporativas em expansão, os blocos de construção estão todos lá - EC2, Lambda, RDS, S3, IAM, VPCs, a lista continua. O problema? Quanto mais opções você tiver, mais fácil será criar uma bagunça emaranhada.

Não é que o AWS seja mal projetado. É só que você precisa projetá-la adequadamente. Caso contrário, você acabará com o que algumas equipes chamam de "espaguete da nuvem": serviços interdependentes, segredos codificados, sem marcação, sem registro e sem absolutamente nenhuma ideia do que está custando quanto.

A confiabilidade e a segurança não são coisas que se pode ter

É tentador tratar a segurança e a confiabilidade como um problema do futuro. "Vamos protegê-lo depois que entrarmos em operação." "Adicionaremos monitoramento no próximo sprint." Mas pergunte a qualquer pessoa que já tenha lidado com uma violação de dados ou uma interrupção de várias horas - ao pular essas etapas, você acaba tendo que passar a noite em claro.

O que a confiabilidade realmente significa

Não se trata de garantias de tempo de atividade em um conjunto de slides. Trata-se de engenharia para falhas. Os serviços caem. Os discos falham. As APIs ficam sem tempo. O que importa é se o seu sistema continua funcionando quando as coisas quebram.

Você tem redundância nas zonas de disponibilidade? Seu sistema pode tolerar um nó de banco de dados com falha sem perder dados ou gerar erros? Você está executando cargas de trabalho críticas em uma única região porque "foi o mais fácil de implantar"? Essas são as perguntas que separam os sistemas funcionais dos resilientes.

E a segurança? Não se trata apenas de IAM

Sim, o gerenciamento de identidade e acesso (IAM) é a primeira barreira. Mas a segurança vai muito além disso. Buckets S3 acessíveis publicamente. Funções com excesso de permissões. Segredos codificados em funções Lambda. Registro de logs desativado "para economizar custos". Tudo isso são bombas-relógio.

Usar a estrutura bem arquitetada da aws pode ajudar a identificar esses problemas antes que eles explodam. Ela divide a arquitetura em cinco áreas principais - segurança, confiabilidade, excelência operacional, eficiência de desempenho e otimização de custos - e força as equipes a avaliar cada uma delas com honestidade. Não é uma solução milagrosa, mas obriga você a fazer perguntas difíceis.

Os blocos de construção que realmente importam

Muito bem, vamos ao que interessa. Aqui está o que importa quando você está criando uma arquitetura segura e confiável na AWS - e onde as equipes costumam errar.

Use as funções de IAM da maneira correta (sim, é verdade)

As funções de IAM são poderosas. Às vezes, poderosas demais. É muito fácil colocar "AdministratorAccess" porque algo não está funcionando, prometer consertar depois... e nunca consertar.

Você precisa bloquear isso desde o início. O princípio do menor privilégio não é apenas uma prática recomendada - é a única maneira sensata de operar. Isso significa que:

• Funções com escopo por serviço

• Evitar curingas nas permissões

• Credenciais de curta duração

• MFA obrigatória para usuários humanos

Parece chato? É. Mas explicar ao seu chefe por que alguém exfiltrou dados de clientes de um Lambda mal configurado também é.

Separe sua rede como se estivesse falando sério

Esta é outra área em que os atalhos saem pela culatra. Você não precisa de uma configuração de rede supercomplexa, mas algumas noções básicas são muito úteis:

• Sub-redes públicas somente para coisas que precisam estar voltadas para a Internet (por exemplo, ALBs)

• Sub-redes privadas para todo o resto

• Gateways NAT para acesso controlado de saída

• Endpoints VPC para o tráfego de serviços do AWS sem atingir a Internet pública

Um VPC plano com tudo na mesma sub-rede pode parecer fácil. Até que algo quebre e leve tudo com ele.

Registro e monitoramento: Não é possível consertar o que não se pode ver

Isso nem deveria mais ser motivo de debate. O registro em log não é opcional. Se você não estiver capturando o CloudTrail, as métricas do CloudWatch e os logs de fluxo de VPC, estará voando às cegas.

Mas aqui está o problema: o registro em log por si só não é suficiente. Você precisa realmente examinar os logs. Criar alertas para as coisas que importam. Filtrar o ruído. E garantir que os registros sejam centralizados em todas as contas e regiões. Visibilidade fragmentada não é visibilidade.

Criptografe tudo (sem exceções)

Use o KMS para dados em repouso. Use TLS para dados em trânsito. Faça a rotação de chaves. Monitore o acesso. Essa é uma daquelas áreas em que ser preguiçoso agora sai muito caro mais tarde.

E não se esqueça de coisas como criptografia RDS, configurações de volume EBS e aplicação de TLS do API Gateway. Esses pequenos detalhes se acumulam.

Infraestrutura como código ou fracasso

Ainda faz a implementação clicando no console do AWS? Isso é bom para desenvolvimento, mas perigoso para produção.

Use o Terraform, o CloudFormation ou o CDK. Seja qual for a preferência da sua equipe, escolha uma e fique com ela. Controle a versão dos seus modelos. Use CI/CD para implementar. Automatize as reversões. As implementações manuais são um convite aberto a erros.

Além disso, marque tudo. Recursos sem tags são como cabos sem etiquetas - ninguém sabe para que servem e todos têm medo de tocá-los.

Dimensionamento sem afundar

Vamos ser claros: a AWS adora quando você provisiona em excesso. Você obtém "desempenho" e eles recebem seu dinheiro. O dimensionamento eficiente consiste em conhecer seus padrões e planejar para eles.

Use grupos de dimensionamento automático, instâncias pontuais (com cuidado) e camadas de cache. Mas o mais importante: teste sob carga. A última coisa que você quer é descobrir que sua instância RDS derrete com o tráfego real dois dias após o lançamento.

Além disso, reserve capacidade quando fizer sentido. Isso economiza dinheiro e evita falhas surpreendentes no provisionamento.

Os planos de recuperação de desastres não são opcionais

O que acontece se uma região ficar inoperante? E se o banco de dados principal for corrompido? Se a resposta for "uh... estaríamos em apuros", então é hora de reformular sua estratégia de DR.

Isso não significa criar uma cópia idêntica de sua infraestrutura em outra região. Significa saber:

• O que você restauraria

• Quanto tempo levaria

• Quais dados seriam perdidos (se houver)

• Quem é responsável pelo quê durante um failover

E sim, você deve testar seu plano de recuperação. Caso contrário, é apenas ficção.

Antipadrões comuns a serem evitados

Vamos apresentar rapidamente alguns "não-não" que aparecem com muita frequência:

• Uma conta grande para tudo: use as organizações da AWS. Separe produção, desenvolvimento, preparação, etc.

• Deixar VPCs padrão e grupos de segurança intocados: bloqueie-os.

• Confiar excessivamente nas instâncias t2.micro "para teste" - elas acabarão na produção eventualmente.

• Não fazer um orçamento para os custos do CloudWatch: sim, o registro custa dinheiro. Não registrar custa mais.

• Dar acesso a "apenas consertar rapidamente": em vez disso, conserte seu processo.

Palavras finais? Mantenha-se flexível, mantenha-se são

A arquitetura de nuvem não se trata de encontrar a configuração perfeita. Trata-se de criar algo que seja flexível, robusto e compreensível por mais do que apenas a pessoa que o escreveu.

Você nunca está realmente "pronto" - e tudo bem. O que importa é ser intencional. Fazer perguntas difíceis desde o início. Fazer auditorias com frequência. Automatizar onde for necessário. E saber quando pedir ajuda.

Porque, sejamos honestos, a AWS é poderosa, mas também é fácil se perder nela. Trabalhar com engenheiros experientes que vivem e respiram arquitetura de nuvem pode fazer a diferença entre "funciona, na maioria das vezes" e "dormimos à noite".

E vale a pena construir para isso.