3.2 Configuring Azure SQL Managed Instance for Scale and Performance

Service Tiers and Sizing Model

Azure SQL Managed Instance (SQL MI) is the platform-as-a-service offering for workloads that need instance-level features - cross-database queries, SQL Server Agent, linked servers, CLR - with minimal re-engineering. Unlike Azure SQL Database, it is purchased only in the vCore model; there is no DTU option. Sizing has three independent levers: the number of vCores (4, 8, 16, 24, 32, 40, 64, or 80), the amount of reserved storage, and the hardware configuration.

There are three service tiers:

• General Purpose stores data and log files on remote Azure premium storage. Compute and storage are scaled and billed independently, and storage can be reserved up to 16 TB depending on vCore count. Latency is higher (single-digit to low double-digit milliseconds) because I/O traverses the network. This is the default, budget-oriented tier.
• Business Critical places the database on local SSD and maintains an Always On availability group with multiple replicas behind the scenes, one of which is a free readable secondary for read scale-out (accessed with ApplicationIntent=ReadOnly, exactly as with Azure SQL Database). Local storage caps capacity lower than General Purpose (a few TB depending on vCore count and hardware), but delivers 1-2 ms I/O latency and in-memory OLTP.
• Next-gen General Purpose keeps the General Purpose pricing posture but moves storage to newer managed disk technology with substantially better IOPS and throughput, closing much of the performance gap to Business Critical. When an exam scenario needs General Purpose economics with better storage performance and does not require a readable secondary, this tier is the intended answer.

Hardware Generations

Within a tier you select a hardware configuration. Standard-series (Gen5) is the baseline. Premium-series offers better compute and storage performance per vCore, and memory-optimized premium-series roughly doubles the memory-to-vCore ratio for buffer-hungry workloads that do not need more CPU. Hardware choice also affects maximum storage throughput and IOPS caps, so a scenario describing I/O-bound performance on undersized memory often resolves to switching to memory-optimized hardware rather than adding vCores.

Instance Pools

An instance pool is a pre-provisioned compute envelope inside a virtual network into which you deploy multiple managed instances that share the pool's total vCore allocation. Two facts are heavily tested. First, instance pools are the only way to get a 2-vCore managed instance - standalone instances start at 4 vCores. Second, pools are a consolidation play: they suit migrations of many small SQL Server instances (each with a handful of databases) that individually need instance features but collectively underutilize their hardware. All instances in a pool must reside in the same virtual network and subnet, all share the pool's service tier, and the combined compute of the hosted instances cannot exceed the pool size. Creating the pool itself is a long-running operation, but deploying additional instances into an existing pool is fast - which makes pools attractive when you need rapid instance provisioning. The tradeoff to cite on the exam: sharing compute reintroduces the noisy-neighbor risk that dedicated instances avoid, so pools fit spiky, non-overlapping workloads rather than uniformly busy ones.

Zone Redundancy

Zone redundancy spreads an instance's replicas across physically separate availability zones within a region, protecting against datacenter-level failures rather than just hardware failures. For Business Critical, the availability group replicas are pinned to different zones; for General Purpose, compute is placed so a standby is ready in another zone while storage is already zone-redundant. Zone redundancy is available only in regions that support availability zones, carries no application-side changes (failover is transparent beyond reconnecting), and adds cost because extra standby capacity is provisioned. The exam contrast to draw: zone redundancy protects against datacenter loss within one region; failover groups protect against regional loss. A scenario asking for the lowest-latency protection against a datacenter outage, without a second region, points to zone redundancy.

Scaling Operations and Failover Behavior

SQL MI supports online changes to vCore count, reserved storage, and hardware generation. The instance keeps serving traffic while the service prepares the new configuration; the operation completes with a failover-style switchover that drops active connections for a few seconds. This is the same operational contract as scaling Azure SQL Database: brief downtime at the end, retry logic mandatory, and the 99.99% availability SLA preserved throughout. Several nuances matter for the exam:

• vCore and storage changes within a tier are metadata-and-compute operations; storage on General Purpose can be grown (and in current generations shrunk) without moving data.
• Changing service tier between General Purpose and Business Critical requires copying the databases onto the new storage architecture, so it is a size-of-data operation - plan for hours on multi-terabyte instances even though the instance stays reachable until the final cutover.
• Changing hardware generation similarly provisions new compute and ends in a failover.
• Creating a brand-new managed instance (outside a pool) is one of the longest provisioning operations in Azure - historically several hours - so an exam scenario that requires fast, repeatable instance deployment is steering you toward instance pools.

A final trap: because failover drops connections mid-transaction, any scaling or tier-change operation should be scheduled in a maintenance window, and applications should use transient-fault retry logic with backoff. Also note that scaling does not change the virtual cluster or connection endpoint - the instance's fully qualified domain name stays constant, so no connection string changes are needed after the operation completes.