# ADR: EKS Provisioned Control Plane e HPA Concurrency 40x

O EKS Provisioned Control Plane agora processa objetos HPA com até 40x mais concorrência que o padrão Kubernetes, eliminando um gargalo silencioso em clusters com centenas de workloads. Neste registro de decisão arquitetural, analiso o contexto que torna essa mudança relevante, as opções que existiam antes dela, e as consequências operacionais que arquitetos precisam endereçar agora.

- URL: https://fernando.moretes.com/blog/adr-eks-provisioned-control-plane-e-hpa-concurrency-40x-amazon-eks-p

- Markdown: https://fernando.moretes.com/blog/adr-eks-provisioned-control-plane-e-hpa-concurrency-40x-amazon-eks-p/article.md?lang=pt

- Published: 2026-07-29T09:03:38.535Z

- Category: IA & Agentes

- Tags: eks, kubernetes, hpa, autoscaling, control-plane, financial-grade, sre, well-architected

- Reading time: 9 min

- Source: [Amazon EKS Provisioned Control Plane now delivers faster pod autoscaling](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-eks-provisioned-control/)

---

Em 28 de julho de 2026, a AWS anunciou que o EKS Provisioned Control Plane aumenta a concorrência de sincronização do HPA para até 40 vezes o valor padrão do Kubernetes — sem nenhuma mudança de configuração exigida do operador. Para quem opera clusters com centenas ou milhares de objetos HPA, isso não é um ajuste cosmético: é a remoção de um gargalo estrutural que, até agora, tornava o autoscaling baseado em métricas fundamentalmente não-determinístico sob carga.

## Contexto e Forças: O Problema que Ninguém Monitorava Direito

O Horizontal Pod Autoscaler do Kubernetes opera em um loop de controle. A cada ciclo — por padrão a cada 15 segundos — o controller manager avalia todos os objetos HPA no cluster, consulta o metrics server ou um adaptador de métricas externas, calcula a réplica desejada e emite uma atualização no objeto Deployment ou StatefulSet. O que a maioria dos times não percebe é que esse loop é **serialmente limitado pelo parâmetro `--horizontal-pod-autoscaler-sync-period` combinado com a concorrência de avaliação**. No Kubernetes padrão upstream, essa concorrência é baixa por design — o projeto assume que o control plane é compartilhado e que workloads concorrentes podem saturar o API server.

Em ambientes financeiros que opero, é comum ter entre 200 e 800 objetos HPA ativos em um único cluster de produção: serviços de cotação, motores de risco, APIs de onboarding, workers de processamento de eventos de mercado. Cada um desses objetos precisa ser avaliado dentro da janela de sincronização. Quando a carga chega — um spike de volume em abertura de mercado, um evento de notícia que dispara requisições simultâneas — o control plane precisa processar todos esses objetos antes que qualquer escalonamento aconteça. Com concorrência baixa e 400 objetos HPA, você pode estar esperando múltiplos ciclos de 15 segundos antes que o workload crítico seja avaliado. Isso se traduz em latência de escalonamento de 45 a 90 segundos em cenários realistas — tempo suficiente para que um SLO de disponibilidade seja violado.

A força arquitetural aqui é clara: **a velocidade de reação do autoscaler é um componente do SLO de disponibilidade**, não apenas uma métrica de infraestrutura. Times que definem SLOs de `p99 < 500ms` para APIs de trading precisam incluir o tempo de escalonamento no orçamento de erro — e a maioria não o faz.

## O Gargalo Estrutural: Como o HPA Sync Concurrency Funciona

O `kube-controller-manager` upstream expõe o flag `--concurrent-horizontal-pod-autoscaler-syncs`, que controla quantos goroutines paralelos processam objetos HPA simultaneamente. O valor padrão histórico é **5**. Isso significa que em um cluster com 500 objetos HPA, o controller precisa de no mínimo 100 iterações seriais de goroutines para completar um ciclo de avaliação completo. Se cada avaliação leva ~100ms (incluindo chamada ao metrics server, cálculo e write no API server), um ciclo completo leva ~10 segundos — já consumindo 67% da janela de sincronização padrão de 15 segundos.

O EKS Provisioned Control Plane, conforme o anúncio de 28 de julho de 2026, aumenta essa concorrência para **até 40x o valor padrão**. Matematicamente, isso significa que o mesmo cluster de 500 objetos HPA pode ser avaliado em aproximadamente 2,5 iterações de goroutines em vez de 100 — reduzindo o tempo de ciclo de ~10 segundos para sub-segundo em condições normais. O efeito prático é que **o tempo entre a detecção de carga e o início do escalonamento colapsa de múltiplos ciclos para uma fração do primeiro ciclo**.

É importante entender que o Provisioned Control Plane é a oferta premium da AWS onde você tem um control plane dedicado, não compartilhado. Isso é o que torna viável aumentar a concorrência sem impacto em outros tenants — o API server subjacente tem capacidade reservada para absorver o throughput adicional de writes e reads que a avaliação concorrente gera. Em um control plane compartilhado padrão, aumentar essa concorrência de forma agressiva poderia gerar throttling no API server e piorar a situação. Aqui, a decisão de arquitetura da AWS é coerente: o benefício só é seguro porque o isolamento de recursos já existe.

## Números que Importam para a Decisão

- **40x** — Aumento de concorrência HPA no Provisioned Control Plane. Versus o padrão upstream do Kubernetes (5 goroutines)
- **~5** — Goroutines HPA padrão no Kubernetes upstream. Valor histórico do flag --concurrent-horizontal-pod-autoscaler-syncs
- **76%** — Melhoria de tempo de scale-out no ECS (benchmark AWS, jun/2026). De 363s para 86s — sinal de que AWS está atacando latência de autoscaling em toda a plataforma
- **43%** — Melhoria de scale-out de nós no EKS Auto Mode (Karpenter). Anunciado em jun/2026 — camada de nós complementar à camada de pods

## Opções Consideradas: Como Resolver o Gargalo de HPA em Escala Antes Deste Anúncio

### Opção A: EKS Standard + Tuning Manual de HPA

**Pros**
- Custo menor — control plane compartilhado sem sobretaxa
- Controle total sobre parâmetros de sincronização via add-on customizado

**Cons**
- Impossível aumentar --concurrent-horizontal-pod-autoscaler-syncs no EKS Standard — o control plane é gerenciado e não expõe esse flag
- Workarounds como KEDA introduzem complexidade operacional e outro plano de controle para gerenciar
- Risco de throttling no API server compartilhado sob alta concorrência de avaliação

**Verdict:** Inadequado para clusters com >200 objetos HPA em ambientes financeiros com SLOs apertados

### Opção B: KEDA (Kubernetes Event-Driven Autoscaling) como substituto do HPA

**Pros**
- Suporte nativo a fontes de métricas externas: Kafka lag, SQS depth, Prometheus, Datadog
- Escalabilidade para zero (scale-to-zero) — relevante para workloads batch
- Não depende do loop de sincronização do kube-controller-manager

**Cons**
- Introduz um operator adicional com seu próprio ciclo de vida, versioning e surface de ataque IAM
- ScaledObjects são objetos CRD — adiciona overhead de API server e etcd
- Não resolve o problema para workloads que já usam HPA nativo com metrics server

**Verdict:** Válido como complemento para fontes de métricas externas, não como substituto universal do HPA

### Opção C: Fragmentação de clusters (sharding por domínio de negócio)

**Pros**
- Reduz o número de objetos HPA por cluster, aliviando o gargalo de concorrência
- Melhora isolamento de blast radius entre domínios

**Cons**
- Multiplicação de custos de control plane, tooling de observabilidade e overhead de operação
- Complexidade de rede e service mesh entre clusters para comunicação cross-domain
- Não escala bem — o problema retorna à medida que cada cluster cresce

**Verdict:** Workaround arquitetural caro que resolve o sintoma sem endereçar a causa raiz

### Opção D: EKS Provisioned Control Plane (decisão escolhida)

**Pros**
- 40x de concorrência HPA sem nenhuma mudança de configuração — zero operational debt
- Control plane dedicado com SLA de disponibilidade e capacidade reservada para API server
- Compatível com KEDA, VPA, Karpenter — não é exclusivo, é aditivo
- Alinhado com a direção de plataforma da AWS: EKS Auto Mode também roda sobre Provisioned Control Plane

**Cons**
- Custo adicional do Provisioned Control Plane versus o tier padrão
- Migração de clusters existentes requer planejamento — não é um upgrade in-place trivial

**Verdict:** Decisão correta para clusters de produção financeira com >150 objetos HPA e SLOs de disponibilidade definidos

## A Decisão: Por Que o Provisioned Control Plane é a Escolha Correta para Ambientes Financeiros

A decisão de adotar o EKS Provisioned Control Plane não é motivada apenas pela melhoria de concorrência HPA anunciada em julho de 2026. Ela é motivada por uma mudança de postura arquitetural: **o control plane do Kubernetes é infraestrutura de dados crítica, não um serviço de conveniência**. Em ambientes financeiros, o control plane determina o tempo de reação do sistema a eventos de mercado. Tratar isso como um recurso compartilhado de commodity é o mesmo que compartilhar o barramento de dados de um sistema de trading — funciona até o momento em que não funciona.

O Provisioned Control Plane oferece capacidade dedicada de API server, o que significa que o throughput adicional gerado por 40x mais goroutines de avaliação HPA não compete com outros tenants. Isso é fundamental: aumentar concorrência sem isolamento de recursos é uma receita para degradação em cascata. O API server do Kubernetes tem limites de rate limiting configuráveis (`--max-requests-inflight`, `--max-mutating-requests-inflight`), e em um control plane compartilhado, a avaliação paralela de 200 objetos HPA pode facilmente saturar esses limites, gerando `429 Too Many Requests` e atrasando não apenas o autoscaling, mas também operações de deployment, health checks e reconciliação de outros controllers.

A decisão também é coerente com a trajetória da plataforma AWS. O EKS Auto Mode — que inclui Karpenter com 43% mais velocidade de scale-out de nós e consolidação 69% mais rápida — opera sobre o Provisioned Control Plane. A AWS está claramente construindo suas capacidades de maior valor sobre essa camada. Times que não migraram para ela estão, efetivamente, acumulando dívida técnica de plataforma.

Para clusters com menos de 50 objetos HPA e workloads sem SLOs de latência de escalonamento definidos, o tier padrão pode ser suficiente. Mas essa é uma exceção, não a regra em ambientes de produção financeira.

## Pipeline de Avaliação HPA: Padrão vs. Provisioned Control Plane (40x)

Comparação do fluxo de avaliação HPA em um cluster com 400 objetos HPA. À esquerda: comportamento padrão com 5 goroutines seriais. À direita: Provisioned Control Plane com até 200 goroutines paralelos. As arestas mostram o caminho crítico que determina a latência de escalonamento.

### 📊 Metrics Layer

- Metrics Server / Prometheus Adapter (data)
- CloudWatch Container Insights (data)

### 🔁 Standard Control Plane (5 goroutines)

- HPA Controller 5 concurrent syncs ~100 iterations/cycle (compute)
- API Server (shared tenant) throttle risk (network)
- Scale Event latency: 45-90s (400 HPAs) (edge)

### ⚡ Provisioned Control Plane (40x concurrency)

- HPA Controller ~200 concurrent syncs ~2.5 iterations/cycle (compute)
- API Server (dedicated capacity) no throttle risk (network)
- Scale Event latency: <5s (400 HPAs) (edge)

### 🚀 Node Scaling Layer

- Karpenter (EKS Auto Mode) 43% faster nodes (compute)
- EC2 Nodes Provisioned (compute)

### Fluxos

- ms -> hpa_std: métricas por ciclo
- ms -> hpa_pcp: métricas por ciclo
- cw -> ms: container metrics
- hpa_std -> api_std: serial writes
(throttle risk)
- hpa_pcp -> api_pcp: parallel writes
(dedicated)
- api_std -> scale_std: replica update
- api_pcp -> scale_pcp: replica update
- scale_pcp -> karp: pending pods trigger
- karp -> ec2: node provisioning

## Consequências Operacionais: O Que Muda na Prática

A primeira consequência operacional é positiva e imediata: clusters existentes no Provisioned Control Plane recebem o benefício sem nenhuma ação. Isso é raro em melhorias de infraestrutura e merece reconhecimento — a AWS absorveu a complexidade de tuning no serviço gerenciado.

A segunda consequência é mais sutil e potencialmente problemática: **workloads que foram dimensionadas com base no comportamento lento do HPA podem agora escalar mais agressivamente do que o esperado**. Imagine um serviço que tinha um `scaleUp.stabilizationWindowSeconds` configurado em 120 segundos precisamente porque o time sabia que o HPA demorava para reagir e queria evitar flapping. Com a nova concorrência, o HPA reage em segundos — e a janela de estabilização pode não ser mais suficiente para absorver spikes transitórios de métricas. O resultado pode ser scale-up desnecessário seguido de scale-down, gerando custo adicional e potencial instabilidade.

A terceira consequência afeta a observabilidade. Se você monitora `kube_horizontalpodautoscaler_status_current_replicas` versus `kube_horizontalpodautoscaler_spec_max_replicas` como proxy para pressão de escalonamento, o comportamento da série temporal vai mudar. O que antes era uma curva gradual de subida (porque o HPA levava tempo para reagir) agora pode ser um step function quase instantâneo. Dashboards de capacity planning que dependem da inclinação dessa curva para prever necessidade de nós precisam ser recalibrados.

Finalmente, há a interação com o Karpenter/EKS Auto Mode. O HPA mais rápido vai gerar pods `Pending` mais rapidamente, o que aciona o Karpenter para provisionar nós. Com o Karpenter 43% mais rápido (anúncio de junho de 2026), a cadeia completa pod-scale → node-provision agora opera em uma janela de tempo muito menor. Isso é excelente para SLOs — mas significa que o `NodePool` do Karpenter precisa ter limites de capacidade máxima bem definidos para evitar provisioning excessivo em casos de runaway scaling.

> **Atenção: Revise Suas Políticas de HPA Antes de Comemorar:** A melhoria de concorrência é automática — mas seus `HorizontalPodAutoscaler` objects foram escritos assumindo o comportamento lento. Revise imediatamente: (1) `scaleUp.stabilizationWindowSeconds` — valores acima de 60s podem ter sido definidos como workaround para latência de HPA; com a nova concorrência, podem ser excessivamente conservadores ou, pior, insuficientes para evitar flapping em métricas ruidosas. (2) `scaleDown.stabilizationWindowSeconds` — o padrão de 300s do Kubernetes é geralmente correto, mas verifique se não foi reduzido para compensar lentidão de scale-up. (3) Limites de `maxReplicas` — com scale-up mais rápido, um `maxReplicas` mal dimensionado pode ser atingido antes que você perceba, criando um teto artificial que viola SLOs. (4) Políticas de `behavior.scaleUp.policies` com `type: Pods` e valores absolutos — o que antes era um rate de escalonamento seguro pode agora ser atingido em segundos em vez de minutos. Monitore `kube_horizontalpodautoscaler_status_condition` com `reason=ScalingLimited` no primeiro ciclo após a migração.

## Observabilidade: O Que Instrumentar Após a Migração

A migração para Provisioned Control Plane com HPA concorrência 40x exige uma revisão do modelo de observabilidade. O conjunto de métricas que você precisa monitorar muda em caráter, não apenas em valores.

**Métricas de control plane que passam a importar mais:** O `apiserver_request_duration_seconds` para verbos `patch` e `update` no grupo `autoscaling/v2` agora reflete o throughput real do HPA. Em um control plane dedicado, você deve ver latências consistentemente abaixo de 50ms para esses requests. Se você observar spikes acima de 200ms, isso é um sinal de que o metrics server está sendo o gargalo, não o HPA controller. Instrumente `metrics_server_api_metric_freshness_seconds` para garantir que as métricas que alimentam o HPA são frescas o suficiente — com HPA mais rápido, métricas com staleness de 30-60 segundos se tornam um limitador real.

**SLO de scaling latency:** Defina explicitamente um SLO para tempo de scaling. Uma métrica composta útil é: `time_from_metric_threshold_breach_to_first_new_pod_ready`. Isso requer correlação entre eventos de HPA (`kube_horizontalpodautoscaler_status_current_replicas` aumentando), criação de pod (`kube_pod_created`) e prontidão (`kube_pod_status_ready`). Com OpenTelemetry, você pode criar um span sintético que cobre esse pipeline completo — do breach ao pod ready — e expô-lo como um SLI mensurável.

**Alertas de runaway scaling:** Configure um alerta no CloudWatch ou Datadog para `kube_horizontalpodautoscaler_status_current_replicas / kube_horizontalpodautoscaler_spec_max_replicas > 0.85` com uma janela de 2 minutos. Isso detecta quando um workload está se aproximando do teto de réplicas rapidamente — situação que, com o HPA mais lento, levava tempo suficiente para intervenção manual, mas agora pode acontecer antes que qualquer alerta tradicional de latência dispare.

**Cost observability:** Habilite AWS Cost Anomaly Detection com um monitor específico para a tag de cluster. Scale-up mais rápido significa que picos de custo de EC2/Fargate também acontecem mais rapidamente. O orçamento de erro de custo precisa ser recalibrado junto com o orçamento de erro de disponibilidade.

## Análise Well-Architected: EKS Provisioned Control Plane com HPA 40x

- **security**: O control plane dedicado reduz a superfície de ataque de noisy neighbor no plano de controle. Combinado com IRSA (IAM Roles for Service Accounts) para acesso granular do metrics server ao CloudWatch, e com Network Policies restringindo comunicação entre o HPA controller e fontes de métricas externas, o modelo de segurança é mais forte que em um control plane compartilhado.
- **reliability**: O aumento de concorrência HPA reduz diretamente o tempo de recuperação de sobrecarga — um componente crítico do RTO em nível de workload. Em ambientes financeiros, isso melhora a conformidade com SLOs de disponibilidade sem mudanças de código. O risco residual é flapping por métricas ruidosas — mitigado com `stabilizationWindowSeconds` adequado e métricas de baixa latência.
- **performance**: O benefício de performance é de segunda ordem: o HPA mais rápido reduz o tempo em que o sistema opera subprovisionado, reduzindo a latência de API durante spikes. Para sistemas de pagamento e trading, isso pode significar a diferença entre cumprir ou violar SLOs de latência de p99 durante picos de volume.
- **cost**: O Provisioned Control Plane tem custo adicional versus o tier padrão. Esse custo precisa ser justificado pelo valor do SLO que protege. Para workloads onde um minuto de degradação tem impacto financeiro mensurável (transações perdidas, multas regulatórias, churn), o ROI é claro. Para workloads internos sem SLO formal, a análise é menos direta.

## Anti-Padrões a Evitar Após a Migração

- Assumir que HPA mais rápido elimina a necessidade de pre-warming. O HPA reage a carga existente — para eventos previsíveis (abertura de mercado, campanhas de marketing), pre-scaling via CronJob ou KEDA ScaledJob ainda é necessário.
- Remover `stabilizationWindowSeconds` completamente para maximizar velocidade de reação. Métricas de CPU e memória têm ruído inerente — sem janela de estabilização, você terá flapping constante que degrada a experiência do usuário e gera custo desnecessário.
- Não revisar `maxReplicas` após a migração. Com HPA mais rápido, um `maxReplicas` conservador pode ser atingido em segundos durante um spike, criando um teto artificial invisível nos dashboards de latência.
- Usar métricas de alta latência (ex: CloudWatch com período de 1 minuto) como fonte para HPA em workloads que agora podem escalar em segundos. A velocidade do HPA controller supera a frequência de atualização das métricas — o gargalo migra para a fonte de métricas.
- Migrar para Provisioned Control Plane sem definir um SLO explícito de scaling latency. Sem um SLO, você não tem como medir se o investimento adicional está gerando valor mensurável.

> **Nota do Arquiteto:** Na minha experiência com clusters de produção financeira, o gargalo de HPA sync concurrency era um dos problemas mais difíceis de diagnosticar porque seus sintomas — latência elevada durante spikes — eram indistinguíveis de problemas de capacidade de aplicação. A lição que aprendi da forma mais difícil é que **você precisa medir o tempo de scaling como um SLI de primeira classe, não como uma métrica de infraestrutura secundária**. Antes de migrar para o Provisioned Control Plane, faça um inventário completo de todos os objetos HPA e classifique-os por criticidade de negócio — você vai descobrir que 20% deles têm `stabilizationWindowSeconds` configurados como workarounds para lentidão que agora não existe mais. Minha recomendação prática: instrumente `kube_horizontalpodautoscaler_status_condition` com labels de workload no Datadog ou CloudWatch antes de migrar, estabeleça uma baseline de comportamento, e só então ative o Provisioned Control Plane — assim você tem um before/after mensurável para justificar o custo adicional para o CFO.

## Decisão Final: Migre para o Provisioned Control Plane se Você Opera Workloads Financeiros com SLOs

O aumento de 40x na concorrência HPA do EKS Provisioned Control Plane não é uma feature de nicho — é a correção de um limite estrutural do Kubernetes que afetava qualquer cluster com mais de ~100 objetos HPA. Para ambientes financeiros, onde a latência de escalonamento é um componente direto do SLO de disponibilidade, essa mudança justifica por si só a migração para o Provisioned Control Plane. A decisão é reforçada pelo alinhamento com a direção de plataforma da AWS (EKS Auto Mode, Karpenter mais rápido) e pelo fato de que o benefício é entregue sem mudança de configuração. O custo adicional do Provisioned Control Plane deve ser avaliado contra o custo de SLO violations — em ambientes de pagamento, trading ou qualquer sistema onde um minuto de degradação tem impacto financeiro mensurável, o ROI é positivo. A ação imediata não é migrar — é revisar todas as políticas de HPA existentes, instrumentar scaling latency como SLI, e então migrar com uma baseline mensurável. Clusters com menos de 50 objetos HPA e sem SLOs formais de scaling podem permanecer no tier padrão por ora.

**Rating:** Strongly Recommended for financial-grade

## Referências

- [Amazon EKS Provisioned Control Plane now delivers faster pod autoscaling (AWS What's New, Jul 28 2026)](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-eks-provisioned-control/)
- [EKS Provisioned Control Plane — EKS User Guide](https://docs.aws.amazon.com/eks/latest/userguide/eks-provisioned-control-plane.html)
- [Kubernetes Horizontal Pod Autoscaler — Official Docs](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/)
- [Amazon ECS announces faster service auto scaling (AWS What's New, Jun 18 2026)](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-ecs-faster-autoscaling/)
- [Faster nodes, smarter scaling: What's new inside Amazon EKS Auto Mode (AWS Containers Blog, Jun 22 2026)](https://aws.amazon.com/de/blogs/containers/faster-nodes-smarter-scaling-whats-new-inside-amazon-elastic-kubernetes-service-amazon-eks-auto-mode/)
- [Kubernetes HPA — concurrent-horizontal-pod-autoscaler-syncs flag reference](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/)
- [KEDA — Kubernetes Event-Driven Autoscaling](https://keda.sh/)
- [AWS Cost Anomaly Detection](https://docs.aws.amazon.com/cost-management/latest/userguide/getting-started-ad.html)