Malha VPC: Descoberta de serviços entre clusters e malha de serviços

13 Maio, 2025

By Masoom Tulsiani, Cloud Solution Architect, Rackspace Technology

Introdução

À medida que as organizações avançam para microsserviços e arquitecturas de aplicações distribuídas, a gestão da comunicação segura, escalável e fiável entre serviços torna-se um desafio crescente. Os modelos de rede tradicionais geralmente ficam aquém em ambientes grandes e dinâmicos, especialmente quando os serviços abrangem várias contas do AWS e VPCs.

Para resolver essas limitações, a AWS introduziu o VPC Lattice, um serviço de rede de aplicativos totalmente gerenciado que simplifica a comunicação serviço a serviço em ambientes nativos da nuvem. O VPC Lattice reúne roteamento de camada de aplicativo, descoberta de serviço, autenticação e observabilidade - tudo isso sem exigir que os desenvolvedores gerenciem configurações de rede complexas ou malhas de serviço baseadas em sidecar.

Este blogue técnico explora a forma como o VPC Lattice pode ajudar a modernizar a conetividade de serviços e a simplificar a implementação de padrões de malha de serviços no Amazon EKS, ECS e Lambda. Ficará a conhecer os principais componentes do VPC Lattice, padrões de conceção comuns, casos de utilização práticos e orientações de implementação para criar arquitecturas de microsserviços seguras, escaláveis e eficientes.

< entidade drupal data-align="left" data-embed-button="media_entity_embed" data-entity-embed-display="view_mode:media.full" data-entity-type="media" data-entity-uuid="ffc70d81-8bc0-42e9-b646-2faec089e354" data-langcode="en"> < /drupal-entity>

Compreender a arquitetura de rede de serviços na nuvem

A arquitetura de rede de serviços aborda muitos dos desafios operacionais e de rede que os programadores enfrentam em sistemas distribuídos ou baseados em microsserviços. No seu núcleo, uma rede de serviços ajuda a gerir a forma como os serviços comunicam entre si, tratando o encaminhamento, a descoberta, a segurança, a observabilidade e as políticas de tráfego sem exigir alterações ao código da aplicação.

Um dos principais blocos de construção é a descoberta de serviços, que permite que os serviços se localizem e se liguem dinamicamente uns aos outros. Numa malha de serviço nativa da nuvem típica, as funcionalidades incluem frequentemente:

Descoberta dinâmica de serviços
Balanceamento de carga
TERMO ; RESCISÃO.
Proxy HTTP/2 e gRPC
Disjuntores
Controlos de saúde
Modelação do tráfego (por exemplo, implementações canárias ou divisão de tráfego)
Injeção de falhas para testes
Métricas ricas e observabilidade

Entrar na rede VPC

VPC Lattice é a solução de rede de aplicativos e malha de serviços de camada 7 totalmente gerenciada da AWS. Permite a comunicação serviço-a-serviço entre VPCs, contas e plataformas de computação como EKS, ECS, EC2 e Lambda, sem exigir proxies sidecar ou configuração manual de rede.

Evolução da rede Kubernetes: da API Ingress à API Gateway

Em ambientes Kubernetes, o recurso Ingress tem sido o padrão para expor serviços a clientes externos. No entanto, à medida que os casos de utilização de redes evoluíram, as limitações da API Ingress tornaram-se mais evidentes.

Para resolver isso, a comunidade Kubernetes introduziu a API Gateway, que representa a próxima geração de recursos de rede L4/L7 para Kubernetes. Melhora e, eventualmente, pretende substituir a API Ingress, suportando capacidades de encaminhamento mais flexíveis e expressivas.

O controlador da API Gateway da AWS para VPC Lattice tira partido desta evolução. Quando um gateway é criado e associado a um VPC de cluster Kubernetes, o controlador provisiona automaticamente uma rede de serviços. Esta rede de serviços actua como o tecido de comunicação, permitindo um fluxo de tráfego seguro, escalável e observável entre serviços.

Além disso, quando define novas CRDs (CustomResourceDefinitions) do Kubernetes, o servidor da API do Kubernetes expõe novos caminhos de recursos RESTful, permitindo configurações de rede mais extensíveis e declarativas através da API do Gateway e da Malha VPC.

Desafios das arquitecturas tradicionais de service mesh

À medida que os ambientes de microsserviços crescem em complexidade, a gestão da comunicação serviço a serviço - especialmente entre contas, regiões e plataformas - torna-se cada vez mais difícil. Embora as arquitecturas de rede de serviços visem resolver estas questões, a sua implementação em ambientes de nuvem pública introduz um novo conjunto de desafios.

Complexidade na configuração e gestão

As malhas de serviço tradicionais podem ser difíceis de implementar e operar, particularmente em ambientes de nuvem pública onde os programadores já estão a gerir uma variedade de ferramentas e serviços.

Complexidade de implantação: A configuração de malhas de serviço como o Istio ou o Linkerd envolve frequentemente a gestão de proxies sidecar, planos de controlo, gestão de certificados e integração com serviços como o AWS IAM ou o Google Cloud Identity.
Manutenção contínua: A atualização dos componentes da rede, a gestão de políticas e a monitorização do comportamento do serviço à escala aumentam o risco de configuração incorrecta, o que pode levar a uma degradação do desempenho ou a vulnerabilidades de segurança.

Latência e sobrecarga de desempenho

O modelo de proxy sidecar central a muitas malhas de serviço pode introduzir uma sobrecarga desnecessária em ambientes onde cada milissegundo e ciclo de computação conta.

Aumento da latência: A comunicação serviço-a-serviço é encaminhada através de sidecars, adicionando saltos extra e potencialmente diminuindo os tempos de resposta, especialmente para aplicações sensíveis à latência.
Custo mais alto: Os Sidecars consomem CPU e memória adicionais, e o aumento do tráfego de rede entre os serviços aumenta os custos de entrada e saída da nuvem pública.

Desafios da multicloud e da nuvem híbrida

As organizações modernas operam frequentemente em várias nuvens públicas e ambientes locais, dificultando a implementação consistente da malha de serviços.

Problemas de interoperabilidade: Cada plataforma tem o seu próprio modelo de rede e sistema de gestão de identidade, o que complica os esforços para criar uma rede de serviços unificada.
Inconsistência de políticas: A aplicação de políticas consistentes de gestão de tráfego, segurança e monitorização em ambientes heterogéneos requer ferramentas personalizadas ou esforço manual.

Considerar a complexidade da segurança

Embora as malhas de serviço ofereçam funcionalidades de segurança incorporadas, como o TLS mútuo (mTLS) e a autorização fina, a sua gestão à escala pode ser complexa.

Carga operacional: A configuração e a rotação de certificados mTLS em centenas de serviços são demoradas e propensas a erros, aumentando o risco de interrupções ou falhas de segurança.
Modelos de segurança sobrepostos: Os mecanismos de segurança nativos da nuvem, como funções de IAM, grupos de segurança e configurações de VPC, podem entrar em conflito com as políticas baseadas em malha, levando a configurações redundantes ou inconsistentes.

Observabilidade e complexidade do controlo

Uma das principais vantagens de um service mesh é a visibilidade melhorada, mas a captura e a integração de dados de telemetria têm os seus próprios desafios.

Alto volume de dados: Os traços, as métricas e os registos gerados pela rede podem resultar em custos significativos de armazenamento e largura de banda em ambientes de nuvem.
Integração de ferramentas: A combinação de ferramentas de observabilidade nativas da malha (por exemplo, Prometheus, Jaeger) com ferramentas nativas da plataforma (por exemplo, CloudWatch, Stackdriver) requer configuração adicional e conhecimento operacional.

Desafios de escalonamento em grandes clusters

À medida que as implantações de service mesh crescem em milhares de serviços e vários clusters, surgem preocupações de escalabilidade, especialmente em ambientes Kubernetes.

Drenagem de recursos: Os proxies Sidecar em cada pod aumentam o consumo de recursos ao nível do nó, reduzindo a eficiência geral do cluster.
Gargalos no plano de controle: Os componentes de malha centralizados (como o Pilot do Istio) podem se tornar pontos de estrangulamento de desempenho, especialmente em ambientes de várias nuvens ou de alta taxa de transferência.

Transição de App Mesh para VPC Lattice

Historicamente, a AWS tem oferecido várias soluções de malha de serviço, incluindo App Mesh e VPC Lattice.

O App Mesh foi concebido para cargas de trabalho executadas em ECS, EKS e EC2, fornecendo capacidades de malha de serviço do lado do cliente, como resiliência de tráfego (por exemplo, novas tentativas, tempos limite, agrupamento de ligações) e encriptação TLS mútua (mTLS). No entanto, dependia de proxies sidecar baseados em Envoy, que introduziam complexidade de configuração e sobrecarga adicional de infraestrutura.

A AWS anunciou que o App Mesh será descontinuado. Após 30 de setembro de 2026, os clientes deixarão de ter acesso à consola ou aos recursos da App Mesh, assinalando uma mudança mais ampla para uma rede de serviços mais integrada e simplificada.

Por outro lado, o VPC Lattice é a solução moderna e totalmente gerida de rede de aplicações de camada 7 e malha de serviços da AWS. Ele faz a ponte entre a rede tradicional e a comunicação da camada de aplicativos, permitindo que as organizações conectem microsserviços em execução no Kubernetes, EC2, grupos de dimensionamento automático, Lambda e Fargate.

O VPC Lattice é ideal para equipes que desejam automatizar a descoberta de serviços, o gerenciamento de tráfego, a autenticação, a autorização e a observabilidade - sem a complexidade das malhas de serviços baseadas em sidecar. É particularmente adequado para utilizadores que pretendam implementar arquitecturas de aplicações modernas sem conhecimentos profundos em redes VPC ou gestão de infra-estruturas de malha.

3. Visão geral da solução

O AWS VPC Lattice fornece uma solução de rede de aplicativos e malha de serviços totalmente gerenciada, projetada para simplificar a comunicação serviço a serviço em ambientes AWS. Permite a conetividade entre serviços executados no Amazon EKS, ECS, EC2, Lambda e muito mais - sem exigir proxies sidecar ou configurações de rede complexas.

Os principais benefícios do VPC Lattice incluem:

Gestão de tráfego e balanceamento de carga: Aproveita as APIs de gateway nativas do Kubernetes para definir regras de roteamento de tráfego e balanceamento de carga entre pontos de extremidade em vários clusters da AWS.
Observabilidade: Ajuda a monitorizar e a resolver problemas de comunicação serviço-a-serviço, incluindo tipos de pedidos, volumes de tráfego, erros e tempos de resposta.
Descoberta de serviços e conetividade em grande escala: Conecta milhares de serviços em VPCs e contas sem aumentar a complexidade da rede.
Autenticação e autorização com políticas de IAM: Usa IAMAuthPolicy, anexado a redes de serviço VPC Lattice ou serviços individuais, para controlar o acesso aos serviços. Estas políticas podem ser diretamente associadas aos recursos da API Gateway.
Controlo de acesso granular: Melhora a segurança serviço-a-serviço com permissões de acesso centralizadas que suportam arquitecturas de confiança zero através de autenticação e autorização específicas do contexto.
Controlos de tráfego avançados: Suporta recursos de roteamento refinados, como roteamento em nível de solicitação e alvos ponderados, permitindo estratégias de implementação como implantações azul/verde e canário.
Configuração de rede abstraída: Simplifica a descoberta e o roteamento de serviços entre tarefas do ECS executadas em diferentes clusters, eliminando a necessidade de emparelhamento VPC ou gateways de trânsito.
Gestão eficiente do tráfego entre regiões: Gerencia o tráfego entre regiões e ambientes, suportando casos de uso como análise e alerta de fraude em tempo real.
Suporte para resiliência de roteamento: Permite capacidades de encaminhamento automático e failover para ajudar a manter a disponibilidade da aplicação, mesmo que partes do sistema tenham problemas.

O VPC Lattice gere automaticamente a comunicação serviço-a-serviço, a conetividade entre VPCs e entre contas e o controlo de tráfego avançado, facilitando a implementação e o funcionamento de aplicações distribuídas modernas à escala.

Figura: Componentes da rede VPC e redes de serviços

4. Descrição pormenorizada da solução

O VPC Lattice abstrai as complexidades da infraestrutura de rede subjacente, permitindo que as equipas se concentrem na comunicação segura e escalável entre serviços. Em vez de depender de construções de rede tradicionais, como peering VPC ou gateways de trânsito, o VPC Lattice introduz uma arquitetura semelhante a uma malha de serviço que simplifica a forma como os microsserviços interagem em ambientes AWS. Os principais componentes incluem:

Rede de serviços: No coração do VPC Lattice está a Rede de Serviços, que actua como um limite lógico para agrupar serviços. Numa rede de serviços, é possível definir e aplicar regras de encaminhamento, aplicar políticas de segurança e gerir o fluxo de tráfego entre serviços. Essas redes oferecem suporte a recursos baseados em VPC e não baseados em VPC, oferecendo flexibilidade em ambientes híbridos e sem servidor.
Gerenciamento de acesso: O VPC Lattice integra-se com o AWS Identity and Access Management (IAM) para controlar quais os serviços que podem comunicar entre si. As políticas de IAM refinadas ajudam a definir o acesso ao nível do serviço ou da rede de serviços, suportando interações seguras e sensíveis ao contexto entre os microsserviços.
Comunicação entre regiões e entre contas: O VPC Lattice elimina a necessidade de emparelhamento complexo de VPC entre regiões ou de gestão de terminais ao nível da conta. Os serviços podem comunicar de forma segura entre contas e regiões do AWS, sem necessidade de configuração de rede personalizada ou configuração manual.

A secção seguinte ilustra um caso de utilização prático: comunicação serviço-a-serviço entre clusters utilizando a rede VPC.

Figura - Comunicação serviço a serviço entre clusters do Amazon EKS utilizando o Amazon VPC Lattice

Dois conceitos fundamentais do VPC Lattice são a Rede de Serviços e o Serviço. Dentro de um serviço, o AWS fornece construções familiares, semelhantes às usadas nos balanceadores de carga de aplicativos (ALBs), incluindo ouvintes e grupos de destino. Esses grupos-alvo podem incluir recursos como pods do Amazon EKS ou tarefas do ECS. Para efeitos deste blogue, vamos concentrar-nos especificamente em exemplos que envolvem o Amazon EKS e o Amazon ECS.

Fluxo de tráfego da rede VPC

O VPC Lattice oferece uma abordagem poderosa e flexível para gerenciar o fluxo de tráfego e as chamadas de API entre serviços implantados em vários recursos do AWS, incluindo grupos de dimensionamento automático e funções Lambda.

Para conectar um grupo do Amazon EC2 Auto Scaling a um serviço VPC Lattice, siga estas etapas:

Crie um grupo de destino que encaminhe pedidos para instâncias EC2, identificadas pelo ID da instância.
Configure um ouvinte no serviço da Malha VPC para encaminhar pedidos de entrada para este grupo-alvo.
Anexe o grupo de destino ao seu grupo de Escalonamento automático.

Uma vez anexado, o Amazon EC2 Auto Scaling gere automaticamente o ciclo de vida do registo de destino. Regista novas instâncias com o grupo alvo à medida que são lançadas e anula o registo quando estão programadas para terminar - assegurando um encaminhamento consistente e preciso.

O grupo de destino torna-se o ponto de entrada para todo o tráfego de entrada para o seu grupo de Escalonamento Automático. Os pedidos de entrada são encaminhados com base em regras de escuta definidas no serviço VPC Lattice, permitindo um controlo preciso sobre a forma como o tráfego é distribuído pelas instâncias.

Estratégias, padrões de conceção e guia de implementação

Em um ambiente AWS com várias contas, o VPC Lattice fornece uma maneira segura e escalonável de permitir a comunicação serviço a serviço entre VPCs e contas AWS. Para tal, estabelece redes de serviços e associações de serviços, que simplificam a conetividade, mantendo simultaneamente fortes limites de segurança.

Considere a seguinte arquitetura:

A conta do consumidor A e a conta do consumidor B precisam de comunicar com serviços alojados na conta do fornecedor A e na conta do fornecedor B, respetivamente.
Na Conta de Fornecedor A, uma VPC Lattice Service Network 1 está associada à VPC Lattice Service 1. Esta configuração permite que as instâncias EC2 na Conta de Consumidor A se liguem através de resolvedores DNS configurados com as associações VPC adequadas.
Na Conta de Fornecedor B, a Rede de Serviços 2 está associada ao Serviço de Malha VPC 2. Uma função Lambda na Conta de Consumidor B utiliza uma Interface de Rede Elástica (ENI) para estabelecer ligação, permitindo uma comunicação segura e dinâmica serviço-a-serviço.
Entretanto, a Conta de Fornecedor B aloja instâncias EC2 num grupo de Escalonamento Automático, garantindo elasticidade e elevada disponibilidade para suportar cargas de trabalho variáveis de ambas as contas de consumidor.

Esta arquitetura simplifica muito a ligação em rede entre contas, eliminando a necessidade de configurações complexas ponto-a-ponto. Ao dissociar a conetividade do serviço da infraestrutura de rede subjacente, o VPC Lattice suporta:

Controlo de acesso de grau fino
Encaminhamento de tráfego na camada de aplicação
Comunicação escalável e segura em diversos ambientes de computação

O resultado é uma sobrecarga operacional reduzida, uma melhor observabilidade e uma maior flexibilidade arquitetónica para as organizações que gerem serviços em várias contas AWS e VPCs.

Figura: Ilustração da comunicação serviço-a-serviço de múltiplos clusters/VPCs

Exemplo: Comunicação entre clusters EKS

Neste exemplo, o Amazon VPC Lattice é usado para permitir a comunicação segura e escalável entre serviços executados em clusters EKS separados.

Figura: Tráfego HTTPS passando pela Malha VPC

O Controlador da API Gateway gere a criação de recursos da Malha VPC com base nas definições HTTPRoute e IAMAuthPolicy.
O External-DNS é responsável por gerar registos DNS numa Zona Privada Alojada do Route 53. Utiliza os mesmos objectos HTTPRoute que definem nomes de domínio personalizados para serviços.
Quando um API Gateway HTTPRoute inclui um domínio personalizado, o Amazon VPC Lattice cria automaticamente um ponto de extremidade DNS correspondente para essa entrada.
Para autorização, a solução utiliza políticas de autenticação IAM em combinação com EKS Pod Identity. Essa abordagem simplifica o processo para que os administradores do Kubernetes concedam permissões de IAM a aplicativos em execução no cluster.

Essa configuração permite que os serviços em clusters se comuniquem com segurança usando ferramentas familiares nativas do Kubernetes e a infraestrutura de malha de serviço gerenciada pela AWS.

Nova funcionalidade: Acesso a recursos entre VPCs com Privatelink para VPC Lattice.

Conforme anunciado no AWS Re:Invent 2024 em 1º de dezembro de 2024, o PrivateLink agora oferece suporte à conetividade nativa entre regiões.

O AWS PrivateLink representa uma tecnologia escalável e altamente disponível que estabelece conetividade privada e unidirecional das suas VPCs para os serviços de ponto final da VPC. Esta conetividade estende-se aos serviços AWS suportados e, agora, diretamente aos recursos VPC. Anteriormente, o acesso e a partilha de serviços estavam limitados aos que utilizavam um Balanceador de Carga de Rede ou um Balanceador de Carga de Gateway e os pontos finais da VPC de Interface apenas suportavam a conetividade com os serviços de pontos finais da VPC na mesma região.

Trazendo vantagens como a conetividade VPC-a-VPC através do Privatelink ou VPC Lattice, partilha de várias contas através do Resource Access Manager (RAM), gestão de tráfego escalável (herdando as vantagens do Lattice e do Privatelink) e melhorando a segurança ao herdar os mecanismos de segurança e as configurações de recursos do VPC Lattice.

Partilha integrada com a RAM

Com esta melhoria, os clientes podem agora partilhar qualquer recurso VPC através do AWS Resource Access Manager (AWS RAM). O recurso partilhado pode ser um recurso nativo do AWS - como uma base de dados Amazon RDS, um nome de domínio ou um endereço IP - localizado noutra VPC ou ambiente local. Uma vez partilhados, os utilizadores autorizados podem aceder a estes recursos de forma privada através de pontos de extremidade VPC.

Arquitetura orientada para eventos Integrações

Os Cusomers podem partilhar recursos da AWS, como instâncias do Amazon Elastic Compute Cloud (EC2), serviços de contentores do Elastic Container Service (ECS) e do Elastic Kubernetes Service (EKS), e os seus próprios serviços HTTPS através do Amazon VPC e dos limites da conta da AWS e utilizá-los para criar aplicações orientadas para eventos através do EventBridge e orquestrar fluxos de trabalho com o AWS Step Functions.

Os clientes podem agora criar e utilizar Gateways de Recursos e Configurações de Recursos. O EventBridge e o Step Functions agora trabalham em conjunto com o PrivateLink e o VPC Lattice para permitir a integração de aplicativos públicos e privados baseados em HTTPS em arquiteturas e fluxos de trabalho orientados por eventos.

Pontos de extremidade VPC

Os clientes do AWS PrivateLink podem agora aproveitar os pontos de extremidade VPC, com a tecnologia do AWS PrivateLink, para acessar de forma segura e privada os recursos VPC. Estes recursos - incluindo, mas não se limitando a, bases de dados e clusters - podem residir na sua VPC ou num ambiente no local e não estão limitados a um equilíbrio de carga.

Os clientes podem configurar um ponto de extremidade VPC de recursos para visar um único recurso ou agregar vários recursos numa rede de serviços Amazon VPC Lattice e, subsequentemente, aceder à rede de serviços utilizando um ponto de extremidade VPC de rede de serviços dedicado.

Estudos de casos e exemplos

1. Deteção de fraudes em tempo real nos serviços financeiros

Uma organização de serviços financeiros utiliza um sistema de deteção de fraudes em tempo real para monitorizar as transacções dos clientes e identificar comportamentos suspeitos. A aplicação foi criada no Amazon ECS Fargate e inclui vários microsserviços, como monitorização de transacções, pontuação baseada em regras e alertas.

Para funcionar eficazmente, a aplicação requer uma comunicação segura e de baixa latência entre vários clusters e a integração com sistemas nativos da nuvem e locais, incluindo:

Centro de dados no local - Aloja dados históricos, incluindo transacções antigas e registos de clientes, que são essenciais para uma análise precisa da fraude.
Amazon RDS para PostgreSQL - Armazena dados de transacções recentes, alertas de fraude e metadados utilizados para análise e relatórios.

Anteriormente, a organização tinha implementado o Cloud Map e experimentado o App Mesh para suportar a conetividade do serviço. No entanto, à medida que a escalabilidade e os requisitos de conformidade aumentavam, crescia também a necessidade de uma solução mais simplificada e fácil de gerir.

Ao adotar o VPC Lattice como uma malha de serviço gerido, a empresa permitiu uma conetividade segura entre clusters nos serviços ECS Fargate - abrangendo várias contas AWS e VPCs, bem como infra-estruturas no local.

Os principais elementos da solução incluem:

1. Descoberta e encaminhamento de serviços entre clusters

As tarefas do ECS Fargate em diferentes clusters comunicam sem necessidade de configurações de rede complexas.
Serviços como a monitorização de transacções são registados no VPC Lattice, que encaminha os pedidos com base em regras de tráfego definidas. Por exemplo, as transacções assinaladas são encaminhadas da monitorização para os serviços de pontuação para avaliação.

2. Acesso a dados no local

O AWS Diret Connect liga o centro de dados no local aos VPCs do AWS.
O VPC Lattice encaminha de forma segura os pedidos entre as tarefas do ECS e as bases de dados locais, impondo controlos de acesso baseados no IAM e impedindo o acesso não autorizado.
Isto permite que o motor de deteção de fraudes recupere dados históricos a pedido, enriquecendo a análise em tempo real.

3. Acesso em tempo real ao Amazon RDS para PostgreSQL

As tarefas ECS interagem com o Amazon RDS para consultar e armazenar registos de transacções recentes.
O VPC Lattice facilita o acesso direto à instância RDS, permitindo que os serviços ECS distribuídos comuniquem com uma base de dados central, mesmo entre clusters.
A arquitetura adapta-se perfeitamente ao aumento do volume de transacções.

4. Segurança unificada e observabilidade

A organização aplica políticas de segurança consistentes, incluindo a encriptação em trânsito e controlos IAM de pormenor.
O VPC Lattice fornece visibilidade do tráfego serviço a serviço, incluindo métricas como latência, volume de solicitações e taxas de erro.
Isto apoia a conformidade regulamentar, oferecendo uma pista de auditoria completa das interações entre serviços.

2. Aplicação de viagens e comércio eletrónico utilizando ECS e Lambda

Uma empresa de viagens e comércio eletrónico precisava de ligar de forma segura aplicações criadas no Amazon ECS e no AWS Lambda. A plataforma incluía vários serviços que exigiam conetividade consistente e gestão de tráfego em diferentes tipos de computação.

Nesta configuração:

A aplicação front-end de reserva de viagens é executada no Amazon ECS e está exposta aos utilizadores da Internet através de um Application Load Balancer (ALB) público.
O serviço de checkout também é executado no ECS.
O serviço de reservas é executado no AWS Lambda.

Tanto os serviços de checkout como os de reserva são publicados como serviços Amazon VPC Lattice e são acessíveis na mesma rede de serviços VPC Lattice.

Para suportar a integração do Lambda, o VPC Lattice foi configurado para usar o Lambda como o tipo de grupo de destino, com uma função designada especificada para invocação.

Esta solução proporcionou um equilíbrio de carga contínuo na camada de aplicação e conetividade de rede entre serviços. Permitiu que a equipa da plataforma se concentrasse no desenvolvimento de aplicações em vez de gerir as complexidades da infraestrutura subjacente, como a configuração de VPCs, a gestão de redes entre contas ou a gestão de intervalos de endereços IP sobrepostos.

Desafios e considerações

Embora o VPC Lattice resolva muitos dos pontos problemáticos tradicionais associados às implantações de service mesh, é importante entender os desafios mais amplos e as compensações que podem surgir, particularmente em cenários de service mesh com vários clusters, híbridos e gerenciados.

Desafios da rede multi-cluster

Um problema comum em ambientes com vários clusters é a sobreposição de intervalos de endereços IP, o que pode complicar o roteamento e a conetividade entre serviços em diferentes VPCs ou contas.

O VPC Lattice ajuda a mitigar esses desafios ao:

Suporte nativo da API do Kubernetes Gateway, eliminando a necessidade de integrações personalizadas.
Evitar a utilização de Definições de Recursos Personalizadas (CRDs) para a configuração de serviços.
Gerir automaticamente a conetividade de rede entre VPCs e contas, incluindo a tradução de endereços de rede (NAT) entre IPv4 e IPv6, e entre intervalos de IP sobrepostos.

Este suporte integrado reduz significativamente a complexidade operacional das implementações de vários clusters.

Restrições de personalização e dependência do fornecedor

As soluções de rede de serviços geridos são muitas vezes fortemente associadas às respectivas plataformas de nuvem, o que pode limitar a portabilidade e a personalização.

As soluções de malha nativas da nuvem, como o AWS App Mesh ou o Cloud Service Mesh do Google, oferecem uma integração profunda com os serviços da plataforma, mas esse acoplamento estreito pode dificultar a transferência de cargas de trabalho para outros provedores ou ambientes locais.
Podem também surgir restrições de personalização. As malhas gerenciadas em nuvem pública normalmente oferecem menos flexibilidade em comparação com projetos de código aberto como o Istio, especialmente para organizações com políticas de tráfego exclusivas ou necessidades avançadas de observabilidade.

Estas considerações são importantes quando se avalia se uma solução gerida como a VPC Lattice se alinha com a sua estratégia de arquitetura a longo prazo.

Porque é que a rede VPC deve fazer parte da sua estratégia de rede AWS

O AWS VPC Lattice simplifica a forma como as organizações conectam, protegem e monitoram serviços entre contas, VPCs e regiões. Ao automatizar a descoberta de serviços, a gestão de tráfego e a aplicação de políticas de segurança, reduz a complexidade operacional e suporta arquitecturas de aplicações escaláveis e resilientes.

Benefícios da utilização da Malha VPC num cenário de deteção de fraude

Redução da complexidade da rede - Resume a configuração de rede necessária para a comunicação entre clusters e no local, simplificando a descoberta de serviços e o encaminhamento entre as tarefas do ECS.
Desempenho escalável e de baixa latência - Gere eficazmente o tráfego entre regiões e ambientes para suportar a deteção e alerta de fraudes em tempo real com latência mínima.
Segurança e conformidade melhoradas - Utiliza políticas de IAM, encriptação e controlos de acesso centralizados para proteger dados sensíveis em trânsito e cumprir os requisitos regulamentares.
Alta disponibilidade e resiliência - Suporta encaminhamento automático e failover, ajudando os sistemas críticos a permanecerem disponíveis mesmo que partes da arquitetura tenham problemas.

Quer esteja a criar fluxos de trabalho de deteção de fraude em tempo real, a modernizar sistemas antigos ou a escalar em várias contas AWS, o VPC Lattice fornece as capacidades de malha de serviço e as ferramentas de rede da camada de aplicação necessárias para simplificar a sua arquitetura - sem o fardo da gestão da infraestrutura de malha de serviço tradicional.

Referência

https://aws.amazon.com/blogs/aws/securely-share-aws-resources-across-vpc-and-account-boundaries-with-privatelink-vpc-lattice-eventbridge-and-step-functions/

Documentação do VPC Lattice AWS: Visão geral do VPC Lattice

Controlador da API de gateway - controlador da API de gateway

Blogpost: https://aws.amazon.com/blogs/containers/build-secure-application-networks-with-vpc-lattice-amazon-ecs-and-aws-lambda/

API do gateway Kubernetes https://aws.amazon.com/blogs/containers/introducing-aws-gateway-api-controller-for-amazon-vpc-lattice-an-implementation-of-kubernetes-gateway-api/

Gerir o fluxo de tráfego com um grupo-alvo da rede VPC https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-vpc-lattice.html

IAM https://docs.aws.amazon.com/vpc-lattice/latest/ug/security_iam_service-with-iam.html

Comunicação segura entre clusters no EKS https://aws.amazon.com/blogs/containers/secure-cross-cluster-communication-in-eks-with-vpc-lattice-and-pod-identity-iam-session-tags/