Escrito por: TIVIT

Está se perguntando qual é o melhor free tier? Para ter essa resposta, é preciso entender quais são as características de cada um deles, certo? Você sabe quais são os recursos externos, customização e segurança em nuvem AWS? O que acha de tirar essas dúvidas? Preparamos este artigo completo com tudo o que você precisa saber sobre o assunto.

 

Continue a leitura e confira!

Criação de recursos externos à AWS

O AWS CloudFormation Resource Type é a evolução do Custom Resources. Por meio dele é possível provisionar recursos customizados externos à AWS, como a configuração de um serviço, de uma aplicação de monitoração ou mesmo a estrutura de um ambiente OnPremise. Ele funciona como um coringa, feito para incluir provisionamentos que ficariam em um outro fluxo, mas dentro do mesmo stack.

 

Sem essa função, você teria que acionar outros targets após a criação da sua stack, mas, dessa forma, é possível interagir com qualquer entidade externa por meio do mesmo template.

Para exemplificar, no seu stack você poderia criar uma instância e adicionar as informações dela a um CMDB externo, tudo nesse mesmo template. Poderia também, durante a criação do stack, fornecer o IP da instância para um serviço de monitoração OnPremise.

 

Uma opção de aplicação muito interessante desse recurso é a remoção de buckets S3. A AWS por padrão não remove buckets com conteúdo. Então, se você provisionou um bucket S3 na criação de um stack, enviou arquivos ao bucket e, dias depois, tentar remover o stack, encontrará uma mensagem de erro, pois não foi possível remover o bucket com conteúdo.

 

Por meio de Resource Types ou Custom Resources você pode definir que na ação de remoção do stack esse recurso deve ser acionado, e nele você associa uma função lambda que faz o cleanup do bucket S3. Essa função atua como coringa para executar qualquer coisa que ainda não seja suportada nativamente pelo CloudFormation.

Segurança e customização

Os parâmetros são essenciais para customizarmos o template, permitindo que ele seja utilizado inúmeras vezes, cada vez com diferentes valores.

 

Não faria sentido ter um template diferente para criação de instância de cada tipo, mas um único template com a opção de escolher o tipo de instância que desejamos, o nome, a chave a ser utilizada, subnet, entre outras informações.

 

Na seção Parameters, podemos definir um parâmetro do tipo String, Número ou Lista de Valores para ser inserido durante a criação do stack.

 

Além desses, é possível especificar os tipos de parâmetros específicos à AWS, como, por exemplo, o comando “AWS::EC2::KeyPair::KeyName” exibiria todas as chaves disponíveis para seleção na criação do stack.

 

Essa alternativa ficará mais fácil de entender com uma imagem. Utilizando esse tipo de parâmetro, são retornadas todas as chaves disponíveis como parâmetros válidos. Veja a configuração a seguir:

 

automacao-aws

 

 

Parâmetros e referências para customização

Parâmetros na criação do stack:

 

automacao-aws2

Uma alternativa interessante é o tipo de parâmetro SSM, com ele, deixamos nossos templates mais seguros e promovemos a reusabilidade, pois, dessa forma, o parâmetro fica externo ao nosso template, e de maneira protegida.

 

Ao criar um banco de dados, em vez de definir a senha por meio de um parâmetro comum, ela fica armazenada no Parameter Store. O banco de dados é criado com a senha definida e essa informação estará protegida.

 

Além dos parâmetros apresentados acima, podemos utilizar referências dinâmicas para referenciar valores do AWS Systems Manager Parameter Store, e ainda do AWS Secrets Manager.

 

Os valores válidos são:

  • ssm (Systems Manager em texto puro);
  • ssm-secure (Systems Manager em texto seguro);
  • SecretsManager (segredo do Secrets Manager).

É importante considerar que podemos usar até 60 referências dinâmicas em um mesmo stack.

Senhas e informações sensíveis nunca devem ser armazenadas nos templates. Esses elementos devem ser guardados em serviços criados para isso. Com o SSM Parameter Store e o Secrets Manager podemos definir quem tem acesso a essas informações, além de outras features, como rotacionamento de senhas.

 

No ssm, precisamos fornecer o nome do parâmetro e a versão daquele parâmetro. No SecretsManager, precisamos fornecer o id do segredo e a chave json do valor que buscamos. No exemplo abaixo, uma chave é username e a outra é password.

 

O SSM e SecretsManager têm sintaxe diferente para recuperar os dados, pois ambos têm mecanismos diferentes para armazenamento e proteção dos parâmetros e segredos.

 

automacao-aws3

automacao-aws4

automacao-aws5

Proteção de recursos

Outro ponto positivo do uso da infraestrutura como código é a agilidade e a simplicidade para a criação de recursos, mas também para a exclusão. Porém, com múltiplos arquitetos gerenciando uma grande quantidade de stacks, como se proteger contra a exclusão ou atualização acidental? Conheça alguns dos recursos mais eficientes.

Termination Protection

Ao criar um stack, você pode selecionar a opção termination protection. Dessa forma, se alguém tentar remover o stack, a ação será negada. É preciso restringir a quantidade de arquitetos que terão privilégio de remover essa função.

Stack-Level Policies

Por padrão, todas as ações de atualização em todos os recursos são permitidas, mas você pode evitar remoção acidental configurando Stack-Level Policy, que ao ativar protege todos os recursos, e então você define através de políticas quais recursos podem ser atualizados.

Cada stack permite apenas um Stack Policy, o que é um ótimo mecanismo para proteger aquele banco de dados crítico.

Resource-Level Policies

Você pode definir dentro do template um Deletion Policy para preservar o recurso ou fazer backup dessa função quando o stack é deletado. Essa política é aplicada a cada recurso.

As opções de Deletion Policy são “delete”, que é a padrão, de remover o recurso quando o stack é removido, “retain”, para manter o recurso mesmo após a deleção do stack, e “snapshot”, que é a padrão em recursos DBCluster e DBInstance, para execução de um snapshot antes da remoção do recurso.

IAM Policies

Como todos os outros serviços na AWS, você deve utilizar o IAM para gerenciar e proteger os serviços, e os recursos, utilizando roles e policies. Você tem uma lista extensa de ações a serem liberadas ou negadas, com o objetivo de atender ao princípio básico de segurança de least privilege only.

Former2

Se você já tem um ambiente em execução, pode criar um template CloudFormation por meio de engenharia reversa utilizando o Former2.

 

Por meio do website “https://former2.com/” você instala uma extensão do seu browser (suportada pelo Google Chrome, Mozilla Firefox e Microsoft Edge), informa as credenciais de acesso de um usuário com a policy ReadOnlyAccess e, então, é apresentado a uma interface que você escolhe os serviços dos quais tem recursos, seleciona os necessários e, a partir daí, consegue gerar o template CloudFormation da sua infraestrutura atual.

TIVIT Cloud Solutions

Com tantas opções no mercado, nem sempre é simples identificar aquilo que é melhor para a sua empresa, não é mesmo? Mas você não precisa se preocupar com isso: a TIVIT Cloud Solutions consegue identificar o melhor de cada nuvem para disponibilizar para a sua empresa. Dessa forma, é possível integrar diferentes ambientes e aplicações com máxima disponibilidade e segurança de dados.

 

A TIVIT é referência na América Latina em soluções completas de nuvem, e disponibiliza toda sua expertise para que sua empresa obtenha todos os benefícios que a computação em nuvem pode oferecer.

 

Quer saber como os recursos externos, customização e segurança em nuvem AWS podem ser estruturados? Fale com um de nossos especialistas e entenda como podemos ajudar!

CTAs-tivit-horizontal (2)

 

Conteúdos Relacionais