O blog da AWS

Prepare-se para escalar na nuvem. Estratégia de Múltiplas contas

Por Rene Martínez, Arquiteto Sênior de Soluções AWS Chile e 
Angel Goñi, Arquiteto de Soluções AWS Chile

 

Interessado em como multiplicar limites de serviço e o nível gratuito para diferentes aplicativos na AWS? Deseja manter um nível mais alto de suporte para ambientes produtivos sem pagar uma porcentagem do consumo total? Procurando uma maneira simples e eficaz de isolar custos e acessos para diferentes aplicações ou unidades de negócios?

Se a resposta a qualquer uma das perguntas acima for sim, você provavelmente precisa de uma estratégia de várias contas. No seguinte post vamos abordar quando é uma boa idéia fazê-lo, quando não e as considerações mais relevantes sobre isso.

 

Multi-contas versus conta única.

Mais e mais clientes estão chegando até nós, pedindo instruções prescritivas para implementar um ambiente de várias contas, especialmente com a AWS Control Tower. As motivações por trás desse interesse são várias:

  • Recomendação de um parceiro, normalmente com competência em segurança.
  • Parte de um processo de projeto fundamental dentro de uma iniciativa de serviços profissionais da AWS.
  • Crescimento na adoção da nuvem e, portanto, a necessidade de exercer maior controle e governança.

Mesmo que as causas tenham sido diferentes, o que é interessante para nós é que as perguntas são recorrentes:

Você realmente precisa de uma estratégia de várias contas e uma Zona de aterrissagem?

  • Deve ser implantado com a AWS Control Tower?
  • Qual o impacto que ela tem na operação atual do cliente?
  • Quantas contas devem ser criadas, qual padrão seguir?

 

Esta situação nos deu um sinal de que havia a necessidade de fornecer um guia que facilitasse a decisão além das melhores práticas e instruções descritas na documentação do serviço.

Para facilitar essas decisões e entender esta publicação, vamos começar revisando algumas definições.

Multi-grânulos:

É um conceito que é introduzido aproximadamente 5 ou 6 anos, uma das primeiras conferências onde o tema é discutido foi em Re:Invent 2016. A ideia por trás da estratégia posiciona a entidade Conta da AWS como a unidade básica para isolar os recursos implantados na AWS — tanto tecnicamente quanto no faturamento.

Zona de aterrissagem:

Implemente logicamente uma estratégia de várias contas usando a solução Amazon Landing Zone (ALZ) ou, mais recentemente, com a Control Tower. Uma implantação da Zona de Landing executa automaticamente várias configurações que podem incluir:

  • Configurando uma Fábrica de contas/Account Factory para automatizar a criação de novas contas na Zona de aterrissagem.
  • Crie a Amazon VPC e outros componentes de rede em cada conta.
  • Implante o AWS Single Sign-On ou federação em um active directory existente
  • Configurando o armazenamento de registros do Amazon CloudTrail em uma conta centralizada.
  • Aplicando Guardrails a cada uma das contas criadas.
  • Estrutura comum de serviços compartilhados, como um diretório, serviços DNS e ferramenta DevOps.

Mesmo que uma zona de aterrissagem possa ser configurada manualmente, é um processo difícil e demorado que pode ser usado para gerar inovação e agregar valor aos negócios.

Fábrica da conta da máquina de venda automática/conta:

Mecanismo de auto serviço que automatiza o processo de criação de contas da AWS. É entregue como um produto do AWS Service Catalog que faz parte dos componentes de uma zona de aterrissagem para a qual a AWS Control Tower fornece uma camada de abstração superior chamada Account Factory. Seu objetivo é criar contas da AWS com uma linha de base específica que atenda às práticas recomendadas propostas pela solução e configurações adicionais definidas pelo cliente.

Unidade Organizacional (OU):

É um agrupamento lógico de contas da AWS dentro do AWS Organizations. As OUs permitem organizar contas em uma hierarquia de árvore, facilitando a aplicação de mecanismos de controle.

 

Existem muitos conceitos novos, pois como decido qual é a melhor opção?

Para responder a esta pergunta de forma mais simples, criamos o seguinte diagrama:

 

 

Se você quiser entender o raciocínio por trás de cada uma dessas alternativas, você pode continuar lendo para aprofundar na análise.

 

Você realmente precisa de uma estratégia de várias contas e uma Zona de aterrissagem?

A resposta curta é que em 90% dos casos é necessário. Geralmente, nossos clientes têm vários aplicativos implantados ou precisam de mais de um ambiente (Dev, QA, Prod), o que já é um motivo para usar mais de uma conta. Várias contas também conseguem maior isolamento em termos de acesso, permissões e custos, desfrutam de um nível gratuito e limites de serviço mais amplos em geral, e diferentes níveis de suporte podem ser alcançados dependendo da criticidade dos aplicativos implantados.

Uma vez que a decisão de várias contas é clara, você tem que ver como ela é implementada. Na tecnologia, as decisões não são geralmente binárias, então vamos explorar um pouco mais as razões por trás de cada alternativa.

Se for necessário apenas:

  • Um pequeno número de contas da AWS.
  • Ambientes separados por unidade de negócios ou por finalidade (ambientes não produtivos e produtivos).
  • Receber faturamento consolidado.
  • Configurar algumas restrições básicas nas contas.

Em seguida, basta implementar uma estratégia de várias contas baseada no AWS Organizations, sem usar ALZ ou Control Tower, para emular Guardrails, você pode usar o AWS Config ou Service Control Policies (SCP).

 

Deve ser implantado com a AWS Control Tower?

Esta decisão é mais complexa e fatores humanos, técnicos, de segurança e regulatórios devem ser considerados. No entanto, existem algumas maneiras de determinar quando o AWS Control Tower não é o caminho. Está prevista a criação de várias contas com frequência? A empresa pertence a uma categoria regulamentada com altos padrões de segurança e conformidade? Você tem uma equipe de TI dedicada à arquitetura governamental e na nuvem?

Se a sua resposta foi “Não “em cada caso, a melhor alternativa é implementar uma estratégia manual de várias contas. Simplificando, o objetivo fundamental da AWS Control Tower é facilitar um processo de criação e gerenciamento de contas, políticas de conformidade e gerenciamento centralizado de acesso. Se você não explorar esses pontos fortes, provavelmente, os benefícios obtidos não justificarão a operação do serviço.

Outros fatores relativos à Torre de Controle que devem ser considerados são:

  • Tamanho da organização e seu modo de operação.
    • Você opera em vários países com requisitos regulatórios ou custos diferentes?
    • Qual é o crescimento esperado da adoção da nuvem?
    • As unidades de negócios funcionam de forma independente e gerenciam seus próprios equipamentos e orçamento?
  • Capacidade do equipamento
    • O cliente tem equipes de nuvem ou parceiros para operar a infraestrutura e desenvolver novos projetos na AWS?
  • Requisitos regulamentares ou de
    • Há algum requisito regulamentar que deve ser cumprido?
    • Existe uma área dedicada à Segurança e Risco que seria responsável pelos processos e aplicativos a serem implantados na nova Zona de aterrissagem?

As grandes empresas têm áreas que suportam processos de governança e segurança que não estão necessariamente envolvidos em projetos de adoção da AWS. Devido a essa desconexão inicial, é comum que o crescimento da infraestrutura seja ignorado ou subestimado até que várias cargas de trabalho produtivas estejam atendendo e cuja migração para uma estrutura robusta de várias contas pode ser um risco comercial. Nesses casos, mesmo que você não pretenda usar os benefícios da AWS Control Tower no curto prazo, é uma boa prática executar uma implantação padrão do serviço. O design da arquitetura inicial forçará você a pensar em detalhes como intervalos CIDR, número de ambientes, gerenciamento de credenciais etc, que geralmente passam despercebidos inicialmente e, portanto, envolvem as equipes que gerenciarão a Zona de aterrissagem no futuro.

 

Portanto, se recomendamos uma implantação padrão; que impacto ela tem na operação atual do cliente?

A AWS Control Tower é um produto que combina vários serviços da AWS para automatizar a implantação e o gerenciamento da zona de aterrissagem. Nem todos esses serviços são aqueles usados inicialmente por nossos clientes nos primeiros dias de sua jornada de adoção da AWS. Observamos que, na fase em que a arquitetura fundadora faz sentido, as equipes internas estão realmente totalmente focadas em serviços de aprendizagem diretamente relacionados às suas aplicações; tais como: Amazon Relational Database Service (RDS), Elastic Cloud Compute (Ec2), Elastic Container Service (ECS), AWS Lambda, Amazon Api Gateway, Amazon DynamoDB ou outro serviço que lhes permita gerar valor para a empresa e seus clientes finais o mais rápido possível.

Dada a superexposição às novas tecnologias, é contraproducente adicionar a operação da AWS Control Tower às mesmas pessoas, que, além dos produtos mencionados acima, devem se familiarizar com um grupo de tecnologias que aplicariam apenas à Zona de Landing, exemplos: AWS CloudFormation StackSets, AWS Single Sign-On, AWS Service Catalog, Guardrails, AWS Control Tower etc.

Esta situação tem duas soluções possíveis:

  1. Crie um computador (semelhante à imagem abaixo) cuja responsabilidade incluirá o gerenciamento da infraestrutura, ou não isso, envolva as equipes de operações, virtualização e rede existentes na empresa naquele momento.
  2. Use uma implantação padrão da Torre de Controle até que sua equipe de “nuvem” cresça o suficiente para começar a usar a ferramenta e tirar o máximo proveito dela.

 

 

Outros itens adicionais para o gerenciamento da AWS Control Tower que você precisa considerar antes de começar a operá-lo:

  • Estratégia de contas, que vamos aprofundar abaixo.
  • Processo de custo e faturamento. Definição de equipamentos responsáveis por custos, orçamentos, relatórios de utilização, estratégia de rotulagem (parte das responsabilidades fundamentais da imagem acima), etc.
  • Operação da zona de aterrissagem e dos aplicativos implantados neles. Divisão de responsabilidades entre operações, segurança e equipes de produtos.

 

Quantas unidades organizacionais ou contas devem ser criadas, qual padrão seguir?

Existem várias publicações dedicadas exclusivamente a este tópico, as mais recentes serão encontradas neste link.

Geralmente todos concordam com uma abordagem semelhante que pode ser resumida da seguinte forma.

 

 

– UO de Aplicativos (Cargas de Trabalho). Que por sua vez pode ser subdividido por ambientes (Dev, QA e PROD), por unidade de negócios (Bancário, Seguros, Corretor) ou por operação país (Chile, Argentina, Colômbia). Dentro de cada unidade organizacional, as contas do aplicativo serão localizadas. Como distribuí-los? Simplificando, se a equipe responsável pelo aplicativo A equipe é incapaz de colaborar com a equipe responsável do aplicativo B, quando se  reporta para um incidente às 2AM, os aplicativos provavelmente devem viver em contas separadas.

– Experimentação OU (Sandbox). Como o nome sugere, o objetivo desta unidade é claramente experimentação e inovação. As contas dentro desta UO devem ser isoladas do resto do ecossistema, pois são necessárias permissões menos restritivas. Além disso, você deve ter um bom controle sobre os orçamentos. Nesta publicação você encontrará uma maneira automatizada com boas práticas incorporadas para operar esta UO.

– UO de infra-estrutura. As contas comuns são implantadas aqui, por exemplo: conta de rede, onde os túneis VPN são fechados, links dedicados, AWS Transit Gateway são implantados e a entrada e saída da Internet pública são centralizadas. Outros exemplos são contas em que os serviços de diretório (AD) são implantados e compartilhados, resolução de nomes de domínio (DNS) e ferramentas de desenvolvimento de software e contas de ciclo de vida: repositório de código-fonte, repositório de artefatos, pipelines CI/CD, serviços de infraestrutura como código, etc.

– UO de exceções. À medida que nossos clientes aumentam o uso da nuvem e implementam mais cargas de trabalho e aplicativos na AWS, começam a aparecer casos especiais que não estão alinhados com as políticas gerais de segurança e conformidade da organização.  A unidade de exceção é para essas contas que, por uma razão ou outra, requerem tratamento especial, por exemplo: implantação de aplicativos que têm de cumprir o padrão PCI DSS.

 

Conclusão

Além da tecnologia, é o exercício de design que torna uma zona de aterrissagem com a AWS Control Tower uma ferramenta valiosa para sua organização. A avaliação do estado atual do ambiente e dos objetivos da empresa determinará a profundidade de uso das funcionalidades de governança fornecidas pelo serviço.

A implementação de tal arquitetura funciona como a pista onde novas aplicações e projetos irão aterrissar. Como qualquer pista, ela requer manutenção de asfalto, limpeza e pintura para que não ocorram acidentes durante a chegada, a AWS exige que as equipes e processos necessários sejam devidamente suportados e não se torne um fardo para a organização.

 

Próximos passos

Se precisar de ajuda, entre em contato com nossa equipe via chat online.

 

 

Sobre os autores

Rene Martínez Bravet é Arquiteto Sênior de Soluções da AWS com foco em clientes corporativos e financeiros do setor.

 

 

 

 

Angel Goñi Oramas é um Arquiteto de Soluções corporativas da AWS com foco na SAP e no setor de CPG.

 

 

 

 

 

Sobre revisores

Bruno Laurenti é Arquiteto Sênior de Soluções na AWS.

 

 

 

 

Felipe De Bene é um Arquiteto de Soluções na AWS.

 

 

 

 

Carlos Tagle é Gerente Sênior da AWS.