Práticas recomendadas do AWS CloudFormation

As melhores práticas são recomendações que podem ajudar você a usar o AWS CloudFormation de forma mais eficaz e segura em todo o fluxo de trabalho dele. Saiba como planejar e organizar suas pilhas, criar modelos que descrevem os recursos e os aplicativos de software que são executados neles, e gerenciar as pilhas e seus respectivos recursos. As práticas recomendadas a seguir são baseadas em experiência real de clientes atuais do CloudFormation.

Encurtar o ciclo de feedback para melhorar a velocidade de entrega

Adote práticas e ferramentas que ajudam a reduzir o ciclo de feedback da infraestrutura que você descreve com os modelos do CloudFormation. Isso inclui fazer mais cedo o linting e os testes de modelos em sua estação de trabalho. Com isso, você descobre possíveis problemas de sintaxe e configuração antes mesmo de enviar suas contribuições para um repositório de código-fonte. A descoberta precoce desses problemas ajuda a evitar que eles atinjam os ambientes formais do ciclo de vida, como desenvolvimento, garantia de qualidade e produção. Essa estratégia de testar cedo e antecipar-se à falha tem a vantagem de reduzir o tempo de espera de retrabalho, diminuir as possíveis áreas de impacto e aumentar seu nível de confiança no sucesso das operações de provisionamento.

As opções de ferramentas que ajudam você a adotar a prática de antecipar-se à falha incluem as ferramentas de linha de comando AWS CloudFormation Linter (cfn-lint) e TaskCat. A ferramenta cfn-lint permite validar os modelos do CloudFormation em relação à Especificação de recursos do AWS CloudFormation. Isso inclui verificar se foram usados valores válidos nas propriedades dos recursos, bem como as práticas recomendadas. Os plug-ins para o cfn-lint estão disponíveis para vários editores de código, o que permite que você visualize os problemas no editor e obtenha feedback direto da ferramenta de linter. Você também pode optar por integrar o cfn-lint à configuração do repositório de código-fonte, para poder validar os modelos quando confirmar suas contribuições. Para obter mais informações, consulte Validação pré-confirmação do Git de modelos do AWS CloudFormation com o cfn-lint. Depois de realizar o linting inicial e corrigir quaisquer problemas que o cfn-lint possa ter apontado, você poderá usar o TaskCat para testar seus modelos criando programaticamente pilhas nas Regiões da AWS de sua escolha. O TaskCat também gera um relatório com os resultados de aprovação/reprovação para cada região escolhida.

Para obter uma demonstração prática passo a passo de como usar as duas ferramentas para encurtar o ciclo de feedback, siga o Laboratório de linting e testes do Workshop do AWS CloudFormation.

Organizar pilhas por ciclo de vida e propriedade

Use o ciclo de vida e a propriedade dos recursos da AWS para ajudar você a decidir quais deles devem estar contidos em cada pilha. Inicialmente, é possível colocar todos os recursos em uma pilha, porém, à medida que ela cresce em escala e aumenta em escopo, o gerenciamento de uma única pilha pode ser trabalhoso e demorado. Ao agrupar recursos com ciclos de vida e propriedade comuns, os proprietários podem fazer alterações no conjunto de recursos deles usando um processo e uma programação próprios sem afetar outros recursos.

Por exemplo, imagine uma equipe de desenvolvedores e engenheiros que possuem um site hospedado em instâncias do Amazon EC2 Auto Scaling atrás de um balanceador de carga. Como o site tem seu próprio ciclo de vida e é mantido pela equipe do site, é possível criar uma pilha para o site e seus respectivos recursos. Agora, imagine que o site também usa bancos de dados de backend, em que os bancos de dados estão em uma pilha separada que cujas propriedade e manutenção são dos administradores de bancos de dados. Sempre que a equipe do site ou a equipe do banco de dados precisa atualizar seus recursos, eles podem fazê-lo sem afetar a pilha uns dos outros. Se todos os recursos estavam em uma única pilha, a coordenação e a comunicação de atualizações pode ser difícil.

Para obter mais orientações sobre como organizar suas pilhas, você pode usar duas estruturas comuns: uma arquitetura em várias camadas e a arquitetura orientada a serviços (SOA).

A arquitetura em camadas organiza pilhas em várias camadas horizontais que se sobrepõem, em que cada camada tem uma dependência na camada diretamente abaixo dela. Você pode ter uma ou mais pilhas em cada camada, mas dentro de cada camada, suas pilhas devem ter recursos da AWS com ciclos de vida e propriedade semelhantes.

Com uma arquitetura orientada a serviços, é possível organizar grandes problemas de negócios em partes gerenciáveis. Cada uma dessas partes é um serviço que tem uma finalidade claramente definida e representa uma unidade independente de funcionalidade. Você pode mapear esses serviços para uma pilha, em que cada pilha tenha seu próprio ciclo de vida e proprietários. Esses serviços (pilhas) podem ser conectados para que possam interagir uns com os outros.

Usar referências entre pilhas para exportar recursos compartilhados

Ao organizar os recursos da AWS com base no ciclo de vida e na propriedade, talvez você queira criar uma pilha que use recursos existentes em outra pilha. Você pode codificar valores ou usar parâmetros de entrada para transmitir os nomes e os IDs dos recursos. No entanto, esses métodos podem dificultar a reutilização dos modelos ou aumentar a sobrecarga para colocar uma pilha em execução. Em vez disso, use referências entre pilhas para exportar os recursos de uma pilha para que as outras pilhas possam usá-los. As pilhas podem usar os recursos exportados chamando-os com a função Fn::ImportValue.

Por exemplo, você pode ter uma pilha de rede que inclui uma VPC, um security group e uma sub-rede. Você deseja que todas aplicações web públicas usem esses recursos. Ao exportar os recursos, você permite que todas as pilhas com aplicações web públicas usem tais recursos. Para ter mais informações, consulte Obter resultados exportados de uma pilha do CloudFormation implantada.

Verificar cotas para todos os tipos de recursos

Antes de executar uma pilha, certifique-se de que pode criar todos os recursos que desejados sem atingir os limites de sua conta da AWS. Se você atingir um limite, o CloudFormation não criará a pilha com êxito até que você aumente sua cota ou exclua recursos adicionais. Cada serviço pode ter vários limites que você deve levar em conta antes de executar uma pilha. Por exemplo, por padrão, você pode executar somente 2000 pilhas do CloudFormation por região em sua Conta da AWS. Para mais informações sobre limites e como aumentar os limites padrão, consulte Cotas de serviços da AWS, no Referência geral da AWS.

Reutilizar modelos para replicar pilhas em vários ambientes

Depois de configurar suas pilhas e recursos, você pode reutilizar os modelos para replicar sua infraestrutura em vários ambientes. Por exemplo, você pode criar ambientes para desenvolvimento, teste e produção para testar as alterações antes de implementá-las na produção. Para tornar os modelos reutilizáveis, use as seções de parâmetros, mapeamentos e condições para personalizar suas pilhas ao criá-las. Por exemplo, para ambientes de desenvolvimento, é possível especificar um tipo de instância de custo mais baixo em comparação com o ambiente de produção, mas todas as outras configurações e definições são as mesmas. Para obter mais informações sobre parâmetros, mapeamentos e condições, consulte Seções de modelos do CloudFormation.

Usar módulos para reutilizar configurações de recursos

À medida que sua infraestrutura cresce, podem surgir padrões comuns em que é possível declarar os mesmos componentes em cada um dos modelos. Os módulos são uma maneira de empacotar configurações de recursos para inclusão entre modelos de pilha, de modo transparente, gerenciável e repetível. Os módulos podem encapsular configurações comuns de serviço e práticas recomendadas como blocos de construção modulares e personalizáveis para você incluir em seus modelos de pilha.

Esses blocos de construção podem ser para um único recurso, como práticas recomendadas para definir uma instância do Amazon Elastic Compute Cloud (Amazon EC2), ou podem ser para vários recursos, para definir padrões comuns de arquitetura de aplicações. Esses blocos fundamentais podem ser aninhados a outros módulos, para que você possa empilhar suas práticas recomendadas em blocos fundamentais de nível superior. Módulos do CloudFormation estão disponíveis no Registro do CloudFormation, para que você possa utilizá-los como um recurso nativo. Quando você usa um módulo do CloudFormation, o modelo de módulo é expandido para o modelo de consumo, o que possibilita acessar os recursos dentro do módulo usando uma função Ref ou Fn::GetAtt. Para ter mais informações, consulte Criar configurações de recursos reutilizáveis que podem ser incluídas em modelos com os módulos do CloudFormation.

Usar tipos de parâmetros específicos da AWS

Se o modelo exige entradas de valores existentes específicos da AWS, como IDs existentes do Amazon Virtual Private Cloud ou um nome de par de chaves do Amazon EC2, use os tipos de parâmetros específicos da AWS. Por exemplo, é possível especificar um parâmetro como o tipo AWS::EC2::KeyPair::KeyName, que usa um nome de par de chaves existente que está em sua Conta da AWS e na região em que você está criando a pilha. O AWS CloudFormation pode validar rapidamente valores de tipos de parâmetros específicos da AWS antes de criar a pilha. Além disso, se você usar o console do CloudFormation, o CloudFormation mostrará uma lista suspensa de valores válidos, de modo que você não precisará examinar ou memorizar os IDs da VPC corretos ou os nomes de pares de chaves. Para ter mais informações, consulte Faça referência aos recursos existentes e aos parâmetros do Systems Manager com os tipos de parâmetros fornecidos pelo CloudFormation.

Usar restrições de parâmetros

Com restrições, é possível descrever valores de entrada permitidos para que o CloudFormation detecte todos os valores inválidos antes de criar uma pilha. É possível definir restrições como um tamanho mínimo ou máximo e padrões permitidos. Por exemplo, você pode definir as restrições em um valor de nome de usuário do banco de dados para que ele tenha no mínimo oito caracteres e contenha apenas caracteres alfanuméricos. Para ter mais informações, consulte Referência de sintaxe de seção Parameters para modelos do CloudFormation.

Use pseudoparâmetros para promover a portabilidade

Você pode usar pseudoparâmetros em seus modelos como argumentos para funções intrínsecas, como Ref e Fn::Sub. Os pseudoparâmetros são parâmetros que são predefinidos pelo CloudFormation. Você não os declará-las em seu modelo. O uso de pseudoparâmetros em funções intrínsecas aumenta a portabilidade de seus modelos de pilha entre regiões e contas.

Por exemplo, imagine que você deseja criar um modelo em que, para uma determinada propriedade de recurso, seja necessário especificar o nome do recurso da Amazon (ARN) de outro recurso existente. Nesse caso, o recurso existente é um recurso do AWS Systems Manager Parameter Store com o seguinte ARN: arn:aws:ssm:us-east-1:123456789012:parameter/MySampleParameter. Você precisará adaptar o formato do ARN à partição, região e ID da conta da AWS de destino. Em vez de realizar a codificação rígida desses valores, você pode usar os pseudoparâmetros AWS::Partition, AWS::Region e AWS::AccountId para tornar seu modelo mais portátil. Nesse caso, o exemplo a seguir mostra como encadear elementos em um ARN com o CloudFormation: !Sub 'arn:${AWS::Partition}:ssm:${AWS::Region}:${AWS::AccountId}:parameter/MySampleParameter.

Como outro exemplo, suponha que você deseje compartilhar recursos ou configurações em várias pilhas. Neste exemplo, suponha que você tenha criado uma sub-rede para sua VPC e, em seguida, exportado seu ID para uso com outras pilhas na mesma região e Conta da AWS. Em outra pilha, você faz referência ao valor exportado do ID da sub-rede ao descrever uma instância do Amazon EC2. Para obter um exemplo detalhado sobre o uso do campo de saída Export e da função intrínseca Fn::ImportValue, consulte Consultar saídas de recurso em outra pilha do CloudFormation.

As exportações de pilha devem ser exclusivas por conta e região. Portanto, nesse caso, você pode usar o pseudoparâmetro AWS::StackName para criar um prefixo para sua exportação. Como os nomes de pilha também devem ser exclusivos por conta e região, o uso desse pseudoparâmetro como prefixo aumenta a possibilidade de haver um nome de exportação exclusivo e, ao mesmo tempo, promove uma abordagem reutilizável entre as pilhas das quais você exporta valores. Alternativamente, você pode usar um prefixo de sua escolha.

Usar AWS::CloudFormation::Init para implantar aplicações de software em instâncias do Amazon EC2

Ao executar pilhas, você pode instalar e configurar aplicativos de software em instâncias do Amazon EC2 usando o script auxiliar cfn-init e o recurso AWS::CloudFormation::Init. Ao usar AWS::CloudFormation::Init, você pode descrever as configurações que deseja em vez criar o script de etapas procedimentais. Também é possível atualizar as configurações sem recriar instâncias. E se algo errado der errado com a configuração, o CloudFormation gerará logs que podem ser usados para investigar problemas.

Em seu modelo, especifique estados de instalação e configuração no recurso AWS::CloudFormation::Init. Para obter uma explicação detalhada que mostra como usar cfn-init e AWS::CloudFormation::Init, consulte Implantar aplicações no Amazon EC2.

Usar os scripts auxiliares mais recentes

Os scripts auxiliares são atualizados periodicamente. Certifique-se de incluir o seguinte comando na propriedade UserData do seu modelo antes de chamar os scripts auxiliares para garantir que suas instâncias executadas obtenham os scripts auxiliares mais recentes:

yum install -y aws-cfn-bootstrap

Consulte mais informações sobre como receber os scripts auxiliares mais recentes em CloudFormation: referência de scripts auxiliares.

Validar modelos antes de usá-los

Antes de usar um modelo para criar ou atualizar uma pilha, você pode usar o CloudFormation para validá-lo. A validação de um modelo pode ajudá-lo a perceber alguns erros de sintaxe e semântica, como dependências circulares, antes que o CloudFormation crie algum recurso. Se você usar o console do CloudFormation, ele validará automaticamente o modelo depois que você especificar os parâmetros de entrada. Para a AWS CLI ou a API do CloudFormation, use o comando validate-template da CLI ou a operação ValidateTemplate da API.

Durante a validação, o CloudFormation primeiro verifica se o modelo é JSON válido. Caso não seja, o CloudFormation verifica se o modelo é YAML válido. Se as duas verificações falharem, o CloudFormation retornará um erro de validação de modelo.

Validar modelos para a conformidade com a política da organização

Você também pode validar a conformidade do seu modelo com as diretrizes da política da organização. O AWS CloudFormation Guard (cfn-guard) é uma ferramenta de interface de linha de comando (CLI) de código aberto que fornece uma linguagem de política como código para definir regras que podem verificar as configurações de recursos obrigatórios e proibidos. Ele permite que você valide seus modelos em relação a essas regras. Por exemplo, os administradores podem criar regras para garantir que os usuários sempre criem buckets do Amazon S3 criptografados.

É possível usar o cfn-guard localmente, durante a edição de modelos, ou automaticamente, como parte de um pipeline de CI/CD para interromper a implantação de recursos não compatíveis.

Além disso, o cfn-guard inclui um recurso, rulegen, que permite extrair regras de modelos existentes compatíveis do CloudFormation.

Para obter mais informações, consulte o repositório cfn-guard no GitHub.

Gerenciar todos os recursos de pilha por meio do AWS CloudFormation

Depois de iniciar uma pilha, use o console do CloudFormation, a API ou a AWS CLI para atualizar recursos na sua pilha. Não faça alterações nos recursos da pilha fora do CloudFormation. Isso pode criar uma incompatibilidade entre seu modelo de pilha e o estado atual dos recursos da pilha, o que pode causar erros se você atualizar ou excluir a pilha. Isso é conhecido como deriva. Se uma alteração for feita em um recurso fora do modelo do CloudFormation e você atualizar a pilha, as alterações feitas diretamente no recurso serão descartadas, e a configuração do recurso será revertida para a configuração no modelo.

Para obter mais informações sobre o desvio, consulte O que é desvio?.

Para obter mais informações sobre como atualizar pilhas, consulte Demonstração: Atualizar uma pilha.

Criar conjuntos de alteração antes de atualizar as pilhas

Conjuntos de alterações permitem que você veja como as alterações propostas para uma pilha podem afetar os recursos em execução antes de implementá-las. O CloudFormation não fará alterações na pilha até que você execute o conjunto de alterações, permitindo que você decida se deseja continuar com as alterações propostas ou criar outro conjunto de alterações.

Use conjuntos de alterações para verificar como as alterações podem afetar os recursos em execução, especialmente em relação a recursos críticos. Por exemplo, se você alterar o nome de uma instância de banco de dados do Amazon RDS, o CloudFormation criará um novo banco de dados e excluirá o antigo. Você perderá os dados do banco de dados antigo, a menos que já tenha feito o backup dele. Se você gerar um conjunto de alterações, verá que sua alteração substituirá seu banco de dados. Isso pode ajudar no planejamento antes de atualizar a pilha. Para ter mais informações, consulte Atualizar pilhas do CloudFormation usando conjuntos de alterações.

Usar políticas de pilha

As políticas de pilha ajudam a proteger recursos de pilha críticos contra atualizações não intencionais capazes de fazer com que os recursos sejam interrompidos ou até mesmo substituídos. Uma política de pilha é um documento JSON que descreve quais ações de atualização podem ser executadas nos recursos designados. Especifique uma política de pilha sempre que criar uma pilha com recursos críticos.

Durante uma atualização de pilha, é necessário especificar explicitamente os recursos protegidos que deseja atualizar, caso contrário, nenhuma alteração será feita nos recursos protegidos. Para ter mais informações, consulte Impedir atualizações nos recursos de pilha.

Usar revisões de código e controles de revisão para gerenciar seus modelos

Os modelos de pilha descrevem a configuração de seus recursos da AWS, como seus respectivos valores de propriedades. Para analisar as alterações e manter um histórico exato de seus recursos, use revisões de código e controles de revisão. Esses métodos podem ajudá-lo a rastrear as alterações entre versões diferentes de seus modelos, o que pode ajudar você a rastrear alterações nos recursos de sua pilha. Além disso, com a manutenção de um histórico, sempre é possível reverter a pilha para uma determinada versão do modelo.

Atualizar suas instâncias do Amazon EC2 regularmente

Em todas as instâncias Windows do Amazon EC2 e instâncias Linux do Amazon EC2 criadas com o CloudFormation, execute regularmente o comando yum update para atualizar o pacote RPM. Isso garante que você obtenha as mais recentes correções e atualizações de segurança.