Il problema: quote regionali condivise e capacity planning complicato

Chi gestisce ambienti Azure SQL Managed Instance (MI) su larga scala conosce bene un problema che, fino a pochi giorni fa, complicava ogni fase di dimensionamento: le quote regionali di subnet. Ogni Managed Instance deve risiedere in una subnet dedicata e delegata al servizio, e fino ad oggi il numero massimo di vCore utilizzabili in quella subnet era vincolato a una quota unica per regione e sottoscrizione, condivisa indistintamente tra tutte le generazioni hardware disponibili (Standard-series, Premium-series e Premium-series Memory Optimized).

In pratica, se un team aveva già saturato la quota regionale con istanze su hardware Standard-series, non poteva provisionare una nuova istanza Premium-series nella stessa regione senza prima aprire una richiesta di supporto per l’aumento della quota, anche se la subnet stessa aveva ancora spazio IP disponibile. Un vincolo “trasversale” che poco aveva a che fare con la reale capacità di rete e molto con una limitazione amministrativa lato piattaforma, particolarmente dolorosa per chi gestisce deployment multi-tenant, ambienti di disaster recovery con failover group, o strategie di aggiornamento side-by-side che richiedono temporaneamente il doppio delle risorse.

Cosa cambia: quote per generazione hardware, non più una quota unica

Microsoft ha annunciato il passaggio a un modello di limiti semplificati e granulari: la quota regionale condivisa viene sostituita da quote indipendenti per ciascuna famiglia hardware. In altre parole, i vCore disponibili per Standard-series, quelli per Premium-series e quelli per Premium-series Memory Optimized vengono ora contabilizzati separatamente, e i deployment sono governati dai normali limiti di rete virtuale di Azure Resource Manager (ARM) piuttosto che da un vincolo specifico del servizio SQL MI.

Il cambiamento si applica sia ai deployment single-zone sia a quelli zone-redundant, e riguarda tutte le subnet delegate a Microsoft.Sql/managedInstances. Per i clienti esistenti la transizione è trasparente: le quote regionali di vCore attualmente in uso vengono convertite automaticamente nel nuovo modello per-hardware, senza necessità di riconfigurare le istanze già in esercizio.

Perché è rilevante per chi fa capacity planning

• Richieste di quota più mirate: se serve solo più capacità Premium-series Memory Optimized, non è più necessario negoziare un aumento che finirebbe per “gonfiare” anche lo spazio per le altre famiglie hardware.
• Pianificazione degli upgrade side-by-side più semplice: le operazioni che richiedono capacità aggiuntiva temporanea (ad esempio il passaggio da hardware Gen5 legacy a Standard-series) impattano ora solo la quota della famiglia hardware coinvolta.
• Meno attrito nei deployment multi-team: in sottoscrizioni condivise tra più team o applicazioni, un consumo intensivo di una famiglia hardware non blocca più il provisioning su un’altra famiglia nella stessa regione.

Cosa resta invariato: il dimensionamento della subnet

È importante non confondere questo cambiamento con un allentamento dei requisiti di rete: la subnet dedicata a Managed Instance deve continuare a rispettare i vincoli storici del servizio. Microsoft continua a raccomandare un blocco CIDR di almeno /27 (32 indirizzi) per garantire margine sufficiente a operazioni di manutenzione, failover e scaling, con /28 come limite minimo assoluto per ambienti realmente contenuti. Restano inoltre valide le regole che vietano di condividere la subnet con altre risorse non delegate e che richiedono una tabella di route e un gruppo di sicurezza di rete (NSG) dedicati e configurati secondo i requisiti del servizio.

Per chi deve verificare lo stato attuale delle quote, il percorso resta quello consueto tramite portale Azure, sotto Subscriptions > Usage + quotas filtrando per il provider Microsoft.Sql, oppure via Azure CLI:

az sql instance-pool list-usage --location "westeurope"

# oppure, per verificare i limiti di risorsa applicabili a una specifica instance pool
az sql instance-pool show --name mypool --resource-group myRG

Le richieste di aumento quota, quando necessarie, si effettuano ancora tramite una richiesta di supporto dedicata dal portale Azure, specificando ora la famiglia hardware interessata anziché una generica richiesta regionale.

Considerazioni pratiche per l’infrastruttura

Per chi sta pianificando una migrazione verso Managed Instance, o un ampliamento di un ambiente esistente, questo è un buon momento per rivedere la topologia di rete. Alcuni suggerimenti operativi:

• Documentate quale famiglia hardware usa ciascuna istanza nel vostro inventario CMDB o nei tag delle risorse: con quote separate, sapere “chi consuma cosa” diventa più rilevante per prevedere colli di bottiglia futuri.
• Rivedete le pipeline di provisioning IaC (Bicep, Terraform, ARM template): se avevate logica custom per gestire manualmente errori di quota condivisa, potete probabilmente semplificarla.
• Pianificate in anticipo gli upgrade di generazione hardware: sapere che la quota Premium-series è indipendente da quella Standard-series consente di programmare finestre di migrazione senza il rischio che un’altra applicazione “consumi” involontariamente la capacità necessaria.
• Verificate i failover group cross-region: assicuratevi che anche nella regione secondaria la quota per la famiglia hardware utilizzata sia sufficiente, dato che il DR richiede risorse equivalenti a quelle primarie.

Conclusione

Si tratta di una modifica infrastrutturale che non introduce nuove funzionalità visibili agli sviluppatori, ma che rimuove un attrito operativo reale per chi amministra ambienti Azure SQL Managed Instance su larga scala. Il passaggio da una quota condivisa a quote per hardware allinea meglio la governance delle risorse SQL a quella già in uso per il resto della rete virtuale, riduce le richieste di supporto necessarie per operazioni di routine e semplifica la pianificazione di capacity planning e upgrade. Per i team che gestiscono più applicazioni con esigenze hardware eterogenee nella stessa sottoscrizione, il beneficio pratico si vedrà già alla prossima richiesta di provisioning.

Fonte: Petri IT Knowledgebase – Azure SQL Managed Instance Removes a Capacity Planning Hurdle for Large Deployments