Entre as várias e rápidas mudanças tecnológicas que surgem conforme a internet ganha novas camadas de complexidade, temos os Protocolos de Internet (IPs). A AWS permite a criação de vários recursos com IPv6, para os quais a viabilidade de funcionamento foi testada em um ambiente AWS IPv6-Only. Este artigo visa auxiliar clientes da AWS em sua tomada de decisão na hora de implementar IPv6 em seus ambientes.
O que são IPs?
Os endereços IPs são endereços lógicos atribuídos a dispositivos conectados a uma rede e são utilizados na comunicação interna e externa entre os ativos de rede. Atualmente, a quantidade disponível de endereços IPs do tipo IPv4 são escassos quando comparados com a demanda atual.
Um bom exemplo está nas várias diferenças entre o IPv4 e sua inovação, o IPv6, que tem causado euforia pela transição entre os dois protocolos dentro das empresas. De modo bastante resumido, o IPv4 é a versão mais antiga e amplamente utilizada do protocolo de internet, que utiliza endereços de 32 bits, proporcionando até 4,3 bilhões de endereços possíveis. No entanto, muitos desses endereços são reservados para redes privadas. Já o IPv6 conta com endereços de 128 bits, oferecendo também um número significativamente maior de endereços. O IPv6 possui um cabeçalho mais eficiente e elimina a necessidade de Tradução de Endereço de Rede (NAT), facilitando a implementação de serviços como VoIP e QoS.
Com a limitação de endereços do IPv4 e o aumento dos dispositivos conectados globalmente, os IPs deste tipo passaram a ser cobrados dentro da nuvem AWS. Afinal, o custo de aquisição dos endereços IPv4 é mais elevado e a cobrança acaba estimulando a adoção da versão mais recente no ambiente dos clientes. Mas será que atualmente a transição de IPv4 para IPv6 dentro da AWS pode acontecer de modo simples e rápido, como se fosse um “clicar de botões”? Na prática, o IPv6 atende mesmo a todas as necessidades dos clientes? Será que todos os recursos da AWS suportam IPv6? Como se certificar que é possível usar o IPv6 no seu ambiente atual?
Pensando nisso, a criamos ambientes de testes para verificar e validar o funcionamento de diversos recursos AWS em um cenário de utilização IPv6 Only. Confira parte desses resultados no estudo de caso a seguir.
Estudo de Caso
É importante contextualizar que os testes e conclusões abaixo observados foram realizados em Abril/24. Sabemos que a AWS lança novidades frequentemente e, por isso, entende-se que as conclusões obtidas foram a partir das funcionalidades que estavam disponíveis nesse período.
Ambientes de análise
Visando entender como se dá o funcionamento dos principais recursos AWS ao utilizar o IPv6, foi efetuado uma análise em 3 tipos diferentes de ambientes. É relevante destacar o fato de que o cenário de implementação deste artigo buscou priorizar ao máximo o uso do IPv6 somente com a utilização do Internet Gateway Egress Only, com o NAT Gateway sendo usado somente no último caso, sendo assim, ao ler os resultados e testes é importante ter em mente que em cenários distintos aos abaixo expostos, os resultados podem variar, conforme a especificidade de cada arquitetura criada na nuvem. Os 3 tipos de ambientes criados foram:
Ambiente AWS IPv6 only
Neste ambiente objetivou-se criar uma infraestrutura de forma que:
- Todos os recursos possuam somente IPv6 atribuídos;
- Todos os recursos se comuniquem entre si e com a rede externa somente via IPv6;
- Utiliza-se somente o Internet Gateway Egress Only como forma de se comunicar com a Internet.
Ambiente IPv6 Dual Stack (IPv6-DualStack)
Neste ambiente objetivou-se criar uma infraestrutura de forma que:
- Todos os recursos possuam IPv6 e IPv4 atribuídos a eles;
- Todos os recursos se comuniquem entre si utilizando Ipv6 e IPv4, preferencialmente via IPv6;
- Todos os recursos se comuniquem com a rede externa utilizando somente IPv6;
- Utiliza-se somente o Internet Gateway Egress Only como forma de se comunicar com a Internet.
Ambiente IPv6 Dual Stack com Nat Gateway (IPv6-Nat)
Neste ambiente objetivou-se criar uma infraestrutura de forma que:
- Todos os recursos possuam IPv6 e IPv4 atribuídos a eles;
- Todos os recursos se comuniquem entre si utilizando Ipv6 e IPv4, preferencialmente via IPv6;
- Todos os recursos se comuniquem com a rede externa utilizando IPv4 ou IPv6, preferencialmente via IPv6;
- Utiliza-se o Internet Gateway Egress Only e o NAT Gateway como forma de se comunicar com a Internet.
A partir dos ambientes acima propostos é possível perceber que o objetivo das análises é realmente verificar o funcionamento dos recursos em três ambientes diferentes, sendo que independente de qual ambiente seja, serão feitas configurações de forma a tentar ao máximo que as comunicações ocorram via IPv6.
Resultado dos Teste Realizados
De antemão, a tabela abaixo mostra quais foram os resultados obtidos. A próxima seção trará mais detalhes com relação a quais testes foram realizados.
Nome | IPv6-Only | IPv6-DualStack | IPv6-Nat |
AWS SSM | ❌ | ❌ | ✅ |
Lambda | ❌ | ✅ | ✅ |
ECS | ⚠️ | ❌ | ✅ |
Acesso ao DynamoDB | ❌ | ❌ | ✅ |
Acesso ao S3 | ❌ | ⚠️ | ✅ |
Acesso EC2 à IPv4-Only | ❌ | ❌ | ✅ |
Acesso EC2 à IPv6-Only | ✅ | ✅ | ✅ |
Acesso EC2 à DualStack | ❌ | ✅ | ✅ |
Onde:
✅ → Indica que o teste foi bem sucedido.
❌ → Indica que o teste foi mal sucedido.
⚠️→ Indica que o comportamento observado não foi totalmente satisfatório.
Para saber mais detalhes do teste realizado, clique abaixo! ↓
Detalhamento dos testes realizados por ambiente
AWS SSM
Teste realizado:Foi criado uma instância com SSM Agent e verificou se o acesso via console seria feito com sucesso.Comportamento observado: AWS SSM não possui suporte para acesso via IPv6, portanto não foi possível acessar a instância na rede IPv6-DualStack.Lambda
Teste realizado:Neste teste foi verificado se uma aplicação em Python conseguiria acessar o S3, a partir da execução da seguinte função:ECS
Teste realizado:O teste realizado consiste na criação de um service privado exposto por um Application Load Balancer.Comportamento observado:AWS ECR não possui suporte para acesso via IPv6, portanto não foi possível fazer o pull da imagem docker na rede IPv6-DualStack.Acesso ao DynamoDB
Teste realizado:Um DynamoDB foi criado na mesma região da rede e os seguintes comandos foram executados através do AWS CLI:aws dynamodb list-tablesComportamento observado:O AWS DynamoDB não possui suporte para acesso via IPv6, portanto não foi possível acessar as tabelas na rede IPv6-DualStack.Acesso ao S3 Teste realizado:
Um bucket foi criado na mesma região da rede e, em seguida, foram executados os seguintes comandos através do AWS CLI:Acesso EC2 a ipv4-ipv6-dualstack
Teste realizado:Para os testes “Acesso EC2 à Ipv4-only”, “Acesso EC2 à Ipv6-only” e “Acesso EC2 à dualstack”, foram executados os seguintes comandos:Acesso EC2 à endpoint IPv6, IPv4 e dualstack
Teste realizado:
Os testes foram realizados executando os seguintes comandos à partir de uma EC2:
# Acesso a website ipv6-only
curl v6.ipv6test.app
traceroute v6.ipv6test.app
# Acesso a website ipv4-only
curl v4.ipv6test.app
traceroute v4.ipv6test.app
# Acesso a website dualstack
curl ipv6test.app
traceroute ipv6test.app
Comportamento observado:
A EC2 com IPv6, que está localizada em uma subnet IPv6 only consegue alcançar o endpoint IPv6, mas não consegue acessar os endpoints do tipo IPv4 e do tipo dualstack.
Assim como especificado na tabela, o acesso do EC2 a websites IPv4 e Dualstack não foi bem sucedido. O erro exposto foi o “connect: Network is unreachable”.
Acesso ao S3
Teste realizado:
Foi criado um bucket na mesma região e através do AWS CLI executados os seguintes comandos:
# S3
aws s3api get-object –bucket omnichat-devel-ipv6-only –key file.txt file.txt
aws s3api get-object –bucket omnichat-devel-ipv6-only –key file.txt file.txt
Comportamento observado:
O comando dá timeout. Nenhuma resposta é obtida.
Considerando a arquitetura com a presença do Internet Gateway Egress Only e também do VPC Endpoint do tipo Gateway para acessar o S3, a comunicação partindo do EC2 para o S3 não foi estabelecida.
Na tentativa de encontrar uma alternativa ao utilizar o outro tipo de endpoint, foi constatado também que o VPC Endpoint do tipo Interface não possui suporte para IPv6 only.
Acesso ao DynamoDB
Teste realizado:
Foi criado um DynamoDB na mesma região e, através do AWS CLI, foram executados os seguintes comandos:
Comportamento observado:
O comando não foi executado com sucesso. Ele traz o erro afirmando que o endpoint do DynamoDB não pôde ser encontrado. Isso porque o DynamoDB não possui suporte para acesso via IPv6, como visto na seção anterior.
Lambda
Teste realizado:
O Lambda não pode ser criado em subnets do tipo IPv6 only. É possível apenas criar Lambdas em VPCs que contenham subnets do tipo dual-stack.
Sendo assim, a conexão entre o Lambda e o S3 pode ocorrer via IPv6, mas somente no cenário apresentado no ambiente de dual-stack, como apresentado na seção anterior.
Criação de Tasks no ECS
Foi possível criar o ECS e a Task, porém não foi possível realizar a criação do ALB, que é responsável por redirecionar o tráfego. Isso porque é solicitado que haja pelo menos 8 IPs do tipo IPv4 disponíveis em cada subnet. A mensagem de erro apresentada foi a seguinte: “Not enough IP space available in subnet-0e2778c701e57a969. ELB requires at least 8 free IP addresses in each subnet.”
Conclusão
Apesar de a princípio parecer se tratar de algo trivial, a troca de IPv4 para IPv6 em um ambiente AWS já consolidado, acarreta uma série de ajustes a nível de recurso, onde é preciso verificar individualmente quais as implicações e ajustes a serem feitos ao se utilizar IPv6.
É certo que, apesar de muitos recursos não oferecerem suporte para a comunicação IPv6, a otimização de custos desejada ainda pode ser obtida a partir da utilização do PrivateLink, que pode ser implementado como uma alternativa ao NAT Gateway, visto que enquanto o AWS Private Link cobra $0.01 por GB, o NAT Gateway cobra $0.045 por GB.
A e-Core é um parceiro AWS preparado para ajudar o seu negócio com soluções de migração e modernização do ambiente cloud, assim como na criação de soluções personalizadas com nossa expertise em computação em nuvem, big data, IA e Machine Learning. Entre em contato conosco e veja como podemos apoiar o seu negócio!
