Por que precisamos de sub-rede privada na VPC?

Existem 4 cenários no AWS VPC configure. Mas vamos olhar para esses dois:

• Cenário 1: 1 sub-rede pública.
• Cenário 2: 1 sub-rede pública e 1 sub-rede privada.

Como qualquer instância iniciada na sub-rede pública não possui EIP (a menos que esteja atribuída), ela já não é endereçável na Internet. Então:

• Por que há uma necessidade de sub-rede privada?
• Quais são exatamente as diferenças entre sub-redes públicas e privadas?

Atualização: no final de dezembro de 2015, a AWS anunciou um novo recurso, um Gateway NAT gerenciado para VPC . Esse serviço opcional fornece um mecanismo alternativo para que as instâncias VPC em uma sub-rede privada acessem a Internet, onde anteriormente a solução comum era uma instância EC2 em uma sub-rede pública na VPC, funcionando como uma "instância NAT", fornecendo tradução de endereço de rede ( tecnicamente, conversão de endereço de porta ) para instâncias em outras sub-redes privadas, permitindo que essas máquinas usem o endereço IP público da instância NAT para acesso à Internet de saída.

O novo serviço NAT gerenciado não altera fundamentalmente a aplicabilidade das informações a seguir, mas essa opção não é abordada no conteúdo a seguir. Uma instância NAT ainda pode ser usada conforme descrito, ou o serviço Gateway Gerenciado NAT pode ser provisionado. Uma versão expandida desta resposta que integra mais informações sobre o Gateway NAT e como ela se compara a uma instância NAT será apresentada, pois ambas são relevantes para o paradigma de sub-rede pública / privada na VPC.

Observe que o Internet Gateway e o NAT Gateway são dois recursos diferentes. Todas as configurações de VPC com acesso à Internet terão um objeto virtual Gateway da Internet.

Para entender a distinção entre sub-redes "privadas" e "públicas" no Amazon VPC, é necessário entender como o roteamento IP e a tradução de endereços de rede (NAT) funcionam em geral e como eles são implementados especificamente na VPC.

A diferenciação principal entre uma sub-rede pública e privada na VPC é definida pela rota padrão da sub-rede nas tabelas de roteamento da VPC.

Essa configuração, por sua vez, determina a validade do uso ou não de endereços IP públicos nas instâncias dessa sub-rede específica.

Cada sub-rede possui exatamente uma rota padrão, que pode ser apenas uma das duas coisas:

• o objeto "Gateway da Internet" da VPC, no caso de uma sub-rede "pública" ou
• um dispositivo NAT - ou seja, um gateway NAT ou uma instância do EC2, executando a função "instância da NAT", no caso de uma sub-rede "privada".

O Gateway da Internet não faz nenhuma conversão de endereço de rede para instâncias sem endereços IP públicos, portanto, uma instância sem um endereço IP público não pode se conectar externamente à Internet - para fazer coisas como baixar atualizações de software ou acessar outros recursos da AWS como S3 ¹ e SQS - se a rota padrão em sua sub-rede VPC for o objeto Gateway da Internet. Portanto, se você é uma instância em uma sub-rede "pública", precisa de um endereço IP público para realizar um número significativo de coisas que os servidores geralmente precisam fazer.

Para instâncias com apenas um endereço IP privado, há uma maneira alternativa de acessar a Internet. É aqui que entram a Network Address Translation² e uma instância NAT.

As máquinas em uma sub-rede privada podem acessar a Internet porque a rota padrão em uma sub-rede privada não é o objeto "Gateway da Internet" da VPC - é uma instância do EC2 configurada como uma instância do NAT.

Uma instância NAT é uma instância em uma sub-rede pública com um IP público e configuração específica. Existem AMIs pré-criadas para isso, ou você pode criar as suas.

Quando as máquinas endereçadas a particulares enviam tráfego para fora, o VPC envia para a instância NAT, que substitui o endereço IP de origem no pacote (o endereço IP privado da máquina privada) pelo seu próprio endereço IP público, envia o tráfego para a Internet, aceita os pacotes de resposta e os encaminha para o endereço privado da máquina de origem. (Ele também pode reescrever a porta de origem e, em qualquer caso, lembra-se dos mapeamentos para saber qual máquina interna deve receber os pacotes de resposta). Uma instância NAT não permite que nenhum tráfego de entrada "inesperado" alcance as instâncias privadas, a menos que tenha sido especificamente configurado para isso.

Assim, ao acessar recursos externos da Internet a partir de uma sub-rede privada, o tráfego percorre a instância NAT e parece que o destino se originou do endereço IP público da instância NAT ... para que o tráfego de resposta retorne à instância NAT. Nem o grupo de segurança atribuído à instância NAT nem o grupo de segurança atribuído à instância privada precisam ser configurados para "permitir" esse tráfego de resposta, porque os grupos de segurança são stateful. Eles percebem que o tráfego de resposta está correlacionado às sessões originadas internamente, portanto, é automaticamente permitido. Obviamente, o tráfego inesperado é negado, a menos que o grupo de segurança esteja configurado para permitir isso.

Diferentemente do roteamento IP convencional, onde o gateway padrão está na mesma sub-rede, a maneira como ele funciona na VPC é diferente: a instância NAT para qualquer sub-rede privada sempre está em uma sub-rede diferente e essa outra sub-rede sempre é uma sub-rede pública, porque a instância NAT precisa ter um IP externo público e seu gateway padrão deve ser o objeto "Internet Gateway" da VPC.

Da mesma forma ... você não pode implantar uma instância com um IP público em uma sub-rede privada. Não funciona, porque a rota padrão em uma sub-rede privada é (por definição) uma instância NAT (que executa NAT no tráfego) e não o objeto Gateway da Internet (que não funciona). O tráfego de entrada da Internet atingiria o IP público da instância, mas as respostas tentariam rotear para fora através da instância NAT, o que reduziria o tráfego (já que seria composto de respostas a conexões das quais não tem conhecimento, portanto, elas seria considerado inválido) ou reescreveria o tráfego de resposta para usar seu próprio endereço IP público, o que não funcionaria, pois a origem externa não aceitaria respostas vindas de um endereço IP diferente daquele com o qual eles estavam tentando iniciar a comunicação. .

Em essência, então, as designações "privadas" e "públicas" não são realmente sobre acessibilidade ou inacessibilidade da Internet. Eles são sobre os tipos de endereços que serão atribuídos às instâncias nessa sub-rede, o que é relevante devido à necessidade de traduzir - ou evitar a tradução - desses endereços IP para interações na Internet.

Como a VPC possui rotas implícitas de todas as sub-redes da VPC para todas as outras sub-redes da VPC, a rota padrão não desempenha uma função no tráfego interno da VPC. Instâncias com endereços IP privados serão conectados a outros endereços IP privados na VPC "de" seu endereço IP privado, não "de" seu endereço IP público (se eles tiverem um) ... desde que o endereço de destino seja outro endereço privado dentro da VPC.

Se suas instâncias com endereços IP privados nunca, em nenhuma circunstância, precisarem originar tráfego de saída da Internet, elas tecnicamente poderiam ser implantadas em uma sub-rede "pública" e ainda assim permaneceriam inacessíveis pela Internet ... mas sob essa configuração, é impossível que eles originem tráfego de saída para a Internet, o que inclui conexões com outros serviços de infraestrutura da AWS, novamente, como S3 ¹ ou SQS.

^{1. Em relação ao S3, especificamente, dizer que o acesso à Internet é sempre necessário é uma simplificação excessiva que provavelmente aumentará em escopo ao longo do tempo e se espalhará para outros serviços da AWS, à medida que os recursos da VPC continuam a crescer e evoluir. Há um conceito relativamente novo chamado de ponto de extremidade da VPCpermite que suas instâncias, incluindo aquelas com apenas endereços IP privados, acessem diretamente o S3 a partir de sub-redes selecionadas na VPC, sem tocar na "Internet" e sem usar uma instância ou gateway NAT, mas isso requer configuração adicional e é apenas utilizável para acessar buckets na mesma região da AWS que sua VPC. Por padrão, o S3 - que é, até o momento em que este documento foi escrito, o único serviço que expôs a capacidade de criar pontos de extremidade de VPC - só pode ser acessado de dentro da VPC pela Internet. Quando você cria um ponto de extremidade da VPC, isso cria uma lista de prefixos (pl-xxxxxxxx) que você pode usar nas tabelas de rotas da VPC para enviar o tráfego vinculado a esse serviço específico da AWS diretamente ao serviço por meio do objeto virtual "Ponto de extremidade da VPC". Ele também resolve um problema de restrição de acesso de saída ao S3, por exemplo, porque a lista de prefixos pode ser usada em grupos de segurança de saída, no lugar de um endereço IP ou bloco de destino - e um ponto de extremidade S3 VPC pode estar sujeito a declarações de política adicionais , restringindo o acesso à caçamba por dentro, conforme desejado.}

^{2. Conforme observado na documentação, o que realmente está sendo discutido aqui é a porta e a tradução de endereços de rede. É comum, embora tecnicamente um pouco impreciso, referir-se à operação combinada como "NAT". Isso é parecido com o modo como muitos de nós costumamos dizer "SSL" quando na verdade queremos dizer "TLS". Sabemos do que estamos falando, mas não usamos a palavra mais correta para descrevê-la. "Nota Usamos o termo NAT nesta documentação para seguir práticas comuns de TI, embora a função real de um dispositivo NAT seja a tradução de endereços e a tradução de endereços de porta (PAT)."}

Eu sugeriria uma sub-rede "privada" e instâncias / gateways NAT particulares. Eles não são necessários. Se você não deseja que a máquina seja acessível pela Internet, não a coloque em um grupo de segurança que permita esse acesso.

Ao abandonar a instância / gateway NAT, você está eliminando o custo de execução da instância / gateway e o limite de velocidade (seja 250mbit ou 10gbit).

Se você possui uma máquina que também não precisa acessar a Internet diretamente (e eu perguntaria como você está corrigindo *), então, por todos os meios, não atribua um endereço IP público.

* Se a resposta aqui é algum tipo de proxy, bem, você está tendo uma sobrecarga, mas cada uma por conta própria.

Não tenho reputação de adicionar um comentário à resposta de Michael acima, adicionando meu comentário como resposta.

Vale ressaltar que o gateway gerenciado da AWS é aproximadamente 3 vezes mais caro do que na data quando comparado à execução de sua própria instância. Obviamente, isso pressupõe que você precisa apenas de uma instância NAT (ou seja, não possui várias instâncias NAT configuradas para failover etc.), o que geralmente é verdadeiro para a maioria dos cenários de casos de uso pequenos e médios. Supondo uma transferência mensal de dados de 100 GB via gateway NAT,

Custo mensal da instância NAT gerenciada = US $ 33,48 / mês (US $ 0,045 / hora * 744 horas em um mês) + US $ 4,50 (US $ 0,045 por GB de dados processados ​​* 100 GB) + US $ 10 (US $ 10,10 / GB de taxas de transferência de dados padrão da AWS de todos os dados transferidos via Gateway NAT) = $ 47,98

instância t2.nano configurada como uma instância NAT = US $ 4,84 / mês (US $ 0,0065 * 744 horas em um mês) + US $ 10 (taxas de transferência de dados padrão da AWS de US $ 0,10 / GB para todos os dados transferidos pela instância NAT) = US $ 14,84

É claro que isso muda quando você procura instâncias NAT redundantes, pois o gateway NAT gerenciado pela AWS possui redundância interna para alta disponibilidade. Se você não se importa com os US $ 33 / mês extras, a instância NAT gerenciada vale definitivamente a dor de cabeça reduzida por não precisar manter outra instância. Se você estiver executando uma instância de VPN (por exemplo, OpenVPN) para acessar suas instâncias na VPC, poderá simplesmente configurá-la para atuar como seu gateway NAT e não precisará manter uma instância extra apenas para NAT ( embora algumas pessoas possam desaprovar a ideia de combinar VPN e NAT).

A resposta de Michael - sqlbot faz a suposição implícita de que endereços IP privados são necessários. Eu acho que vale a pena questionar essa suposição - precisamos mesmo usar endereços IP privados em primeiro lugar? Pelo menos um comentarista fez a mesma pergunta.

Qual é a vantagem de um servidor em uma sub-rede privada com uma instância NAT [vs.] um servidor [em] uma sub-rede pública com uma política de segurança estrita? - abhillman 24 '14 junho às 23:45

Imagine um cenário em que você esteja usando uma VPC e atribua endereços IP públicos a todas as suas instâncias do EC2. Não se preocupe, isso não significa que eles estejam necessariamente acessíveis pela Internet, porque você usa grupos de segurança para restringir o acesso exatamente da mesma maneira que as coisas funcionavam com o EC2 classic. Ao usar endereços IP públicos, você tem a vantagem de poder expor facilmente determinados serviços a um público limitado, sem precisar usar algo como um ELB. Isso libera você da necessidade de configurar uma instância ou gateway NAT. E como você precisa de metade do número de sub-redes, pode optar por usar uma alocação CIDR menor para sua VPC ou criar sub-redes maiores com o mesmo tamanho de VPC. E menos sub-redes significa que você também pagará menos pelo tráfego entre AZ.

Então, por que não fazemos isso? Por que a AWS diz que a melhor prática é usar IPs privados?

O Amazon Web Services possui um suprimento limitado de endereços IPv4 públicos, porque a Internet como um todo possui um suprimento limitado de endereços IPv4 públicos. É do interesse deles usar endereços IP privados efetivamente ilimitados, em vez de consumir excessivamente endereços IPv4 públicos escassos. Você pode ver algumas evidências disso em como a AWS precifica IPs elásticos; um EIP anexado a uma instância é gratuito, mas um EIP não utilizado custa dinheiro.

Mas, por uma questão de argumento, vamos supor que não nos importamos com a falta de endereços IPv4 públicos na Internet. Afinal, minha inscrição é especial. O que acontece depois?

Existem apenas duas maneiras de conectar um endereço IP público a uma instância do EC2 em uma VPC.

1. Endereço IP público associado

Você pode solicitar um endereço IP público ao iniciar uma nova instância do EC2. Essa opção aparece como uma caixa de seleção no console, como o sinalizador --associate-public-ip-address ao usar o aws-cli e como o sinalizador AssociatePublicIpAddress em um objeto de interface de rede incorporado ao usar o CloudFormation. De qualquer forma, o endereço IP público é atribuído a eth0(DeviceIndex = 0). Você só pode usar essa abordagem ao iniciar uma nova instância. No entanto, isso vem com algumas desvantagens.

Uma desvantagem é que alterar o grupo de segurança de uma instância que está usando um objeto de interface de rede incorporado forçará a substituição imediata da instância, pelo menos se você estiver usando o CloudFormation.

Outra desvantagem é que um endereço IP público atribuído dessa maneira será perdido quando a instância for parada.

2. IP elástico

Em geral, os IPs elásticos são a abordagem preferida porque são mais seguros. É garantido que você continua usando o mesmo endereço IP, não corre o risco de excluir acidentalmente nenhuma instância do EC2, pode anexar / desanexar livremente um IP Elastic a qualquer momento e tem a liberdade de alterar os grupos de segurança aplicados às instâncias do EC2.

... Mas a AWS limita você a 5 EIPs por região. Você pode solicitar mais e sua solicitação pode ser atendida. Mas a AWS poderia igualmente negar essa solicitação com base no raciocínio mencionado acima. Portanto, você provavelmente não deseja confiar nos EIPs se planeja escalar sua infraestrutura além de 5 instâncias do EC2 por região.

Em conclusão, o uso de endereços IP públicos traz alguns benefícios, mas você terá problemas administrativos ou de escala se tentar usar exclusivamente endereços IP públicos. Espero que isso ajude a ilustrar e explicar por que as melhores práticas são do jeito que são.