Migre da Vercel para a Azion

Um projeto na Vercel guarda seu comportamento em vários lugares: configurações de build, vercel.json, funções de servidor, stores do Blob, Edge Config, regras de firewall e um domínio de produção. Migrá-lo significa recriar cada parte na Azion e confirmar que o projeto responde corretamente antes da mudança do domínio.

Na Azion, uma aplicação e suas regras assumem a entrega, o roteamento e o cache. Functions executa as rotas de API e o código de servidor, e AI Inference executa modelos. KV Store recebe os dados do Edge Config, e Object Storage recebe os arquivos do Blob. Firewall filtra as requisições, um workload atende o domínio e Edge DNS pode hospedar a zona. Real-Time Metrics, Real-Time Events e Data Stream informam sobre o tráfego.

As etapas abaixo seguem a ordem em que uma migração acontece: inventário, deployment, código e regras, dados, segurança, monitoramento e DNS. A maior parte do código migra com mudanças pontuais: como uma função lê uma variável, como abre o armazenamento e como chama um modelo. 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 janela, então os dados não precisam ficar sincronizados entre duas plataformas.

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, como descreve Crie uma conta.
• Acesso ao projeto da Vercel: seu repositório, suas configurações e suas variáveis de ambiente.
• Acesso aos registros DNS ou ao registrador de cada domínio que você move.
• curl e dig, para verificar as respostas HTTP e as respostas DNS.

Faça o inventário do projeto da Vercel

Comece por um único projeto que teste o caminho completo e ainda migre rápido. Um bom primeiro projeto tem um domínio parecido com o de produção, algumas rotas, redirecionamentos e headers e uma função. Ele também tem um store do Blob, um store do Edge Config e um fluxo de analytics. Registre cada passo durante o processo e depois repita a mesma ordem nos outros projetos. Comprove que o primeiro deployment faz o build e roda na Azion antes de mover seus domínios, seu armazenamento ou seu firewall.

Antes de criar qualquer coisa na Azion, liste o que o projeto usa:

• Projetos, equipes, deployments de produção e preview deployments.
• Comandos de build, diretórios de saída, presets de framework e comandos de instalação.
• vercel.json, a configuração do framework, o middleware e as definições de rotas.
• Variáveis de ambiente de produção, preview e desenvolvimento.
• Rotas de API, server actions, funções e workloads do Fluid Compute.
• Redirecionamentos, reescritas, headers, comportamento do cache e configurações de otimização de imagens.
• Rotas de IA, provedores de modelos e configurações do AI Gateway.
• Stores do Blob, stores do Edge Config, feature flags e experimentos.
• Regras de firewall, controles de WAF, rate limits, proteções contra bots e controles de acesso a deployments.
• SAML Single Sign-On e as funções de equipe que dependem dele.
• Dashboards de observabilidade, Speed Insights, Web Analytics, alertas, fluxos de logs e integrações do Marketplace.
• Domínios, registros DNS, nameservers e o status de cada certificado.

Cada item tem uma etapa própria nesta página. Mapeie cada produto da Vercel para a Azion indica o destino de cada um.

Mapeie cada produto da Vercel para a Azion

Encontre cada item do inventário na primeira coluna. A última coluna indica o destino na Azion, e a etapa com o nome desse destino o move. Todo produto da Vercel da lista tem um destino, então nenhuma linha traz um traço.

Para verificar uma função antes que ela receba tráfego, Preview deployment a executa contra uma requisição simulada no editor de código do Azion Console. Ele testa uma função e não cria um ambiente separado para cada mudança.

Faça o deploy do projeto na Azion

Na Azion, um projeto da Vercel se torna uma aplicação, e um workload atende essa aplicação em um domínio. A Vercel lê a configuração de build do vercel.json, da configuração do framework e das configurações do projeto. A Azion a lê do azion.config.js, que alguns presets chamam de azion.config.mjs ou azion.config.cjs.

A Azion suporta 19 frameworks e 5 presets genéricos. Nenhuma interface detecta o framework sozinha: Azion Console oferece seis presets para escolher, e Azion CLI lista os presets em um seletor.

A Azion dá ao workload um domínio sob map.azionedge.net. Teste o projeto nele antes de mover qualquer domínio de produção. Requisite o caminho raiz, com o domínio do workload no lugar de <your-workload-domain>:

A resposta traz o código de status, os headers e o corpo que o projeto serve para /. Repita a requisição para cada rota importante, como o caminho de health check de uma API:

Até que o vínculo com a aplicação se propague, um workload novo responde com um 404 provisório. Isso pode levar vários minutos, e nenhuma duração é garantida. Envie a requisição de novo até que a resposta venha do projeto.

Se o build falhar na Azion, compare o preset com o framework do projeto da Vercel. Depois verifique build.preset, build.entry e build.bundler no azion.config.js, além do comando de instalação e dos scripts do pacote. O bloco build não tem campo para um comando de build.

Mova as variáveis de ambiente

Um projeto lê de suas variáveis chaves de API, credenciais de banco de dados, secrets de autenticação, endpoints de terceiros, tokens de provedores de IA e feature flags. Quando uma delas falta na Azion, o deployment ainda tem sucesso, e o projeto falha em tempo de execução.

Reúna todas as variáveis antes de mudar qualquer código. Na Vercel, elas vêm destes lugares:

• As configurações de ambiente do projeto.
• Variáveis gerenciadas com a Vercel CLI.
• Os arquivos .env do framework usados no desenvolvimento local.
• Chaves de provedores de IA e configurações do gateway de modelos.
• Tokens do Blob e credenciais de armazenamento.
• IDs, tokens e chaves do Edge Config.
• O ambiente de CI/CD.
• Configurações escritas no código-fonte.

A Azion armazena as variáveis na conta, até 100 delas. Cada uma tem uma chave, um valor e uma flag que a marca como secret. Uma função lê uma variável com Azion.env.get().

Depois altere o código que lê cada variável:

Uma função em produção também aceita process.env.API_KEY. No azion dev, uma função lê o arquivo .env do projeto em vez das variáveis da conta. Sem um arquivo .env, ela lê todo o ambiente do shell. Se uma função informar que uma variável não foi encontrada, confirme que a conta a guarda e que o código a lê com Azion.env.get(). Feature flags e configurações guardadas no Edge Config vão para KV Store, em Mova dados do Edge Config para KV Store.

Mova rotas de API e funções de servidor

Rotas de API, server actions, webhooks, autenticação, personalização, orquestração de IA e chamadas de backend costumam ficar em Vercel Functions e Fluid Compute. Na Azion, esse código roda em Functions. Uma função guarda o código, uma instância de função o executa em uma aplicação, e uma regra escolhe as requisições que chegam até ela.

Em uma função em produção, env é um objeto vazio, e ctx traz args e waitUntil. O handler lê o corpo do Request e retorna um Response:

A Vercel associa uma requisição a uma função pelo caminho do arquivo, como app/api/users/[id]/route.ts ou pages/api/users/[id].ts. Na Azion, quem faz essa associação é uma regra da aplicação. A regra abaixo envia cada requisição GET para /api/users/<id> a uma instância de função:

Run Function (run_function) recebe o ID da instância, não o ID da função. A aplicação precisa de Application Accelerator e Functions ativados, e uma aplicação nova já vem com Functions ativado. Para o comportamento, consulte Run Function.

Uma requisição que corresponde à regra agora executa a função. Se uma rota de API falhar na Azion, confirme que o handler é fetch(request, env, ctx). Ele precisa ler a requisição com Web APIs padrão, não com helpers do runtime da Vercel.

Recrie redirecionamentos e reescritas

Redirecionamentos mantêm funcionando rankings de busca, links de campanhas, backlinks e favoritos, e um redirecionamento quebrado perde tráfego. A Vercel define o roteamento nas rotas do framework, no middleware, no vercel.json, nas configurações do projeto e no comportamento da CDN. A Azion guarda redirecionamentos e reescritas nas regras da aplicação, que Azion Console, a API, a CLI e o azion.config.js gravam. Cada regra une critérios a comportamentos e pertence à Request Phase ou à Response Phase.

Esta entrada do vercel.json move todo caminho sob /old-blog/ para o mesmo caminho sob /blog/, com um redirecionamento permanente:

Um critério apenas seleciona as requisições e não captura nada. A captura é tarefa do capture_match_groups, e o redirecionamento é o redirect_to_301. Para levar parte do caminho antigo ao destino, coloque um comportamento Capture Match Groups antes do redirecionamento, na mesma regra. Esse comportamento requer Application Accelerator na aplicação. O array capturado é local à sua regra, então nenhuma outra regra pode lê-lo. Para cada argumento, consulte Capture Match Groups e Redirect To.

A regra da Azion corresponde ao caminho antigo, captura o restante dele em capture e redireciona com 301 para o novo caminho:

Para verificar o redirecionamento, requisite um caminho antigo:

A resposta é 301 Moved Permanently, com um header location que termina em /blog/post. Um caminho aninhado como /old-blog/a/b redireciona para /blog/a/b. Uma regra nova pode levar alguns minutos para se propagar. Diante de uma resposta inesperada, aguarde e tente de novo antes de diagnosticar.

Para servir outro caminho sem redirecionamento, use Rewrite Request com as mesmas capturas. Mova cada rota restante da mesma forma:

• Converta cada padrão de rota da Vercel em critérios e expressões regulares do Rules Engine.
• Mova os redirecionamentos simples para regras.
• Use Functions para reescritas dinâmicas, autenticação, URLs assinadas e consultas externas.
• Teste barras finais, prefixos de idioma e caminhos canônicos.
• Antes da virada, compare os headers de cache e os redirecionamentos de que o ranking de busca depende.

Em mudanças que afetam a busca, prefira redirecionamentos permanentes e evite cadeias de redirecionamento. Quando um redirecionamento ou uma reescrita se comporta diferente da rota da Vercel, teste os grupos de captura e os critérios em que o padrão se transformou.

Recrie headers personalizados

Headers controlam o cache, a segurança e o comportamento do navegador. Na Vercel, as rotas adicionam headers de requisição ou de resposta. Na Azion, Add Request Header altera a requisição enviada à origem. Add Response Header, em uma regra da Response Phase, altera a resposta enviada ao usuário.

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

Cada valor tem o formato Name: value. Azion Console recusa qualquer outro formato com Header must follow the header-name: value format. Um valor também pode trazer uma variável de regra, como X-Docs-Uri: ${uri}, que se expande em tempo de execução. Os headers só chegam a um domínio por meio de um workload que atende a aplicação. Execute azion deploy e depois verifique uma resposta:

A resposta traz x-frame-options: SAMEORIGIN e x-content-type-options: nosniff. Um 404 que a Azion gera sem origem não traz nenhum dos dois headers.

Recrie as configurações de cache

Um projeto da Vercel pode misturar cache da CDN, configurações de cache do framework, renderização dinâmica, geração estática e comportamento por rota. Na Azion, uma configuração de cache guarda o TTL e a chave de cache. Uma regra com Set Cache Policy aplica a configuração às requisições a que corresponde. Toda configuração de cache pertence a uma aplicação, então cada chamada que cria ou altera uma configuração indica essa aplicação.

O TTL é o Max Age de cada configuração de cache, de 0 a 31.536.000 segundos, com padrão de 60. Sem Application Accelerator na aplicação, um valor abaixo de 60 é recusado com 21021. Com Tiered Cache ativado, uma configuração de cache precisa de Override cache behavior e de pelo menos 3 segundos. 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 no Azion Console e desativado na API e na CLI.

Crie a configuração de cache

A configuração dynamic-cache desta seção mantém uma cópia no navegador por 300 segundos e no cache da Azion por 3.600 segundos. Tiered Cache está ativado.

Aplique a configuração de cache a um caminho

Uma configuração de cache não tem efeito até que uma regra a indique com Set Cache Policy. A regra desta seção aplica dynamic-cache a todo caminho sob /products/.

A Azion se recusa a excluir uma configuração de cache enquanto uma regra a aplica, com 400 e o código 21014. Altere ou exclua a regra primeiro.

Para variar o cache por query string, cookie ou dispositivo, use os controles Cache vary by da configuração de cache. Cache vary by Devices com o comportamento Allowlist mantém uma cópia para cada grupo de dispositivos que você seleciona na aba Device Groups da aplicação. Os três controles requerem Application Accelerator.

Faça purge de conteúdo em cache

Um novo deploy invalida o cache da Vercel. Na Azion, Real-Time Purge remove objetos antes do fim do TTL, por uma lista de URLs, uma lista de chaves de cache ou uma expressão wildcard. Um purge por URL aceita até 50 itens, e um purge por wildcard aceita uma expressão por requisição. Um item de purge cujo domínio está fora da sua conta é recusado com 400 e o código 30003.

Purge é um endpoint de nível superior, não aninhado em applications. Só um purge por chave de cache, em /v4/workspace/purge/cachekey, alcança Tiered Cache com "layer": "tiered_cache". Um purge por URL ou wildcard com essa camada falha com 30001. Quando o conteúdo em cache se comportar diferente da Vercel depois da migração, compare os TTLs, a chave de cache e as regras com o projeto da Vercel.

Entregue imagens otimizadas

A Vercel transforma uma imagem por uma URL que o framework gera. Na Azion, Image Processor transforma uma imagem quando a requisição traz o parâmetro de query ims. Ele redimensiona, recorta, encaixa, preenche, rotaciona, aplica marca d’água, define a qualidade e converte o formato. Ele não armazena nada: a imagem de origem vem da origem da aplicação, um servidor HTTP ou um bucket do Object Storage.

A primeira linha abaixo é uma URL gerada pelo framework, cujo padrão varia conforme o framework. A segunda pede ao Image Processor a mesma imagem com 1.200 pixels de largura. A terceira também traz a qualidade, como faz q=75:

Image Processor entrega WebP quando o header Accept do navegador 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 do Image Processor.

Image Processor atua apenas em uma requisição a que uma regra com Optimize Images corresponde, e entrega qualquer outra requisição sem processamento. Uma regra da Request Phase com ${uri} matches \.(jpg|jpeg|gif|bmp|png|ico|webp|avif) cobre os arquivos de imagem comuns. Para manter em cache uma cópia para cada valor de ims, ative Application Accelerator e varie o cache por query string. Para a regra e a chave de cache, consulte Primeiros passos com Image Processor. Para uma aplicação que já recebe tráfego, consulte Configure Image Processor em uma aplicação.

Antes da virada, requisite algumas URLs de imagem típicas. Se uma imagem voltar sem transformação, confirme que Image Processor está ativado, que a regra corresponde e que a URL traz ims.

Mova rotas de IA para AI Inference

Uma rota de IA na Vercel mistura código da aplicação, chamadas a modelos, streaming, chamadas de ferramentas, roteamento entre provedores, rastreamento de uso e observabilidade. Na Azion, uma função faz a chamada ao modelo, seja para AI Inference ou para um provedor externo. As credenciais dos provedores passam para variáveis de ambiente.

AI Inference executa um catálogo de modelos open source: large language models, vision language models, um modelo de embedding e um reranker. Um modelo não é um objeto que você cria, e a Azion não hospeda um endpoint de inferência para ele. Uma função chama um modelo pelo seu ID com Azion.AI.run(), sem 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 e a API de runtime de IA.

Uma rota que mantém um provedor externo encaminha o corpo da requisição e retorna a resposta do provedor. Esta função lê a chave do provedor de uma variável:

Para um endpoint /v1/chat/completions compatível com OpenAI no AI Inference, faça o deploy do template AI Inference Starter Kit. Ele cria uma aplicação e uma função que atendem esse endpoint. Acesse Azion Console > Create, selecione o template e selecione Deploy. Azion CLI não tem flag de template.

Para mover cada rota de IA:

1. Registre cada modelo, provedor, rota e fallback que o projeto usa.
2. Mova as credenciais dos provedores para variáveis de ambiente.
3. Para cada rota, decida se a inferência roda no AI Inference ou em um provedor externo.
4. Reescreva cada rota como uma função e roteie um caminho para ela com uma regra, como em Mova rotas de API e funções de servidor.
5. Recrie a observabilidade de IA em Real-Time Events, Real-Time Metrics e Data Stream.
6. Teste respostas em streaming, timeouts e o tratamento de erros.

Mova dados do Edge Config para KV Store

O Edge Config costuma guardar feature flags, experimentos, redirecionamentos, configurações e outros dados que um projeto lê com frequência. KV Store guarda pares chave-valor em namespaces e cobre esses usos, além de estado de sessão e outros estados leves. Uma função o alcança por Azion.KV, um global do runtime que não precisa de linha de import.

O código que lia o Edge Config passa a abrir um namespace:

Azion.KV.open() é o único ponto de entrada e é assíncrono. O namespace precisa existir antes, ou open() lança NotFound. get() retorna null para uma chave inexistente, assim como para uma chave expirada.

KV Store não tem tela no Azion Console nem comando na Azion CLI, então o namespace é criado pela API em todas as interfaces. O nome aceita de 3 a 63 caracteres e diferencia maiúsculas de minúsculas. Nenhuma interface renomeia ou exclui um namespace, então defina o nome antes.

KV Store não tem importação em massa, e nenhuma chamada de API, comando da CLI ou tela do Console lê ou grava chaves. Uma função em produção as grava com kv.put(). Para mover os dados:

1. Exporte do Edge Config as chaves, os valores, os metadados e os valores por ambiente.
2. Mantenha os prefixos das chaves e as convenções de nomes sempre que possível.
3. Grave cada chave a partir de uma função em produção com kv.put().
4. Documente o que o código faz quando uma chave não existe.
5. Teste cada caminho de leitura antes que o tráfego de produção chegue à Azion.
6. Confirme que os valores mantêm sua codificação e sua serialização JSON.
7. Recrie qualquer fluxo de flags ou de experimentos que dependia de ferramentas da Vercel.

A função grava a mesma 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. Uma expiração vai na opção expiration, em segundos Unix, ou em expirationTtl, em segundos com mínimo de 60. Uma gravação fica visível em todos os lugares em até 60 segundos, ou dentro do cacheTtl da leitura. Se faltarem dados depois da migração, grave as chaves de novo, verifique o nome do namespace e teste os valores padrão.

Mova arquivos do Blob para Object Storage

O Vercel Blob guarda arquivos como imagens, documentos, vídeos e uploads. Object Storage os guarda como objetos em buckets e fala o protocolo S3. Ferramentas S3, a API, Azion CLI e a API de runtime de uma função o alcançam. O gerenciamento de objetos passa pelo endpoint S3 s3.us-east-005.azionstorage.net, na região us-east-005.

Uma função que gravava com o SDK do Blob passa a gravar com a classe Storage da API de runtime do Object Storage. O construtor recebe o nome do bucket e nenhum token. put recebe um ArrayBuffer ou um ReadableStream, não uma string:

No azion dev, o módulo guarda os objetos no disco local e se comporta de outra forma, então teste as chamadas de armazenamento em uma função em produção.

Um script de migração em Node.js alcança o endpoint S3 com qualquer SDK S3, informando o endpoint, a região e um par de chaves:

O par de chaves vem de uma credencial do Object Storage, criada no Azion Console ou com uma requisição POST para https://api.azion.com/v4/workspace/storage/credentials. A secret_key só aparece na resposta de criação. Uma migração precisa de listBuckets, listFiles e writeFiles na credencial, além de listAllBucketNames para listar os buckets. Ferramentas compatíveis com S3 como s3cmd, rclone e a AWS CLI fazem a cópia em massa. Para as operações S3 que Object Storage aceita, e a forma s3cmd de cada uma, consulte Compatibilidade com S3.

Crie o bucket de destino antes de uma cópia em massa, 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.

O acesso do bucket aos workloads é read_only, read_write ou restricted, e uma credencial funciona de forma independente dele. Um arquivo que a Vercel mantinha privado atrás de um token ou de um padrão de URL depende do nível de acesso do seu bucket e da lógica da aplicação. Os usuários recebem os objetos por uma aplicação e um connector, não pelo endpoint S3. Esse caminho coloca o cache, as regras de firewall e o domínio de produção na frente dos arquivos. Para conectar o bucket, consulte Use um bucket como origem. Se faltarem arquivos depois da migração, exporte-os de novo e verifique as chaves dos objetos e o nível de acesso do bucket.

Proteja a aplicação com WAF

Web Application Firewall (WAF) pontua as requisições em relação a oito famílias de ameaças: cross-site scripting, directory traversal, evading tricks, file upload, identified attack, remote file inclusion, SQL injection e unwanted access. Um conjunto de regras WAF guarda uma sensibilidade para cada família, e uma regra de firewall o aplica com Set WAF. O workload faz o deploy do firewall junto com a aplicação, e no Azion Console as Deployment Settings do workload o selecionam.

mode é obrigatório em todo comportamento Set WAF e não tem padrão. Comece em Logging para verificar o que o conjunto de regras bloquearia e depois mude para Blocking. No modo Blocking, uma requisição que o conjunto de regras bloqueia recebe 400. Antes de bloquear, compare os falsos positivos, as regras que mais disparam e as exceções de que a aplicação precisa. Para evitar que uma requisição legítima corresponda, adicione uma exceção de WAF ou use a aba Tuning.

Uma regra de proteção de deployment da Vercel se torna uma regra de firewall que nega requisições de fora de uma rede aprovada. As variáveis do firewall diferem das variáveis da aplicação: o caminho é ${request_uri}, e uma faixa de endereços vai em uma Network List comparada com ${network}. Esta regra nega /admin a qualquer cliente fora de uma Network List que contém 10.0.0.0/8:

Uma segunda regra com ${request_uri} starts with /preview/ protege os caminhos de preview da mesma forma. O critério ${network} requer Network Shield no firewall. Para escrever as regras, consulte Crie uma regra de firewall. Se uma regra bloquear usuários válidos, volte o conjunto de regras para Logging, compare os eventos e ajuste os critérios.

Conte com DDoS Protection

DDoS Protection cobre todo workload, sem nada para criar e nada para configurar. Ele assume a mitigação de DDoS do Vercel Platform Security. Ele mitiga ataques volumétricos, de protocolo e de camada de aplicação nas camadas 3, 4, 6 e 7, como floods UDP e ICMP, SYN floods, fragmentação de pacotes, floods HTTP e slowloris.

Todo firewall mostra a chave DDoS Protection Unmetered em Main Settings > Modules, sempre ativada, e modules.ddos_protection é somente leitura na API. DDoS Protection não tem limiares, chaves por regra nem alertas. Para uma mitigação direcionada, escreva regras personalizadas no firewall vinculado ao workload. O Security Response Team é um add-on dos suportes Enterprise e Mission-Critical. Para os tipos de ataque, consulte Mitigação de ataques.

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 do critério ${network}. Use-o para permitir ou bloquear conjuntos de clientes, restringir países ou aplicar rate limit a um conjunto de clientes. Para a configuração, consulte Primeiros passos com Network Shield.

Recrie o gerenciamento de bots

Vercel Bot Management e BotID passam para Bot Manager, que 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 sua ação padrão é deny. Ele também pode verificar o cliente em Network Lists de reputação. Os níveis de tolerância pertencem às regras dinâmicas do Bot Manager completo, que Bot Manager Lite não tem.

Para configurar Bot Manager Lite no Azion Console:

O firewall pontua cada requisição do workload. Para cada argumento, consulte Instale Bot Manager Lite e Bot Manager Lite. Para saber como uma função roda em um firewall, consulte Functions para Firewall. A integração Radware Bot Manager adiciona proteção contra bots de terceiros.

Uma regra de firewall também bloqueia um cliente pelo seu user agent:

${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, 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 resposta é 403, com a página de erro Forbidden. Uma requisição com o user agent de um navegador recebe a resposta normal.

Recrie os rate limits

A Azion limita a taxa de requisições de duas formas, e cada uma cobre uma parte diferente dos controles de taxa do Vercel Firewall. O comportamento nativo Set Rate Limit de uma regra de firewall limita as requisições por segundo ou por minuto. Ele conta por endereço IP do cliente ou entre todos os clientes. Para chaves personalizadas, janelas personalizadas ou um período de penalidade, use a integração Upstash Rate Limiting. Ela é um rate limit com penalidade executado como função de firewall.

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 um caminho em ${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. 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. Critérios que unem vários caminhos com or compartilham uma contagem entre todos eles.

Uma requisição além da taxa e do burst recebe 429, com a página de erro 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 guarda 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. Um cliente em penalidade recebe 403 Forbidden. Caso contrário, a função conta a requisição e 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.

Mova o acesso à conta

Uma equipe da Vercel que entra por SAML Single Sign-On mantém esse padrão na Azion com Single Sign-On e um provedor de identidade externo. A Azion documenta apps SAML para Microsoft Entra, Google e Okta como provedores de identidade. O SSO para membros da equipe precisa de um serviço de suporte Enterprise ou Mission-Critical, e apenas um Account Owner o configura.

Antes da migração, registre as configurações do provedor de identidade, os grupos, os acessos de usuários e os runbooks que dependem deles. Depois mova o acesso:

1. Registre cada provedor de identidade e seus metadados SAML.
2. Converta cada função de equipe da Vercel em funções de conta da Azion e em permissões de equipes.
3. Configure o SSO na Azion antes que a maior parte da equipe migre.
4. Garanta que um administrador de emergência mantenha uma forma de entrar.
5. Revise a autenticação multifator, o tempo limite de sessão do usuário e a política de bloqueio de conta.

Reconstrua o monitoramento

Vercel Observability passa para três produtos da Azion, para que a visibilidade da produção, a resolução de problemas e os relatórios de compliance continuem depois da virada. 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. Speed Insights e Web Analytics passam para Edge Pulse, em Substitua Speed Insights e Web Analytics.

Para planejar a migração, liste os dashboards, relatórios, alertas e fluxos de logs que o projeto usa. Decida quais deles vão para Real-Time Metrics, Real-Time Events, Data Stream ou uma ferramenta de BI externa. As integrações do Vercel Marketplace vão para o Marketplace da Azion ou para um destino do Data Stream. Configure cada uma antes que o tráfego de produção migre, para que não haja lacuna de analytics na virada.

Real-Time Metrics

Os dashboards de Applications mostram:

• Requests: total de requisições, requisições por método e por esquema e Average Request Time. Esse gráfico é 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 e a tabela Requests by Status and Upstream Status. Essa tabela 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.

Real-Time Metrics não informa latência, tempo até o primeiro byte nem tempo de resposta da origem. 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:

Substitua as datas por um intervalo dentro do período de retenção, porque um intervalo fora dele retorna um array vazio. limit aceita até 10.000 linhas e tem padrão 10. O dataset httpMetrics de consultas antigas ainda funciona, mas está obsoleto. Para cada campo, consulte Campos GraphQL do Real-Time Metrics e Crie dashboards. Para o Grafana, consulte Dashboards personalizados do plugin Grafana e dashboards pré-configurados. Para ler os dashboards, consulte Analise métricas.

Real-Time Events

Real-Time Events guarda o registro de cada requisição para investigação e não precisa de configuração. 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:

Substitua as datas por um intervalo dentro dos últimos 7 dias. upstreamResponseTime e upstreamHeaderTime existem apenas como campos brutos de workloadEvents, e upstreamResponseTime mostra - para uma resposta entregue a partir do cache. Para cada campo, consulte Campos GraphQL do Real-Time Events e Investigue requisições com a API GraphQL.

Data Stream

Um stream lê uma fonte de dados, como Applications ou WAF Events, e formata cada registro com um template. Ele entrega os registros a um destino, com suas credenciais:

• 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.

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 e Endpoints. Para guias de destinos, consulte Amazon S3, Azion Object Storage, Datadog, Splunk, Elasticsearch, Kinesis, BigQuery e Configure o sampling.

Substitua Speed Insights e Web Analytics

Edge Pulse assume as medições de usuários reais do Speed Insights e do Web Analytics. Uma tag JavaScript coleta medições de navegação, disponibilidade, latência e largura de banda nos navegadores de visitantes reais. Real-Time Metrics cobre o lado do tráfego dos mesmos relatórios.

Para mover o monitoramento de usuários reais:

1. Liste os Core Web Vitals, os relatórios por página e os dashboards de analytics que o time consulta.
2. Decida quais deles vão para Edge Pulse, Real-Time Metrics ou uma ferramenta de BI externa.
3. Recrie o rastreamento de eventos personalizados onde o projeto precisar.
4. Revise os requisitos de privacidade e de consentimento da tag.
5. Depois da virada, compare as medições de experiência do usuário com a linha de base da Vercel.

Prepare o certificado

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

Assim que você escolhe um preset Let’s Encrypt, a Azion emite o certificado sem custo adicional. O desafio depende de 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 Vercel, use DNS-01, para que o certificado esteja ativo antes da troca do domínio.

Se o certificado não ficar ativo, leia seus campos status e status_detail. Para HTTP-01, verifique se o hostname aponta para a Azion. Para DNS-01, verifique o CNAME _acme-challenge. As novas tentativas continuam conforme o cronograma, então um registro corrigido emite o certificado mais tarde. Para as regras de emissão, consulte Emissão e renovação.

O mTLS precisa de um certificado Trusted CA, e um certificado gerado pela Azion não pode ser o Trusted CA. A equipe de vendas ativa o mTLS na conta. Depois defina mtls.enabled, mtls.config.certificate e verification, enforce ou permissive, no workload pela API ou com azion update workload --file. O mTLS funciona apenas por HTTPS. Para os passos, consulte Configure o mTLS em um workload e mTLS.

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. Pule esta etapa para manter o provedor de DNS atual e apontar apenas subdomínios, como mostra Aponte o domínio para o workload.

Recrie cada registro da zona atual com seu tipo:

Edge DNS recusa outros tipos, como SOA. Os registros A, AAAA, ANAME, DS, MX e NS guardam até 10 valores cada.

Com o DNSSEC ativado, Edge DNS mostra quatro valores DS: Key Tag, Algorithm 13, Digest Type 2 e Digest. Recarregue a página depois de salvar para vê-los. Adicione-os no registrador, que pode levar até 48 horas para publicá-los. Para os passos, consulte DNSSEC.

Para verificar a migração, 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. Com o DNSSEC ativado, o terceiro retorna dois registros DNSKEY, com flags 257 e 256 e algoritmo 13. Não consulte um nome novo antes de o registro dele existir, porque Edge DNS mantém a resposta negativa em cache por uma hora. Para mais comandos, consulte Execute o comando dig e Execute o comando traceroute.

Aponte o domínio para o workload

O domínio é o último a migrar, porque a mudança de DNS é a virada: assim que o domínio resolve para o workload, os usuários acessam o projeto pela Azion. Ela afeta usuários, ranking de busca, confiança na marca e disponibilidade, então trate-a como uma transição planejada. Antes da virada, confirme que:

• O certificado está ativo.
• O hostname está nos Domains do workload. Para as configurações de domínio, consulte Domains.
• Os registros DNS estão prontos.
• As rotas críticas e os redirecionamentos respondem como esperado no domínio do workload. Para testá-los antes com o hostname real, consulte Teste uma aplicação pelo arquivo hosts.
• 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:

A resposta é o domínio do workload, como xxxxxxxxxx.map.azionedge.net. Mudanças de DNS levam tempo para se propagar. Assim que o nome resolver, requisite-o, com o domínio no lugar de <your-domain>:

A resposta vem da aplicação, com o status e os headers que ela retorna para /. Se o HTTPS falhar, leia o status do certificado e confirme que o hostname está no workload. Para as configurações do domínio personalizado no Console, consulte Aponte um domínio para um workload. Para mover os nameservers, consulte Migre os nameservers para a Azion.

Próximos passos