Migre da Akamai para a Azion

Uma configuração na Akamai distribui um site entre delivery properties, comportamentos de origem, Cloudlets, EdgeWorkers, dados do EdgeKV, políticas de segurança, zonas DNS, direcionamento de tráfego, armazenamento e streams de logs. Movê-la significa recriar cada um desses itens na Azion. Depois confirme que a property responde da mesma forma antes de qualquer mudança de hostname de produção.

Na Azion, uma aplicação e suas regras assumem a property: entrega, roteamento, cache e headers. Connectors alcançam as origens, e Functions executa o código dos EdgeWorkers. KV Store, Object Storage e SQL Database guardam os dados. Firewall filtra o tráfego, um workload atende o hostname e Edge DNS responde pela zona. Real-Time Metrics, Real-Time Events, Data Stream e Edge Pulse mostram o que acontece com cada requisição e cada visita.

Cada etapa deste guia move uma camada, na ordem em que uma migração acontece: inventário, a property, código e regras, dados, segurança, monitoramento e DNS. O DNS e o direcionamento de tráfego vêm por último, quando a entrega e a segurança respondem como esperado. Quando um downtime próximo de zero não é um requisito, migre em fases com janelas de manutenção. As gravações param durante cada passo, então os dados não precisam de sincronização paralela.

Os pré-requisitos e os procedimentos desta página mudam conforme a interface que você seleciona:

Pré-requisitos

• Uma conta Azion. Para abrir uma, cadastre-se no Azion Console. Para mais informações, consulte Crie uma conta.
• Acesso à conta Akamai, com suas properties, políticas de Cloudlets, EdgeWorkers, dados do EdgeKV, configurações de segurança e zonas DNS.
• Acesso aos registros DNS ou ao registrador de cada hostname que você move.
• curl e dig, para verificar as respostas e as respostas DNS.

Faça o inventário da conta Akamai

Mova uma property primeiro, e não a mais complexa do portfólio. Escolha uma que teste o caminho completo e ainda migre rápido. Uma boa primeira property tem um ou dois hostnames, algumas origens, regras de cache, redirecionamentos e headers. Ela também tem um Cloudlet ou um EdgeWorker e um destino de logs. Use-a para documentar o processo e depois mova regras mais complexas, mais EdgeWorkers, dados, monitoramento e segurança na mesma ordem.

Uma migração pode parecer completa quando a primeira requisição retorna 200 e ainda assim falhar depois. O comportamento do cache, a lógica de redirecionamento, o roteamento para a origem, os headers ou a aplicação das regras de segurança podem diferir da property original. Antes de criar qualquer coisa na Azion, liste do que a property depende:

• Properties ativas e versões de properties.
• Hostnames da property, edge hostnames, certificados e registros DNS.
• Servidores de origem, configurações de failover, health checks e padrões de shielding.
• Chaves de cache, TTLs, comportamento de conteúdo expirado, CP codes, cache tags e fluxos de purge.
• Regras, comportamentos, variáveis, critérios de correspondência e metadados avançados da property.
• Cloudlets, suas políticas, regras de correspondência e dependências de ativação.
• Bundles de EdgeWorkers, namespaces do EdgeKV e configuração de runtime.
• Políticas do App & API Protector, controles de bots, proteções de API e premissas do Prolexic.
• Zonas do Edge DNS, registros do DNS Manager e políticas do Global Traffic Management.
• Conteúdo do NetStorage, buckets de armazenamento de objetos e bancos de dados gerenciados.
• Streams do DataStream, dashboards do TrafficPeak, tags do mPulse, alertas e dependências de monitoramento externo.

Cada item da lista corresponde a uma etapa deste guia. A tabela em Mapeie cada produto da Akamai para a Azion indica o destino de cada um.

Mapeie cada produto da Akamai para a Azion

Todo produto da Akamai do inventário tem um destino na Azion. Encontre o produto na primeira coluna e mova-o com a etapa que indica seu destino. Um traço (-) na última coluna significa que a Azion não tem um equivalente direto.

A Azion possui um relatório SOC 2 Type 2 e um relatório SOC 3 e é PCI DSS 4.0.1 Level 1 Service Provider. Para as atestações, consulte SOC 2 e SOC 3 e Certificação PCI DSS.

Faça o deploy da property na Azion

Uma property da Akamai se torna uma aplicação e um workload na Azion. A aplicação guarda as regras, e cada servidor de origem se torna um connector. Uma regra com Set Connector envia as requisições para ele, e um workload atende a aplicação em um domínio.

As tarefas do dia a dia passam para Azion CLI:

Comece pelo connector para a origem da property:

Para declarar a property no código, escreva a aplicação em um arquivo azion.config.mjs. Este arquivo guarda uma configuração de cache com TTL de 3.600 segundos, aplicada a toda requisição. Uma segunda regra ignora o cache para /api/:

Bypass Cache requer Application Accelerator, que applicationAcceleratorEnabled ativa. Para enviar as requisições para a origem, adicione uma regra cujo comportamento é set_connector, com o nome ou o ID do connector em value. Execute azion config apply na pasta do projeto. O comando cria cada recurso e imprime seu ID. Para cada chave, consulte azion.config.js.

Quando a property atende um projeto de framework em um repositório do GitHub, faça o deploy do repositório. No Azion Console, acesse Create, selecione a aba Import from GitHub e selecione Connect with GitHub. Depois selecione o repositório e o preset: Next.js, Angular, Astro, Hexo, React ou Vue. Para os campos, consulte Importe um projeto do GitHub.

Com Azion CLI, execute azion link na raiz do projeto, selecione o preset e depois execute azion deploy. O preset vai em build.preset de um azion.config.js que importa defineConfig de @aziontech/config. O preset de um projeto Next.js é next, e o pacote azion de exemplos antigos está obsoleto. Instale esse pacote no projeto antes, com npm install -D @aziontech/config. Sem ele, a CLI falha com Failed to load configuration file. Para os comandos, consulte Primeiros passos com Azion CLI e azion deploy.

O deployment responde em um domínio de workload que a Azion atribui sob map.azionedge.net. Um workload novo pode levar vários minutos para atender seu primeiro deployment e responde 404 até lá. Envie uma requisição para o caminho raiz, com esse domínio no lugar de <your-workload-domain>:

A resposta traz o status, os headers e o corpo que a origem retorna para /. Envie a mesma requisição para cada rota crítica, como /health. Quando uma resposta diferir da Akamai, compare a versão ativa da property com as regras da aplicação e o connector. Para a cadeia completa, consulte Applications, Main Settings e Connectors.

Mova as variáveis de ambiente

Os EdgeWorkers leem a configuração de variáveis da property, do EdgeKV ou de outros armazenamentos, conforme a implementação. Na Azion, as variáveis pertencem à conta, até 100 delas, e uma função as lê com Azion.env.get(). Cada variável tem uma chave, um valor e uma flag que a marca como secret.

Depois altere o código que lê o valor:

Uma função em produção também lê uma variável como process.env.API_TOKEN. No azion dev, uma função lê o arquivo .env do projeto em vez das variáveis da conta. Se uma função informar que uma variável não foi encontrada, confirme que a variável existe na conta. Depois confirme que o código a lê com Azion.env.get().

Mova EdgeWorkers para Functions

Os EdgeWorkers executam JavaScript que personaliza requisições e respostas. Na Azion, esse código roda em Functions: tratamento de requisições, orquestração de APIs, personalização, redirecionamentos, autenticação e integrações. Uma função guarda o código, uma instância de função o executa em uma aplicação, e uma regra com Run Function decide quais requisições chegam até ela.

Uma função tem 512 MB de memória por isolate em todos os planos e nenhum cold start. Em uma função em produção, env é um objeto vazio, e ctx traz args e waitUntil. Um event handler do EdgeWorkers se torna um handler fetch que retorna uma resposta:

A função encaminha a requisição para a origem com o novo header. Para adicionar um header sem código, use Add Request Header em uma regra. Associe cada API do EdgeWorkers à sua substituta:

Se o código dos EdgeWorkers falhar na Azion, procure APIs de runtime da Akamai que permaneçam nele. Para as APIs de runtime, consulte Web APIs e Functions instances.

Recrie redirecionamentos e reescritas

A Akamai guarda os redirecionamentos no Edge Redirector Cloudlet, em comportamentos da property ou em EdgeWorkers. A Azion os guarda nas regras da aplicação, que você escreve no Azion Console, na API ou no azion.config.js. Mova os redirecionamentos simples para regras e mantenha Functions para a lógica que precisa de código, de uma consulta externa ou da validação de um token assinado.

Os critérios de uma regra selecionam as requisições, mas não capturam nada. Para reutilizar parte do caminho no destino, adicione Capture Match Groups antes do redirecionamento, na mesma regra. Capture Match Groups requer Application Accelerator na aplicação. O array é local, então só a regra que o captura pode lê-lo.

Para verificar o redirecionamento, requisite um caminho antigo:

A resposta traz 301 Moved Permanently e um header location que termina em /new/page. Uma regra nova pode levar alguns minutos para se propagar. Se o redirecionamento não disparar, teste a expressão regular e seus grupos de captura em caminhos reais.

Recrie headers personalizados

A Akamai altera headers com os comportamentos Modify Incoming Request Header e Modify Outgoing Response Header. A Azion os adiciona com regras em qualquer uma das fases. Add Request Header altera a requisição enviada à origem. O mesmo comportamento em uma regra da Response Phase altera a resposta enviada ao usuário.

Este azion.config.js adiciona dois headers de segurança a toda resposta da aplicação:

O valor tem o formato Name: value e pode trazer variáveis de regra, como ${uri}. Execute azion deploy e depois verifique uma resposta:

A resposta traz x-frame-options: SAMEORIGIN e x-content-type-options: nosniff. Se um header estiver faltando, verifique se uma regra na fase certa o adiciona. Para um header calculado por código, use uma função.

Converta as políticas de Cloudlets

Os Cloudlets guardam políticas de redirecionamentos, reescritas, segmentação, releases, balanceamento de carga e controle de requisições. A Azion não tem uma camada de Cloudlets. Cada política se torna uma regra, uma função, uma configuração do Load Balancer ou uma regra de firewall. Faça o inventário de cada política e depois converta-a com a etapa responsável pelo seu destino:

${device_group} nomeia um grupo da aba Device Groups da aplicação. Ele requer Application Accelerator, assim como Add Cookie. ${cookie_name} lê um cookie: substitua name pelo nome do cookie, como ${cookie_segment}. Para cada variável e comportamento, consulte Rules Engine para Applications.

Recrie as configurações de cache

Na Azion, uma configuração de cache define por quanto tempo uma resposta fica em cache e o que faz duas requisições compartilharem uma cópia em cache. Uma regra com Set Cache Policy aplica a configuração às requisições a que corresponde. A regra seleciona uma configuração, e a configuração guarda o TTL e a chave de cache.

Max Age tem padrão de 60 segundos. Um valor abaixo de 60 requer Application Accelerator, e uma configuração de cache com Tiered Cache ativado precisa de pelo menos 3 segundos e de Override cache behavior. Stale cache respeita o stale-while-revalidate que a origem envia, ou mantém uma janela de 300 segundos com Override cache behavior. Ele vem ativado por padrão no Azion Console e desativado na API e na CLI.

Para variar o cache por query string, cookie ou dispositivo, use Cache vary by Query String, Cache vary by Cookies e Cache vary by Devices. Eles requerem Application Accelerator na aplicação. Para os passos, consulte Configure o Advanced Cache Key e Variação de cache.

Para fazer purge de conteúdo em cache, envie uma requisição POST para o endpoint de purge do tipo correspondente:

Um purge por URL aceita até 50 itens, e um purge por wildcard aceita uma expressão. Só um purge por chave de cache, em /v4/workspace/purge/cachekey, alcança Tiered Cache com "layer": "tiered_cache". Com Azion CLI, azion purge --urls imprime Purge carried out successfully. Valide o fluxo de purge antes da virada. Para os tipos de purge, consulte Real-Time Purge.

Se menos respostas vierem do cache depois da migração, revise as configurações de cache, seus controles Cache vary by e Tiered Cache. A Azion faz purge por URL, chave de cache ou wildcard, então associe cada purge por CP code ou cache tag a um desses tipos.

Balanceie o tráfego entre origens

Na Azion, Load Balancer é um módulo de um connector, não um recurso separado. Um connector do tipo http guarda cada origem como um endereço, até 15 endereços com Load Balancer ativado e um endereço sem ele. Uma regra com Set Connector envia as requisições da aplicação para o connector.

Nenhum método direciona por localização, e não há afinidade por cookie. IP Hash associa cada endereço IP de cliente a um endereço. Cada endereço tem um Weight de 1 a 100, que define sua parcela do tráfego. IP Hash recusa endereços Backup, com 28005 na API.

Max Retries aceita de 0 a 20, Connection Timeout de 1 a 300 segundos e Read/Write Timeout de 1 a 600 segundos. Esses campos existem apenas com Load Balancer ativado. Quando você o ativa no Azion Console, o formulário preenche Round Robin, 3, 30 e 60. Os padrões da API são 0, 60 e 120.

Para os campos do connector, consulte Configurações de connectors. Para Origin Shield, consulte Origin IP ACL e HMAC.

Entregue imagens otimizadas

Image Processor substitui a parte de imagens do Image & Video Manager. Ele redimensiona, recorta, converte e aplica filtros a imagens sob demanda. Ele não armazena nada: lê a imagem de origem da origem da aplicação, que pode ser um bucket do Object Storage.

Image Processor funciona em dois passos: ative o módulo na aplicação e depois crie uma regra com o comportamento Optimize Images. Uma requisição que nenhuma regra desse tipo atende é entregue sem processamento.

Image Processor lê a transformação do parâmetro de query ims:

Image Processor converte para WebP quando o header Accept do cliente permite. AVIF precisa de ?ims=filters:format(avif) e de um cliente que aceite image/avif. Para cada parâmetro, consulte Parâmetros de URL. Para a configuração, consulte Configure Image Processor em uma aplicação.

Entregue mídia, downloads e transmissões ao vivo

Adaptive Media Delivery, Download Delivery, Dedicated Delivery e Media Services Live carregam tráfego com alto consumo de banda. Mova cada um conforme seu modelo de tráfego: mídia armazenável em cache, vídeo sob demanda, arquivos grandes ou transmissões ao vivo.

Live Ingest recebe a transmissão ao vivo do seu encoder em um connector do tipo live_ingest. O encoder envia por RTMP, com autenticação por usuário e senha. Live Ingest converte a transmissão para HLS, e uma aplicação a entrega aos espectadores por esse connector.

O connector traz um atributo, region: us-east-1, us-east-2, br-east-1, br-east-2 ou br-east-3. A Azion fornece um endpoint de ingestão primário e um de backup. Coloque-os em regiões diferentes, para que uma falha regional não interrompa a transmissão. O comportamento Enforce HLS cache aplica a política de cache que a Azion define para HLS ao vivo e requer Live Ingest.

Para as configurações do encoder e o checklist do evento, consulte Boas práticas de connectors. Para as regras de cache de HLS, consulte Implemente cache HLS para transmissões ao vivo.

Roteie APIs e chame modelos de IA

Os padrões de API Gateway e API Acceleration passam para uma aplicação. As regras roteiam os caminhos, Functions guarda a lógica da API e Firewall protege as rotas. Application Accelerator e Cache aceleram as respostas.

Esta função envia as requisições /api/ para uma origem de API, com um token de uma variável de ambiente. Todas as outras requisições vão para a origem principal, com seus headers inalterados:

AI Inference executa um catálogo de modelos open source. Uma função chama um modelo pelo seu ID com Azion.AI.run() e não precisa de credencial:

No azion dev, Azion.AI é undefined, então teste a chamada em uma função em produção. Para os campos da requisição, consulte Invocação de modelos.

Mova dados do EdgeKV para KV Store

KV Store guarda configurações, feature flags, metadados de sessão e estado leve, os mesmos usos que o EdgeKV atende.

O EdgeKV endereça um item por namespace, grupo e item. KV Store não tem grupos, então incorpore o grupo à chave, como features:checkout:

get() retorna texto por padrão e null para uma chave inexistente. Azion.KV.open() é o único ponto de entrada. O namespace precisa existir antes, ou open() lança NotFound.

O nome de um namespace aceita de 3 a 63 caracteres, diferencia maiúsculas de minúsculas e é permanente: um namespace não pode ser renomeado nem excluído. KV Store não tem importação em massa, e nenhuma API, comando da CLI ou tela do Console grava chaves. Para mover os dados:

1. Exporte da Akamai os namespaces, grupos, itens, metadados e regras de expiração.
2. Decida como cada grupo e item se torna uma chave e mantenha os prefixos e as convenções de nomes existentes sempre que possível.
3. Grave as chaves a partir de uma função em produção com kv.put().

A função grava uma chave no máximo uma vez por segundo. Um valor aceita até 25 MB, uma chave até 512 bytes e os metadados até 1.024 bytes. Associe cada expiração à opção expiration, em segundos Unix, ou a expirationTtl, em segundos com mínimo de 60. Uma gravação fica visível em todos os lugares em até 60 segundos.

Antes de mover o tráfego de produção, documente o que o código faz com uma chave inexistente e verifique a codificação dos valores, a serialização JSON e os dados binários. Teste os caminhos de leitura e de gravação. Se faltarem dados, exporte as chaves de novo e verifique o nome do namespace e a codificação. Para o cliente, consulte API de runtime do KV Store e Gerencie dados chave-valor a partir de uma função.

Mova o NetStorage para Object Storage

Object Storage guarda imagens, documentos, assets estáticos, mídia, downloads, uploads e arquivos gerados. Ele fala o protocolo S3, então ferramentas e SDKs S3 o alcançam com um novo endpoint, uma região e um par de chaves.

O par de chaves vem de uma credencial do Object Storage. Crie-a no Azion Console ou com uma requisição POST para https://api.azion.com/v4/workspace/storage/credentials. A secret_key só volta na resposta de criação. Para migrar, a credencial precisa de pelo menos listBuckets, listFiles e writeFiles, além de listAllBucketNames para listar os buckets.

Um script de migração em Node.js alcança Object Storage com o AWS SDK:

Quando a origem fala S3, copie os objetos com o s3cmd, o rclone ou a AWS CLI. Para fluxos específicos do NetStorage, exporte antes o conteúdo para uma pasta local ou um bucket intermediário. Crie o bucket de destino no Azion Console, na API ou na CLI: s3cmd mb e s3cmd rb são recusados com 403 AccessDenied. Um nome de bucket aceita de 6 a 63 caracteres, é único entre todas as contas e não pode começar com azion.

Para enviar uma pasta exportada com o s3cmd, configure-o para a Azion com s3cmd --configure -c ~/.s3cfg-azion. Informe o par de chaves, us-east-005 como Default Region e s3.us-east-005.azionstorage.net como S3 Endpoint. Depois sincronize a pasta:

Os objetos estão no bucket da Azion. Para verificar, execute s3cmd -c ~/.s3cfg-azion ls s3://azion-bucket/. Se o acesso for negado, verifique o par de chaves e o endpoint s3.us-east-005.azionstorage.net.

Azion Console recusa um upload individual acima de 300 MB, e a API e as ferramentas S3 não estão sujeitas a esse limite. Use o endpoint S3 apenas para gerenciar os objetos. Entregue-os aos usuários por um connector e uma aplicação, para que o cache, a segurança e o domínio de produção se apliquem. Para os passos, consulte Use ferramentas compatíveis com S3, Crie e modifique um bucket, Faça upload e download de objetos e Use um bucket como origem.

Mova bancos de dados gerenciados para SQL Database

SQL Database usa o dialeto SQLite e é totalmente compatível com ACID. Uma instância principal recebe todas as gravações, e réplicas de leitura respondem às leituras. SQL Database está em Preview em todos os planos.

Para mover um banco de dados:

1. Exporte do banco de dados de origem o schema, os dados, os índices, os usuários e os requisitos de extensões.
2. Crie o banco de dados na Azion.
3. Importe os dados e valide a contagem de linhas.
4. Atualize as configurações de conexão da aplicação, ou as funções que leem os dados.
5. Execute testes de leitura e de gravação no nível da aplicação antes da virada.

O EdgeSQL Shell lê uma tabela por vez de um servidor MySQL ou PostgreSQL ativo, com .import mysql ou .import postgres. O shell não inicia em uma instalação limpa, então verifique EdgeSQL Shell antes de depender dele. Você também pode enviar instruções SQL no array statements de uma requisição POST para https://api.azion.com/v4/workspace/sql/databases/<database-id>/query.

Uma função lê o banco de dados com Database.open() do global Azion.Sql. Um insert ou delete por essa conexão falha com attempt to write a readonly database. Para os caminhos de importação, consulte Importe dados para SQL Database. Para a API de runtime, consulte API de runtime do SQL Database.

Proteja a aplicação com WAF

Web Application Firewall assume as proteções gerenciadas do App & API Protector. Ele pontua as requisições em relação a oito famílias de ameaças. Um conjunto de regras WAF guarda uma sensibilidade para cada família, e uma regra de firewall o aplica com Set WAF.

mode é obrigatório em todo comportamento Set WAF e não tem padrão. Comece em Logging e compare os falsos positivos, as regras mais disparadas e as exceções de que a aplicação precisa. Depois mude para Blocking. No modo Blocking, uma requisição que o conjunto de regras bloqueia recebe 400.

As regras de política do App & API Protector, o Request Control Cloudlet e o Input Validation Cloudlet se tornam regras de firewall. As variáveis do firewall diferem das variáveis da aplicação: o caminho é ${request_uri}. Uma faixa de endereços vai em uma Network List, comparada com ${network}:

O critério ${network} requer Network Shield no firewall. Para proteger uma rota sem verificação de endereço, envie a regra para as regras de requisição do firewall:

A resposta traz "state": "pending" e a regra. Uma requisição correspondente recebe 403 com a página de erro Forbidden. Deny não aceita atributos. Para verificações que precisam de código ou de um serviço externo, execute uma função no firewall. Para mais detalhes, consulte Functions para Firewall e Conjuntos de regras WAF.

Conte com DDoS Protection

DDoS Protection assume o papel do Prolexic para o tráfego que a Azion atende. Ele está ativado em todo workload, sem nada para criar e nada para configurar. Ele mitiga ataques volumétricos, de protocolo e de camada de aplicação nas camadas 3, 4, 6 e 7. Exemplos são floods UDP e ICMP, SYN floods, fragmentação de pacotes, floods HTTP e slowloris.

Um firewall mostra a chave DDoS Protection Unmetered em Main Settings > Modules, sempre ativada. Na API, modules.ddos_protection é somente leitura. DDoS Protection não tem limiares, chaves por regra nem alertas. As camadas 3 e 4 não são medidas, e a mitigação na camada 7 pode gerar tráfego cobrável.

Para migrar do Prolexic:

1. Documente as premissas atuais do Prolexic, os prefixos protegidos, o modelo de roteamento, os processos de suporte e os caminhos de escalonamento.
2. Confirme o workload, o firewall e a configuração do Network Shield na Azion.
3. Recrie os controles da camada de aplicação como regras do firewall vinculado ao workload.
4. Confirme que Real-Time Metrics, Real-Time Events e Data Stream mostram o tráfego.
5. Tenha à mão os procedimentos de rollback e de escalonamento para a janela da virada.

O Security Response Team é um add-on dos suportes Enterprise e Mission-Critical. Network Shield é um módulo diferente do firewall. Ele compara o endereço do cliente com uma Network List de endereços IP, faixas CIDR, ASNs ou países, por meio de ${network}. Para os tipos de ataque, consulte Mitigação de ataques.

Recrie o gerenciamento de bots

Bot Manager substitui o Akamai Bot Manager, o Account Protector e o Content Protector. Ele pontua cada requisição e age conforme a pontuação. Bot Manager Lite é a função do Marketplace incluída em todos os planos, e Bot Manager completo está disponível no Enterprise.

Bot Manager Lite pontua uma requisição com 26 regras estáticas, em relação a um threshold cujo padrão é 30, e executa a ação deny por padrão. Ele também pode verificar o cliente em Network Lists de reputação.

Para configurar Bot Manager Lite no Azion Console:

O firewall pontua as requisições do workload. Para cada argumento, consulte Bot Manager Lite e Instale Bot Manager Lite. Para fazer o deploy a partir de um template, consulte Adicione Bot Manager Lite a um firewall.

Para bloquear um cliente pelo seu user agent, adicione uma regra de firewall:

${header_user_agent} requer o módulo WAF no firewall e suporta apenas matches e does not match. O firewall não tem comportamento de permissão. Para isentar um cliente, como um crawler de busca, adicione um critério does not match à regra de bloqueio ou ordene as regras. Um cliente pode enviar qualquer user agent, então verifique um bot legítimo de outra forma. Para verificar a regra:

A primeira resposta é 403, com a página de erro Forbidden. A segunda requisição recebe a resposta normal.

Recrie os rate limits

A Azion limita a taxa de requisições de duas formas, e cada uma atende uma necessidade diferente. Use o comportamento nativo Set Rate Limit de uma regra de firewall para limitar as requisições por segundo ou por minuto. Ele conta por endereço IP do cliente ou entre todos os clientes. Use a integração Upstash Rate Limiting, um rate limit com penalidade executado como função de firewall, para chaves personalizadas, janelas personalizadas ou um período de penalidade.

Use o rate limit nativo

Um comportamento Set Rate Limit conta as requisições a que sua regra corresponde. Os critérios da regra definem o escopo do limite, como o caminho com ${request_uri}. Rate Limit Type é Req/s ou Req/min, e Limit By é Client IP address ou Global. Average Rate Limit aceita no mínimo 1, e Maximum Burst Size aceita no mínimo 1 e se aplica apenas a Req/s. Nenhum comportamento pode vir depois de Set Rate Limit em uma regra. Uma regra cujos critérios unem vários caminhos com or compartilha uma contagem entre todos eles.

Uma requisição além da taxa e do burst recebe 429, com a página de erro intitulada Too Many Requests. Para saber como a taxa e o burst admitem requisições, consulte Set Rate Limit.

Use o rate limit com penalidade

A função Upstash Rate Limiting mantém seus contadores em um Upstash Global Database. Por isso, ela conta cada requisição em toda a rede, e não em cada data center. Uma requisição durante uma penalidade recebe 403 Forbidden. Uma requisição válida é contada, e a função retorna 429 Too Many Requests quando a contagem atinge o limite.

Para configurá-la no Azion Console:

A função conta as requisições a que a regra corresponde. Estes argumentos definem uma sliding window de 2 requisições a cada 20 segundos, da meia-noite ao meio-dia UTC, com uma penalidade de 45 segundos:

A chave une o prefixo e cada valor que os argumentos selecionam. Neste exemplo, ela é my_rate_limit + client IP + x-a-custom-header value + hostname, como my_rate_limit_127.0.0.1_Value_azion.com. Para a configuração completa, consulte Instale a integração Upstash Rate Limiting.

Reconstrua o monitoramento

A Azion divide a observabilidade em três produtos. Real-Time Metrics mostra agregados ao longo do tempo em gráficos, Real-Time Events responde a consultas sobre requisições individuais, e Data Stream envia os logs para destinos externos. Reconstrua-os antes da virada, para que a visibilidade da produção, a resolução de problemas e os relatórios de compliance continuem depois dela.

Real-Time Metrics

Os dashboards de Applications mostram:

• Requests: total de requisições e requisições por método e por esquema. Average Request Time é o tempo médio, em segundos, que a Azion leva para processar e responder a uma requisição.
• Status Codes: as respostas 2XX, 3XX, 4XX e 5XX. A tabela Requests by Status and Upstream Status distingue erros da Azion de erros da origem.
• Data Transferred: dados e largura de banda economizados e perdidos e Edge Offload.
• Cache: Requests Offloaded, Saved Requests e Missed Requests.

Para ler o status de cache das requisições, filtre um dashboard por Upstream Cache Status, cujos valores incluem HIT, MISS, STALE e EXPIRED. Para encontrar erros da origem, filtre por Upstream Status, que é 0 quando a origem não respondeu.

Para abrir os dashboards, acesse Azion Console > Real-Time Metrics. Ele abre em Build > Applications > Data Transferred, nos Last 5 minutes. Para restringir um dashboard a um workload, adicione o filtro Domain ou Workload. Para exportar um gráfico, abra seu menu More options e selecione Export CSV.

Para consultar os mesmos dados, envie uma consulta GraphQL para https://api.azion.com/v4/metrics/graphql:

A resposta lista o total de requisições por timestamp. Substitua as datas por um intervalo dentro do período de retenção, ou o array volta vazio. O dataset httpMetrics de consultas antigas ainda funciona, mas está obsoleto. Para cada campo, consulte Campos GraphQL do Real-Time Metrics. Para ler os dashboards, consulte Primeiros passos com Real-Time Metrics, Analise métricas e Dashboards personalizados do plugin Grafana.

Real-Time Events

Real-Time Events não precisa de configuração. Um evento pode ser consultado até 30 segundos depois de acontecer e fica disponível por 7 dias. Para uma retenção maior, use Data Stream. Suas fontes de dados são HTTP Requests, Functions, Functions Console, Image Processor, Tiered Cache, Edge DNS, Data Stream e Activity History. Os resultados do WAF são campos de HTTP Requests.

Para consultar os eventos no Azion Console:

A tabela de resultados lista os eventos. Selecione uma linha para abrir o registro completo.

Para consultar os mesmos dados, envie uma consulta GraphQL para https://api.azion.com/v4/events/graphql. O dataset workloadEvents guarda as requisições HTTP:

A resposta lista até 100 requisições, das mais recentes para as mais antigas. Substitua as datas por um intervalo dentro dos últimos 7 dias. upstreamResponseTime mostra - para uma resposta entregue a partir do cache. Para cada campo, consulte Campos GraphQL do Real-Time Events. Para os passos, consulte Primeiros passos com Real-Time Events, Investigue requisições com a API GraphQL e Leia um registro de evento.

Data Stream

Um stream envia uma fonte de dados para um destino:

• Armazenamento: Amazon S3, Azure Blob Storage e Azion Object Storage, pelo tipo S3.
• Monitoramento: Datadog, Splunk, Elasticsearch e Azure Monitor.
• Streaming: AWS Kinesis Data Firehose e Apache Kafka.
• Analytics: Google BigQuery.
• Segurança: IBM QRadar.
• Personalizado: Standard HTTP/HTTPS POST.

Um stream precisa de exatamente um entre sampling e um filtro de workload. Salvar um stream ativo com sampling desativa todos os outros streams da conta. Streams com filtro coexistem.

Se os logs não chegarem ao destino, verifique o status do stream, as credenciais do destino e as variáveis do template. Para um destino Object Storage, a credencial precisa de listAllBucketNames, listBuckets, listFiles e writeFiles, ou todo envio falha com 503. Para os campos, consulte Configurações do stream, Fontes de dados e variáveis e Configure o sampling.

Mova o mPulse para Edge Pulse

Edge Pulse mede a partir dos navegadores de visitantes reais, o papel que o mPulse cumpre. Uma tag JavaScript em cada página executa um teste e envia o resultado para a Azion. Um teste mede navegação, disponibilidade, latência e largura de banda.

Edge Pulse está ativo em todas as contas, e a tag não precisa de configuração. Nenhuma página do Azion Console mostra as medições em gráficos, e Real-Time Metrics e Data Stream não as trazem. Uma consulta em pulseEvents é a única forma de lê-las, e elas duram 7 dias. A tag não tem configurações e mede um visitante uma vez a cada 30 minutos.

Para mover o monitoramento:

1. Liste cada template de página, regra do gerenciador de tags ou shell de aplicação que carrega o mPulse.
2. Documente as métricas, as dimensões, os dashboards e os alertas que a equipe usa.
3. No Azion Console, acesse Products menu > Observe > Edge Pulse e copie a Default Tag. Copie a Pre-loading Tag quando a Content Security Policy da página bloquear JavaScript inline.
4. Cole a tag imediatamente antes do fechamento da tag body de cada página, manualmente ou por um sistema de gerenciamento de tags, e publique as páginas.

Cada página publicada agora mede seus visitantes. Para verificar se as medições chegam, calcule a média do tempo de carregamento por página:

O endpoint retorna 200, com um objeto para cada página com tag que teve visitas na janela. Uma janela sem medições retorna um array vazio. Substitua as datas por um intervalo dentro dos últimos 7 dias. Uma página com tag que tem visitas e nenhuma linha é uma página em que a tag não roda, porque a tag não informa erros.

Uma aplicação de página única é medida uma vez por carregamento completo da página. Reconstrua os dashboards e os alertas do mPulse como consultas em pulseEvents, em um dashboard personalizado ou em uma plataforma de observabilidade. Para os passos, consulte Primeiros passos com Edge Pulse, Como Edge Pulse funciona e Consulte as medições do Edge Pulse com GraphQL.

Prepare o certificado

Certificate Manager guarda os certificados que os workloads servem. Prepare o certificado antes de o hostname apontar para a Azion, para que os usuários acessem a property por HTTPS desde a primeira requisição.

Escolha o desafio do Let’s Encrypt conforme onde o DNS responde:

• HTTP-01 precisa que o hostname, e cada nome alternativo, já apontem para a Azion.
• DNS-01 funciona antes da migração. Em um provedor de DNS externo, adicione um CNAME de _acme-challenge.<domain> para <domain>.letsencrypt.azion.com. No Edge DNS, o registro é automático.

Para uma migração a partir da Akamai, use DNS-01.

Se o certificado não ficar ativo, leia seus campos status e status_detail. Para DNS-01, verifique o CNAME _acme-challenge. Confirme que o hostname está nos Domains do workload certo antes da mudança de DNS. Para as regras de emissão, consulte Emissão e renovação.

Mova zonas DNS para Edge DNS

Mover a zona para Edge DNS dá à Azion todos os registros do domínio, incluindo o apex. Toda zona usa os mesmos três nameservers, ns1.aziondns.net, ns2.aziondns.com e ns3.aziondns.org. Mova o DNS apenas depois que as aplicações, os workloads, os certificados e as regras de segurança responderem como esperado. Pule esta etapa quando mantiver o provedor de DNS atual e apontar apenas subdomínios.

Edge DNS suporta 11 tipos de registro: A, AAAA, ANAME, CAA, CNAME, DS, MX, NS, PTR, SRV e TXT. Um ANAME cria um alias do apex para um hostname da Azion, como o domínio do workload, e seu TTL precisa ser 20. Um CNAME guarda exatamente um valor e não pode ficar no apex. Edge DNS recusa outros tipos, como SOA.

Para dividir as respostas entre destinos, como o Global Traffic Management direciona o tráfego, use registros ponderados. Com Policy Type Weighted, vários registros compartilham um nome e um tipo, cada um com um Weight de 0 a 255. Cada resposta traz um registro, escolhido na proporção do seu peso. A política de um registro é Simple ou Weighted.

Antes da janela da virada, exporte da Akamai as zonas, os registros, os TTLs, as configurações de DNSSEC e as regras de direcionamento de tráfego e reduza os TTLs. Com o DNSSEC ativado, Edge DNS mostra quatro valores DS para adicionar no registrador, que pode levar até 48 horas para publicá-los. Para os passos, consulte DNSSEC.

Para verificar a zona, consulte os nameservers e os registros:

O primeiro comando lista os três nameservers da Azion assim que a mudança no registrador se propaga. O segundo mostra a resposta do Edge DNS antes que a mudança chegue a todos os resolvers. Não consulte um nome novo antes de o registro dele existir: Edge DNS mantém a resposta negativa em cache por uma hora.

Aponte o domínio para o workload

A mudança de DNS é a virada: assim que o hostname resolve para o workload, os usuários acessam a property pela Azion. Trate-a como uma transição controlada. Ela afeta os usuários, os rankings de busca, a cobertura do certificado e a disponibilidade. Antes da virada, confirme que:

• O certificado está ativo.
• O hostname está nos Domains do workload.
• Os registros DNS estão prontos.
• As rotas críticas e os redirecionamentos respondem como esperado no domínio do workload. Para testá-los com o hostname real antes, consulte Teste uma aplicação pelo arquivo hosts.
• O firewall está vinculado ao workload.
• O monitoramento está pronto para acompanhar o tráfego depois da virada.

Aponte cada nome com o registro que sua zona permite:

Para verificar um CNAME e a resposta:

A primeira resposta é o domínio do workload, como xxxxxxxxxx.map.azionedge.net. A segunda é a resposta da property pela Azion. Se o tráfego não migrar, verifique os TTLs, os registros CNAME, os nameservers e o hostname no workload. Depois da virada, acompanhe Real-Time Metrics e Real-Time Events e o Upstream Status da origem.

Para as configurações do domínio personalizado no Console, consulte Aponte um domínio para um workload e Workloads. Para mover os nameservers, consulte Migre os nameservers para a Azion.

Próximos passos