Perguntas frequentes sobre a Amazon VPC

Não há encargos adicionais para a criação e o uso da própria VPC. Os encargos de uso de outros Amazon Web Services, incluindo Amazon EC2, ainda se aplicam a taxas publicadas para tais recursos, incluindo cobrança por transferência de dados. Se você conectar sua VPC ao datacenter corporativo usando a conexão via VPN de hardware opcional, a definição de preço será por hora de conexão da VPN (o período no qual uma conexão VPN ficou no estado “available”). Horas parciais são cobradas como horas completas. Os dados transferidos em conexões VPN serão cobrados como taxas padrão de transferência de dados da AWS. Para obter informações sobre a definição de preço da VPC-VPN, visite a seção de definição de preço da página do produto Amazon VPC.

A cobrança de uso de outros serviços da Amazon Web Services, como o Amazon EC2, ainda serão aplicados de acordo com as taxas publicadas para tais recursos. As cobranças por transferência de dados não são feitas durante o acesso a serviços da Amazon Web Services, como o Amazon S3, por meio do gateway da Internet da VPC.

Se você acessar recursos da AWS por meio da sua conexão VPN, serão cobradas taxas de transferência de dados pela Internet.

Você pode conectar a Amazon VPC:

• À Internet (por meio de um Internet Gateway)
• Ao seu datacenter corporativo usando uma conexão do AWS Site-to-Site VPN (por meio do gateway privado virtual)
• À Internet e ao datacenter corporativo (utilizando um Internet Gateway e um gateway privado virtual)
• A outros serviços da AWS (por meio de Internet Gateway, NAT, gateway privado virtual ou VPC endpoints)
• Outras Amazon VPCs (por meio de conexões emparelhadas de VPCs)

A Amazon VPC é compatível com a criação de um gateway da Internet. Esse gateway permite que instâncias do Amazon EC2 no VPC acessem diretamente a Internet. Você também pode usar um gateway da Internet somente para saída, que é um gateway com estado para oferecer acesso somente de saída a tráfego IPv6 da VPC para a Internet.

Não. Um Internet Gateway é horizontalmente escalado, redundante e altamente disponível. Não há limites de largura de banda.

É possível usar endereços IP públicos, como endereços IP elásticos (EIPs) e Global Unicast Adresses (GUAs - endereços globais unicast) IPv6, para disponibilizar às instâncias da VPC a capacidade de se comunicarem diretamente fora da Internet e de receber tráfego interno não solicitado da Internet (por exemplo, servidores da Web). Você também pode usar as soluções da próxima pergunta.

Qualquer endereço IP atribuído a uma instância ou serviço hospedado em uma VPC que pode ser acessado na Internet é considerado um endereço IP público. Somente endereços IPv4 públicos, incluindo endereços IP elásticos (EIPs) e GUAs IPv6 podem ser roteáveis na Internet. Para tal, é necessário que você primeiro conecte a VPC à Internet e, em seguida, atualize a tabela de rotas para torná-las acessíveis de/para a Internet.

As instâncias sem endereços IP públicos podem acessar a Internet de duas formas:

1. As instâncias sem endereços IP públicos podem rotear seus tráfegos por meio de um gateway NAT ou uma instância NAT para acessar a Internet. Essas instâncias usam o endereço IP público do gateway NAT ou da instância NAT para percorrer a Internet. O gateway NAT ou a instância NAT permite a comunicação do lado de fora, mas não permite que as máquinas na Internet iniciem uma conexão com instâncias com endereços privados.
2. Para VPCs com uma conexão VPN de hardware ou Direct Connect, as instâncias podem rotear o tráfego de Internet por meio do gateway privado virtual para o seu datacenter atual. Lá, ele pode acessar a Internet por meio dos pontos de saída existentes e dos dispositivos de segurança/monitoramento de rede.

Sim. É possível usar uma VPN de software terceirizado para criar uma conexão VPN entre sites ou para acesso remoto com a VPC por meio do gateway da Internet.

Não. Ao usar endereços IP públicos, todas as comunicações entre instâncias e serviços hospedados na AWS usam a rede privada da AWS. Os pacotes que se originam da rede da AWS com destino na rede da AWS permanecem na rede global da AWS, exceto o tráfego de ou para as regiões da AWS China.

Além disso, todos os dados que passam pela rede global da AWS que interconectam nossos datacenters e regiões são criptografados automaticamente na camada física antes de sair de nossas instalações protegidas. Existem também camadas de criptografia adicionais; por exemplo, todo o tráfego de emparelhamento de VPC entre regiões e conexões TLS de clientes ou entre serviços. 

Uma conexão do AWS Site-to-Site VPN conecta a VPC ao datacenter. A Amazon oferece suporte a conexões de VPN Internet Protocol Security (IPSec). Os dados transferidos entre a VPC e o datacenter passam por uma conexão VPN criptografada para ajudar a manter a confidencialidade e a integridade dos dados em trânsito. Não é necessário ter um Internet Gateway para estabelecer uma conexão do AWS Site-to-Site VPN.

É possível usar qualquer intervalo de endereço IPv4, inclusive RFC 1918 ou intervalos IP publicamente roteáveis para o bloco CIDR principal. Para os blocos CIDR secundários, são aplicadas determinadas restrições. Os blocos IP publicamente direcionáveis são acessados apenas por meio do gateway privado virtual e não podem ser acessados pela Internet por meio do Internet Gateway. A AWS não publica blocos de endereços IP de propriedade do cliente na Internet. Você pode alocar até cinco blocos BYOIP CIDR GUA IPv6 fornecidos pela Amazon a uma VPC chamando a API relevante ou por meio do Console de Gerenciamento da AWS.

Você pode atribuir um único intervalo de endereço IP de Classless Internet Domain Routing (CIDR - Roteamento entre domínios sem classes) como bloco CIDR principal ao criar uma VPC, e adicionar até 4 (quatro) blocos CIDR secundários após a criação da VPC. As sub-redes em uma VPC são endereçadas por você com base nesses intervalos CIDR. Observe que, embora seja possível criar várias VPCs com intervalos de endereços IP sobrepostos, você não conseguirá conectar estas VPCs a uma rede doméstica comum por meio da conexão VPN de hardware. Por isso, recomendamos o uso de intervalos de endereço IP que não se sobrescrevam. Você pode alocar até cinco blocos BYOIP CIDR GUA IPv6 fornecidos pela Amazon à sua VPC.

As VPCs padrão recebem uma atribuição de intervalo CIDR de 172.31.0.0/16. Os subnets padrão dentro de uma VPC padrão recebem uma designação de netblocks /20 dentro do intervalo CIDR da VPC. 

Sim. Você pode trazer seus endereços IPv4 públicos e GUA IPv6 para a VPC da AWS e alocá-los estaticamente em sub-redes e instâncias do EC2. Para acessar esses endereços pela Internet, será necessário publicá-los na Internet a partir da rede on-premises. Também será necessário rotear o tráfego por esses endereços entre a VPC e a rede local usando uma conexão AWS DX ou AWS VPN. Você pode rotear o tráfego da VPC usando o Virtual Private Gateway. De forma semelhante, você pode rotear o tráfego de sua rede local de volta para a VPC usando seus routers.

No momento, a Amazon VPC aceita cinco intervalos de endereço IP, um principal e quatro secundários para IPv4. Cada um desses intervalos pode ter um tamanho entre /28 (em notação CIDR) e /16. Os intervalos de endereço IP da VPC não devem sobrepor os intervalos de endereço IP da rede atual.

No IPv6, a VPC tem um tamanho fixo de /56 (em notação CIDR). Uma VPC pode ter blocos CIDR IPv4 e IPv6 associados a ela.

Sim. É possível expandir a VPC atual ao adicionar quatro intervalos (CIDRs) IP IPv4 secundários à VPC. É possível reduzir a VPC excluindo blocos CIDR secundários adicionados por você à VPC.   Da mesma maneira, você pode acrescentar até cinco intervalos (CIDRs) adicionais IP IPv6 à VPC.  É possível reduzir a VPC excluindo esses intervalos adicionais.

No momento, é possível criar 200 sub-redes por VPC. Se você desejar criar mais, envie um caso à central de suporte.

O tamanho mínimo de uma sub-rede é /28 (ou 14 endereços IP) para IPv4. As sub-redes não podem ser maiores que a VPC na qual foram criadas.

Para IPv6, o tamanho da sub-rede é fixo em /64. Apenas um bloco CIDR IPv6 pode ser alocado a uma sub-rede.

Não. A Amazon reserva os primeiros quatro (4) endereços IP e o último (1) endereço IP de toda sub-rede para finalidades de rede IP.

Ao iniciar uma instância do Amazon EC2 em uma sub-rede que não seja somente IPv6, você pode especificar opcionalmente o endereço IPv4 privado primário para a instância. Se você não especificar o endereço IPv4 privado primário, a AWS o endereçará automaticamente com base no intervalo de endereços IPv4 que você atribuiu para essa sub-rede. Você pode atribuir endereços IPv4 privados secundários ao iniciar uma instância, ao criar uma interface de rede elástica ou a qualquer momento após a inicialização da instância ou a criação da interface. Se você iniciar uma instância do Amazon EC2 em uma sub-rede somente IPv6, a AWS automaticamente a endereçará a partir do CIDR GUA IPv6 desta sub-rede. O GUA IPv6 de instância permanecerá privado, a menos que você os torne acessíveis de e para a Internet com o grupo de segurança certo, com a Network Access Control List (NACL - lista de controle de acesso à rede) e com a configuração da tabela de rotas.

Para uma instância iniciada em um sub-rede IPv4 ou de pilha dupla, o endereço IPv4 privado primário é retido durante o tempo de vida da instância ou da interface. Endereços IPv4 privados secundários podem ser atribuídos, ter sua atribuição cancelada ou movidos entre interfaces ou instâncias a qualquer momento. Para uma instância iniciada em uma sub-rede somente IPv6, o GUA IPv6 atribuído, que também é o primeiro endereço IP da interface de rede primária, pode ser modificado pela associação de um novo GUA IPv6 e pela remoção do GUA IPv6 existente a qualquer momento.

Não. Um endereço IPv4 atribuído a uma instância em execução só pode ser usado novamente por outra instância, desde que a instância original em execução esteja no estado “encerrado”. Entretanto, o GUA IPv6 atribuído a uma instância em execução pode ser usado novamente depois de ser removido da primeira instância.

Não. Você pode especificar o endereço IP de uma instância em um momento ao iniciar a instância.

Você pode atribuir qualquer endereço IP à sua instância, contanto que ele:

• Faça parte do intervalo de endereços IP da sub-rede associada
• Não esteja reservado pela Amazon para finalidades de rede IP
• Não atribuído a outra interface atualmente

Sim. Você pode atribuir um ou mais endereços IP privados secundários a uma interface de rede elástica ou instância do EC2 na Amazon VPC. O número de endereços IP privados secundários que você pode atribuir depende do tipo de instância. Consulte o Guia do usuário do EC2 para obter mais informações sobre o número de endereços IP privados secundários que podem ser atribuídos por tipo de instância.

Sim, porém os endereços EIP estarão acessíveis apenas com base na Internet (não por meio de uma conexão VPN). Cada endereço EIP deve ser associado a um endereço IP privado exclusivo na instância. Os endereços EIP devem ser usados apenas em instâncias em sub-redes configuradas para direcionar seu tráfego diretamente para o Internet Gateway. Os EIPs não podem ser usados em instâncias em sub-redes configuradas para usar um gateway NAT ou uma instância NAT para acessar a Internet. Isso se aplica apenas ao IPv4. No momento, as Amazon VPCs não oferecem suporte a EIPs para IPv6.

O recurso Bring Your Own IP (BYOIP – Traga seu próprio IP) permite que os clientes transfiram todo ou parte do espaço de endereços IPv4 ou IPv6 publicamente roteável deles para a AWS a fim de usá-lo com seus recursos da AWS. Os clientes continuarão a possuir o intervalo de IP. Os clientes podem criar IPs elásticos com base no espaço IPv4 que eles trouxerem para a AWS e usá-los com instâncias do EC2, Gateways NAT e Network Load Balancers. Os clientes também podem associar até cinco CIDRs a uma VPC a partir do espaço IPv6 que eles trazem para a AWS. Os clientes continuarão tendo acesso a IPs fornecidos pela Amazon e poderão optar pelo uso de IPs elásticos BYOIP, IPs fornecidos pela Amazon ou ambos.

Você pode querer trazer seus próprios endereços IP para a AWS pelos seguintes motivos:
Reputação do IP: muitos clientes consideram que a reputação dos endereços IPs deles é um ativo estratégico e querem usar esses IPs na AWS com os recursos deles. Por exemplo, clientes que mantêm serviços como MTA de e-mail de saída e têm IPs de alta reputação agora podem trazer o próprio espaço de IP e manter com sucesso sua taxa de sucesso de envio existente.

Lista de permissão de clientes: o BYOIP também permite que clientes transfiram cargas de trabalho baseadas em listas de permissão de endereço IP para a AWS sem a necessidade de restabelecer a lista de permissão com novos endereços IP.

Dependências inseridas no código: vários clientes têm IPs inseridos no código de dispositivos ou assumiram dependências de arquitetura em seus IPs. O BYOIP permite que esses clientes concretizem uma migração para a AWS livre de preocupações.

Regulamentação e conformidade: muitos clientes são obrigados a usar determinados IPs por questões de regulamento e conformidade. Eles também são desbloqueados pelo BYOIP.

Política de rede IPv6 no local: Muitos clientes podem rotear apenas o IPv6 na rede local. Esses clientes são desbloqueados pelo BYOIP, pois podem atribuir seu próprio intervalo de IPv6 à sua VPC e optar por rotear para sua rede local usando a Internet ou o Direct Connect.

Quando você libera um Elastic IP BYOIP, ele volta para o grupo de IPs BYOIP de onde foi alocado.

Consulte nossa documentação de para obter detalhes sobre a disponibilidade do BYOIP.

Sim. Você pode usar o prefixo BYOIP com qualquer número de VPCs na mesma conta.

Você pode trazer um máximo de cinco intervalos de IP para a sua conta.

Por BYOIP, o prefixo IPv4 mais específico que você pode trazer é um prefixo IPv4/24 e um prefixo IPv6/56. Se você pretende anunciar seu prefixo Ipv6 na Internet, o prefixo IPv6 mais específico é /48.

Você pode usar prefixos registrados ARIN, RIPE e APNIC.

Não aceitamos prefixos reatribuídos ou realocados no momento. Os intervalos de IP devem ser de um tipo líquido de alocação direta ou atribuição direta.

Sim. Você pode fazer isso não provisionando o prefixo BYOIP da região atual e então provisionando o prefixo na nova região.

O IP Address Manager (IPAM) do Amazon VPC é um serviço gerenciado que facilita o planejamento, rastreamento e monitoramento de endereços IP para as suas workloads da AWS. Com o IPAM você pode organizar facilmente endereços IP com base no seu roteamento e necessidades de segurança e estabelecer regras de negócios simples para regular atribuições de endereço IP. Você também pode automatizar a atribuição de endereço IP para VPCs, eliminando a necessidade de usar aplicações baseadas em planilhas ou de planejamento de endereço IP desenvolvidas internamente, que podem demandar manutenções difíceis e demoradas. O IPAM fornece uma visualização operacional unificada, que pode ser usada como uma fonte única de verdade, permitindo que você execute atividades rotineiras de gerenciamento de endereços IP, como rastrear a utilização de IP, solucionar problemas e fazer auditoria de maneira rápida e eficiente.

Você deve usar o IPAM para tornar o gerenciamento de endereço IP mais eficiente. Mecanismos existentes que utilizam planilhas ou ferramentas internas requerem trabalho manual e são propensos a erros. Com o IPAM, você pode, por exemplo, estender aplicações de maneira rápida uma vez que seus desenvolvedores não precisam aguardar a alocação da equipe central de administração de endereços IP. Você também pode detectar a sobreposição de endereços IP e repará-la antes que ocorra uma interrupção na rede. Além disso, é possível criar alertas para que o IPAM notifique se os grupos de endereços estão próximos da exaustão ou se os recursos não estão em conformidade com as regras de alocação definidas para um grupo. Esses são alguns dos motivos para usar o IPAM.

O AWS IPAM disponibiliza os seguintes recursos:
 

• Alocação de endereços IP para redes em escala: o IPAM pode automatizar as alocações de endereços IP através de centenas de contas e VPCs baseadas em regras de negócio configuráveis.
   
• Monitoramento de uso de IP através da sua rede: o IPAM pode monitorar endereços IP e permite que você receba alertas quando forem detectados potenciais problemas como endereços IP exauridos, que podem interromper a expansão da rede, ou sobreposições de endereços IP, que podem resultar em roteamentos errôneos.
   
• Solução de problemas em sua rede: o IPAM pode ajudar você a identificar se os problemas de conectividade devem-se a configurações incorretas de endereços IP ou outros problemas.
   
• Auditoria de endereços IP: o IPAM retém seus dados de monitoramento de endereços IP automaticamente (por um máximo de três anos). Você pode usar esses dados históricos para realizar análises e auditorias retrospectivas da sua rede.

A relação a seguir compõe os componentes principais do IPAM:

• Um escopo é um contêiner de nível mais alto no IPAM. Um IPAM contém dois escopos padrão. Cada escopo representa o espaço de IP para uma única rede. O escopo privado destina-se a todos os espaços privados. O escopo público destina-se a todos os espaços públicos. Os escopos permitem que você reuse endereços IP através de diversas redes não conectadas sem que isso cause sobreposição de endereços IP ou conflitos. Dentro de um escopo, você pode criar grupos de IPAM.
   
• Um grupo é uma coleção de faixas contínuas de endereços IP (ou CIDRs). Os grupos do IPAM permite que você organize seus endereços IP de acordo com suas necessidade de roteamento e segurança. Você pode ter diversos grupos dentro de um grupo superior. Por exemplo, se você tiver necessidades de roteamento e segurança separadas para aplicações de desenvolvimento e produção, você pode criar um grupo para cada uma delas. Dentro de grupos do IPAM, é possível alocar CIDRs para recursos da AWS.
• Uma alocação é uma atribuição da CIDR de um grupo do IPAM para outro recurso ou grupo. Ao criar uma VPC e selecionar um grupo do IPAM para a CIDR da VPC, essa CIDR é alocada da CIDR provisionada para o grupo do IPAM. Você pode monitorar e gerenciar a alocação com o IPAM.

Sim. O IPAM é compatível como os endereços BYOIPv4 e BYOIPv6. O BYOIP é um recurso do EC2 que permite que você traga seu próprio endereço IP para AWS. Com o IPAM, é possível provisionar e compartilhar diretamente seus blocos de endereço IP entre contas e empresas. Clientes do BYOIP existentes que usam IPv4 podem migrar seus grupos para o IPAM, simplificando o gerenciamento de IP.

Sim, a Amazon fornece blocos contínuos de CIDR IPv6 para alocação de VPC. Os blocos contínuos de CIDR permite agregar CIDRs para uma única entrada em estruturas de rede e segurança, como listas de controle de acesso, tabelas de rotas, grupos de segurança e firewalls. Você pode provisionar CIDRs IPv6 da Amazon em um grupo de escopo público e usar todos os recursos do IPAM para gerenciar e monitorar o uso de IP. A alocação desses blocos CIDR inicia em /52 incrementos e blocos maiores estão disponíveis mediante solicitação. Por exemplo, você pode alocar /52 CIDR da Amazon e usar o IPAM para o compartilhamento entre contas e criar VPCs entre elas.

Não, os blocos CIDR IPv6 contínuos fornecidos pela Amazon somente são compatíveis atualmente no IPAM.

Você pode compartilhar grupos do IPAM com outras contas em sua organização da AWS através do AWS Resource Access Manager (RAM). Você também pode compartilhar grupos do IPAM com contas externas à sua organização da AWS primária. Por exemplo, essas contas podem representar outra linha de negócios na empresa ou um serviço gerenciado hospedado para você por um parceiro em outra organização da AWS.

Sim. Você poderá criar uma rota padrão para cada sub-rede. A rota padrão pode direcionar o tráfego para encaminhar a VPC para fora via gateway da Internet, virtual private gateway ou gateway NAT.

Os grupos de segurança do Amazon EC2 podem ser usados para ajudar a proteger instâncias dentro do Amazon VPC. Os grupos de segurança em uma VPC permitem que você especifique o tráfego de rede de entrada e de saída permitido de/para cada instância do Amazon EC2. O tráfego que não é explicitamente permitido para ou com base em uma instância é recusado automaticamente.

Além dos grupos de segurança, o tráfego de rede entrando e saindo de cada sub-rede pode ser permitido ou recusado por meio de Listas de controle de acesso (ACLs) da rede.

Os grupos de segurança em um VPC especificam qual tráfego é permitido para ou com base em uma instância do Amazon EC2. Os ACLs da rede operam no nível da sub-rede e avaliam o tráfego que entra e sai de uma sub-rede. Os ACLs da rede podem ser usados para definir as regras Permitir e Recusar. Os ACLs da rede não filtram o tráfego entre instâncias na mesma sub-rede. Além disso, os ACLs de rede desempenham a filtragem sem estado, enquanto os grupos de segurança desempenham a filtragem com estado.

A filtragem stateful monitora a origem de uma solicitação e pode permitir automaticamente que a resposta à solicitação seja devolvida para o computador de origem. Por exemplo, um filtro stateful que permite o tráfego de entrada na porta 80 TCP em um servidor web permitirá que o tráfego de retorno passe pelo filtro stateful entre o cliente e o servidor web, normalmente em uma porta de numeração elevada (por exemplo, porta 63.912). O dispositivo de filtragem mantém uma tabela de estado que monitora os números das portas de origem e de destino e os endereços IP. Somente uma regra é exigida no dispositivo de filtragem: permitir tráfego de entrada no servidor web na porta 80 TCP.

Por outro lado, a filtragem stateless analisa somente o endereço IP de origem e de destino, e a porta de destino, ignorando se o tráfego é uma nova solicitação ou uma resposta a uma solicitação. No exemplo acima, seria necessário implementar duas regras no dispositivo de filtragem: uma regra para permitir a entrada do tráfego no servidor da web na porta 80 TCP e outra regra para permitir o tráfego de saída do servidor da web (intervalo de portas TCP de 49, 152 até 65, 535).

Sim. Se um Internet Gateway tiver sido configurado, o tráfego da Amazon VPC vinculado a instâncias do Amazon EC2 que não estiver em uma VPC passará pelo Internet Gateway e, em seguida, entrará na rede pública da AWS para acessar a instância do EC2. Se um gateway da Internet não tiver sido configurado ou se a instância estiver em uma sub-rede configurada para direcionar por meio do virtual private gateway, o tráfego passará pela conexão VPN, sairá do datacenter e, em seguida, será reinserido na rede pública da AWS.

Sim. As instâncias em uma região podem se comunicar com outras usando o Inter-Region VPC Peering, endereços IP públicos, gateway NAT, instâncias NAT ou conexões VPN ou Direct Connect.

Sim. Existem várias opções para que os seus recursos dentro da VPC se comuniquem com o Amazon S3. Você pode usar o VPC endpoint para o S3, que garante a permanência de todo o tráfego dentro da rede da Amazon e permite que você aplique políticas de acesso adicionais ao tráfego do Amazon S3. Você pode usar o Internet Gateway para permitir acesso da sua VPC à Internet, e as instâncias na VPC podem se comunicar com o Amazon S3. Você também pode fazer com que todo o tráfego para o Amazon S3 passe pelo Direct Connect ou pela conexão VPN, saia do seu datacenter e entre novamente na rede pública da AWS.

Sim. Você pode usar os recursos de espelhamento de tráfego e logs de fluxo do Amazon VPC para monitorar o tráfego de rede no Amazon VPC.

Os logs de fluxo de VPC são um recurso que permite capturar informações sobre o tráfego IP que vai de e para as interfaces de rede em sua VPC. Os dados dos logs de fluxo podem ser publicados no Amazon CloudWatch Logs ou no Amazon S3. Você pode monitorar seus logs de fluxo de VPC para obter visibilidade operacional sobre suas dependências de rede e padrões de tráfego, detectar anomalias e evitar vazamento de dados ou solucionar problemas de conectividade e configuração de rede. Os metadados enriquecidos em logs de fluxo ajudam você a obter insights adicionais sobre quem iniciou suas conexões TCP e a origem e destino em nível de pacote real para o tráfego que flui por camadas intermediárias, como o Gateway NAT. Você também pode arquivar seus logs de fluxo para atender aos requisitos de conformidade. Para saber mais sobre os logs de fluxo do Amazon VPC, consulte a documentação.

Você pode criar um log de fluxo para uma VPC, uma sub-rede ou uma interface de rede. Se você criar um log de fluxo para uma sub-rede ou VPC, cada interface de rede nessa sub-rede ou VPC será monitorada. Ao criar uma assinatura de log de fluxo, você pode escolher os campos de metadados que deseja capturar, o intervalo máximo de agregação e seu destino de log preferido. Você também pode optar por capturar todo o tráfego ou apenas o tráfego aceito ou rejeitado. Você pode usar ferramentas como o CloudWatch Log Insights ou CloudWatch Contributor Insights para analisar seus logs de fluxo de VPC entregues a CloudWatch Logs. Você pode usar ferramentas como o Amazon Athena ou AWS QuickSight para consultar e visualizar seus logs de fluxo de VPC entregues ao Amazon S3. Você também pode criar uma aplicação downstream personalizada para analisar seus logs ou usar soluções de parceiros, como Splunk, Datadog, Sumo Logic, Cisco StealthWatch, Checkpoint CloudGuard, New Relic etc.

Sim, você pode criar o log de fluxo da VPC para um gateway de trânsito ou para um anexo do gateway de trânsito individual. Com esse recurso, o Transit Gateway pode exportar informações detalhadas, como endereços IP de origem/destino, portas, protocolo, contadores de tráfego, carimbos de data/hora e vários metadados dos fluxos de rede por meio do Transit Gateway. Para saber mais sobre o suporte aos logs de fluxo do Amazon VPC para o Transit Gateway, consulte a documentação.

Os dados do log de fluxo são coletados fora do caminho de seu tráfego de rede e, portanto, não afetam a taxa de transferência ou a latência da rede. Você pode criar ou excluir logs de fluxo sem nenhum risco de impacto na performance da rede.

O consumo de dados e as cobranças por arquivamento de logs vendidos se aplicam quando você publica logs de fluxo no CloudWatch Logs ou no Amazon S3. Para obter mais informações e exemplos, consulte Preço do Amazon CloudWatch. Você também pode rastrear cobranças de publicação de logs de fluxo usando tags de alocação de custos.

O espelhamento de tráfego do Amazon VPC facilita a replicação do tráfego de rede de/para uma instância do Amazon EC2 e o encaminhamento desse tráfego replicado para dispositivos de segurança e monitoramento assíncronos para casos de uso como inspeção de conteúdo, monitoramento de ameaças e resolução de problemas. Os dispositivos podem ser implantados em uma instância do EC2 individual ou em uma frota de instâncias atrás de um network load balancer (NLB) com um listener do protocolo UDP (user datagram protocol).

O espelhamento de tráfego oferece suporte a capturas de pacote de redes no nível da interface de rede elástica (ENI) de instâncias do EC2. Consulte a documentação sobre espelhamento de tráfego das instâncias do EC2 compatíveis com o Amazon VPC Traffic Mirroring.

Os clientes podem usar ferramentas de código aberto ou escolher entre uma grande variedade de soluções de monitoramento disponíveis no AWS Marketplace. O espelhamento de tráfego permite que os clientes façam streaming do tráfego replicado para qualquer coletor/agente ou ferramenta analítica de pacotes de rede, sem necessidade de instalar agentes específicos dos fornecedores.

Os logs de fluxo do Amazon VPC permitem que os clientes coletem, armazenem e analisem logs de fluxo de rede. As informações capturadas em logs de fluxo incluem informações sobre tráfego permitido e proibido, endereços IP de origem e destino, portas, número de protocolos, quantidade de pacotes e bytes e uma ação (aceitar ou rejeitar). Você pode usar esse recurso para solucionar problemas de conectividade e segurança, bem como para garantir que as regras de acesso à rede funcionem da maneira esperada.

O espelhamento de tráfego do Amazon VPC oferece insights mais detalhados do tráfego de rede, permitindo que você analise o conteúdo real do tráfego, incluindo a carga útil, e é direcionado a casos de uso em que é necessário analisar os pacotes reais para determinar a causa-raiz de um problema de performance, fazer engenharia reversa de um ataque de rede sofisticado ou detectar e interromper cargas de trabalho comprometidas ou abusos internos.

No momento, a Amazon VPC está disponível em várias zonas de disponibilidade em todas as regiões do Amazon EC2.

Sim. 

Não. Um sub-rede deve residir em uma única zona de disponibilidade.

Quando você executa uma instância do Amazon EC2, deve especificar a sub-rede na qual a instância será executada. A instância será executada na zona de disponibilidade associada à sub-rede especificada.

Ao criar um subnet, você deve especificar a zona de disponibilidade na qual o subnet será disposto. Ao usar o Assistente da VPC, você pode selecionar a zona de disponibilidade do sub-rede na tela de confirmação do assistente. Usando a API ou a ILC, é possível especificar a zona de disponibilidade para o sub-rede durante sua criação. Caso uma zona de disponibilidade não seja especificada, a opção padrão "No Preference" será selecionada e a sub-rede será criada em uma zona de disponibilidade disponível na região.

Se as instâncias residirem em sub-redes em zonas de disponibilidade diferentes, haverá uma cobrança 0,01 USD por GB para a transferência de dados.

Sim. DescribeInstances() retornará todas as instâncias em execução do Amazon EC2. Você pode diferenciar instâncias EC2-Classic de instâncias EC2-VPC por uma entrada no campo de sub-rede. Se houver um ID de subnet listado, a instância estará dentro de uma VPC.

Sim. DescribeVolumes() retornará todos os volumes do EBS.

Para instâncias que requerem endereçamento IPv4, você pode executar qualquer número de instâncias do Amazon EC2 em uma VPC, desde que a VPC esteja adequadamente dimensionada para ter um endereço IPv4 para cada instância. Inicialmente, há um limite de execução de 20 instâncias do Amazon EC2 a qualquer momento e um tamanho máximo de VPC de /16 (65.536 IPs). Se você quiser aumentar esses limites, preencha o formulário a seguir. Para instâncias somente IPv6, o tamanho /56 da VPC fornece a capacidade de inicialização de um número praticamente ilimitado de instâncias do Amazon EC2.

É possível usar AMIs no Amazon VPC que estão registrados na mesma região que seu VPC. Por exemplo, você pode usar AMIs registradas em us-east-1 com uma VPC em us-east-1. Mais informações estão disponíveis nas perguntas frequentes sobre regiões e zonas de disponibilidade do Amazon EC2.

Sim, você poderá usar snapshots do Amazon EBS se estiverem localizados na mesma região que a VPC. Mais detalhes estão disponíveis nas perguntas frequentes sobre regiões e zonas de disponibilidade do Amazon EC2.

Sim, no entanto, uma instância iniciada em uma VPC usando uma Amazon EBS-backed AMI mantém o mesmo endereço IP quando interrompida e reiniciada. Isso ocorre em contrapartida a instâncias semelhantes iniciadas fora de uma VPC, que obtêm um novo endereço IP. Os endereços IP para quaisquer instâncias interrompidas em uma sub-rede são considerados indisponíveis.

Sim.

Sim. 

Sim. As instâncias de cluster são compatíveis com a Amazon VPC. No entanto, nem todos os tipos de instâncias estão disponíveis em todas as regiões e zonas de disponibilidade.

Quando uma instância é iniciada, um nome de host é atribuído a ela. Existem duas opções disponíveis: um nome baseado em IP ou um nome baseado em recurso. Esse parâmetro é configurável na inicialização da instância. O nome baseado em IP usa uma forma de endereço IPv4 privado e o nome baseado em recurso usa uma forma do instance-id.

Sim, você pode alterar o nome de host de uma instância baseada em IP para baseada em recurso ou vice-versa interrompendo a instância e alterando as opções de nomeação baseada em recurso.

Sim, os nomes de host das instâncias podem ser usados como nomes de host de DNS. Para instâncias iniciadas em uma sub-rede somente IPv4 ou de pilha dupla, o nome baseado em IP sempre define o endereço IPv4 privado na interface de rede primária da instância. Isso não pode ser desativado. Além disso, o nome baseado em recurso pode ser configurado para definir o endereço IPv4 privado na interface de rede primária ou o primeiro GUA IPv6 na interface de rede primária ou ambos. Para instâncias iniciadas em uma sub-rede somente IPv6, o nome baseado em recurso será configurado para resolver o primeiro GUA IPv6 na interface de rede primária. 

Uma VPC padrão é uma rede virtual logicamente isolada na nuvem da AWS criada automaticamente para a sua conta da AWS na primeira vez que você provisiona recursos da Amazon EC2. Quando você executa uma instância sem especificar um ID de sub-rede, a sua instância será executada na sua VPC padrão.

Quando você executa recursos em uma VPC padrão, pode veneficiar-se com as funcionalidades avançadas de rede da Amazon VPC (EC2-VPC) com a facilidade do uso do Amazon EC2 (EC2-Classic). Você pode aproveitar recursos como alterar associações a grupos de segurança em tempo real, filtragem de saída de grupos de segurança, vários endereços IP e várias interfaces de rede sem necessidade de criar explicitamente uma VPC e lançar instâncias nessa VPC.

Se a sua conta da AWS foi criada após 18 de março de 2013, pode ser capaz de executar recursos em uma VPC padrão. Consulte este anúncio de fórum para determinar em que regiões o conjunto de atributos da VPC padrão foi disponibilizado. Além disso, as contas criadas antes das datas listadas podem utilizar VPCs padrão em qualquer região padrão habilitada para VPCs na qual você ainda não executou instâncias do EC2 ou provisionou recursos de Amazon Elastic Load Balancing, Amazon RDS, Amazon ElastiCache ou Amazon Redshift.

Não. Você pode usar o Console de Gerenciamento da AWS, a ILC do AWS EC2 ou a API do Amazon EC2 para executar e gerenciar instâncias do EC2 e de outros recursos da AWS em uma VPC padrão. A AWS criará automaticamente uma VPC padrão e uma sub-rede padrão em cada zona de disponibilidade na região da AWS. Sua VPC padrão será conectada a um gateway da Internet e suas instâncias receberão automaticamente endereços IP públicos, da mesma forma que no EC2-Classic.

Consulte Differences between EC2-Classic and EC2-VPC no Guia de usuários do EC2.

Não. As VPCs padrão são associadas à Internet e todas as instâncias executadas em sub-redes padrão na VPC padrão recebem automaticamente endereços IP públicos. Você pode adicionar uma conexão VPN à sua VPC padrão, se desejar.

Sim. Para lançar uma instância em uma VPC não padrão, você deve especificar um ID de sub-rede durante a execução da instância.

Sim. Para executar em sub-redes fora do padrão, você pode direcionar suas execuções usando o console ou a opção --subnet de CLI/API/SDK.

Você pode ter uma VPC padrão em cada região da AWS onde o atributo "Supported Platforms" estiver definido como "EC2-VPC".

Uma sub-rede padrão é criada para cada zona de disponibilidade na VPC padrão.

Não neste momento.

Não neste momento.

Sim, é possível excluir uma VPC padrão. Depois de excluída, será possível criar uma nova VPC padrão diretamente no Console da VPC ou usando a ILC. Isso criará uma nova VPC padrão na região. Isso não restaura a VPC anterior que foi excluída.

Sim. É possível excluir uma sub-rede padrão. Depois de excluída, você poderá criar uma nova sub-rede padrão na zona de disponibilidade usando a ILC ou o SDK. Isso criará uma nova sub-rede padrão na zona de disponibilidade especificada. Isso não restaura a sub-rede anterior que foi excluída.

A maneira mais simples de obter uma VPC padrão é criar uma nova conta em uma região habilitada para VPCs padrão ou usar uma conta atual em uma região na qual você nunca esteve antes, contanto que o atributo Supported Platforms dessa conta, nessa região, esteja definido como "EC2-VPC".

Sim. No entanto, a habilitação de uma conta existente para uma VPC padrão somente será possível se você não tiver nenhum recurso do EC2-Classic para essa conta nessa região. Além disso, você deve encerrar todos os recursos de Elastic Load Balancer, Amazon RDS, Amazon ElastiCache e Amazon Redshift não provisionados pela VPC naquela região. Após a configuração da sua conta para uma VPC padrão, todas as execuções futuras de recursos, inclusive as instâncias executadas via Auto Scaling, serão efetuadas na VPC padrão. Para solicitar que sua conta atual seja configurada com uma VPC padrão, acesse Account and Billing -> Service: Account -> Category: Convert EC2 Classic to VPC e crie uma solicitação. Analisaremos a solicitação, os seus serviços da AWS atuais e a sua presença de EC2-Classic e orientaremos você nas etapas seguintes.

Se a sua conta da AWS tem uma VPC padrão, todas as contas IAM associadas à sua conta da AWS usam a mesma VPC padrão que a sua conta da AWS.

EC2-Classic é uma rede plana que lançamos com EC2 no verão de 2006. Com o EC2-Classic, suas instâncias são executadas em uma única rede plana que você compartilha com outros clientes. Com o tempo, inspirados pela evolução das necessidades de nossos clientes, lançamos a Amazon Virtual Private Cloud (VPC) em 2009 para permitir que você execute instâncias em uma nuvem privada virtual que está logicamente isolada da sua conta AWS. Hoje, embora a maior parte de nossos clientes use o Amazon VPC, alguns clientes ainda usam o EC2-Classic.

Recolheremos o Amazon EC2-Classic em 15 de agosto de 2022 e precisamos que você migre todas as instâncias do EC2 e outros recursos da AWS em execução no EC2-Classic para o Amazon VPC antes dessa data. A seção a seguir fornece mais informações sobre o recolhimento do EC2-Class, bem como ferramentas e recursos para ajudá-lo na migração.

Você será afetado por essa mudança apenas se tiver o EC2-Classic habilitado em sua conta em qualquer uma das regiões da AWS. Você pode usar o console ou o comando describe-account-attribute para verificar se você tem o EC2-Classic habilitado em uma região da AWS; consulte este documento para mais detalhes.

Se você não tiver nenhum recurso ativo da AWS em execução no EC2-Classic em qualquer região, solicitamos que você desative o EC2-Classic de sua conta para essa região. Desativar o EC2-Classic em uma região permite iniciar o VPC padrão lá. Para fazer isso, acesse o AWS Support Center em console.aws.amazon.com/support, escolha “Criar processo” e, em seguida, “Suporte de conta e cobrança”, para “Tipo” escolha “Conta”, para “Categoria” escolha “Converter EC2 Classic para VPC”, preencha os outros detalhes conforme necessário e clique em “Enviar”.

Desativaremos automaticamente o EC2-Classic de sua conta em 30 de outubro de 2021 para qualquer região da AWS onde você não tenha nenhum recurso da AWS (instâncias EC2, Amazon Relational Database, AWS Elastic Beanstalk, Amazon Redshift, AWS Data Pipeline, Amazon EMR, AWS OpsWorks) no EC2-Classic desde 1º de janeiro de 2021.

Por outro lado, se você tiver recursos da AWS em execução no EC2-Classic, solicitamos que planeje sua migração para o Amazon VPC o mais rápido possível. Você não poderá iniciar nenhuma instância ou serviço da AWS na plataforma EC2-Classic após 15 de agosto de 2022. Quaisquer workloads ou serviços em estado de execução perderão gradualmente o acesso a todos os serviços da AWS no EC2-Classic, já que os recolheremos a partir de 16 de agosto de 2022.

Você pode encontrar os guias de migração para seus recursos da AWS na pergunta seguinte.

O Amazon VPC oferece controle total sobre seu ambiente de rede virtual na AWS, logicamente isolado para sua conta AWS. No ambiente EC2-Classic, suas workloads estão compartilhando uma única rede plana com outros clientes. O ambiente Amazon VPC oferece muitas outras vantagens em relação ao ambiente EC2-Classic, incluindo a capacidade de selecionar seu próprio espaço de endereço IP, configuração de sub-rede pública e privada e gerenciamento de tabelas de rotas e gateways de rede. Todos os serviços e instâncias atualmente disponíveis no EC2-Classic têm serviços comparáveis disponíveis no ambiente Amazon VPC. O Amazon VPC também oferece uma geração de instâncias muito mais ampla e mais recente do que o EC2-Classic. Mais informações sobre o Amazon VPC estão disponíveis neste link.

Para ajudá-lo a migrar seus recursos, publicamos manuais e criamos soluções que você encontrará a seguir. Para migrar, você deve recriar seus recursos EC2-Classic em seu VPC. Primeiro, você pode usar este script para identificar todos os recursos disponibilizados no EC2-Classic em todas as regiões de uma conta. Você pode então usar o guia de migração para os recursos relevantes da AWS abaixo:

• Instâncias e grupos de segurança
• Balanceador de carga clássico
• Amazon Relational Database Service
• AWS Elastic Beanstalk
• Amazon Redshift para migração de clusters DC1 e para outros tipos de nós
• AWS Data Pipeline 
• Amazon EMR 
• AWS OpsWorks

Além dos guias de migração acima, também oferecemos uma solução lift-and-shift (rehost) altamente automatizada, o AWS Application Migration Service (AWS MGN), que simplifica, agiliza e reduz o custo de migração de aplicativos. Você pode encontrar recursos relevantes sobre AWS MGN aqui:

• Introdução ao AWS Application Migration Service. 
• Treinamento técnico sob demanda do AWS Application Migration Service
• Documentação para se aprofundar nos recursos e funcionalidades do AWS Application Migration Service
• Vídeo sobre arquitetura de serviço e arquitetura de rede

Para migrações simples de instâncias EC2 individuais de EC2-Classic para VPC, além do AWS MGN ou do Guia de migração de instâncias, você também pode usar o runbook “AWSSupport-MigrateEC2 ClassicToVPC“ de ”AWS Systems Manager > Automação“. Esses runbooks automatizam as etapas necessárias para migrar uma instância de EC2-Classic para VPC criando uma AMI da instância em EC2-Classic, criando uma nova instância da AMI em VPC e, facultativamente, encerrando a instância EC2-Classic.

Se você tiver alguma dúvida ou preocupação, pode entrar em contato com a equipe de AWS Support por meio do AWS Premium Support.

Observação: se você tiver recursos da AWS em execução no EC2-Classic em várias regiões da AWS, recomendamos que você desative o EC2-Classic para cada uma dessas regiões assim que tiver migrado todos os seus recursos para o VPC nelas.

Tomaremos as duas ações seguintes antes da data de recolhimento de 15 de agosto de 2022:

• Pararemos de emitir instâncias reservadas de 3 anos (IR) e IR de 1 ano para o ambiente EC2-Classic em 30 de outubro de 2021. As IRs já em vigor no ambiente EC2-Classic não serão afetados neste momento. As IRs marcadas para vencer após 15/08/2022 precisarão ser modificadas para usar o ambiente Amazon VPC no período restante do lease. Para obter informações sobre como modificar suas IRs, visite nosso documento.
• Em 15 de agosto de 2022, não permitiremos mais a criação de novas instâncias (Spot ou sob demanda) ou outros serviços da AWS no ambiente EC2-Classic. Quaisquer workloads ou serviços em estado de execução perderão gradualmente o acesso a todos os serviços da AWS no EC2-Classic, já que os recolheremos a partir de 16 de agosto de 2022.

Sim.

As interfaces de rede só podem ser associadas a instâncias residentes na mesma zona de disponibilidade.

As interfaces de rede só podem ser acopladas a instâncias em VPCs na mesma conta.

Sim, no entanto, este não é o caso de uso mais adequado para múltiplas interfaces. Em vez disso, designe endereços IP privados adicionais à instância e então associe EIPs aos IPs privados, conforme necessário.

Não. Você pode associar e separar a interface secundária (eth1-ethn) em uma instância do EC2, mas não pode separar a interface eth0.

Sim. As conexões de emparelhamento podem ser criadas com VPCs em diferentes regiões. O emparelhamento de VPC entre regiões está disponível globalmente em todas as regiões comerciais (exceto China).

Sim, assumindo que o dono da outra VPC aceite a sua solicitação de conexão de emparelhamento.

Não é feita cobrança pela criação de conexões emparelhadas de VPCs, porém a transferência de dados entre conexões emparelhadas é cobrada. Consulte as taxas de transferência de dados na seção transferência de dados da página de definição de preço do EC2.

Não. As conexões de emparelhamento de VPCs não requerem um Internet Gateway.

Não. O tráfego entre instâncias em VPCs emparelhadas permanece privado e isolado, similar à forma como o tráfego entre duas instâncias na mesma VPC é privado e isolado.

Não. Ambos os lados de uma conexão emparelhada podem encerrá-la a qualquer momento. O encerramento de uma conexão emparelhada significa que o tráfego não será transmitido entre as duas VPCs.

Não. Relacionamentos transitivos de emparelhamento não são suportados.

A AWS utiliza a infraestrutura existente da VPC para criar uma conexão emparelhada entre VPCs; ela não é um gateway e nem uma conexão VPN e não depende de hardware físico externo. Não há um ponto único de falha de comunicação ou um gargalo de largura de banda.

O emparelhamento de VPCs entre regiões opera na mesma tecnologia altamente disponível, redundante e escalada horizontalmente que faz funcionar a VPC de hoje em dia. O tráfego do emparelhamento de VPCs entre regiões vai além do backbone da AWS, que tem redundância embutida e alocação de largura de banda dinâmica. Não há um único ponto de falha nas comunicações.

Se uma conexão de Inter-Region peering for interrompida, o tráfego não será direcionado pela internet.

A largura de banda entre instâncias em VPCs emparelhadas é igual à largura de banda entre instâncias na mesma VPC. Observação: um grupo de localização pode abranger VPCs emparelhadas. No entanto, não será disponibilizada a largura de banda bissecionada total entre as instâncias nas VPCs emparelhadas. Saiba mais sobre os grupos de localização.

O tráfego é criptografado usando algoritmos AEAD (Authenticated Encryption with Associated Data) modernos. A AWS cuida do contrato e do gerenciamento.

Por padrão, uma consulta de um nome de host público de uma instância em uma VPC com peering em uma região diferente será resolvida em um endereço IP público. O DNS privado de Route 53 pode ser usado para resolução em um endereço IP privado com o Inter-Region VPC Peering.

Não. Os grupos de segurança não podem ser consultados nas conexões do emparelhamento de VPCs entre regiões.

Sim. Emparelhamento de VPC entre regiões oferece suporte ao IPv6

Não. O emparelhamento de VPCs entre regiões não pode ser usado com o EC2-ClassicLink.

O Amazon Virtual Private Cloud (VPC) ClassicLink permite que instâncias do EC2 na plataforma do EC2-Classic se comuniquem com instâncias em uma VPC usando endereços IP privados. Para usar o ClassicLink, habilite-o para uma VPC em sua conta e associe um Grupo de Segurança daquela VPC com uma instância no EC2-Classic. Todas as regras do seu Grupo de Segurança da VPC se aplicarão às comunicações entre instâncias do EC2-Classic e as instâncias na VPC. 

Não há custo adicional para usar o ClassicLink. No entanto, haverá cobranças de transferência de dados entre Zonas de Disponibilidade existentes. Para obter mais informações, consulte a página de definição de preço do EC2.

Para usar o ClassicLink, você primeiro precisa habilitar pelo menos uma VPC em sua conta para o ClassicLink. Depois você associa um Grupo de Segurança da VPC à instância desejada do EC2-Classic. A instância do EC2-Classic agora é vinculada à VPC e é membro do Grupo de Segurança selecionado na VPC. Sua instância EC2-Classic não pode ser vinculada a mais de uma VPC ao mesmo tempo.

A instância do EC2-Classic não se torna membro da VPC. Ela se torna membro do Grupo de Segurança da VPC associada com a instância. Todas as regras e referências ao Grupo de Segurança da VPC se aplicam à comunicação entre as instâncias na instância do EC2-Classic e recursos na VPC.

Não. O nome de host DNS público do EC2 não resolverá para o endereço IP privado da instância EC2-VPC quando consultado a partir de uma instância do EC2-Classic e vice-versa.

Sim. O ClassicLink não pode ser habilitado para uma VPC com CIDR (Classless Inter-Domain Routing) dentro do intervalo 10.0.0.0/8, com exceção de 10.0.0.0/16 e 10.1.0.0/16. Além disso, o ClassicLink não pode ser habilitado para nenhuma VPC com entrada na tabela de rotas apontando para o espaço 10.0.0.0/8 CIDR para um destino que não seja “local”.

O tráfego de uma instância do EC2-Classic só pode ser direcionado para endereços IP privados dentro da VPC. Ele não será direcionado para nenhum destino fora da VPC, inclusive destinos de gateway da Internet, virtual private gateway ou VPC emparelhadas.

O ClassicLink não muda o controle de acesso definido para uma instância do EC2-Classic através dos seus Grupos de Segurança existentes na plataforma do EC2-Classic.

A conexão do ClassicLink não persistirá através dos ciclos de parar/iniciar da instância do EC2-Classic. A instância do EC2-Classic precisará ser vinculada novamente a uma VPC depois de ser parada e iniciada. No entanto, a conexão do ClassicLink persistirá através dos ciclos de reinicialização da instância.

O ClassicLink não permite que as regras do Grupo de Segurança do EC2-Classic façam referência aos Grupos de Segurança da VPC ou vice-versa.

O AWS PrivateLink permite que clientes acessem os serviços hospedados na AWS de forma altamente disponível e escalável enquanto mantém todo o tráfego de rede dentro da rede da AWS. Os usuários de serviços podem usar essa tecnologia para acessar com privacidade serviços baseados no PrivateLink de sua Amazon Virtual Private Cloud (VPC) ou de seu próprio datacenter, sem IPs públicos e sem precisar que o tráfego atravesse a Internet. Os proprietários de serviços podem registrar seus Network Load Balancers em serviços do PrivateLink e oferecer os serviços a outros clientes da AWS.

Como usuário de serviços, você precisará criar VPC endpoints do tipo interface para serviços baseados no PrivateLink. Esses endpoints de serviço serão exibidos como interfaces de rede elástica (ENIs) com IPs privados nas VPCs. Após a criação desses endpoints, todo o tráfego destinado a esses IPs será roteado de modo privado para os Serviços da AWS correspondentes.

Como proprietário de serviços, você pode integrar seu serviço ao AWS PrivateLink estabelecendo um Network Load Balancer (NLB) na frente do seu serviço e criando um serviço do PrivateLink para registro no NLB. Os clientes poderão estabelecer endpoints em suas VPCs para conectar-se ao seu serviço depois que você autorizar suas contas e funções do IAM.

Os seguintes serviços da AWS são compatíveis com esse recurso: Amazon Elastic Compute Cloud (EC2), Elastic Load Balancing (ELB), Kinesis Streams, Service Catalog, EC2 Systems Manager, Amazon SNS e AWS DataSync. Muitas soluções de SaaS também são compatíveis com esse recurso. Acesse AWS Marketplace para ver mais produtos de SaaS baseados no AWS PrivateLink.

Sim. O aplicativo no local pode conectar-se aos endpoints de serviços na Amazon VPC usando o AWS Direct Connect. Os endpoints de serviço direcionarão automaticamente o tráfego aos Serviços da AWS baseados no AWS PrivateLink.

Sim. Você pode usar o Console de Gerenciamento da AWS para gerenciar objetos da Amazon VPC, como VPCs, sub-redes, tabelas de roteamento, gateways da Internet e conexões VPN IPSec. Além disso, é possível usar um assistente simples para criar uma VPC.

Consulte o Guia do Usuário da Amazon VPC para obter mais informações sobre os limites da VPC.

Sim. Clique aqui para obter mais informações sobre o AWS Support.

O ElasticFox não é mais oficialmente compatível para a gestão da Amazon VPC. O suporte da Amazon VPC está disponível por meio de APIs da AWS, ferramentas da linha de comando, Console de Gerenciamento da AWS e diversos utilitários de terceiros.