Il lancio più rilevante della settimana del 17 agosto è uno che la maggior parte dei team non noterà finché non arriva una notifica: Amazon EKS ora gestisce la rotazione delle certificate authority, ed esiste perché i primi cluster EKS, creati nel 2018 con CA decennali, si stanno avvicinando alla loro fine. Accanto a questo, Direct Connect ha alzato il tetto dei prefissi in ingresso da 100 a 1.000, Europe (London) ha ottenuto una quarta Availability Zone, e IAM Policy Autopilot ha imparato a leggere i file di plan Terraform. Nessun lancio di AWS Transform o DMS questa settimana, quindi l'angolo migrazione è quello di rete: il limite sui prefissi era un vero blocco per i grandi cutover ibridi.

Rotazione delle CA in EKS: la scadenza che nessuno ha messo in un ticket

Ogni cluster EKS ha una CA che firma il certificato dell'API server, e ogni cluster creato dal lancio in avanti ne porta una valida per dieci anni. I primi risalgono a metà 2018. Se quella CA scade, nulla che si fidi di lei può parlare con il control plane: kubelet, kubectl, i runner di CI, gli operator che avevi dimenticato. La nuova rotazione gestita ti dà un ciclo di vita con delle protezioni: EKS aggiunge una CA successore, aggiorna i componenti gestiti da AWS perché si fidino di lei, gestisce automaticamente le istanze EKS Auto Mode e i nodi Fargate, invia notifiche anticipate di scadenza, attiva il successore secondo il proprio calendario se non lo fai mai tu, e mantiene un rollback alla CA precedente. Nessun costo aggiuntivo, tutte le Region commerciali, pilotabile da CLI, API EKS, CloudFormation o console.

Leggi la lista per quello che AWS non fa. Devi comunque sostituire i tuoi worker node perché si fidino del successore, e devi comunque aggiornare ogni client esterno, cioè ogni kubeconfig cablato in un sistema di CI, ogni bastion, ogni strumento di terze parti che ha fissato il certificate-authority-data. L'attivazione automatica è la parte da rispettare: è una rete di sicurezza contro la scadenza, ma se scatta prima che tu abbia ruotato i tuoi client, quei client si rompono in un momento scelto da AWS. La mossa giusta è fare adesso l'inventario di chi parla con ogni cluster, ruotare i node group self-managed come un normale refresh, e attivare il successore tu stesso dentro una finestra di cambiamento. Parti dal cluster più vecchio dell'account; aws eks describe-cluster e il createdAt del cluster ti dicono qual è.

Direct Connect: 1.000 prefissi e un pool di capacità

Una VIF privata o transit accettava al massimo 100 prefissi di rotta annunciati dall'on-premises. Per un data center con un decennio di proliferazione di subnet questo voleva dire riassumere in modo aggressivo o dividere su più VIF, e durante una migrazione voleva dire le rotte riassuntive "temporanee" che sopravvivono alla migrazione. I controlli sui prefissi in ingresso ti permettono di allocare fino a 1.000 prefissi IPv4 e 1.000 IPv6 per VIF su connessioni dedicate e hosted, presi da nuovi pool di capacità a livello di connessione dedicata e di Direct Connect gateway. I pool delle connessioni scalano con la velocità del link e quelli dei LAG con il numero di membri. Nessun costo aggiuntivo; Region commerciali, GovCloud (US) ed entrambe le Region cinesi.

Il modello a pool è la parte da capire prima di toccarlo. La capacità è un budget condiviso, quindi un team che alloca 900 prefissi a una VIF ha speso il pool per tutti gli altri su quella connessione. Tratta le allocazioni come IaC, non come click in console, e decidi la ripartizione prima che il primo team la chieda.

Region: eu-west-2d e una Local Zone a Las Vegas

Europe (London) ha aggiunto eu-west-2d il 19 agosto, con capacità accelerata Trn3 e P6 oltre al calcolo general-purpose. Le nuove AZ sono facili da ignorare e costose da ignorare: se la tua VPC è stata costruita con tre subnet per tier e nomi di AZ cablati, la quarta zona è invisibile ai tuoi Auto Scaling group e ai tuoi node group EKS finché qualcuno non aggiunge le subnet. Il giorno dopo, una Local Zone a Las Vegas (us-west-2-las-2a) è passata in GA con istanze C7i, M7i, R7i e C8gn, i tipi EBS gp3/gp2/io1/sc1/st1, ECS, EKS, ALB e Direct Connect.

IAM: Policy Autopilot per Terraform, e una quota che hai smesso di raggiungere

IAM Policy Autopilot, lo strumento open source del re:Invent 2025 che deriva policy ristrette dal codice applicativo, ora prende un file di plan Terraform e produce una policy di base limitata a create, read, update e delete sulle risorse di quel plan, con ARN specifici dove può. Gira in locale e vive in awslabs/iam-policy-autopilot. Il vuoto che colma è reale: il ruolo di deploy di una pipeline Terraform è di solito il ruolo più largo dell'account proprio perché nessuno sapeva enumerare cosa gli serve. Una base derivata dal plan è un punto di partenza difendibile, con l'avvertenza che una base ricavata da un plan non copre il destroy di una risorsa che nel plan successivo non c'è. Separatamente, il limite di default di managed policy per ruolo è raddoppiato da 10 a 20, con 25 disponibili su richiesta, il che manda in pensione una classe di workaround del tipo "policy troppo grande, attaccane un'altra".

Anche questa settimana

Il filo conduttore

Tre dei lanci di questa settimana riguardano limiti fissati quando la piattaforma era piccola: una CA decennale che nel 2018 sembrava per sempre, una VIF da 100 prefissi di quando ibrido voleva dire un solo data center, un ruolo da 10 policy di prima che qualcuno attaccasse managed policy a dozzine. AWS li sta alzando o automatizzando uno per uno, ed è benvenuto, ma il peso non scompare, si sposta. La rotazione delle CA ti lascia i client, il pool di prefissi ti lascia la policy di allocazione, la base di Autopilot ti lascia il percorso di destroy. L'automazione a livello di piattaforma converte un limite rigido in una decisione di design, e le decisioni di design hanno bisogno di un owner.

Leggi questo dopo

Per la lettura AI e agenti della stessa settimana, le note sul campo stanno su ercan.ai. Per consulenza su AWS, cloud, pipeline CI/CD, Linux, GitHub/GitLab e altro, parti da ercanermis.com.

Riferimenti