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)

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.

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. 

É 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.

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.

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.

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.

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.

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

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.

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.

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).

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.

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.

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 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 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.

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.