Migrar o Gateway de API da Amazon para o Gerenciamento de API do Azure

Se você usar o Gateway de API da Amazon e quiser migrar sua carga de trabalho para o Azure, este guia ajudará você a entender os mapeamentos de recursos, as práticas recomendadas e o processo de migração. No Azure, o Gerenciamento de API do Azure fornece recursos de gateway de API. Esses recursos incluem roteamento de solicitação de API e resposta, autorização e controle de acesso, monitoramento e governança e gerenciamento de versão da API.

O que você vai realizar

Neste guia, você:

• Avalie sua implantação atual do Gateway de API da Amazon.
• Mapeie os recursos do Gateway de API da Amazon para os recursos de Gerenciamento de API do Azure.
• Prepare seus ambientes do Amazon e do Azure para uma migração bem-sucedida.
• Planeje e execute uma migração com tempo de inatividade mínimo.
• Valide se a carga de trabalho migrada atende aos requisitos de desempenho e confiabilidade.
• Saber como iterar na arquitetura para aprimoramentos futuros.

Cenário de exemplo: sistema de registros de saúde com múltiplos back-ends

Uma organização de serviços de saúde usa o Gateway de API da Amazon para acessar um sistema de registros de saúde que tem vários back-ends. Este cenário de exemplo apresenta uma configuração comum do Gateway de API da Amazon em um ambiente do AWS (Amazon Web Services). Ele mostra integrações típicas com os serviços relacionados da Amazon e vários back-ends de API comuns, incluindo funções Lambda com proxie e APIs HTTP ou REST.

Essa arquitetura inclui:

• Autenticação de usuário por meio do Amazon Cognito com JWTs (Tokens Web JSON).

• Filtragem de segurança de solicitações por meio do WAF (Firewall de Aplicativo Web) da Amazon antes de chegarem ao Gateway de API da Amazon.

• Gateway de API da Amazon configurado com um domínio personalizado por meio de um certificado armazenado no Gerenciador de Certificados.

• Monitoramento por meio do Amazon CloudWatch.

• Conectividade privada por meio de endpoints da Amazon Virtual Private Cloud (VPC) para três sub-redes privadas.

• Serviços de back-end, incluindo:

  • Lambda para acionar atualizações no registro do paciente.
  • Amazon Elastic Compute Cloud (EC2), que hospeda serviços herdados por trás de um balanceador de carga do aplicativo.
  • Amazon Elastic Kubernetes Service (EKS) por trás de um balanceador de carga de aplicativo para processamento de dados por meio de microsserviços.

Aqui está um exemplo de arquitetura da carga de trabalho migrada para o Azure. Nesse cenário, o Gerenciamento de API do Azure é implantado na camada Premium.

Essa arquitetura inclui:

• Entrada segura por meio do Gateway de Aplicativo do Azure com um Firewall de Aplicativo Web (WAF). O firewall encaminha solicitações com um JWT adicionado para autenticação.

• Gerenciamento de API do Azure configurado dentro de uma rede virtual. Ele usa a ID do Microsoft Entra para validar JWTs.

• Um balanceador de carga interno que roteia o tráfego para o AKS (Serviço de Kubernetes do Azure) para back-ends baseados em microsserviços.

• Garantir conexões seguras por meio de endpoints privados para apps de função do Azure e backends do Microsoft Foundry.

• Monitoramento manipulado pelo Azure Monitor.

• Certificados e um domínio gerenciado por meio do Azure Key Vault e de uma zona DNS do Azure. Um certificado também é configurado no Gateway de Aplicativo para terminação de TLS.

Visão geral da arquitetura

Este exemplo de arquitetura mostra recursos comuns no Gateway de API da Amazon e no Gerenciamento de API do Azure. Esses recursos incluem isolamento de rede, gerenciamento de tráfego e roteamento para várias APIs de back-end, autorização e controle de acesso e monitoramento.

Ambas as arquiteturas fornecem funcionalidade comparável:

• Implantação de alta disponibilidade: os recursos são distribuídos entre várias zonas de disponibilidade em uma região para tolerância a falhas, com opções para maior disponibilidade por implantação em várias regiões.

• Domínios e certificados personalizados: as plataformas dão suporte a nomes de domínio personalizados com terminação TLS/SSL para comunicação de API segura.

• Isolamento de rede: o tráfego para APIs de back-end é isolado em uma rede virtual.

• Filtragem de tráfego: um firewall de aplicativo Web na borda filtra e ajuda a proteger o tráfego de entrada.

• Suporte à carga de trabalho de API: os gateways atuam como proxies para solicitações para diversos sistemas de back-end, incluindo serviços de computação em nuvem, microsserviços baseados em Kubernetes e back-ends personalizados.

• Monitoramento de API: Serviços de plataforma embutidos registram a atividade da API e expõem métricas de serviço.

• Modulação de API: os serviços dão suporte a cache de resposta, cotas de solicitação e limites de taxa, configuração de CORS (compartilhamento de recursos entre origens) e transformações de solicitação/resposta.

• Autenticação e autorização de API: os gateways dão suporte a vários métodos de acesso, incluindo chaves, acesso baseado em token OAuth e políticas baseadas em API.

Etapa 1: Avaliação

Antes de migrar do Gateway de API da Amazon para o Gerenciamento de API do Azure, avalie os recursos de infraestrutura, as cargas de trabalho de API e as configurações de API existentes. Identifique as capacidades a serem mapeadas ou substituídas. Essa avaliação ajuda a garantir uma migração tranquila e mantém a funcionalidade de seus aplicativos.

Avaliar os recursos de infraestrutura

Incompatibilidades de funcionalidade e estratégias

• A integração do WAF no Gateway de API da Amazon não tem uma correspondência direta no Gerenciamento de API do Azure. No Gateway de API da Amazon, as regras do WAF são aplicadas diretamente nos estágios da API REST. No Gerenciamento de API do Azure, a configuração das regras do WAF normalmente requer a implantação de uma instância upstream do Gateway de Aplicativo, encaminhamento de tráfego e terminação TLS por meio do gateway. Como alternativa, para cenários ativos/ativos de várias regiões, use o Azure Front Door na frente do Gerenciamento de API do Azure.
• Domínios personalizados têm suporte no Gerenciamento de API do Azure. Se você utilizar o Gateway de Aplicativo e o Firewall do Aplicativo Web do Azure como front-end, também deverá configurar o domínio personalizado e o certificado TLS na camada do Gateway de Aplicativo.
• Os pontos de extremidade com otimização de borda no Gateway de API da Amazon dão suporte a clientes geograficamente distribuídos. A funcionalidade semelhante no Gerenciamento de API do Azure requer a implantação de gateways regionais extras a um custo extra.

Comparar cargas de trabalho de API

Como parte da avaliação, considere se os serviços existentes devem ser retidos ou substituídos. Avalie se a migração é uma oportunidade para modernizar ou consolidar serviços.

Incompatibilidades de funcionalidade e estratégias

• Os lambda backends têm suporte nativamente no Amazon API Gateway como APIs HTTP. O Gerenciamento de API do Azure não fornece integração nativa com os aplicativos de funções comparáveis do Azure. O Gerenciamento de API do Azure deve chamar aplicativos de funções por HTTP usando uma chave de função ou uma identidade gerenciada.
• As especificações de OpenAPI exportadas de uma API REST do Gateway de API da Amazon contêm detalhes específicos para a implementação de front-end no Gateway de API da Amazon, não o serviço de back-end. Você precisa remover marcas específicas do AWS e configurar detalhes na especificação (como a URL do serviço de back-end) antes de importar para o Gerenciamento de API do Azure ou durante o processo de migração.
• Os back-ends de microsserviços do Kubernetes, como APIs gRPC, são tratados de forma diferente:
  • O Gateway de API da Amazon conecta-se ao balanceador de carga do aplicativo no VPC, que, por sua vez, fornece entrada para o AWS EKS.
  • O Gerenciamento de API do Azure suporta APIs gRPC em clusters Kubernetes acessados apenas por meio do gateway auto-hospedado.
  • O uso de gRPC impede o uso do Gateway de Aplicações como um WAF.

Comparar configurações de API

A abordagem de migração para configurações de API deve considerar o escopo da configuração no Gateway de API da Amazon. Em um alto nível, os escopos da API são mapeados da seguinte maneira do Gateway de API da Amazon para o Gerenciamento de API do Azure:

A tabela a seguir avalia as configurações de API no Gateway de API da Amazon e configurações equivalentes no Gerenciamento de API do Azure:

Incompatibilidades de funcionalidade e estratégias

• Os limites de cota e limitação são impostos pelo Gateway de API da Amazon por conta da AWS. No Azure API Management, o escopo mais abrangente é o escopo "todas as APIs" por instância.

• Os métodos de autenticação e autorização de API no Gateway de API da Amazon, como permissões de IAM e autorizadores Lambda, não são mapeados diretamente para o Gerenciamento de API do Azure. Os clientes podem avaliar métodos alternativos de autenticação e autorização, como usar a ID do Microsoft Entra ou um provedor de identidade externo.

• As métricas relacionadas ao cache no Gateway de API da Amazon não são mapeadas diretamente para as métricas de Gerenciamento de API do Azure. Os acertos e erros de cache podem ser contados em logs de rastreamento no Gerenciamento de API do Azure.

Examinar os recursos para migração

• Zona de destino do Gerenciamento de API do Azure

• Práticas recomendadas de arquitetura para o Gerenciamento de API do Azure

• Autenticação e autorização de API no Gerenciamento de API do Azure

• Azure para profissionais da AWS

• Microsoft Copilot no Azure para geração de política de Gerenciamento de API

• Servidor MCP de documentação do AWS e servidor MCP do Microsoft Learn

Além disso, para cargas de trabalho de API:

• Migrar cargas de trabalho lambda do AWS para o Azure Functions

• Migrar do Serviço de Kubernetes Elástico do Amazon para o Serviço de Kubernetes do Azure

Passo 2: Preparação

Na fase de preparação, planeje sua infraestrutura do Azure, selecione as camadas apropriadas de Gerenciamento de API para teste e produção e documente minuciosamente suas APIs de origem e serviços integrados. Exporte configurações relevantes do AWS e crie uma estratégia de migração em fases para garantir uma transição suave.

Planejar a configuração da infraestrutura

Planeje a entrada e saída, firewalls, isolamento de rede e integração com pontos de entrada de tráfego de rede, como Gateway de Aplicativo, Azure Front Door ou Gerenciador de Tráfego do Azure. Entenda as implicações da exposição privada versus pública do sistema de Gerenciamento de API do Azure de destino, especialmente em relação ao DNS e à rastreabilidade.

Examine as diretrizes no acelerador de zona de destino do Gerenciamento de API do Azure e avalie cenários que podem ser adequados para sua migração e back-ends de API. Considere quando as cargas de trabalho estão isoladas o suficiente para que possam se beneficiar disso.

Um cenário básico que você pode usar para migração inicial e build-out no Azure é uma linha de base segura com uma carga de trabalho de exemplo.

Planejar instâncias de gerenciamento de API de teste e produção

Escolha as camadas de serviço apropriadas do Gerenciamento de API do Azure para ambientes de teste e produção:

• Se você precisar de isolamento de rede do tráfego de entrada e de saída, juntamente com a entrada de tráfego por meio do Azure Front Door ou gateway de aplicativo, recomendamos atualmente a camada Premium do Gerenciamento de API do Azure. Se você selecionar a camada Premium, poderá usar a camada Desenvolvedor (sem suporte com um contrato de nível de serviço) para migrações de prova de conceito. A camada De desenvolvedor dá suporte a recursos de rede que também estão disponíveis na camada Premium. No entanto, você não deve usar a camada Desenvolvedor para produção.

• Dependendo de seus requisitos de disponibilidade, desempenho e isolamento de rede, considere a camada Standard v2 ou Premium v2. Ambos dão suporte à integração com back-ends isolados pela rede. A camada Premium v2 também dá suporte à injeção em uma rede virtual para isolar o tráfego de entrada.

• Atualmente, a camada Premium v2 com recursos para isolar o tráfego de entrada está em versão prévia. Você pode considerar usá-lo para migrações, dependendo dos cronogramas de implementação em relação às informações disponíveis sobre o lançamento da versão Premium v2 e os caminhos de migração.

Entender e documentar as APIs de origem sob gerenciamento

Capturar configurações de API, incluindo fluxos de autenticação e autorização, transformação e mecanismos de cache.

Identifique todos os serviços integrados ao Gateway de API da Amazon, como autorizadores Lambda, balanceadores de carga de aplicativo, balanceadores de carga de rede e cargas de trabalho do Kubernetes.

Para catalogar APIs sob gerenciamento, considere usar o Centro de API do Azure e sincronizar APIs do Gateway de API da Amazon.

Use ferramentas de descoberta, como o AWS Resource Explorer sempre que possível. Mas espere depender muito de informações coletadas manualmente, documentação interna e listas de verificação.

Documentar fluxos de dados, topologia de rede e diagramas de arquitetura, mesmo que sejam aproximados.

Exportar configurações do AWS sempre que possível

Exportar configurações como:

• Especificações OpenAPI de APIs de back-end; por exemplo, usando o console da AWS ou a CLI da AWS. Se as APIs foram definidas por meio do OpenAPI originalmente, talvez você já tenha essas especificações.

• Certificados SSL/TLS armazenados no Gerenciador de Certificados do AWS.

• Regras do WAF, exportadas para o CloudFormation.

Capture artefatos, incluindo modelos do CloudFormation, que podem ser exportados para o Terraform por meio de ferramentas externas. Esses artefatos podem facilitar o mapeamento para o Azure (modelos Bicep, Azure Resource Manager e Terraform).

Planejar uma estratégia de fases

Recomendamos que você planeje uma migração em fases (API por API ou domínio por domínio). Atualize um conjunto de domínios ou pontos de extremidade de API para o Gerenciamento de API do Azure, enquanto outros permanecem na AWS e, em seguida, mova gradualmente o restante. Essa estratégia pode exigir que seus aplicativos cliente manipulem pontos de extremidade mistos ou usem uma camada de roteamento.

Etapa 3: Avaliação

A migração é considerada bem-sucedida quando o sistema migrado atende aos critérios de validação e quando o Gerenciamento de API do Azure atende a todo o tráfego de produção sem regressão significativa em funcionalidade ou desempenho.

Os critérios de validação incluem:

• Validar a infraestrutura: a infraestrutura de rede está documentada e acessível somente conforme o esperado. Por exemplo, se ele for injetado em uma rede virtual interna, confirme se nenhum IPs público está expondo-a.

  A instância de Gerenciamento de API do Azure pode alcançar todas as redes ou dependências necessárias para operações.

• Validar a funcionalidade da API para todos os pontos de extremidade: todos os pontos de extremidade da API funcionam conforme o esperado em cenários reais, incluindo solicitações e cargas úteis válidas e inválidas. Verifique se todas as transformações de solicitação ou resposta em políticas configuradas ocorrem:

  • Confirme todas as configurações de autenticação e autorização necessárias (chaves de assinatura, tokens OAuth, certificados) para cada API.

  • Confirme se os clientes podem usar APIs como antes sem alterações (exceto possivelmente a URL do ponto de extremidade, se o nome de domínio foi alterado).

  • Confirme se os limites de taxa e as cotas estão configurados no escopo apropriado.

• Validar métricas operacionais: monitore o desempenho usando dashboards ou outras ferramentas de observabilidade sob carga de produção. Examine as métricas, como latência e taxa de transferência médias, e compare-as com dados históricos do Gateway de API da Amazon. Examine as métricas de capacidade para garantir que a instância de Gerenciamento de API do Azure seja dimensionada corretamente.

Etapa 4: Processo

Espere que o processo de migração leve várias semanas ou meses, dependendo da complexidade da infraestrutura de serviço e do número e complexidade das APIs a serem migradas.

Concluir a configuração fundamental

Se você ainda não tiver o locatário do Azure e a infraestrutura central (rede central, entrada, segurança) estabelecida, crie-os antes de migrar o API Gateway da Amazon e as APIs. Você pode configurar o ambiente usando uma arquitetura de zona de destino do Azure adequada para sua migração.

Se um acelerador de zona de destino de infraestrutura como código do Gerenciamento de API do Azure for adequado para sua migração, implemente-o na sua implantação fundamental do Gerenciamento de API do Azure. Inclua o Gateway de Aplicativo e a rede virtual interna no Gerenciamento de API do Azure. Embora o acelerador de zona de aterrissagem use a camada Premium do Gerenciamento de API do Azure, recomendamos que você adapte os modelos para usar a camada Developer para migração de prova de conceito.

Crie e atribua funções de RBAC (controle de acesso baseado em função) do Azure para que somente os administradores autorizados possam gerenciar a instância de Gerenciamento de API do Azure e as APIs.

Definir as configurações da plataforma de Gerenciamento de API do Azure

Na nova instância de Gerenciamento de API do Azure, configure configurações globais semelhantes às do Gateway de API da Amazon:

• Nome do host personalizado: adicione seu domínio personalizado ao Gerenciamento de API do Azure, carregue o certificado SSL (ou use referências do Key Vault) e execute a validação. Faça essa tarefa agora ou pouco antes da substituição da produção. Quando você estiver usando o Application Gateway (recomendado), configure um listener com o domínio e o certificado personalizados e aponte-o para o endpoint interno do Azure API Management. Configurar o ouvinte simplifica a configuração porque ela não requer validação de domínio.

• Rede e segurança: verifique se o Gateway de Aplicativo (ou outro ponto de entrada do Azure) está configurado para encaminhar solicitações para o Gerenciamento de API do Azure. Configure regras de NSG (grupo de segurança de rede) ou regras de firewall para que o Gerenciamento de API do Azure possa alcançar serviços de back-end. Esses serviços podem incluir seus back-ends do Azure ou até mesmo os back-ends de origem da AWS, caso você esteja inicialmente apontando para eles.

• Identidade gerenciada: habilite uma identidade gerenciada no Gerenciamento de API do Azure para chamar os serviços do Azure com segurança (como o Key Vault para certificados ou aplicativos de funções).

Ao final dessa fase, você deve ter um shell de trabalho do Gerenciamento de API do Azure no Azure com conectividade e a estrutura básica pronta para começar a importar APIs.

Importar e recriar APIs no Gerenciamento de API do Azure

Com a infraestrutura pronta, comece a migrar as definições e configurações da API:

• Comece com uma API simples e de baixo risco: use uma API representativa para validar a funcionalidade básica do gateway no Gerenciamento de API do Azure antes de recriar APIs do Gateway de API da Amazon.

• Importar no Gerenciamento de API do Azure: use o portal do Azure ou scripts para importar definições de OpenAPI do Gateway de API da Amazon ou sistemas de back-end como novas APIs no Azure API Management. Durante a importação, o Gerenciamento de API do Azure cria automaticamente a estrutura de APIs e operações. Se você tiver vários estágios de API no Gateway de API da Amazon, crie várias versões de API no Gerenciamento de API do Azure.

  Inicialmente, defina a URL de back-end para cada API para apontar para o back-end atual. (Por enquanto, o back-end atual ainda pode ser um ponto de extremidade da AWS ou um ponto de extremidade público.) Por exemplo, se o API Gateway da Amazon for encaminhado para o Lambda, você poderá definir o back-end do Gerenciamento de API do Azure como a API equivalente no API Gateway da Amazon ou para um aplicativo de funções equivalente do Azure, caso já tenha sido migrado. (Se você definir o back-end do Gerenciamento de API do Azure como a API equivalente no Gateway de API da Amazon, alterará essa configuração mais tarde se migrar a função Lambda para o Azure.) Se o back-end for um balanceador de carga ou ponto de extremidade do aplicativo AWS, o Gerenciamento de API do Azure poderá chamá-lo pela Internet.

  Se você tiver um grande número de APIs, poderá usar o Centro de API do Azure para catalogar as APIs migradas para o Gerenciamento de API do Azure ao longo do tempo e as que permanecem no Gateway de API da Amazon.

  Considere migrar ou refatorar serviços de back-end (por exemplo, como aplicativos de funções do Azure ou cargas de trabalho do AKS) depois de validar a infraestrutura. Consulte as diretrizes no hub de migração do Azure.

Configurar autenticação e autorização

• Assinaturas e produtos: se suas APIs exigirem chaves de API no Gateway de API da Amazon (por meio do x-api-key cabeçalho), decida como lidar com isso no Gerenciamento de API do Azure. Uma abordagem é tornar essas APIs acessíveis somente aos usuários que têm uma assinatura de um produto. Crie produtos iniciais no Gerenciamento de API do Azure, correspondendo um a um aos planos de uso do AWS ou reorganizados logicamente.

• Grupos de usuários: crie grupos de usuários no Gerenciamento de API do Azure para espelhar como você compartilha APIs com desenvolvedores.

• Valores Nomeados: Importe quaisquer valores de configuração (como endpoints ou chaves de API para serviços de back-end) que estavam em variáveis de estágio do Amazon API Gateway para os valores nomeados no Gerenciamento de API do Azure. Para valores confidenciais, use a integração do Azure Key Vault.

• Recuperação e validação de token: para validação JWT de solicitações de API, configure políticas de validação no Gerenciamento de API do Azure que autorizam o acesso à API. Inicialmente, você pode usar seu provedor de identidade existente (como o AWS Cognito) e considerar a migração ao longo do tempo para a ID do Microsoft Entra.

  Configure o gerenciador de credenciais no Gerenciamento de API do Azure para gerenciar tokens para back-ends do OAuth. Ou configure a lógica de recuperação de token usando políticas do repositório de snippets de política.

• Back-ends no Gerenciamento de API do Azure: configure back-ends no Gerenciamento de API do Azure para registrar cada serviço de back-end (com sua URL, credenciais e outras informações). Essa ação fornece um local central para atualização caso a URL do backend seja alterada. Por exemplo, se você inicialmente apontar para um ponto de extremidade da AWS, mas depois mudar para um back-end do Azure, poderá simplesmente atualizar a configuração do back-end no Gerenciamento de API do Azure.

• Verificações de paridade de recursos: examine a lista de recursos que cada API usa e verifique se eles são resolvidos.

  Por exemplo, teste APIs que lidam com cargas binárias (imagens e arquivos) ou cargas grandes. Verifique se o Gerenciamento de API do Azure está configurado com tempo limite, tamanho ou configurações de validação de conteúdo adequadas para esses cenários.

  O Gerenciamento de API do Azure trata todas as APIs importadas de forma bastante uniforme, de modo que as APIs HTTP do Gateway de API da Amazon (o tipo leve mais recente) versus AS APIs REST (o tipo clássico) sejam gerenciadas consistentemente no Gerenciamento de API do Azure. Diferenças, como a falta de planos de uso em APIs HTTP, tornam-se irrelevantes depois que as APIs estão no Gerenciamento de API do Azure. No entanto, é preciso garantir que quaisquer restrições específicas do Amazon API Gateway sejam tratadas.

Gerenciar a transformação e o mapeamento de política

Replique as configurações de API existentes como políticas de Gerenciamento de API do Azure quando aplicável, especialmente para autorização e compatibilidade com versões anteriores.

Mapeie a configuração do CORS no Gateway de API da Amazon para uma política CORS no Gerenciamento de API do Azure.

Manipular transformações (como mapeamento de esquema ou enriquecimento) caso a caso.

Ferramentas de IA, como o Microsoft Copilot no Azure no portal do Azure e servidores MCP para documentação do AWS e da Microsoft, podem ajudar no mapeamento de configuração ou em outra transformação. No entanto, espere realizar a configuração manual e a depuração de políticas no Azure API Management.

Configure a observabilidade

Para monitoramento inicial, configure o Azure Monitor para coletar métricas e logs de API. Mais soluções de monitoramento ou observabilidade, como Application Insights, podem ser adicionadas posteriormente.

Executar testes

Com as APIs configuradas no Gerenciamento de API do Azure, o teste completo é fundamental. Espere que essa fase seja iterativa.

• Teste funcional: para cada API, chame o novo ponto de extremidade do Gerenciamento de API do Azure (por meio do console de teste do portal do Azure ou ferramentas de cliente) e compare as respostas com o ponto de extremidade do Gateway de API da Amazon. Verifique se há códigos de status, cabeçalhos e corpo esperados. Se você encontrar diferenças, ajuste as políticas ou a configuração do Gerenciamento de API do Azure adequadamente.

  Observação

  Se a instância de Gerenciamento de API estiver em uma configuração de rede virtual interna, o console de teste não funcionará. Você pode testar APIs usando outras ferramentas de cliente implantadas na rede ou usando o portal do desenvolvedor do Gerenciamento de API (se você habilitá-la para sua instância).

• Teste de segurança: valide se a autenticação e a autorização da API estão funcionando. Por exemplo, apresente uma chave de assinatura ou JWT válida para o Gerenciamento de API do Azure. Verifique se o Gerenciamento de API do Azure aceita a solicitação e se as credenciais inválidas são rejeitadas com códigos de erro adequados. Os clientes que passam tokens para validação JWT podem precisar autenticar-se com um provedor de identidade diferente, caso você tenha configurado um durante a migração. Se você usar chaves de assinatura, teste com e sem a chave.

• Linha de base de desempenho: use uma ferramenta para simular a carga nos pontos de extremidade do Gerenciamento de API do Azure e verificar se eles podem lidar com a taxa de transferência esperada. Compare a latência de chamadas por meio do Gerenciamento de API do Azure com a latência por meio do Gateway de API da Amazon. O Gerenciamento de API do Azure na camada De desenvolvedor tem menos desempenho do que a camada Premium e a instância única, portanto, o teste de desempenho pesado pode aguardar até que você implante uma instância de Gerenciamento de API do Azure de camada Premium.

Iniciar a implantação de produção

Atualize para a camada Premium ou outra camada pronta para produção do Gerenciamento de API do Azure no ambiente de produção. Repita ou migre as configurações de importação e configuração da API que você criou em ambientes de pré-produção. Você pode usar processos de APIOps para publicar APIs e gerenciar configurações de API em ambientes.

Ensaie a substituição em um ambiente inferior ou com um subconjunto de tráfego. Por exemplo, selecione uma API não crítica e faça com que um aplicativo cliente mude para usar o endpoint do Azure. Essa prática pode revelar problemas do lado do cliente ou ajudar a validar seu processo de alteração de DNS. Se os consumidores de API forem internos, você poderá simular uma alteração editando arquivos de host ou usando uma zona DNS de teste para apontar o domínio para o Gerenciamento de API do Azure temporariamente.

• Mudança de DNS: a abordagem mais comum é mudar a entrada DNS do domínio personalizado do Amazon API Gateway para apontar para o novo endpoint do Azure. Por exemplo, se você mapeou seu nome de domínio api.example.com para o Amazon API Gateway, atualize seu registro CNAME ou A para apontar para o nome do host do Azure API Management ou para o domínio frontend (como o Application Gateway).

• Considerações de TTL (vida útil): reduza o TTL DNS de antemão para que os clientes assimilem as alterações rapidamente. Quando estiver pronto, altere o DNS. A propagação pode levar minutos a horas. Durante esse tempo, algum tráfego ainda pode ir para a AWS enquanto alguns vão para o Azure. Se você precisar de um corte imediato, poderá usar um método alternativo, como um proxy reverso.

• Métodos de substituição alternativos: às vezes, em vez de DNS, as organizações usam um proxy reverso ou uma inversão de gateway. Por exemplo, uma organização pode manter o DNS público igual, mas inicialmente ter o Gateway de Aplicativo encaminhando solicitações para o Gateway de API da Amazon (por meio de sua URL). Durante a inversão, a organização aponta internamente o Gateway de Aplicações para o Gerenciamento de API do Azure. Essa abordagem é mais complexa, mas pode conseguir uma mudança instantânea. Se você usar o Azure Front Door ou o Gerenciador de Tráfego, outro método é redistribuir gradualmente o tráfego de um back-end (AWS) para outro (Azure).

• Monitoramento durante a mudança: assim que a troca ocorrer, monitore de perto as solicitações para a API Management do Azure e o Gateway de API da Amazon. Monitore as métricas de Gerenciamento de API do Azure (solicitações, latência, CPU, memória de capacidade) em tempo real por meio do portal do Azure ou qualquer painel configurado. Use também o Azure Monitor para observar picos de erros, como respostas 4XX/5XX.

• Plano de reversão: decida sobre o que dispara uma reversão. Por exemplo, se a taxa de erros exceder um determinado percentual ou uma funcionalidade crítica for interrompida, você poderá reverter dentro de 30 minutos. Uma reversão significa desfazer qualquer opção que você fez. Por exemplo, se a mudança for DNS, reverta o registro DNS para apontar de volta para o Gateway de API da Amazon. Devido à propagação de DNS, a reversão pode levar algum tempo. O tempo de reversão destaca a importância de um baixo TTL e, possivelmente, de manter ambos os sistemas em execução. Se você usou um proxy reverso, volte para a AWS.

Desativar o Gateway de API da Amazon

Desativar o Gateway de API do Amazon após um período em que ele recebe tráfego zero e a instância de Gerenciamento de API do Azure atende aos critérios de validação. Normalmente, você executa ambos em paralelo (com o Azure levando todo o tráfego) por pelo menos um ciclo de negócios completo ou período de pico de tráfego para garantir que o novo sistema o manipule.

Otimização iterativa

Após a migração, concentre-se em otimizar a configuração do Gerenciamento de API iterativamente fechando lacunas de recursos e implementando as práticas recomendadas. Esse processo de melhoria iterativa garante que a carga de trabalho migrada atenda a todos os critérios de êxito estabelecidos durante a etapa de avaliação. Ele também garante que a carga de trabalho migrada siga as práticas recomendadas de arquitetura para o Gerenciamento de API.

Itere nas lacunas de funcionalidades

Alguns recursos do Gateway de API da Amazon não têm um mapeamento um-para-um no Gerenciamento de API do Azure e exigem soluções alternativas, conforme descrito anteriormente na seção Avaliação . Por exemplo:

• Firewall do aplicativo Web: o Gerenciamento de API do Azure não bloqueia automaticamente os conteúdos incorretos que o WAF da AWS bloqueia. Se você configurar o Firewall de Aplicativo Web do Azure, verifique se o Gerenciamento de API do Azure só está acessível por meio do WAF e se as regras do WAF replicam as restrições do WAF do AWS.

• Fluxos de eventos: se os alarmes ou eventos do CloudWatch estiverem vinculados ao Gateway de API da Amazon (por exemplo, em determinados padrões de erro), configure alertas equivalentes no Azure Monitor para Gerenciamento de API do Azure (por exemplo, um alerta sobre uma taxa 5XX do Gerenciamento de API do Azure).

• Automação: se você tiver pipelines de CI/CD (integração contínua e entrega contínua), integre o Gerenciamento de API do Azure a eles. Por exemplo, você pode armazenar suas configurações de Gerenciamento de API do Azure (APIs e políticas) no controle do código-fonte usando abordagens de infraestrutura como código. Essas abordagens podem incluir modelos do Azure Resource Manager, Bicep ou Terraform ou uma metodologia APIOps. Essa integração garante que as alterações futuras nas APIs possam ser implantadas de forma consistente com o controle de versão.

Implementar práticas recomendadas

Implemente iterativamente as práticas recomendadas, incluindo otimização de custos, proteção de segurança e melhorias operacionais. Examine e implemente as melhores práticas de arquitetura para o Gerenciamento de API do Azure nos pilares de confiabilidade, segurança, excelência operacional, gerenciamento de custos e desempenho. Resolva as recomendações do Assistente do Azure para sua instância de Gerenciamento de API do Azure.

Ao longo do tempo, adicione mais funcionalidades, como:

• Cache externo.
• Recursos de monitoramento além do Azure Monitor, como o Application Insights ou soluções que não são da Microsoft, como o Datadog.
• Políticas no Gerenciamento de API do Azure que não estão disponíveis no Gateway de API da Amazon.

Principais conclusões

A migração do Gateway de API da Amazon para o Azure requer um planejamento cuidadoso e execução sistemática para obter funcionalidades equivalentes ou abordagens alternativas. Os principais fatores de sucesso incluem:

• Avaliação completa: realize uma avaliação detalhada da configuração existente do Gateway de API da Amazon, incluindo todas as APIs, integrações de serviço e dependências. Identificar lacunas ou diferenças nos recursos entre o Gateway de API da Amazon e o Gerenciamento de API do Azure.

• Oportunidades de modernização: use a migração como uma oportunidade para modernizar ou migrar serviços de back-end ou melhorar o design da API.

• Preparação abrangente: prepare o ambiente do Azure, incluindo rede, segurança e configuração de infraestrutura. Documente todas as configurações e planeje todas as alterações necessárias nos serviços de back-end.

• Migração incremental: planeje uma abordagem de migração incremental, começando com APIs ou serviços menos críticos. Essa abordagem permite testar e validar a nova configuração antes que você se comprometa totalmente com a opção.

• Validação e teste: implemente processos abrangentes de teste e validação para garantir que a instância de Gerenciamento de API do Azure atenda a todos os requisitos funcionais e de desempenho. Esse esforço inclui testes de carga, testes de segurança e testes de aceitação do usuário.

• Monitoramento e observabilidade: configure o monitoramento e a observabilidade robustos para que a nova instância de Gerenciamento de API do Azure identifique e resolva rapidamente todos os problemas que surgirem durante ou após a migração.

• Otimização iterativa: após a migração, otimize continuamente a instalação do Gerenciamento de API do Azure resolvendo as lacunas de recursos e implementando as práticas recomendadas.