Fixed links

Author: dimitri-furman

articles/sql-database/sql-database-service-tiers-vcore.md

@@ -27,7 +27,7 @@ Service tier options in the vCore model include General Purpose, Business Critic
 |---|---|---|---|
 |Best for|Most business workloads. Offers budget-oriented, balanced, and scalable compute and storage options. |Offers business applications the highest resilience to failures by using several isolated replicas, and provides the highest I/O performance per database replica.|Most business workloads with highly scalable storage and read-scale requirements.  Offers higher resilience to failures by allowing configuration of more than one isolated database replica. |
 |Storage|Uses remote storage.<br/>**Single databases and elastic pools provisioned compute**:<br/>5 GB – 4 TB<br/>**Serverless compute**:<br/>5 GB - 3 TB<br/>**Managed Instance**: 32 GB - 8 TB |Uses local SSD storage.<br/>**Single databases and elastic pools provisioned compute**:<br/>5 GB – 4 TB<br/>**Managed Instance**:<br/>32 GB - 4 TB |Flexible autogrow of storage as needed. Supports up to 100 TB of storage. Uses local SSD storage for local buffer-pool cache and local data storage. Uses Azure remote storage as final long-term data store. |
-|IOPS and throughput (approximate)|**Single databases and elastic pools**: See resource limits for [single databases](../sql-database/sql-database-vcore-resource-limits-single-databases) and [elastic pools](../sql-database/sql-database-vcore-resource-limits-elastic-pools).<br/>**Managed Instance**: See [Overview Azure SQL Database managed instance resource limits](../sql-database/sql-database-managed-instance-resource-limits#service-tier-characteristics).|See resource limits for [single databases](../sql-database/sql-database-vcore-resource-limits-single-databases) and [elastic pools](../sql-database/sql-database-vcore-resource-limits-elastic-pools).|Hyperscale is a multi-tiered architecture with caching at multiple levels. Effective IOPS and throughput will depend on the workload.|
+|IOPS and throughput (approximate)|**Single databases and elastic pools**: See resource limits for [single databases](../sql-database/sql-database-vcore-resource-limits-single-databases.md) and [elastic pools](../sql-database/sql-database-vcore-resource-limits-elastic-pools.md).<br/>**Managed Instance**: See [Overview Azure SQL Database managed instance resource limits](../sql-database/sql-database-managed-instance-resource-limits.md#service-tier-characteristics).|See resource limits for [single databases](../sql-database/sql-database-vcore-resource-limits-single-databases.md) and [elastic pools](../sql-database/sql-database-vcore-resource-limits-elastic-pools.md).|Hyperscale is a multi-tiered architecture with caching at multiple levels. Effective IOPS and throughput will depend on the workload.|
 |Availability|1 replica, no read-scale replicas|3 replicas, 1 [read-scale replica](sql-database-read-scale-out.md),<br/>zone-redundant high availability (HA)|1 read-write replica, plus 0-4 [read-scale replicas](sql-database-read-scale-out.md)|
 |Backups|[Read-access geo-redundant storage (RA-GRS)](../storage/common/storage-designing-ha-apps-with-ragrs.md), 7-35 days (7 days by default)|[RA-GRS](../storage/common/storage-designing-ha-apps-with-ragrs.md), 7-35 days (7 days by default)|Snapshot-based backups in Azure remote storage. Restores use these snapshots for fast recovery. Backups are instantaneous and don't impact compute I/O performance. Restores are fast and aren't a size-of-data operation (taking minutes rather than hours or days).|
 |In-memory|Not supported|Supported|Not supported|