Cloud infrastructure and recovery services

What NIST says a cloud service actually is

The definition most contracts assume is NIST's: cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort. NIST breaks it into five essential characteristics — on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service — three service models (software, platform and infrastructure as a service) and four deployment models (private, community, public and hybrid). The vocabulary earns its place commercially, because measured service is the property that makes the bill metered and resource pooling is the property that makes a shared-fate event possible.

• Five characteristics, three service models, four deployment models.
• Measured service is what makes the bill metered rather than flat.
• Resource pooling is what makes a shared-fate event possible.
• Name which deployment model is on the table before comparing anything.

How the bill is actually structured

A cloud bill is not one charge, and reading it as one is how budgets drift. It is a combination of compute, storage, request and API activity, data transfer, and whatever discount mechanism has been applied on top. On-demand capacity carries no commitment. Committed-use discounts trade a lower unit rate for a commitment over a term, and the commitment is written differently by provider: AWS Savings Plans discount eligible usage in exchange for a spend commitment, while Reserved Instances attach the commitment to specified service attributes and a term. Spot or interruptible capacity is surplus capacity priced variably, and the trade is a possible interruption. Data transfer out is normally metered on its own, so the direction the bytes travel, the destination and the volume tier all change what a workload costs to move. Ask which of those lines a proposed architecture is heavy in before comparing anything else.

• Compute, storage, requests, transfer and discounts are separate lines.
• A commitment lowers the unit rate and raises the cost of being wrong about volume.
• Spend commitments and attribute commitments are not the same instrument.
• Data transfer out is metered separately, by destination and volume.

What the shared responsibility model actually assigns

Cloud contracts divide duty along a line the provider draws, and the line moves by service model. With infrastructure as a service the provider secures the facilities, the hardware and the virtualisation layer while the customer owns operating system hardening, application security, identity, data protection and backup policy. Platform as a service shifts patching and runtime management to the provider and leaves application code, configuration and data with the customer. Software as a service shifts the most, but the customer still owns access control, retention decisions and, in most agreements, recovery of its own deleted or corrupted data. The industry shorthand is security of the cloud against security in the cloud, and the useful reading is a division of labour rather than a level of protection.

• Read the model as a division of labour, not a level of protection.
• Identify which party patches, which monitors and which restores.
• Check whether the agreement limits provider liability for data loss.
• Confirm export and portability rights before you depend on them.

Separate the platform decision from the recovery decision

Two separate purchases get treated as one, and that is where most cloud procurements go wrong. The first is the platform: where the workload runs and who operates it. The second is recovery: what happens to the data and the service when the platform, the network or the operator fails. A provider that runs an application competently may have no obligation to restore data a customer deletes, and no obligation to meet a recovery time the customer assumed. Ask both questions explicitly and get both answers in the agreement, because a recovery position that was never proposed is not a recovery position.

• Name the workloads and their dependencies before comparing platforms.
• State the maximum tolerable outage and data loss in minutes or hours.
• Ask what the provider restores by default, and what costs extra.
• Decide who operates the environment after cutover, in writing.

Where compliance changes the shortlist

For a regulated business, or one selling into the public sector, compliance can remove providers from consideration before structure is discussed at all. US federal agencies buy cloud through FedRAMP, which sorts offerings into three impact levels — Low, Moderate and High — by the adverse effect a loss of confidentiality, integrity or availability would have, running from limited through serious to severe or catastrophic. An offering authorised at one level is not automatically usable at another, and the level is set by the data being handled rather than by the deployment model. Outside government, the Cloud Security Alliance's Cloud Controls Matrix is the reference buyers use to state cloud-specific control requirements and to compare a supplier's assurance claims against a common set.

• FedRAMP sorts offerings by impact level, not by deployment model.
• An authorisation attaches to a level, not to a vendor's whole catalogue.
• The Cloud Controls Matrix states cloud-specific control requirements.
• Establish the compliance floor before building a shortlist.

Read the agreement for portability and exit

Recovery and ownership outcomes are set by contract language rather than by product capability, and the exit clauses decide how much of your architecture you actually keep. Four deserve a direct read. Scope: which systems, data and configurations are protected, listed rather than described. Interval: the protected copy schedule, in hours rather than adjectives, because it is the practical ceiling on how much data can be lost. Geography: where the copies sit relative to the primary environment, since geography is what protects against a regional failure. And exit: whether the provider owes an export, in what format, within what period, and what leaving costs in data transfer. A recovery that depends on a provider you are leaving is not a recovery plan.

• Scope: systems, data and configuration, listed rather than described.
• Interval: the protected copy schedule, in hours rather than adjectives.
• Geography: where the copies sit relative to the primary environment.
• Exit: export format, retention after termination and transfer cost.

What to gather, and how HighGround helps

Bring the workload inventory with dependencies and business owners, the written recovery objective per system, twelve months of utilisation where it exists, the current agreement with its end date and exit terms, the compliance floor that applies to you, and the list of operating duties your team performs today. HighGround sources infrastructure, cloud and managed services through the AppDirect catalog and scopes each requirement individually. Availability, terms and structure depend on the workload, the providers serving your location and the contract term, so no two environments produce the same answer. An inquiry places no order and commits you to nothing, and HighGround may receive compensation from a provider on a completed purchase.

• Workload inventory with dependencies and business owners.
• Recovery objectives per system, written down and agreed.
• Current agreement, renewal date and exit terms.
• Who operates the environment, and with what authority.

Availability is an architecture property, and the SLA prices it in credits

A provider's availability commitment is not one number: it is tiered by how the workload is deployed, and the tiers sit in the service level agreement for the specific service rather than in a brochure. AWS publishes two commitments in the same document for EC2 — a region-level SLA of at least 99.99% monthly uptime for EC2 deployed across multiple availability zones or regions, and an instance-level SLA of at least 99.5% for each individual instance. Google's Compute Engine SLA is built the same way: instances in multiple zones carry at least 99.99%, a single instance of a memory-optimised family at least 99.95%, and a single instance of any other family at least 99.9%, with a lower multi-zone figure on the standard network tier. Microsoft's own documentation puts the availability-set arrangement at the 99.95% Azure SLA. In every case the higher tier is conditional on the architecture described in the agreement, so running more instances inside one availability zone does not reach it — which means the availability conversation belongs in design, not in the purchase order.

• Two commitments in one document: deployed across zones, and single instance.
• AWS EC2: 99.99% region-level, 99.5% instance-level.
• Compute Engine: 99.99% across multiple zones, 99.9% single instance of most families.
• The higher tier requires the architecture, not a larger order.

The remedy for a missed service level is a credit, and it has to be claimed

Service level agreements are enforced with credits, not with guarantees of service, and the claim is the buyer's obligation rather than the provider's. AWS's EC2 SLA makes a service credit the remedy and requires the claim to be received by the end of the second billing cycle after the incident, with a further restriction that a claim can be made under either the region-level or the instance-level commitment but not both for the same instance. Google's Compute Engine SLA states that the financial credits are the customer's sole and exclusive remedy for a failure to meet the objective. Microsoft's online-services terms take the same shape, framing the credit as the exclusive remedy behind a claim window. The practical consequence is blunt: an outage that nobody noticed in the billing data, or a claim filed after the window closed, is worth nothing. Put the claim windows, the qualifying configuration and the evidence each provider requires into the operating calendar alongside the backup tests.

• The remedy is a credit, not a promise of uptime.
• AWS: claim by the end of the second billing cycle, and the two commitments cannot be stacked.
• Google: financial credits are the sole and exclusive remedy.
• A claim window is an operating task, not a legal one.

Commitment discounts commit different things, and that is the whole decision

The discount instruments look interchangeable and are not, because each attaches the commitment to a different object. AWS measures Savings Plans as a commitment to a consistent amount of usage in currency per hour: the Compute Savings Plan applies across instance family, size, region, operating system and tenancy and can reach serverless services, while the EC2 Instance Savings Plan narrows the commitment to one instance family in one region. A Standard Reserved Instance attaches to a specific configuration — instance type, region, tenancy and platform — and is a billing discount rather than a reservation of hardware; guaranteeing capacity in a particular availability zone is a separate capacity reservation product. Microsoft draws the same line between a reservation, which commits to a specific instance or family in a specific region, and a savings plan, which commits to an hourly amount of eligible compute spending. Google splits committed use discounts into resource-based, committing to a minimum quantity of resources in a region, and spend-based, committing to a minimum hourly spend on eligible services. Every model offers one- and three-year terms, and every model carries the same exposure: usage that never materialises is still committed.

• Savings Plans commit to an hourly spend; Reserved Instances commit to a configuration.
• A capacity reservation is a different product from a billing discount.
• Azure: reservation is configuration-specific, savings plan is spend-based.
• Google: resource-based committed use against spend-based committed use.
• The unit rate is only as good as the forecast behind the commitment.

Exit is the part of the contract nobody reads until it matters

Two developments changed the exit question, and both are worth reading before renewal rather than after. The EU's Data Act, Regulation (EU) 2023/2854, applied from 12 September 2025 and addresses switching between data-processing services directly: it requires providers to remove contractual, technical, commercial and organisational obstacles to switching and to support export of data and digital assets, and Article 29 caps any switching charge at the provider's directly linked costs until 12 January 2027, after which no switching charge may be imposed at all. Separately, AWS has published a worldwide exit process under which it waives data transfer out to the internet when an eligible customer moves all data from all eligible accounts, or all data for a particular service across those accounts, and asks customers needing more than 180 days for the migration to contact it. Both are distinct from ordinary egress, which is metered by direction, source region, destination and volume: inbound transfer is generally free, outbound is billed, the destination changes the treatment, and some services carry their own allowances. Regulated buyers carry a further layer — the EU's DORA, Regulation (EU) 2022/2554, requires covered financial entities to hold contractual exit strategies and provider support for orderly migration.

• EU Data Act applied from 12 September 2025; switching charges end 12 January 2027.
• AWS waives egress on exit for eligible accounts through a support process.
• Ordinary egress is metered by direction, source, destination and volume.
• Covered financial entities under DORA must contract for exit and migration support.

PUT THE OPTIONS SIDE BY SIDE

Your comparison checklist

Common questions