S&P Global Market Intelligence has built a cross-region disaster recovery design for its Capital IQ platform on Amazon FSx for NetApp ONTAP, using SnapMirror snapshots and FlexClone volumes to make a read-only SQL Server environment available in AWS’s US-West-2 region within 15 minutes. The interesting part is not that a financial-data giant moved another workload to the cloud. It is that S&P Global chose not to treat disaster recovery as a binary switch between dead and fully restored. As detailed by AWS’s Architecture Blog in a post co-written with Nishanth Charlakola of S&P Global, the company’s design separates continuity of access from full read-write recovery — and that distinction is where the architectural lesson lives.
Most disaster recovery plans are written as if the only meaningful question is whether the secondary site can become the primary site. That framing is tidy for diagrams and audit binders, but it does not match how users experience outages. For customers depending on financial intelligence, market data, and corporate fundamentals, losing the ability to read trusted data can be nearly as damaging as losing the ability to write new transactions.
S&P Global Market Intelligence’s Capital IQ platform sits in that uncomfortable zone where stale or unavailable data can quickly become a business problem. The platform serves global clients who use it for decision-making, reporting, and analysis. In that context, disaster recovery is not merely a back-office resiliency exercise; it is part of the customer experience.
The AWS write-up says the business requirement was specific: once the decision to fail over had been made, the disaster recovery read-only system had to become operational and accessible within 15 minutes. That is a useful number because it forces the architecture away from vague resilience language and toward operational mechanics. The system either presents usable data in the secondary region inside that window, or it does not.
The trick is that S&P Global did not try to make every part of the platform instantly read-write in the disaster region. Instead, it accepted a more nuanced model: get customers back to essential information quickly in read-only mode, then execute the heavier process required to resume full read-write operations. That is not a compromise disguised as innovation. It is an acknowledgment that not every recovery objective carries the same urgency.
That matters because disaster recovery runbooks often fail at the seams between infrastructure readiness and application cutover. Storage might be replicated, compute might exist, and networks might be routable, but the actual recovery clock keeps running while teams connect those pieces under stress. S&P Global’s design reduces the first failover action to something closer to redirection than reconstruction.
FlexClone is doing important work here. In NetApp ONTAP terms, a FlexClone volume can be created from a snapshot while sharing unchanged data blocks with its parent. That makes it fast and space-efficient compared with building a full independent copy. In S&P Global’s case, AWS says FlexClone creation completes in under two minutes, which leaves most of the 15-minute window for validation and traffic cutover rather than storage provisioning.
There is also a subtle operational benefit: the clone is independent of the active SnapMirror relationship. That means the disaster recovery read-only instance can serve traffic without interrupting ongoing replication from the production environment. The clone represents a consistent point in time; the replication relationship continues doing its job.
This is the kind of storage architecture that looks old-fashioned and modern at the same time. Snapshots, clones, and replication are not new ideas. But packaging them inside a managed AWS file service, then wiring them into a cloud-region failover plan for SQL Server, gives an old storage discipline a more contemporary operating model.
SQL Server disaster recovery is full of sharp edges because the database is rarely the only thing that matters. Storage consistency, cluster behavior, application connection strings, identity, DNS, network paths, and release processes all become part of the recovery story. The AWS post describes a compute layer spanning regions, storage on two FSx for ONTAP file systems, SnapMirror replication from US-East-1 to US-West-2 at 15-minute intervals, and FlexClone volumes for rapid recovery.
That combination signals a hybrid of familiar Windows enterprise patterns and cloud-native service consumption. The cluster and SQL Server topology still require the kind of discipline Windows administrators already know. But the storage layer shifts from self-managed ONTAP infrastructure to Amazon FSx for NetApp ONTAP, which preserves ONTAP features while moving the operational burden into a managed service.
This is why the example is more interesting than a simple “we moved to AWS” story. Many enterprises do not want to throw away battle-tested storage and database patterns just because the infrastructure is now cloud-hosted. S&P Global’s design suggests another path: keep the semantics that matter, change the substrate, and only modernize where the cloud actually improves the outcome.
RTO and RPO are too often treated as ceremonial acronyms. Recovery Time Objective is the time it should take to restore service; Recovery Point Objective is the amount of data loss the business is prepared to tolerate. In real systems, neither number is magic. They are products of replication intervals, write rates, network behavior, operational automation, and the messy work of deciding when a regional problem is serious enough to trigger failover.
S&P Global’s design narrows the decision space. If the immediate requirement is read access to essential financial information, the team does not have to wait for a complete writeable recovery path before restoring customer utility. That changes the psychology of incident response. It gives operators a lower-risk first move.
The full read-write recovery path is still more invasive. AWS describes a sequence that includes stopping SQL Server and freezing writes in the primary region, applying a final SnapMirror update, breaking the SnapMirror relationship to make the DR volume read-write, reversing replication direction, failing over SQL Server resources, and resuming operations in the DR region. That is the serious surgery. The read-only DR clone is the stabilizing intervention before surgery begins.
For financial services, that distinction can matter enormously. A client who can view critical data during a disruption may be inconvenienced; a client who cannot access anything may be forced into manual escalation, contractual review, or operational workarounds. Disaster recovery architecture is ultimately about buying time, and S&P Global’s design buys time with a usable service state rather than a progress bar.
That matters because cloud migrations often fail when they assume the platform shift also requires an operational identity crisis. A team that has spent years building safe, auditable recovery procedures around ONTAP snapshots and SQL Server does not necessarily want to replace all of that with a new set of primitives on day one. Sometimes the fastest way to modernize is to preserve the right abstractions.
S&P Global appears to have done exactly that. The AWS post quotes Charlakola saying that FSx for NetApp ONTAP helped S&P Global extend a proven disaster recovery strategy into the cloud, using native ONTAP snapshots and FlexClone technology on AWS without compromising the level of data protection clients expect. That is vendor-friendly language, naturally, but it also describes a real enterprise priority: continuity of controls.
There is an implicit critique here of cloud migration theater. Moving to the cloud is not inherently modernization if the result is slower recovery, weaker operational confidence, or higher risk during incidents. In this case, the cloud story is persuasive because the migration seems to have preserved S&P Global’s existing reliability expectations while improving the mechanics around failover speed and storage efficiency.
Traditional DR readiness often forces an expensive choice. Either maintain a hot environment that looks a lot like production and pay for capacity that may sit idle most of the time, or keep a colder environment that costs less but takes longer to activate. S&P Global’s read-only clone strategy splits the difference: maintain a usable access path without duplicating every block as an independent copy.
That does not make disaster recovery cheap. Cross-region replication, secondary compute, networking, monitoring, licensing, and operational validation all still cost money. But it targets spending where it improves the user-visible recovery state. That is the right place to spend.
There is another benefit that is easy to miss: the same read-only environment can help during production code releases. AWS says S&P Global’s read-only instances support application availability during releases, extending the design beyond pure disaster scenarios. That is a sign of a mature resilience pattern. The best DR investments are not museum pieces waiting for a regional failure; they become part of routine operational safety.
This is also where the Windows and SQL Server community should pay attention. Read-only access patterns are not just for disaster recovery. They can support reporting, validation, release insulation, and user continuity during maintenance events. Once a platform has a reliable way to present consistent read-only data from a recent point in time, teams usually find more than one use for it.
Read-only failover also requires product discipline. Applications must know how to behave when writes are unavailable. Users need a clear experience rather than mysterious failures. Reporting workflows, authentication flows, caches, background jobs, and scheduled processes all need to tolerate the degraded mode.
That is often harder than storage teams expect. A database can be mounted read-only, but an application may still attempt writes for session state, audit records, telemetry, saved preferences, or background reconciliation. If those write paths are not isolated, the supposed continuity mode becomes a cascade of errors.
S&P Global’s Capital IQ platform likely benefits from the fact that financial intelligence products already have strong read-consumption use cases. Still, any organization copying this pattern should treat “read-only DR” as an application architecture project, not merely a storage feature. The infrastructure can make the data available; the application has to make that availability useful.
AWS’s own FSx for ONTAP documentation distinguishes between high availability within a region and disaster recovery across regions. Multi-AZ file systems can provide resilience across Availability Zones in a region, while SnapMirror can replicate data to another ONTAP file system, including one in another AWS Region. S&P Global’s case uses both the language and the mechanics of regional separation because the business requirement is not merely surviving an instance or AZ failure.
That distinction matters because cloud marketing often collapses resilience into a single word. High availability is not disaster recovery. Backups are not replication. Snapshots are not a runbook. A second region is not a service until applications, users, networks, and operating procedures can actually use it.
S&P Global’s design is notable because it does not pretend that one mechanism solves everything. SnapMirror handles replicated data protection. FlexClone handles rapid presentation of a consistent copy. The Windows Server Failover Cluster and SQL Server topology provide the compute and database framework. The application cutover process turns those parts into a customer-facing recovery state.
The lesson is architectural humility. Resilience is layered, and each layer has a job.
That is why the read-only-first model is powerful. It recognizes that data integrity is not negotiable, even during a crisis. Rather than rushing a writeable failover before the system is ready, S&P Global can expose a consistent point-in-time view while the full recovery sequence proceeds with appropriate controls.
Regulators and auditors tend not to be impressed by heroic improvisation. They want documented objectives, tested controls, and evidence that continuity planning maps to business risk. A DR design that can say “clients regain read access within 15 minutes, with full read-write recovery following a controlled SnapMirror break and reversal process” is more credible than one that says “we will restore service as quickly as possible.”
This is also where cloud services have matured. A decade ago, many conservative enterprises viewed cloud storage as either too abstract or too immature for complex, stateful platforms. Today, the more persuasive cloud argument is not that it eliminates enterprise storage complexity. It is that managed services can host enterprise storage semantics while reducing infrastructure toil.
S&P Global’s case will not convince every regulated enterprise that FSx for ONTAP is the right answer. It should, however, make the broader point harder to dismiss: cloud disaster recovery does not have to mean abandoning proven data-management techniques.
But the pattern is bigger than AWS. The deeper idea is that disaster recovery can be staged into service levels. First, restore trusted read access. Then restore full transactional capability. Finally, reverse replication and normalize operations in the new primary environment.
That sequence is not appropriate for every workload. A payments system, order-entry platform, or collaboration application may have little value in a read-only state. But for analytics, reporting, market data, knowledge bases, document repositories, dashboards, and many internal enterprise applications, read-only continuity may preserve most of the value users need during the first minutes or hours of an incident.
The storage industry has long had the primitives to support this. What S&P Global’s example shows is the operational packaging: scheduled replication, automated clone refresh, pre-provisioned SQL Server read-only capacity, and a cutover model that treats the first recovery state as a legitimate product mode.
That is a useful mental shift. DR is not just “restore production somewhere else.” Sometimes it is “restore the most valuable slice of production first.”
Answering that question requires inventory work. Which databases are authoritative? Which writes are essential and which are incidental? Which jobs must be disabled in DR read-only mode? Which connection strings, DNS records, load balancers, and application flags control user routing? Which teams have authority to declare the failover?
It also requires testing beyond infrastructure drills. A clone can be created quickly, but the application has to be exercised in the mode customers will actually see. Login flows must work. Queries must return expected data. Reporting tools must not attempt to write temporary state to protected locations. Monitoring must distinguish expected read-only limitations from true failures.
The encouraging part is that this kind of work pays dividends outside of disasters. Systems that can tolerate read-only operation are often easier to maintain, easier to release, and easier to reason about during partial outages. They are less brittle because they have more than one valid operating state.
That may be the most transferable lesson from S&P Global’s design. The technology stack is specific, but the architectural posture is broadly useful: build degraded modes deliberately, automate them, and test them as real user experiences.
S&P Global Treats Disaster Recovery as a Product Feature, Not an Insurance Policy
Most disaster recovery plans are written as if the only meaningful question is whether the secondary site can become the primary site. That framing is tidy for diagrams and audit binders, but it does not match how users experience outages. For customers depending on financial intelligence, market data, and corporate fundamentals, losing the ability to read trusted data can be nearly as damaging as losing the ability to write new transactions.S&P Global Market Intelligence’s Capital IQ platform sits in that uncomfortable zone where stale or unavailable data can quickly become a business problem. The platform serves global clients who use it for decision-making, reporting, and analysis. In that context, disaster recovery is not merely a back-office resiliency exercise; it is part of the customer experience.
The AWS write-up says the business requirement was specific: once the decision to fail over had been made, the disaster recovery read-only system had to become operational and accessible within 15 minutes. That is a useful number because it forces the architecture away from vague resilience language and toward operational mechanics. The system either presents usable data in the secondary region inside that window, or it does not.
The trick is that S&P Global did not try to make every part of the platform instantly read-write in the disaster region. Instead, it accepted a more nuanced model: get customers back to essential information quickly in read-only mode, then execute the heavier process required to resume full read-write operations. That is not a compromise disguised as innovation. It is an acknowledgment that not every recovery objective carries the same urgency.
The Real Breakthrough Is the Read-Only Landing Zone
The most important design choice is the pre-provisioned read-only disaster recovery environment. According to AWS, S&P Global’s automation refreshes the DR environment daily by finding the most recent SnapMirror snapshot in the secondary region and creating a NetApp FlexClone volume from that point-in-time image. The resulting read-only SQL Server instance is not something that has to be assembled during a crisis.That matters because disaster recovery runbooks often fail at the seams between infrastructure readiness and application cutover. Storage might be replicated, compute might exist, and networks might be routable, but the actual recovery clock keeps running while teams connect those pieces under stress. S&P Global’s design reduces the first failover action to something closer to redirection than reconstruction.
FlexClone is doing important work here. In NetApp ONTAP terms, a FlexClone volume can be created from a snapshot while sharing unchanged data blocks with its parent. That makes it fast and space-efficient compared with building a full independent copy. In S&P Global’s case, AWS says FlexClone creation completes in under two minutes, which leaves most of the 15-minute window for validation and traffic cutover rather than storage provisioning.
There is also a subtle operational benefit: the clone is independent of the active SnapMirror relationship. That means the disaster recovery read-only instance can serve traffic without interrupting ongoing replication from the production environment. The clone represents a consistent point in time; the replication relationship continues doing its job.
This is the kind of storage architecture that looks old-fashioned and modern at the same time. Snapshots, clones, and replication are not new ideas. But packaging them inside a managed AWS file service, then wiring them into a cloud-region failover plan for SQL Server, gives an old storage discipline a more contemporary operating model.
SQL Server Remains the Center of Gravity
The Windows angle here is not cosmetic. S&P Global’s architecture uses a four-node geo-distributed Windows Server Failover Cluster across two AWS Regions, with Microsoft SQL Server running on Amazon EC2 instances in both the primary and DR regions. For WindowsForum readers, that detail is the difference between a generic cloud case study and something recognizably enterprise.SQL Server disaster recovery is full of sharp edges because the database is rarely the only thing that matters. Storage consistency, cluster behavior, application connection strings, identity, DNS, network paths, and release processes all become part of the recovery story. The AWS post describes a compute layer spanning regions, storage on two FSx for ONTAP file systems, SnapMirror replication from US-East-1 to US-West-2 at 15-minute intervals, and FlexClone volumes for rapid recovery.
That combination signals a hybrid of familiar Windows enterprise patterns and cloud-native service consumption. The cluster and SQL Server topology still require the kind of discipline Windows administrators already know. But the storage layer shifts from self-managed ONTAP infrastructure to Amazon FSx for NetApp ONTAP, which preserves ONTAP features while moving the operational burden into a managed service.
This is why the example is more interesting than a simple “we moved to AWS” story. Many enterprises do not want to throw away battle-tested storage and database patterns just because the infrastructure is now cloud-hosted. S&P Global’s design suggests another path: keep the semantics that matter, change the substrate, and only modernize where the cloud actually improves the outcome.
The 15-Minute Target Changes the Economics of Panic
The AWS post says SnapMirror replication is scheduled every 15 minutes between the primary FSx for ONTAP file system in US-East-1 and the DR file system in US-West-2. The actual recovery point varies with production activity: during quieter periods it can be only a few minutes, while heavier transaction volumes may push the data-loss exposure closer to the 15-minute window. That is an honest framing, and it is important.RTO and RPO are too often treated as ceremonial acronyms. Recovery Time Objective is the time it should take to restore service; Recovery Point Objective is the amount of data loss the business is prepared to tolerate. In real systems, neither number is magic. They are products of replication intervals, write rates, network behavior, operational automation, and the messy work of deciding when a regional problem is serious enough to trigger failover.
S&P Global’s design narrows the decision space. If the immediate requirement is read access to essential financial information, the team does not have to wait for a complete writeable recovery path before restoring customer utility. That changes the psychology of incident response. It gives operators a lower-risk first move.
The full read-write recovery path is still more invasive. AWS describes a sequence that includes stopping SQL Server and freezing writes in the primary region, applying a final SnapMirror update, breaking the SnapMirror relationship to make the DR volume read-write, reversing replication direction, failing over SQL Server resources, and resuming operations in the DR region. That is the serious surgery. The read-only DR clone is the stabilizing intervention before surgery begins.
For financial services, that distinction can matter enormously. A client who can view critical data during a disruption may be inconvenienced; a client who cannot access anything may be forced into manual escalation, contractual review, or operational workarounds. Disaster recovery architecture is ultimately about buying time, and S&P Global’s design buys time with a usable service state rather than a progress bar.
Cloud Migration Without Throwing Away Storage Muscle Memory
Amazon FSx for NetApp ONTAP occupies a peculiar but increasingly important place in the cloud storage market. It is an AWS-managed service, but it exposes NetApp ONTAP capabilities that many enterprise storage teams already understand: snapshots, SnapMirror replication, FlexClone volumes, SMB and NFS access, and integration patterns familiar from on-premises NetApp estates. AWS documentation also notes support for encryption at rest through AWS Key Management Service and encryption in transit options, including Kerberos-based encryption for SMB or NFS and encrypted SnapMirror transfers.That matters because cloud migrations often fail when they assume the platform shift also requires an operational identity crisis. A team that has spent years building safe, auditable recovery procedures around ONTAP snapshots and SQL Server does not necessarily want to replace all of that with a new set of primitives on day one. Sometimes the fastest way to modernize is to preserve the right abstractions.
S&P Global appears to have done exactly that. The AWS post quotes Charlakola saying that FSx for NetApp ONTAP helped S&P Global extend a proven disaster recovery strategy into the cloud, using native ONTAP snapshots and FlexClone technology on AWS without compromising the level of data protection clients expect. That is vendor-friendly language, naturally, but it also describes a real enterprise priority: continuity of controls.
There is an implicit critique here of cloud migration theater. Moving to the cloud is not inherently modernization if the result is slower recovery, weaker operational confidence, or higher risk during incidents. In this case, the cloud story is persuasive because the migration seems to have preserved S&P Global’s existing reliability expectations while improving the mechanics around failover speed and storage efficiency.
FlexClone Is the Quiet Cost Argument
The speed of FlexClone gets the headline, but the storage efficiency may be just as important. Because FlexClone volumes share unchanged blocks with their parent snapshots, they do not require a full physical copy at creation time. For a large SQL Server-backed financial platform, that can materially change the cost profile of maintaining a ready DR environment.Traditional DR readiness often forces an expensive choice. Either maintain a hot environment that looks a lot like production and pay for capacity that may sit idle most of the time, or keep a colder environment that costs less but takes longer to activate. S&P Global’s read-only clone strategy splits the difference: maintain a usable access path without duplicating every block as an independent copy.
That does not make disaster recovery cheap. Cross-region replication, secondary compute, networking, monitoring, licensing, and operational validation all still cost money. But it targets spending where it improves the user-visible recovery state. That is the right place to spend.
There is another benefit that is easy to miss: the same read-only environment can help during production code releases. AWS says S&P Global’s read-only instances support application availability during releases, extending the design beyond pure disaster scenarios. That is a sign of a mature resilience pattern. The best DR investments are not museum pieces waiting for a regional failure; they become part of routine operational safety.
This is also where the Windows and SQL Server community should pay attention. Read-only access patterns are not just for disaster recovery. They can support reporting, validation, release insulation, and user continuity during maintenance events. Once a platform has a reliable way to present consistent read-only data from a recent point in time, teams usually find more than one use for it.
The Architecture Still Demands Discipline
The risk in any polished vendor case study is that it can make the hard parts look too clean. S&P Global’s design is compelling, but it is not a shortcut around disaster recovery fundamentals. It assumes that teams can operate SnapMirror relationships correctly, automate clone refreshes safely, maintain SQL Server readiness in the secondary region, validate application behavior in read-only mode, and execute traffic redirection under pressure.Read-only failover also requires product discipline. Applications must know how to behave when writes are unavailable. Users need a clear experience rather than mysterious failures. Reporting workflows, authentication flows, caches, background jobs, and scheduled processes all need to tolerate the degraded mode.
That is often harder than storage teams expect. A database can be mounted read-only, but an application may still attempt writes for session state, audit records, telemetry, saved preferences, or background reconciliation. If those write paths are not isolated, the supposed continuity mode becomes a cascade of errors.
S&P Global’s Capital IQ platform likely benefits from the fact that financial intelligence products already have strong read-consumption use cases. Still, any organization copying this pattern should treat “read-only DR” as an application architecture project, not merely a storage feature. The infrastructure can make the data available; the application has to make that availability useful.
Multi-Region Does Not Mean Magic
The primary and disaster recovery regions in the AWS post are US-East-1 and US-West-2. That cross-region design helps protect against regional service disruption, but it also brings familiar trade-offs. Replication lag, inter-region network dependency, identity and access management consistency, DNS behavior, certificate management, and operational visibility all become part of the architecture.AWS’s own FSx for ONTAP documentation distinguishes between high availability within a region and disaster recovery across regions. Multi-AZ file systems can provide resilience across Availability Zones in a region, while SnapMirror can replicate data to another ONTAP file system, including one in another AWS Region. S&P Global’s case uses both the language and the mechanics of regional separation because the business requirement is not merely surviving an instance or AZ failure.
That distinction matters because cloud marketing often collapses resilience into a single word. High availability is not disaster recovery. Backups are not replication. Snapshots are not a runbook. A second region is not a service until applications, users, networks, and operating procedures can actually use it.
S&P Global’s design is notable because it does not pretend that one mechanism solves everything. SnapMirror handles replicated data protection. FlexClone handles rapid presentation of a consistent copy. The Windows Server Failover Cluster and SQL Server topology provide the compute and database framework. The application cutover process turns those parts into a customer-facing recovery state.
The lesson is architectural humility. Resilience is layered, and each layer has a job.
Financial Services Forces the Cloud to Grow Up
The financial-services context is not incidental. S&P Global Market Intelligence has been operating in markets where trust, availability, and data integrity are not soft values. Its customers depend on information systems for investment, corporate, compliance, and risk decisions. In that environment, disaster recovery architecture has to satisfy both engineering and governance.That is why the read-only-first model is powerful. It recognizes that data integrity is not negotiable, even during a crisis. Rather than rushing a writeable failover before the system is ready, S&P Global can expose a consistent point-in-time view while the full recovery sequence proceeds with appropriate controls.
Regulators and auditors tend not to be impressed by heroic improvisation. They want documented objectives, tested controls, and evidence that continuity planning maps to business risk. A DR design that can say “clients regain read access within 15 minutes, with full read-write recovery following a controlled SnapMirror break and reversal process” is more credible than one that says “we will restore service as quickly as possible.”
This is also where cloud services have matured. A decade ago, many conservative enterprises viewed cloud storage as either too abstract or too immature for complex, stateful platforms. Today, the more persuasive cloud argument is not that it eliminates enterprise storage complexity. It is that managed services can host enterprise storage semantics while reducing infrastructure toil.
S&P Global’s case will not convince every regulated enterprise that FSx for ONTAP is the right answer. It should, however, make the broader point harder to dismiss: cloud disaster recovery does not have to mean abandoning proven data-management techniques.
The Vendor Win Is Real, but So Is the Pattern
AWS naturally benefits from the story. FSx for NetApp ONTAP is positioned as the bridge between on-premises NetApp reliability and cloud agility. The AWS Architecture Blog emphasizes reduced failover time, data consistency, storage efficiency, and regulatory alignment. Those are exactly the terms a cloud provider wants attached to a financial-services migration.But the pattern is bigger than AWS. The deeper idea is that disaster recovery can be staged into service levels. First, restore trusted read access. Then restore full transactional capability. Finally, reverse replication and normalize operations in the new primary environment.
That sequence is not appropriate for every workload. A payments system, order-entry platform, or collaboration application may have little value in a read-only state. But for analytics, reporting, market data, knowledge bases, document repositories, dashboards, and many internal enterprise applications, read-only continuity may preserve most of the value users need during the first minutes or hours of an incident.
The storage industry has long had the primitives to support this. What S&P Global’s example shows is the operational packaging: scheduled replication, automated clone refresh, pre-provisioned SQL Server read-only capacity, and a cutover model that treats the first recovery state as a legitimate product mode.
That is a useful mental shift. DR is not just “restore production somewhere else.” Sometimes it is “restore the most valuable slice of production first.”
Windows Administrators Should Read This as a Runbook Challenge
For Windows administrators and SQL Server teams, the story should provoke a practical question: could your most important applications run usefully in a read-only state within 15 minutes? Not technically mount a database. Not merely start a VM. Actually serve users something coherent.Answering that question requires inventory work. Which databases are authoritative? Which writes are essential and which are incidental? Which jobs must be disabled in DR read-only mode? Which connection strings, DNS records, load balancers, and application flags control user routing? Which teams have authority to declare the failover?
It also requires testing beyond infrastructure drills. A clone can be created quickly, but the application has to be exercised in the mode customers will actually see. Login flows must work. Queries must return expected data. Reporting tools must not attempt to write temporary state to protected locations. Monitoring must distinguish expected read-only limitations from true failures.
The encouraging part is that this kind of work pays dividends outside of disasters. Systems that can tolerate read-only operation are often easier to maintain, easier to release, and easier to reason about during partial outages. They are less brittle because they have more than one valid operating state.
That may be the most transferable lesson from S&P Global’s design. The technology stack is specific, but the architectural posture is broadly useful: build degraded modes deliberately, automate them, and test them as real user experiences.
The S&P Global Blueprint Rewards Teams That Know Their Failure Modes
The concrete lesson from S&P Global’s FSx for ONTAP design is not that every enterprise should copy the same AWS regions, NetApp commands, or SQL Server cluster layout. It is that meaningful disaster recovery begins when a team names the service state it needs first and builds the platform around that state.- S&P Global’s Capital IQ design prioritizes restoring read access within 15 minutes before completing full read-write recovery.
- The architecture uses SnapMirror replication between Amazon FSx for NetApp ONTAP file systems in US-East-1 and US-West-2 on a 15-minute schedule.
- FlexClone volumes allow the DR environment to present a point-in-time copy quickly while sharing unchanged data blocks with the parent snapshot.
- The read-only recovery path is operationally separate from the more disruptive process of breaking and reversing SnapMirror for full write capability.
- The same read-only capability can support availability during production code releases, making the DR investment useful outside regional failure scenarios.
- Windows Server Failover Cluster and SQL Server remain central to the design, proving that cloud migration can preserve familiar enterprise patterns while changing the underlying service model.