Escolhendo sua estratégia de endpoint de VPC para o Amazon S3

Por Jeff Harman e Gilles-Kuessan Satchivi, Arquitetos Senior de Soluções

Este post foi escrito em parceria com Anusha Dharmalingam, ex-arquiteta de soluções da AWS.

Sua aplicação na Amazon Web Services (AWS) precisa se conectar aos endpoints públicos dos buckets do Amazon Simple Storage Service (S3) sem passar pela Internet? E essa conexão precisa escalar automaticamente para atender às demandas de largura de banda? A AWS oferece um mecanismo chamado endpoints de VPC (VPC Endpoints) para atender a esses requisitos. Este artigo fornece orientação para selecionar o tipo apropriado de endpoint de VPC para acessar o Amazon S3. Um endpoint de VPC permite que cargas de trabalho que estão em uma Amazon VPC (Virtual Private Cloud) se conectem a serviços públicos compatíveis da AWS ou a serviços de terceiros por meio da rede da AWS. Essa abordagem é usada para cargas de trabalho que não devem se comunicar em redes públicas.

Quando uma arquitetura de solução usa endpoints de VPC, as aplicações se beneficiam da escalabilidade, resiliência, segurança e controles de acesso nativos dos serviços da AWS. O Amazon S3 pode ser acessado usando um endpoint de VPC do tipo interface com o AWS PrivateLink ou um endpoint de VPC do tipo gateway. Para determinar o tipo de endpoint certo para suas cargas de trabalho, discutiremos os critérios de seleção a serem considerados com base em seus requisitos.

Visão geral do endpoint de VPC

Um endpoint de VPC é um componente de rede virtual escalável criado em uma VPC e usado como um ponto de entrada privado para serviços compatíveis da AWS e serviços de terceiros. Atualmente, dois tipos de endpoints de VPC podem ser usados para se conectar ao Amazon S3: endpoint de VPC do tipo interface e do tipo gateway.

Quando você configura um endpoint de VPC do tipo interface, uma interface de rede elástica (Elastic Network Interface – ENI) com um endereço IP privado é implementada na sub-rede da VPC. Uma instância do Amazon EC2 na VPC pode se comunicar com um bucket do Amazon S3 por meio da ENI e da rede AWS. Usando o endpoint do tipo interface, os aplicativos em seu data center local podem facilmente consultar buckets do S3 por meio do AWS Direct Connect ou de VPN site-to-site. O endpoint do tipo interface oferece suporte a uma lista crescente de serviços da AWS. Consulte nossa documentação para encontrar serviços da AWS compatíveis com endpoints do tipo interface aproveitados com a tecnologia AWS PrivateLink.

Os endpoints de VPC do tipo gateway usam listas de prefixos como a rota IP de destino em uma tabela de rotas da VPC.  Isso direciona o tráfego de forma privada para o Amazon S3 ou o Amazon DynamoDB. Uma instância do Amazon EC2 em uma VPC sem acesso à Internet ainda pode ler e/ou gravar diretamente em um bucket do Amazon S3. O Amazon DynamoDB e o Amazon S3 são os serviços atualmente acessíveis por meio de endpoints do tipo gateway.

As políticas de segurança internas da sua organização podem ter regras rígidas contra a comunicação entre sua VPC e a Internet. Para manter a conformidade com essas políticas, você pode usar o endpoint de VPC para se conectar a serviços públicos da AWS, como o Amazon S3. Para controlar o acesso de usuários ou aplicações ao endpoint de VPC e aos recursos que ele suporta, você pode usar uma política de recursos do AWS Identity and Access Management (AWS IAM). Isso protegerá separadamente o endpoint de VPC e os recursos que podem ser acessados através dele.

Seleção de endpoints de VPC do tipo gateway ou do tipo interface

Com os dois tipos de endpoints disponíveis para o Amazon S3, há alguns fatores a serem considerados ao escolher uma estratégia em vez da outra.

• Custo: Os endpoints de VPC do tipo gateway para o Amazon S3 são oferecidos sem nenhum custo e as rotas são gerenciadas por meio das tabelas de rotas. Os endpoints de VPC do tipo interface custam 0,01/USD por zona de disponibilidade (AZ) por hora. O custo depende da região, verifique os preços atuais. Os dados transferidos por meio do endpoint de VPC do tipo interface são cobrados em 0,01/USD por GB (dependendo da região).
• Padrão de acesso: O acesso ao Amazon S3 por meio de endpoints de VPC do tipo gateway só é suportado para recursos na VPC específica à qual esse endpoint está associado. Atualmente, os endpoints de VPC do tipo gateway para o Amazon S3 não oferecem suporte ao acesso a recursos em uma região diferente, em uma VPC diferente ou de um data center local (ambiente fora da AWS). No entanto, se você estiver disposto a gerenciar uma arquitetura personalizada complexa, poderá usar proxies. Em todos esses cenários, em que o acesso é de recursos externos à VPC, os endpoints de VPC do tipo interface do Amazon S3 permitem o acesso de forma segura.
• Arquitetura de endpoint de VPC: Alguns clientes usam padrões centralizados de arquitetura de endpoint de VPC. Neste cenário todos os endpoints de VPC do tipo interface são gerenciados em uma VPC central (hub), que é usada para acessar o serviço a partir de várias VPCs radiais (spokes). Essa arquitetura ajuda a reduzir a complexidade e a manutenção de vários endpoints de VPC do tipo interface em diferentes VPCs. Ao usar um endpoint do tipo interface para o Amazon S3, você deve considerar a quantidade de tráfego de rede que fluiria pela rede das VPCs radiais para a VPC central. Se a conectividade de rede entre as VPCs radiais e a VPC central estiver configurada através de um AWS Transit Gateway ou um peering de VPC, considere as cobranças de processamento de dados (atualmente 0,02/GB). Se o peering de VPC for usado, não haverá cobrança pelos dados transferidos entre sub-redes que estão na mesma zona de disponibilidade. No entanto, os dados transferidos entre zonas de disponibilidade ou entre regiões incorrerão em cobranças conforme definido em nossa documentação.
  Em cenários em que você precisa acessar os buckets do Amazon S3 com segurança a partir do data center local ou de outras regiões, é recomendável usar um endpoint do tipo interface. Se você escolher um endpoint do tipo gateway, instale uma frota de proxies na VPC para realizar o roteamento transitivo.

Figura 1. Arquitetura de endpoint de VPC

 

• Considerações sobre largura de banda: Ao configurar um endpoint do tipo interface, escolha várias sub-redes em várias zonas de disponibilidade para implementar a alta disponibilidade. O número de ENIs deve ser igual ao número de sub-redes escolhidas. Os endpoints do tipo interface oferecem desempenho de 10 Gbps por ENI com uma capacidade de intermitência (burst) de 40 Gbps. Se seu caso de uso exigir maior desempenho, entre em contato com a equipe de suporte da AWS.

Os endpoints do tipo gateway são entradas na tabela de rotas que roteiam seu tráfego diretamente da sub-rede em que o tráfego se origina para o serviço Amazon S3. O tráfego não flui por meio de um dispositivo ou instância intermediária. Portanto, não há limite de desempenho para o endpoint do tipo gateway. A configuração inicial para endpoints do tipo gateway consiste em especificar as tabelas de rotas da VPC que você deseja usar para acessar o serviço. As entradas da tabela de rotas para o destino (lista de prefixos) e o destino (ID do endpoint) são adicionadas automaticamente às tabelas de rotas.

As duas opções de arquitetura para criar e gerenciar endpoints são:

Arquitetura VPC única

Usando uma única VPC, podemos configurar:

• Endpoints de VPC do tipo gateway para que recursos de VPC acessem o Amazon S3.
• Endpoints de VPC do tipo interface para que os recursos locais do data center acessem o Amazon S3.

A arquitetura a seguir mostra a configuração de como os dois tipos de endpoints de VPC podem ser configurados em uma única VPC para acesso. Isso é útil quando o acesso da AWS é limitado a uma única VPC enquanto o acesso externo (ambiente fora da AWS) está habilitado.

Figura 2. Arquitetura VPC única

 

O DNS configurado no data center local apontará para os endereços IP do endpoint de VPC do tipo interface. Ele encaminhará todo o tráfego do data center para o Amazon S3 por meio do endpoint de VPC do tipo interface. A tabela de rotas configurada na sub-rede garantirá que qualquer tráfego para o Amazon S3 originado na VPC flua usando endpoints do tipo gateway.

Arquitetura centralizada de várias VPC

Em uma arquitetura hub-and-spoke que centraliza o acesso ao Amazon S3 para cargas de trabalho multirregionais, em diferentes VPCs e para cargas de trabalho hospedadas no data center local, recomendamos o uso de um endpoint de VPC do tipo interface no VPC central (hub). O mesmo padrão também funcionaria no design de várias contas/regiões, em que várias VPCs exigem acesso a buckets do Amazon S3 centralizados.

Observe que, usando uma combinação do AWS Transit Gateway e do endpoints de VPC para rotear o tráfego para o serviço de destino, podem ser cobradas taxas de processamento acumuladas de entrada e saída para o AWS Transit Gateway e o endpoint de VPC. Deve-se tomar cuidado para entender essa implicação de custo. Veja os preços do AWS PrivateLink e os preços do AWS Transit Gateway.

Além disso, os dispositivos de firewall que monitoram o tráfego leste-oeste enfrentarão uma carga maior com a arquitetura centralizada de várias VPC. Talvez seja necessário usar o design de endpoint de VPC único para reduzir o impacto nos dispositivos de firewall.

Figura 3. Arquitetura centralizada de várias VPC

Conclusão

Com base nas considerações acima, você pode optar por usar uma combinação de endpoints do tipo gateway e do tipo interface para atender às suas necessidades específicas. Dependendo da estrutura da conta e da configuração da VPC, você pode oferecer suporte aos dois tipos de endpoints de VPC em uma única VPC usando uma arquitetura VPC compartilhada.

Com a AWS, você pode escolher entre dois tipos de endpoints de VPC (gateway ou interface) para acessar com segurança seus buckets do Amazon S3 por meio de uma rede privada. Neste post, mostramos como selecionar o endpoint de VPC correto usando critérios como arquitetura de VPC, padrão de acesso e custo. Para saber mais sobre os endpoints de VPC e melhorar a segurança de sua arquitetura, leia “Securely Access Services Over AWS PrivateLink”.

Este artigo foi traduzido do Blog da AWS en Inglês

Sobre os autores

Jeff Harman é arquiteto de soluções sênior na AWS com sede em Boston. Ele é apaixonado por projetar e implementar plataformas de nuvem modernas e escaláveis para serviços financeiros. Ele trabalhou em serviços financeiros por 20 anos antes de ingressar na AWS.

Gilles-Kuessan Satchivi é arquiteto de soluções de negócios da AWS com experiência em redes, infraestrutura, segurança e operações de TI. Ele é apaixonado por ajudar os clientes a criar sistemas bem projetados na AWS. Antes de ingressar na AWS, ele trabalhou no comércio eletrônico por 17 anos. Fora do trabalho, ele gosta de passar tempo com sua família e torcer pelo time de futebol de seus filhos.

Revisor

Davi Garcia está localizado no Brasil e é arquiteto de soluções da AWS especializado em modernização de infraestrutura e aplicações na nuvem, para clientes de diversos segmentos na América Latina. Possui larga experiência em plataforma de containers, arquiteturas nativas de nuvem e automação. No seu tempo livre, ele gosta de contribuir com projetos open-source, se divertir em família com jogos de tabuleiros e viajar