La settimana del 14 settembre è stata AWS che vende il platform engineering come prodotto: Elastic Beanstalk Cluster Mode mette un portfolio di applicazioni su EKS condiviso e completamente gestito, e la nuova esperienza di onboarding consegna a chi inizia un progetto preconfigurato invece di un account vuoto. Sotto, il calcolo è diventato più economico in due direzioni (istanze T8i, ARM64 in ECS Express Mode), PrivateLink ha guadagnato un tunnel endpoint per condividere interi segmenti di rete, e sono arrivate due modifiche all'identità che romperanno silenziosamente il monitoraggio se le ignori. Il tooling di migrazione è stato tranquillo questa settimana (niente da AWS Transform o DMS), quindi apre la storia della piattaforma.

Elastic Beanstalk Cluster Mode: l'argomento PaaS, di nuovo

Il 17 settembre AWS Elastic Beanstalk ha introdotto Cluster Mode: più applicazioni girano su infrastruttura condivisa basata su Amazon EKS, completamente gestita, con una sola baseline operativa. Carichi il sorgente in Java, .NET, Python, Node.js, PHP, Ruby o Go (oppure un Dockerfile, oppure un'immagine), Beanstalk lo containerizza con Cloud Native Buildpacks quando serve, e l'ambiente ottiene deploy con spostamento graduale del traffico e rollback automatico, autoscaling event-driven, integrazione con Secrets Manager, osservabilità OpenTelemetry e troubleshooting assistito dall'AI. Gli ambienti Standard e Cluster Mode convivono nella stessa applicazione, quindi migri un ambiente alla volta.

L'argomento del costo per applicazione è quello che ogni team di piattaforma interno ha usato per finanziare un cluster EKS condiviso. La differenza è chi lo gestisce: AWS, per tutta la vita del workload, e tu non vedi mai un nodo, un kubeconfig o una finestra di upgrade.

Con venti piccoli servizi e nessuna voglia di Kubernetes, Cluster Mode è probabilmente il default giusto. Se hai un team di piattaforma che già possiede EKS, Cluster Mode compete con loro per gli stessi workload e offre meno controllo: niente admission policy personalizzate, niente tuning dei nodi, nessuna scelta della CNI. La modalità di guasto è quella che le piattaforme condivise hanno sempre, un upgrade della baseline giusto per diciannove applicazioni e sbagliato per la ventesima, solo che ora la ventesima non può bloccare nulla a una versione. Fai un pilota con le applicazioni di cui saresti contento di perdere il controllo.

Calcolo più economico, in due modi

Il 17 settembre le istanze EC2 T8i sono diventate generally available: Intel Xeon 6 di sesta generazione personalizzato, schede Nitro di sesta generazione, quattro taglie (nano, micro, small, medium), fino al 30% di rapporto prezzo-prestazioni in più rispetto a T3, fino al 70% di calcolo in più, 1,25x la banda di rete, 2,4x la banda EBS. Stesso sistema di crediti CPU con modalità Standard e Unlimited, quindi il passaggio da T3 è un cambio di tipo di istanza e nient'altro. t8i.micro e t8i.small sono nel Free Tier.

Il 18 settembre ECS Express Mode ha aggiunto ARM64 come architettura CPU, quindi il percorso "dammi un URL per questa immagine" può atterrare su Graviton, che AWS valuta fino al 40% meglio di x86 in prezzo-prestazioni. Configurabile per servizi Express Mode nuovi ed esistenti tramite console, CLI, SDK e IaC.

Entrambi fanno risparmiare solo se qualcuno fa la modifica. La flotta T3 nella maggior parte degli account è fatta di bastion, build runner e strumenti interni dimenticati; un cambio di variabile Terraform e un instance refresh sono tutto il lavoro. Per Express Mode ARM64 il prerequisito è un'immagine multi-arch, e la modalità di guasto è un'immagine base o una dipendenza nativa che esiste solo in amd64. Compila con docker buildx build --platform linux/amd64,linux/arm64, lascia che la manifest list faccia il lavoro, poi cambia l'architettura.

PrivateLink Tunnel Endpoint: condividi un CIDR, non un servizio

Il 18 settembre AWS PrivateLink ha annunciato i Tunnel Endpoint, un nuovo tipo di VPC endpoint. Prima, condividere risorse con una parte esterna significava una Resource Configuration per risorsa. Ora una Resource Configuration può rappresentare un intervallo CIDR della tua rete; lo condividi tramite AWS RAM, e l'altra parte crea un tunnel endpoint e usa l'incapsulamento GENEVE per raggiungere qualsiasi cosa dentro quell'intervallo. Costo orario per tunnel endpoint più un costo per GB di dati elaborati.

Questo colma il vuoto tra PrivateLink (un servizio, un endpoint, nessuna esposizione del routing) e Transit Gateway o peering (routing completo, in entrambe le direzioni, e una negoziazione dei CIDR). Un vendor che ha bisogno di quaranta host nella tua subnet di management prima ti costringeva all'opzione pesante; ora ottiene un tunnel esattamente verso l'intervallo che hai indicato.

Il costo per GB rende questo un percorso da control plane, non da dati in massa; modella il costo prima che qualcuno ci faccia passare i backup. E "un intervallo CIDR" è una concessione più ampia di "un servizio": la disciplina su security group e NACL dentro quell'intervallo fa ora parte della tua superficie di attacco esterna, quindi tratta l'intervallo che esponi come una DMZ e dimensionalo di conseguenza.

Due modifiche all'identità che rompono le dashboard

Il 14 settembre il sign-in dell'utente root ha iniziato a essere servito da US East (Ohio) e US West (Oregon) oltre che da N. Virginia, con il traffico distribuito su tutte e tre. Bene per la resilienza, ma l'evento CloudTrail ConsoleLogin di un sign-in root ora viene registrato nella Region che lo ha elaborato. Se il tuo allarme sui login root è un metric filter su un trail in us-east-1, ora intercetta circa un terzo dei login root. Spostalo su un trail di organizzazione o aggiungi le altre due Region questa settimana.

Il 15 settembre STS ha unificato i limiti dei session token in un unico limite di 4.096 byte, sostituendo i tetti separati sulla dimensione del token e sulle session policy e i tag passati in input. STS ora restituisce la dimensione del token e la percentuale di utilizzo, le registra in CloudTrail e pubblica metriche CloudWatch; un nuovo parametro opzionale genera token deliberatamente grandi così puoi verificare se i tuoi proxy e i tuoi header li reggono. Se hai mai incontrato "packed policy too large", questa è la correzione, e il parametro di test dimostra che il tuo stack gestisce il tetto prima che un session tag ti ci spinga contro.

Anche questa settimana

Il filo conduttore

Cluster Mode e la nuova esperienza per i builder sono lo stesso prodotto a due scale: AWS sceglie i default e si prende la responsabilità operativa che ne deriva. Il costo è che i default scelti per tutti non calzano perfettamente a nessuno, e i punti in cui questo morde (tuning dei nodi, un allarme sui login root che presupponeva una sola Region, un session token che presupponeva due limiti) sono esattamente i punti toccati dai lanci minori di questa settimana. Il lavoro di piattaforma non scompare quando la piattaforma la gestisce AWS; si sposta dal costruire la cosa al sapere quali dei suoi default sono sbagliati per te.

Leggi questo dopo

Per la lettura AI e agenti della stessa settimana, vedi ercan.ai. Per consulenza su AWS, architettura cloud, pipeline CI/CD, Linux, GitHub o GitLab e il lavoro di piattaforma intorno a essi, parti da ercanermis.com.

Riferimenti