Cost Optimization practice questions

Azure Cosmos DB

Why it fails: Cosmos DB is a multi-model NoSQL service built for globally distributed document, key-value, column-family, and graph workloads. It exposes SQL/MongoDB/Cassandra-compatible APIs and stores data in partitions, but it has no concept of static files, no web server endpoint, and cannot serve HTML/JS/CSS to browsers as a hosted website.

Azure NetApp Files

Why it fails: Azure NetApp Files is an enterprise-grade file service backed by NetApp ONTAP, providing high-performance NFS and SMB shares for HPC, SAP, and VDI workloads. It operates at the file-system protocol layer over the network and has no HTTP-based content serving, no `$web` container, and no static website hosting capability.

Azure Files

Why it fails: Azure Files provides managed SMB and NFS file shares for lift-and-shift migrations, shared application data, and Azure File Sync scenarios. It presents a standard file share path (e.g., UNC or mount point) and has no HTTP/S static content engine, so it cannot translate a directory of HTML files into a browsable, publicly accessible website.

Azure Blueprints

Why it fails: Azure Blueprints were a packaging service that bundled templates, policies, and RBAC assignments into a single deployable artifact, but they are deprecated and no longer recommended. Blueprints do not provide a persistent governance hierarchy; they simply orchestrate deployment, whereas management groups offer ongoing, inherited governance. Azure now recommends using management groups combined with policy assignments and deployment stacks as a modern replacement.

Resource tags

Why it fails: Resource tags are key-value pairs attached to resources for metadata, cost allocation, and filtering, but they are not a governance mechanism. Tags do not enforce compliance, provide hierarchical inheritance, or manage access across subscriptions. While policies can require or generate tags, tags themselves cannot organize resources for cross-subscription policy or cost management.

Resource groups

Why it fails: Resource groups are logical containers that group related resources within a single subscription, offering management and lifecycle operations like templates and access control. However, they cannot span multiple subscriptions, do not inherit policies across subscriptions, and lack the organizational hierarchy needed for enterprise-wide governance. Resource groups are operational scopes, not governance structures for the entire Azure environment.

Create a manual inventory of all servers and use Azure Pricing Calculator to estimate costs.

Why it fails: A manual inventory relies on spreadsheets and human data entry, which is error-prone and quickly outdated. More importantly, it captures only static specifications (vCPU, RAM, disk size) and omits utilization rates, performance counters, and application dependencies that determine appropriate Azure VM sizing. The Azure Pricing Calculator can price a manually specified VM, but it cannot discover or right-size the workload, so the resulting estimate is often inaccurate for a migration at scale.

Use Azure Advisor to analyze on-premises server usage and recommend Azure VM sizes.

Why it fails: Azure Advisor is a personalized cloud consultant that analyzes existing Azure subscriptions and resources to provide recommendations on high availability, security, performance, and cost. It cannot connect to or scan on-premises infrastructure, so it cannot discover server workloads or collect utilization metrics needed for migration sizing. At best, Advisor would only help after migration, not for assessing the source environment.

Use Azure Cost Management to estimate costs based on manual input of server specifications.

Why it fails: Azure Cost Management is a monitoring and governance tool for tracking spend on resources already running in Azure, offering budgets, alerts, and cost analysis. It has no discovery capability and no assessment logic to identify on-premises servers or infer their Azure VM equivalents. Manually entering specifications into Cost Management is not a supported workflow; that function belongs to Azure Migrate or the Azure Pricing Calculator, so this approach misses dependency mapping and rightsizing.

Use the Cool tier for initial storage, and a lifecycle rule to move to Archive after 30 days.

Why it fails: Cool tier is for data accessed infrequently but with immediate availability. Using Cool for the first 30 days may increase cost compared to Hot because Cool has higher read costs and lower storage cost, but Hot is cheaper for frequent access. More importantly, the requirement is to minimize cost, and Hot then Archive is the optimal path.

Use the Hot tier for initial storage, and a lifecycle rule to move to the Cool tier after 30 days, then to Archive after 7 years.

Why it fails: This two-step transition is inefficient and more expensive. Moving blobs from Hot to Cool after 30 days incurs a write operation cost, and then moving them again from Cool to Archive after 7 years incurs an additional transition cost, but the data is rarely accessed and can go directly from Hot to Archive. Moreover, Cool tier storage is more expensive than Archive, so holding the data in Cool for nearly the entire 7-year retention period defeats the goal of minimizing cost. A single lifecycle rule from Hot to Archive after 30 days achieves the same retention with lower operational and storage costs.

Use the Archive tier for initial storage, and a lifecycle rule to move to Hot for the first 30 days.

Why it fails: Storing logs in Archive from day one is impractical because Archive is optimized for rarely accessed data with retrieval latency measured in hours. Any reads to these logs during the first 30 days would trigger rehydration, incurring substantial costs and delays, and the lifecycle rule to move them to Hot would also require rehydration and a costly archival read operation. This arrangement inverts the required access pattern: frequent reads require Hot, not Archive. The correct design is to keep data hot for initial access and then transition to Archive to minimize cost.

Use Hot tier for 30 days, then use Cool tier for 7 years, with a lifecycle rule to delete after 7 years.

Why it fails: Using the Cool tier for a seven-year retention period overlooks that Archive tier provides a substantially lower storage price for data that is no longer actively accessed. While the lifecycle rule correctly automates deletion after 7 years, the Cool tier's storage rate is significantly higher than Archive for long-lived, rarely read data, making this solution unnecessarily expensive over the retention period. Since the data is only frequently accessed for the first 30 days, Cool tier is an economically suboptimal middle ground for the remaining 6+ years.

Use Cool tier for 30 days, then use Archive tier for 7 years, no lifecycle rule needed.

Why it fails: Choosing Cool tier for the initial 30 days is cost-inefficient because Cool tier has higher per-GB read and retrieval costs than Hot tier, which already offers the lowest access costs for frequently used data. Additionally, without a lifecycle rule, the data will never be automatically deleted after 7 years, resulting in ongoing storage charges indefinitely. The correct pattern pairs a Hot tier for frequent reads with an Archive tier for infrequent, long-term retention, coupled with a lifecycle policy that deletes the blob at a specific age.

Use Archive tier immediately, with a lifecycle rule to delete after 7 years.

Why it fails: Placing data directly into Archive tier fails to account for the high frequency of access during the first 30 days; Archive tier's retrieval latency (typically minutes to hours) and per-GB read charges make it inappropriate for active use. Although the lifecycle rule handles the eventual deletion correctly, immediate archiving would force repeated expensive rehydration operations for the very data users need most often. A tiering strategy must match early access patterns with Hot tier, then transition to Archive only once the data becomes rarely accessed.

B

Why it fails: Creating a second Recovery Services vault in North Europe and backing up to both vaults substantially increases operational overhead and storage cost because the same SQL Server databases would be protected twice. The SQL IaaS Agent extension registers the VM with a single vault; backing up to a second vault requires a second backup schedule and duplicate metadata, and you still need to enable cross-region restore anyway to meet the DR objective. Azure Backup's built-in CRR already replicates the same vault data to North Europe, so a separate vault adds unnecessary complexity with no additional resilience benefit.

C

Why it fails: Manually copying .bak files (or using SQL Server Managed Backup to a storage account) to a North Europe storage account is a fragile, labor-intensive process that requires custom scripts, scheduling, and monitoring to stay current with the transaction log chain. Unlike Azure Backup, which orchestrates backups, verifies consistency, and manages retention automatically, a manual copy introduces a significant window of data loss between copies, risks corruption or incomplete file sets, and does not provide a native restore experience. This approach is not scalable for production SQL Server workloads and lacks the built-in cross-region restore capabilities that are available with a Recovery Services vault.

D

Why it fails: Azure Site Recovery (ASR) is a disaster-recovery service that replicates entire VMs for failover, not a backup service for SQL Server databases. ASR recovery points are snapshots of the entire VM with limited retention (typically up to 72 hours), and it does not support SQL Server–consistent point-in-time restore or long-term retention of transaction log backups. While ASR could be used alongside Azure Backup, it cannot replace it, and mixing the two does not address the requirement for long-term backup retention with cross-region restore. The correct service for database-level backup, log chains, and retention is Azure Backup, not ASR.

Single-master write region with Strong consistency and multiple read regions

Why it fails: A single-master write region with strong consistency requires every write to be synchronously replicated to all read regions before acknowledging the client, so write latency scales with the distance to the farthest region and can be significantly higher than necessary. This configuration also reduces write availability because if any read region is unreachable or unhealthy, writes cannot be committed, risking availability during a partial regional outage. Since the application only needs per-user session consistency, strong consistency is an unnecessary and costly over-provisioning that does not align with the global e-commerce reading pattern, where reads dominate and writes are localized.

Multi-master write with Eventual consistency and all regions enabled for writes

Why it fails: Enabling all regions for writes (multi-master) is unjustified because the application receives writes from only one region, so a single write region avoids the need for conflict-resolution logic and reduces operational cost. Eventual consistency, without session tokens, cannot guarantee that a user reads the data they just wrote within the same session; they might see stale or conflicting data as reads are served from different regions. This directly violates the explicit session consistency requirement while adding unnecessary write-write conflict handling, higher complexity, and no tangible benefit for a workload with a single write location.

Multi-master write with Strong consistency and two regions

Why it fails: This configuration is invalid in Azure Cosmos DB because strong consistency is not supported when multiple write regions are enabled; the service only allows strong consistency with a single write region, making a multi-master strong-consistency topology technically impossible. Even if it were possible, combining strong consistency with multi-master would force every write to be synchronously replicated across all regions before acknowledgment, which eliminates the latency benefits of multi-master writes and significantly increases both write latency and RU consumption. Since writes originate from only one region and the application only requires session consistency, this approach is overkill, unsupported, and not aligned with the stated requirements.

Deploy the application on Azure Kubernetes Service (AKS) and use Azure Database for PostgreSQL.

Why it fails: AKS supplies a resilient Kubernetes control plane, but it imposes ongoing cluster lifecycle duties on the development team: managing node pools, patching the OS and kubelet, configuring ingress controllers, monitoring resource quotas, and upgrading Kubernetes versions. Even though Azure Database for PostgreSQL reduces database admin, the containerized app still must be built, configured, and operated as a workload on the cluster, which substantially exceeds the management overhead of a single App Service instance. This trade-off only pays off for larger microservice teams and custom infrastructure requirements, not for a startup's straightforward web application.

Deploy the application as Azure Functions and use Azure Cosmos DB for storage.

Why it fails: Azure Functions is a serverless compute platform optimized for event-driven triggers and transient execution, with a maximum execution timeout and cold-start latency that make it unsuitable for consistent, stateful web request serving to users. Cosmos DB is a NoSQL, multi-model database, not a relational PostgreSQL source, so any existing SQL schema, joins, transactions, or object-relational mapping would require substantial redesign. The combination fails both the compute model and the relational storage expectations of a typical web application.

Deploy the application on Azure Virtual Machines and use PostgreSQL on the same VM.

Why it fails: Deploying on Azure Virtual Machines creates an IaaS footprint where the startup is solely responsible for patching the guest OS, installing PostgreSQL, managing backups and high availability, storing database files, and handling scaling via VM resizing or replicated endpoints. Additionally, hosting the web app and database on the same VM couples compute and storage on one hardware boundary, creating a single point of failure and making it impossible to independently scale either tier. This operational burden directly contradicts the requirement to minimize management overhead.

Move to Cool tier after 30 days, move to Archive tier after 365 days, delete after 7 years

Why it fails: The flaw is not the tier transitions but the deletion expression: '7 years' is not a valid Azure lifecycle numeric value. Azure lifecycle management rules only accept integers for 'days after creation' or 'days after last modification', so the policy would be rejected at validation time. Using '2555 days' is the correct equivalent for 7 years and removes ambiguity around leap-year intervals; therefore this option fails because the rule cannot be executed as written.

Move to Cool tier after 30 days, move to Archive tier after 30 days, delete after 2555 days

Why it fails: Moving to Archive after only 30 days violates the intended access pattern: for the first year logs are accessed occasionally, and Cool tier is designed for that exactly—it offers lower storage cost than Hot while still allowing near-real-time reads. Archive, by contrast, requires rehydration and can add minutes to hours of latency before access. If you transition to Archive at day 30, you'll incur unnecessary retrieval and rehydration costs for every one of the occasional accesses during the remaining 335 days, which is more expensive than leaving the data in Cool.

Move to Archive tier after 30 days, keep in Archive until deletion after 2555 days

Why it fails: Skipping Cool and placing logs into Archive at day 30 means the most frequently used period (the first 30 days) remains Hot, but from day 31 through day 365, when logs are still occasionally queried, you're hit with Archive's rehydration latency and per-GB retrieval charges. Also, once a blob is in Archive it cannot be read directly; you must 'rehydrate' it, adding operational complexity and cost for each access. The correct sequence is Hot→Cool→Archive, so this option misplaces the first-year data and penalizes normal operational workflows.

Azure Blob Storage with Azure Data Lake Storage Gen2

Why it fails: Blob Storage with ADLS Gen2 is a valid, cost-effective landing zone for raw IoT telemetry, offering massive scale and lifecycle management. However, it is an object store, not a query engine: it has no native time-series indexing, partitioning, or retention-aware query semantics, and no built-in KQL/SQL-style analytics. Any exploration requires an external service such as Azure Data Explorer, Databricks, or Synapse to read the files, adding latency and operational complexity that conflicts with real-time and interactive historical analysis.

Azure SQL Database

Why it fails: Azure SQL Database uses a row-oriented, transactional engine with B-tree indexes that are optimized for OLTP workflows, not the compound-write, append-heavy pattern of IoT telemetry. Sustained ingestion from millions of devices would force heavy DTU/vCore consumption and frequent index maintenance, while lookups by time range become expensive because there is no native time-series partitioning or compression. The required throughput would require massive over-provisioning, making it cost-prohibitive for this workload.

Azure Cosmos DB with SQL API

Why it fails: Cosmos DB is an excellent globally distributed multi-model database, but its SQL API charges request units (RUs) per operation, so the constant high-velocity writes from millions of devices translate into enormous, predictable RU expenditure. Its index is document-centric and does not provide columnar compression or time-series aggregation functions, so typical telemetry queries like 'average temperature per hour over 30 days' require client-side aggregation or expensive scans. Additionally, Cosmos DB struggles with long-range, scan-heavy analytical queries, making it a poor fit for this scenario.

Hot tier

Why it fails: Hot tier is designed for frequently accessed data and carries the highest per-GB storage price, with no early-deletion penalty but premium capacity costs. Since the video files are touched only once each month, you would be provisioning high-cost storage for long idle periods, making it economically unjustified. The access latency is identical to Cool tier, so you gain no operational benefit that compensates for the extra storage expense.

Cold tier

Why it fails: Cold tier lowers the base storage cost but imposes a higher per-GB retrieval fee and a mandatory 90-day retention period, which does not match a 30-day access cadence. Over the course of a year, the cumulative retrieval charges for twelve monthly reads can quickly erase the storage savings relative to Cool tier. Additionally, the 90-day minimum means you would either pay early-deletion fees or keep data longer than the business needs, further increasing cost.

Archive tier

Why it fails: Archive tier is the least expensive for static data, but it stores blobs in an offline state that requires manual rehydration to a readable tier, a process that can take up to 15 hours. For a media company that must access a video every month, this delay is operationally unacceptable, and rehydration also incurs additional read and write costs. Even if you schedule the rehydration in advance, the complexity and unpredictability make Archive unsuitable for a predictable 30-day access pattern.

SQL Server Always On Availability Group with asynchronous commit.

Why it fails: With asynchronous commit, the primary replica accepts a transaction and acknowledges it without waiting for the secondary replica to harden that log block. Under normal operation the secondary stays near-real-time, but any lag—network latency, heavy log volume, or a regional disruption—creates a window where committed transactions on the primary are absent from the secondary. If a failover is triggered during that window, those transactions are lost, so the recovery point objective (RPO) is non-zero. Because the requirement mandates zero data loss, asynchronous commit fails even though it avoids the performance penalty of synchronous replication.

Azure Site Recovery to another region.

Why it fails: Azure Site Recovery continuously copies Azure VM disks asynchronously, producing recovery points that are typically 5–15 minutes old, and it is not application-aware for SQL Server transactional consistency. Even when application-consistent snapshots are enabled, ASR only guarantees that VSS-backed applications are in a consistent state at the snapshot moment—it does not guarantee that every SQL transaction committed before failure is included in the recovered copy. A database failover via ASR therefore restores to a point in time before the outage, losing any transactions committed after the last captured recovery point. This cannot satisfy an RPO of zero and is better suited for crash-consistent DR where limited data loss is acceptable.

Deploy the VMs in a different availability zone within the same region.

Why it fails: Deploying the SQL Server VMs in separate availability zones places them in different fault domains and power/cooling/network domains within the same Azure region, which protects against a single datacenter failure but not an outage that takes down the entire region. A regional event—such as a natural disaster or a large-scale platform failure affecting all zones—would still make the database unavailable, and the cluster or AG replicas would be in the same regional blast radius. The requirement explicitly says 'across regions,' so zone-level redundancy is technically outside the scope. While zones do help with in-region SLA, they do not provide cross-region disaster recovery or guarantee zero RPO for a regional outage.

Deploy an active-passive configuration with Azure Front Door and Traffic Manager

Why it fails: Azure Front Door and Traffic Manager provide global DNS/HTTP load balancing and health-based traffic steering, but they do not replicate VM disks, memory, or application state. An active-passive configuration only directs user traffic to a pre-provisioned secondary site; unless the VMs themselves are continuously replicated to that site, a failover would present stale or missing data, failing the 15-second RPO and minute-level RTO. Additional replication infrastructure would be required, making this incomplete and insufficient.

Configure the VMs in an availability zone across East US and West US

Why it fails: Availability zones are physically separate datacenters located within the same Azure region, so you cannot span a single availability zone across East US and West US, which are distinct regions. Deploying VMs across availability zones within one region only provides resilience against local datacenter failures, not against a regional catastrophe. This option confuses high availability within a region with disaster recovery across regions.

Use Azure Backup with cross-region restore for the VMs

Why it fails: Azure Backup for VMs relies on scheduled snapshot-based backups, with the default policy capturing a recovery point once per day, yielding an RPO of up to 24 hours—far looser than the required 15 seconds. While cross-region restore can copy backup data to another region, the restore point's age and the time required to materialize a VM from backup mean the RTO is unlikely to be in minutes. Thus it protects against data loss but not the near-zero RPO/RTO required here.

Azure Files with SMB protocol

Why it fails: Azure Files provides managed SMB/NFS file shares intended for lift-and-shift file servers and application sharing, not for HTTP-based web serving. It exposes no native static website endpoint, and the SMB protocol is unsuitable for anonymous internet browser clients. Serving a website from Azure Files would require an additional web server or VM to translate SMB into HTTP, making it an inefficient and awkward storage solution.

Azure Content Delivery Network only

Why it fails: Azure CDN is a caching and delivery layer that accelerates content but cannot store or serve the original website files by itself. A CDN endpoint must point to a backend origin, such as Azure Blob Storage or a web server, otherwise there is no source of truth for the content. Without a storage origin, the site has no durable, highly available files to cache, so CDN alone fails as the primary storage solution.

Azure App Service

Why it fails: Azure App Service is a fully managed compute platform designed for dynamic web apps, APIs, and background jobs that need server-side code execution. Hosting immutable static assets on App Service wastes compute resources and costs more than optimized object storage, even though it can technically serve static files. For a purely content-based site, Blob Storage paired with CDN delivers faster and more economical performance than a dedicated app-hosting tier.

Use Azure SQL Database active geo-replication for the database and Azure Backup for VMs.

Why it fails: Active geo-replication is intended for read-scale scenarios: it maintains a readable secondary replica but lacks automatic failover, requiring manual promotion and application-level monitoring to redirect connections. Azure Backup for VMs, meanwhile, takes scheduled snapshots at daily or coarser intervals with a default RPO around 24 hours, not continuous replication. Together they do not provide the low RPO or automated failover needed for disaster recovery.

Use Azure Backup to back up VMs and Azure SQL Database to a secondary region.

Why it fails: Azure Backup copies virtual machines and Azure SQL Database to a Recovery Services vault, which may be geo-redundant, but those are point-in-time backups, not live replicas. The default backup frequency for VMs is 24 hours, and even SQL backups are snapshots rather than continuously applied transaction log replication. That yields an RPO far higher than the required 1-hour objective and requires full restore before the workload is usable, both of which fail the stated DR requirements.

Use Azure Traffic Manager to distribute traffic to VMs in multiple regions and Azure SQL Database failover groups.

Why it fails: Traffic Manager is a DNS-based load balancer that routes traffic only to endpoints that already exist and are healthy; it does not provision, replicate, or cold-start VMs in a secondary region. While SQL Database failover groups handle the database tier, the VM tier has no presence in the secondary region, so redirected traffic would have no compute resource to serve it. The solution therefore addresses availability but not the actual replication of compute, missing the RPO and RTO targets.

Enable VM insights in Azure Monitor and use its live map and performance views for historical analysis.

Why it fails: VM insights in Azure Monitor delivers interactive views of VM health and dependencies, but its live map and performance views are intended for real-time troubleshooting, not long-term historical trend analysis. To analyze past performance you'd need to query the Log Analytics workspace with KQL, which this option does not mention. Furthermore, VM insights does not by itself create proactive alerts; alert rules must be explicitly defined, so this approach lacks both critical capabilities required by the solution.

Configure Azure Autoscale for the VMs based on CPU metrics and use Azure Monitor for logging.

Why it fails: Configuring Azure Autoscale to scale VMs based on CPU metrics addresses infrastructure capacity changes but does nothing to analyze historical performance trends; autoscale rules only act on the current metric value. While Azure Monitor for logging can store operational data, simply logging without a Log Analytics query layer or alert rules cannot provide proactive notifications or trend analysis. This option conflates scaling actions with monitoring and analysis, leaving the mission-critical performance data unexamined.

Deploy Application Insights on each VM and use its built-in alerts for performance.

Why it fails: Application Insights is an application performance monitoring (APM) service that instruments the application code via SDKs or the Application Insights agent to track server-side application telemetry such as requests, dependencies, and exceptions. It does not collect VM-level guest OS metrics like overall CPU or memory utilization, which are the very metrics your solution requires. Adding Application Insights to each VM would monitor the app's behavior but would fail to provide alerts and historical analysis for the underlying virtual machine's resource consumption, so this option does not meet the stated monitoring requirements.

Azure Disk Storage Standard HDD with shared disks

Why it fails: Azure Disk Storage Standard HDD with shared disks is a block-level storage solution, not a managed file-sharing service. Shared disks attach to multiple VMs via SCSI and require you to build and operate your own clustered file server (e.g., Windows Server Failover Clustering) on top of them to expose any SMB file sharing. This approach adds significant management overhead, has strict SCSI persistent reservation limitations, and does not directly replace an on-premises file server with a simple, fully managed file share.

Azure NetApp Files Standard tier with cross-region replication

Why it fails: Azure NetApp Files Standard tier with cross-region replication delivers high-performance enterprise file services for workloads that require low latency, advanced networking, or multi-region disaster recovery. However, it is considerably more expensive and operationally complex than Azure Files Standard tier, especially when you add cross-region replication, and it is overprovisioned for a small business just migrating a file server. For a straightforward SMB share with on-premises caching, Azure NetApp Files introduces unnecessary cost and capabilities that do not align with the scenario.

Azure Blob Storage Cool tier with Azure Storage Explorer

Why it fails: Azure Blob Storage Cool tier is an object storage service that does not provide native SMB access, so it cannot serve as a direct replacement for an on-premises file server. Azure Storage Explorer is merely a management and browsing tool for blobs; it does not expose a network share that existing file clients can map to a drive, nor does it preserve NTFS ACLs or Windows file semantics. While Blob Storage is excellent for object workloads and backups, it lacks the file-level protocol and permission model required by a Windows file server migration.

Deploy a second set of VMs in a secondary region. Use Azure File Sync to keep Azure Files in sync. Use Azure SQL Database failover groups with a readable secondary.

Why it fails: Deploying an always-on second set of VMs in a secondary region is not the optimal DR pattern because it requires continuous compute spend and licensing for idle capacity, whereas Azure Site Recovery provides pay-as-you-go replication and only starts VMs during a failover. Azure File Sync is designed for hybrid scenarios—syncing on-premises file servers to Azure and caching shares across sites—not as a primary cross-region disaster recovery mechanism for Azure Files, and it does not provide automatic failover of the Azure file share itself. Moreover, Azure SQL Database Hyperscale does not support failover groups or readable secondary replicas; Hyperscale uses named replicas, so the proposed failover group with a readable secondary is technically invalid for this service tier, making the combination incorrect.

Back up the VMs using Azure Backup with a 15-minute frequency. Use Azure File Sync to replicate Azure Files to a secondary region. Use Azure SQL Database backup with point-in-time restore.

Why it fails: Azure Backup for Azure VMs does not support a 15-minute backup frequency—the minimum for scheduled VM backups is one hour—so this option cannot satisfy the 15-minute RPO for compute. Additionally, Azure File Sync is not a substitute for geo-redundant storage for Azure Files DR; it is intended for hybrid multi-site sync and caching, not for replicating an Azure file share to a secondary region for automatic failover, and it lacks a built-in regional failover mechanism. For SQL Database, point-in-time restore (PITR) restores to a specified time from backups, but the restore process can take hours depending on database size, so it generally cannot meet a strict 15-minute RTO; you would need geo-replication or geo-restore for faster recovery, making this backup-centric approach insufficient.

Use Azure Site Recovery for VMs. Use Azure File Sync for Azure Files. Use active geo-replication for Azure SQL Database.

Why it fails: Azure File Sync for Azure Files is primarily designed for hybrid cloud scenarios, extending Azure file shares to on-premises servers, or for multi-site caching, not as a primary cross-region disaster recovery mechanism with a strict 15-minute RPO. While it facilitates replication, its RPO and RTO capabilities for a full Azure Files share failover between regions are not optimised for such tight requirements. This option is tempting as "sync" implies replication, and it is ideal for consolidating file server capabilities into Azure while maintaining local access or for distributing a single namespace across multiple locations.

Premium tier.

Why it fails: Azure Premium Block Blob Storage is designed for high-throughput, low-latency workloads that require single-digit millisecond response times, using SSD-backed accounts that substantially increase per-GB storage cost. For a large set of unstructured images that are accessed infrequently, this tier is over-provisioned and not cost-effective. Its pricing model is based on high IOPS and performance, not on storage efficiency for occasional reads, so it does not meet the business requirement of minimizing cost while allowing retrieval within minutes.

Archive tier.

Why it fails: The Archive tier stores blobs in an offline state, meaning data cannot be read directly and must first be rehydrated to Hot or Cool before access. Rehydration time with standard priority can take up to 15 hours, and even high-priority rehydration typically takes about one hour—so retrieval is far from 'within minutes.' Additionally, Archive imposes a 180-day minimum storage duration, and early deletion incurs penalty charges, making it unsuitable for any workflow that needs timely access.

Hot tier.

Why it fails: The Hot tier is optimized for high-frequency access, with the highest storage cost per GB among the live access tiers and lower per-transaction charges. If the images are only read occasionally, you would be paying a premium for storage capacity that sits idle between accesses. While data is always immediately available, the overall cost for infrequent access is excessive compared with Cool, making Hot the wrong choice for a cost-conscious workload where images are not accessed on a regular basis.

Azure SQL Database single database with reserved capacity

Why it fails: With Azure SQL Database reserved capacity, you commit to a one- or three-year compute plan for a single database, but that database is still isolated and billed for its own DTUs or vCores. Each database must be provisioned for its individual peak, so intermittent spikes force you to overprovision per DB; the reservation discount only lowers the unit price, it does not let idle capacity in one database be used by another. As a result, many small databases end up with high aggregate provisioned throughput and wasted spend compared to a shared elastic pool.

Azure SQL Managed Instance

Why it fails: Azure SQL Managed Instance is intended for lift-and-shift migrations that need near-complete SQL Server instance-level compatibility, but it runs on a dedicated set of vCores and storage that are billed as a single instance, not per database. This means all your small databases share a fixed resource allocation, and you pay for the compute and capacity of that instance even if each database only uses a tiny fraction of it. Unlike an elastic pool, there is no fine-grained per-database resource control, and adding a new database doesn't increase pool capacity cheaply; it simply uses more of the instance's already-provisioned resources.

SQL Server on Azure Virtual Machines

Why it fails: Running SQL Server on Azure VMs places the entire database engine on a virtual machine where you must size the VM, manage SQL Server configuration, apply OS and SQL patches, and maintain high availability with manual or automated processes. Each VM has fixed vCPU and memory resources, so to support many small databases you either overprovision multiple VMs or manually hyper-converge them onto one instance with complex resource governance. There is no Azure-native elastic pooling or per-database scaling, and you pay continuous VM compute costs plus licensing (bring-your-own or included) regardless of how lightly the databases are used, making it far more expensive than an elastic pool.