AWS VPC – Virtual Private Cloud

Como o próprio nome sugere, Virtual Private Cloud (VPC) é um segmento isolado da infraestrutura da Amazon AWS no qual você pode provisionar seus recursos. É possível criar até 5 VPCs por conta AWS/região. Neste artigo, vou listar os principais pontos de configuração, segurança e conectividade de AWS VPCs.

Para criar uma VPC, você precisa de pelo menos um nome e um range de endereços IP que farão parte da sua rede (CIDR block). Uma VPC será então composta por subnets, que podem ser tanto public subnets (acessíveis a partir da internet) quanto private subnets (acessíveis apenas dentro da VPC associada). Apenas para exemplificar, pode ser que você queira que alguns web services rodem dentro de uma subnet pública e alguns serviços de storage rodem dentro de uma subnet privada.

Cada subnet criada possui uma entrada local em sua Root Table (RC), o que permite com que todas elas se comuniquem entre si. Não é possível remover esta configuração.

Para tornar uma VPC pública, você precisa:

  • Ter um Internet gateway (IGW) associado à VPC:
  • Ter uma entrada na Root Table (RC) apontando para o Internet Gateway

Cada subnet deve ser associada a uma Availability Zone (AZ). Se a Availability Zone associada a uma subnet estiver indisponível, então a subnet também estará indisponível. Para criar um ambiente de alta disponibilidade você deve replicar suas subnets em diferentes Availability Zones.

Endereços IP reservados
Dentro de uma subnet, os seguintes endereços IP são reservados para a AWS:

  • x.x.x.0 => Network
  • x.x.x.0 => AWS Routing
  • x.x.x.0 => AQS DNS
  • x.x.x.0 => AWS Future
  • x.x.x.last => Broadcast

Configuração de segurança em uma VPC

Network Access Control Lists (NACLs)

Usamos NACLs para controlar o tráfego de entrada e saída de uma subnet (também chamamos de network level). Você pode configurar os protocolos, portas e endereços IP (tanto para aceitar ou rejeita o tráfego).

Uma subset deve possuir apenas uma RC e um NACL, no entanto, uma mesma RC ou NACL pode ser compartilhada em múltiplas subnets.

Security Groups (SG)

Este é um outro recurso de segurança, similar aos NACLs, porém configurados no nível da instância (é possível limitar acessos a determinados recursos de dentro de uma subnet, por exemplo, databases). Por padrão, o que estiver dentro do SG é permitido (não nos dá a opção de permitir ou negar, como acontece nos NACLs).

Sendo assim, quando uma determinada requisição é enviada, primeiro a requisição será confrontada pelo NACL associado à subnet e depois será confrontada com o SG associado ao serviço que a requisição está tentando acessar.

Por fim, SG são stateful, o que significa que não é necessário criar regras específicas para controlar retorno de tráfego (return traffic) das requisições. Diferentemente de NACLs, que são stateless.

By default, security groups allow all outbound traffic and deny all inbound traffic.

NAT Gateway

Você pode usar um NAT Gateway para permitir acesso à internet dentro de uma subnet private. Esse tipo de cenário é necessário para que seja possível atualizar serviços que rodam dentro de uma subnet sem acesso à internet.

Neste caso, podemos configurar um NAT Gateway dentro de uma subnet pública para que o mesmo tenha acesso a um Internet Gateway e, consequentemente, tenha acesso à internet. Em seguida, alteramos a Root Table da subnet private para apontar para este NAT Gateway (da mesma forma como a subnet pública foi associada ao Internet Gateway).

O NAT Gateway permitirá tráfego de saída entre a subnet PARA a internet (outbound traffic).

Bastion Hosts

São instâncias EC2 configuradas dentro da subnet pública que podem ser configuradas para permitir acesso os recursos de uma subnet privada. Por exemplo, um desenvolvedor que precisa acessar uma instância EC2 que pertence à rede privada.

Neste caso, bastion host funciona como uma ponte de conexão entre a rede pública e a rede privada. Você deve efetuar as devidas configurações nos securiry groups de cada recurso (bastion host e nos recursos da rede privada) para que esta conexão seja possível. Neste exemplo, teria que liberar o acesso SSH apropriado, exemplo:

  • Permitir acesso SSH a partir do endereço IP do desenvolvedor para o bastion host
  • Permitir acesso ao recurso que está dentro da rede privada a partir do bastion host

Por segurança, uma boa prática é armazenar as chaves de acesso aos recursos privados dentro da própria máquina do desenvolvedor, ao invés de guardar estas chaves no bastion host.

Configuração de conectividade de uma VPC

VPN

Também é possível estabelecer conexão entre uma remote location (por exemplo, um data center) e uma Amazon VPC. Para que isso seja possível é preciso configurar um Customer Gateway (do lado do cliente) e um Virtual Gateway (do lado da VPC da Amazon AWS).

Com estes dois elementos adicionados à arquitetura, cria-se então um VPN Tunnel para estabelecimento da conexão (este túnel utiliza a internet). Vale ressaltar que a conexão só pode ser estabelecida a partir do lado do cliente.

Similarmente ao que já foi dito até agora, para configurar este túnel é necessário alterar Root Table da sua VPC e especificar a relação entre os Gateways (Customer e Virtual Gateways).

Direct Connect

Esta é uma forma de conectar uma remote location com uma Amazon VPC por meio de uma conexão direta (não usa a internet…mas sim uma infraestrutura própria). Esta infraestrutura própria é conhecida como Direct Connect Location.

VPC Peering

Permite a conexão entre duas VPCs (não precisam estar na mesma região). Se você possui mais de duas VPCs e quer conectar todas elas, então precisa criar uma conexão para cada par de VPCs (requester e acceptor).

Um outro ponto muito importante é que não será possível conectar duas VPCs caso exista um conflito de IP entre as mesmas.

O pareamento de duas VPCs também requer a adição de novas entradas nas Root Tables de cada VPC. Ambas devem apontar para a mesma peered connection.

Transit Gateway

Até aqui vimos que existem diferentes formas de configurar conexões entre VPCs. O grande problema é que, dependendo da quantidade de VPCs, pode ser difícil gerenciar essa infraestrutura. Transit Gateway resolve este problema ao centralizar todas as configurações de conexão em um único local. Desta forma, sempre que uma nova forma de conexão for necessária, a configuração deve ser feita diretamente no Transit Gateway.

Fonte: Cloud Academy – Virtual Private Cloud

1 comentário

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s

%d blogueiros gostam disto: