Procurement: Cloud Hosting

What this is and who it’s for

This runbook tells you how to buy cloud hosting — IaaS and PaaS, the compute and managed services your application runs on — on a Maryland contract vehicle without overrunning your budget or getting locked in. It’s for an agency tech lead who owns the architecture and the procurement officer who has to put that capability on a contract. It assumes you already have a target architecture; the job here is converting that into a defensible requirement, the right acquisition model, a SOW you can stand behind, and an evaluation that picks on merit rather than on a sales deck. If you can’t yet describe your workload profile, the managed services you need, and your data classification, stop and read the prerequisites first.

Prerequisites

• You have a target architecture, not just a desire to “move to the cloud.” Read the Reference Web Application Architecture and the Reference Data Platform Architecture and decide which managed services you actually need. You cannot price hosting for a system you can’t draw.
• You know your data classification and residency requirement — what categories of data the workload handles and whether it must stay in specific regions or jurisdictions [VERIFY]. This narrows the eligible provider regions before you price anything, so settle it up front.
• You’ve determined your authorization posture — whether the workload requires StateRAMP or FedRAMP authorization, and at what impact level [VERIFY]. Not every provider region carries every authorization, so this constrains the vendor field before you start.
• You have a defensible spend estimate: expected steady-state monthly cost and a growth assumption. Cloud bills are consumption-based, so a number you can defend — not a license count — is what drives both the vehicle and the evaluation.

The practice

Run this as five moves in order: define the requirement, fix the authorization boundary, choose an acquisition model, map to a vehicle, write the SOW, evaluate. The acquisition model is the hinge decision — it changes the vehicle, the cost transparency you’ll get, and who you can hold accountable — so make it explicitly rather than letting a reseller make it for you.

Define the requirement

Write down five things before you talk to anyone: the workload profile, the managed services needed, the data classification, the residency requirement, and the expected spend. State the workload profile as numbers — peak and steady-state compute, storage volume, egress expectation — because consumption pricing tracks those, not features. List managed services as outcomes (“managed Postgres with point-in-time recovery,” “object storage with lifecycle policies”), so you’re buying capability rather than a brand’s product names. Capture data classification and residency together, because the two of them decide which provider regions are even eligible.

Fix the authorization boundary

Decide what authorization the workload requires before you compare anything else, because it eliminates options rather than scoring them. If the workload needs StateRAMP or FedRAMP at a given impact level [VERIFY], only provider regions and services that carry that authorization are in scope — and not every region or managed service in a provider’s catalog is in the authorized boundary [VERIFY]. Government-cloud regions exist for exactly this reason, but they carry their own service availability and pricing differences [VERIFY], so confirm the specific services you need are authorized in the specific region you’ll use. Never assume a provider’s authorization covers your whole shopping list; require the authorization status of each in-scope service in writing.

Choose an acquisition model

Direct cloud-provider agreement

You contract with the cloud provider directly and consume their services at their published or negotiated rates. Highest cost transparency — you see the provider’s own billing, line by line — and the shortest accountability chain when something breaks. The trade is that you carry the operational burden yourself, and a direct enterprise agreement may need its own negotiation and legal review [VERIFY]. Procurement-wise this is a cloud-services buy that maps to a cloud-specific vehicle if one exists [FILL IN].

Cloud marketplace

You buy provider and third-party services through a cloud marketplace, often drawing down against a committed spend agreement. Fast to transact and consolidates many SaaS and infrastructure purchases under one billing relationship. The trade is that marketplace pricing and the eligibility of marketplace purchases against a Maryland vehicle both need confirmation [VERIFY] — a marketplace is a convenience, not automatically an approved acquisition path. Cost transparency is generally good, but read how marketplace fees and any reseller-of-record markup appear on the bill.

Reseller or MSP on a state vehicle

You buy cloud capacity through a reseller or managed-service provider who holds a Maryland vehicle, and they pass the provider’s services through to you. Often the fastest path to a contract because the vehicle already exists, and an MSP can also operate the environment for you. The trade is cost transparency: the reseller’s markup may be bundled into the rate, so require a separate, visible markup or management fee and the underlying provider invoices [VERIFY]. This model is attractive precisely when you lack the staff to run cloud directly — but price the management service explicitly so you can tell capacity cost from labor cost.

Fully managed hosting vendor

You buy an outcome — “run my application, hit these SLAs” — and the vendor chooses and operates the underlying infrastructure. Lowest operational burden and a single throat to choke on availability. The trade is the least cost transparency and the most lock-in: you typically don’t see the underlying cloud bill, and exiting means re-platforming. Make the data-exit and portability clause non-negotiable here, and require the vendor to name the underlying provider and authorization boundary [VERIFY] so you’re not buying an opaque box.

Choose a commitment model

On-demand consumption

You pay published rates for what you use, with no upfront commitment. Maximum flexibility and the right default when the workload is new or its scale is uncertain. The trade is the highest unit price — you pay for the option to walk away. Start here for anything you haven’t run in production long enough to size confidently.

Committed-use or reserved capacity

You commit to a spend level or specific capacity for one or more years in exchange for a discount [VERIFY]. The right move once a workload’s baseline is well understood and stable, because the savings on predictable baseline load are real. The trap is over-committing: a multi-year reservation against a workload you haven’t measured locks you into paying for capacity you may not use, and the discount never recovers a bad sizing decision. Reserve only the baseline you’ve actually observed, leave the variable layer on-demand, and treat any reservation before you have production data as a red flag.

Map to a vehicle

Match the acquisition model to the smallest vehicle that fits. A modest, short-term consumption buy under the small-purchase threshold [VERIFY] may not need a full solicitation; a multi-year committed-use agreement will. A reseller or MSP path may already sit on an existing Maryland vehicle, which can be the fastest route to award. Confirm the candidate vehicles in Procurement notes before committing.

Write the SOW

Fork the skeleton in Reference implementation. Keep the authorization boundary, data residency, and data-exit terms as explicit, testable requirements — not preferences. Put data ownership, exit, and egress handling in writing every time, regardless of acquisition model.

Evaluate

Score against the published rubric, not against the demo. Weight the authorization boundary and data exit/egress as gates: a bid that fails either is out, however attractive the rate looks. Run your spend estimate and growth assumption through each bidder’s pricing model and evaluate cost at projected scale plus a growth band, not at pilot scale.

Reference implementation

Fork this SOW skeleton. Every bracketed item is a decision you must make or a value a human must verify; do not ship it with placeholders intact.

# STATEMENT OF WORK — CLOUD HOSTING (IaaS / PaaS)

### 1. Scope

The Contractor shall provide [direct cloud-provider agreement | cloud marketplace access | reseller/MSP-provided cloud capacity | fully managed hosting] for [AGENCY / SYSTEM]. Estimated scale: [N vCPU / N GB RAM steady-state], [peak factor], [N TB storage], [N TB/month egress]. Commitment model: [on-demand | committed-use for base period]. Term: [base period + option years].

### 2. Workloads and Managed Services

The environment shall provide:

- **Compute** — [VMs | containers | serverless] sized for the profile above.
- **Managed database** — [e.g. managed Postgres] with [point-in-time recovery, automated backups, [N]-day retention].
- **Object/block storage** — with lifecycle policies and [encryption at rest].
- **Networking** — [private networking, load balancing, WAF] as required.
- **Additional managed services** — [FILL IN: per target architecture].

### 3. Security and Authorization Boundary

All in-scope services shall hold [StateRAMP | FedRAMP authorization at IMPACT LEVEL] for the term. The Contractor shall identify the specific authorized region(s) and confirm that EACH managed service in Section 2 is within the authorized boundary — not merely that the provider holds the authorization.

### 4. Data Residency, Ownership, Exit, and Egress

All agency data is the property of [AGENCY] and shall reside only in [approved region(s) / jurisdiction]. On termination the Contractor shall, within [N days], export all data in [open format] and assist migration at [no additional charge | stated rate], and certify deletion of agency data. Egress fees, if any, shall be stated in Section 7 and waived for termination export. No proprietary format or data-gravity dependency shall prevent export.

### 5. Cost Reporting and Budget Controls

The Contractor shall provide [monthly | near-real-time] cost reporting itemized by service, and showback by [AGENCY-defined tag/account]. Any reseller/MSP markup or management fee shall be shown as a SEPARATE line item with the underlying provider invoices attached. Budget alerts shall fire at [e.g. 50% / 80% / 100%] of the monthly budget to [AGENCY contact].

### 6. Service Levels and Support

- **Availability:** [e.g. 99.9%] measured monthly.
- **Support tier:** [severity tiers and response times].
- [For managed hosting: application-level SLAs and on-call coverage.]

### 7. Pricing

Pricing shall be stated at the estimated scale in Section 1 AND at [+50% | +100%] of that scale, so cost growth is visible before award. Egress, support tier, and any committed-use discount shall be priced as separate, visible line items. [FILL IN: ceiling / NTE amount per agency budget authority.]

Score every responsive bid against this rubric. Treat the two gate rows as pass/fail: a failure on either eliminates the bid regardless of total score.

Criterion	Weight	Notes
Authorization boundary (gate)	Pass/fail	StateRAMP/FedRAMP at required level, per in-scope service and region [VERIFY]
Data exit and egress (gate)	Pass/fail	Open-format export, no egress penalty on exit, no data-gravity lock-in
Cost at projected scale	30%	Scored at +50%/+100% scale, including egress, not pilot
Cost transparency	20%	Itemized billing, showback, visible markup/management fee
Managed-service fit	15%	Covers the services in the target architecture
Operational burden	15%	Staff effort to run vs. managed by vendor
Support and SLAs	10%	Response SLAs, availability commitment
Scalability headroom	10%	Performance and pricing at growth

Common pitfalls

• The bill grew with no warning. Consumption pricing has no natural ceiling, and a misconfigured workload can run up cost overnight. Require itemized cost reporting, showback, and budget alerts in SOW Section 5 — a contract with no budget alerting or showback is a blank check.
• Egress fees and data gravity quietly locked you in. Moving data out of a provider costs money, and the more data you accumulate the more expensive leaving becomes. Price egress as a visible line item and require waived export egress on termination, per SOW Section 4, before any data lands.
• You bought reserved capacity before you knew the workload. A multi-year committed-use discount against an unmeasured workload locks you into paying for capacity you may not use. Reserve only the baseline you’ve observed in production; default new workloads to on-demand.
• There’s no exit or portability clause. Without open-format export and migration assistance, the vendor owns your leverage at renewal and re-platforming becomes the only way out. SOW Section 4 is non-negotiable; make it a rubric gate.
• The authorization boundary doesn’t match the workload. Discovering at award that the workload needs StateRAMP coverage the provider’s chosen region doesn’t carry [VERIFY] restarts the procurement. Confirm per-service, per-region authorization up front and make it a pass/fail gate, not a scored line.
• Reseller markup with no cost transparency. If the reseller or MSP bundles its margin into the rate, you can’t tell capacity cost from labor cost or benchmark either. Require a separate markup/management line item and the underlying provider invoices, per SOW Section 5.

Procurement notes

Candidate Maryland vehicles depend on the acquisition model and dollar value, and must be confirmed with your procurement officer.

• Direct cloud-provider agreement: [FILL IN: Maryland cloud-services contract vehicle # / NASPO ValuePoint cloud vehicle].
• Cloud marketplace purchase: [FILL IN: Maryland vehicle that permits marketplace draw-down, if any] [VERIFY marketplace eligibility].
• Reseller/MSP on a state vehicle: [FILL IN: Maryland IT master services / cloud reseller vehicle #].
• Fully managed hosting: [FILL IN: Maryland IT services vehicle #].

Thresholds decide the path. Below the small-purchase threshold [VERIFY] you may avoid a full solicitation; above it you run an RFP against this runbook’s SOW and rubric [VERIFY]. A typical timeline runs roughly [VERIFY: e.g. 4–8 weeks for a small purchase, 3–6 months for a competitive RFP] — confirm against current Maryland procurement guidance before you commit a date to anyone.

Multi-year matters here. A committed-use or reserved agreement spans option years, so account for annual true-up of actual versus committed spend and how unused commitment is handled [VERIFY], and confirm whether multi-year cloud commitments are permitted on the chosen vehicle [VERIFY] before you negotiate a discount against them.

For SOW drafting mechanics beyond this skeleton, see How to write a good SOW.

Maintenance

Owner: [FILL IN: runbook owner] · Last reviewed: 2026-05-31 · Next review: 2026-08-31