Procurement Models for Managed Cross-Cloud Databases

Key points#

• A managed cross-cloud database can be bought through six models: a direct vendor contract, a marketplace public listing, a marketplace private offer, a channel or reseller private offer, the cloud provider's own managed database, or a self-managed license running on cloud compute.
• A direct contract is billed by the database vendor and does not draw down any cloud provider's spend commitment.
• Marketplace purchases are billed on the cloud provider's invoice and can draw down that provider's commitment, but only when the specific offer is eligible under the buyer's agreement.
• A marketplace purchase is transacted through one cloud, so it can only count toward one cloud's commitment, even when the database runs on AWS, Azure, and Google Cloud at the same time.
• Channel private offers, such as AWS Channel Partner Private Offers and Azure multiparty private offers, let a reseller set the price while billing still flows through the cloud marketplace.
• The cloud provider's own databases, such as Amazon Aurora, Azure Cosmos DB, and Google Cloud Spanner, are bought under the cloud agreement and generally count toward that cloud's commitment, but each runs on one cloud only.
• Before signing, check commitment eligibility, overage pricing, credit rollover, multi-cloud usage rights, and the data egress charges that land outside the database bill.

What procurement models exist for managed cross-cloud databases?#

There are six procurement models for a managed cross-cloud database: buy directly from the database vendor, subscribe through a cloud marketplace public listing, accept a marketplace private offer, buy through a channel partner's private offer, use the cloud provider's own managed database under the cloud agreement, or license the database software and run it yourself on cloud compute. The models differ on who invoices you, whether the spend can draw down an existing cloud commitment such as an Azure MACC, an AWS EDP, or a Google Cloud committed spend agreement, and how much of the price is negotiable. For a database that runs on more than one cloud, the deciding question is usually which cloud commitment, if any, the purchase should count toward.

Why cross-cloud databases complicate procurement#

Vendors such as MongoDB Atlas, Snowflake, Databricks, Confluent Cloud, Elastic Cloud, Redis Cloud, CockroachDB, and Aiven run their managed services on AWS, Azure, and Google Cloud. One customer account or organization with the vendor can hold deployments on several of those clouds, and some services let a single cluster span them. The vendor meters all of that usage and bills it centrally, as one relationship.

The cloud providers see it differently. A marketplace transaction happens inside one cloud's billing system, so the charge lands on one cloud's invoice and can only draw down that cloud's commitment: an Azure MACC, an AWS EDP or private pricing agreement, or a Google Cloud committed spend contract. If a cluster runs on Google Cloud but the vendor subscription was bought through AWS Marketplace, the Google Cloud commitment gets nothing from it.

Vendors also differ on what a marketplace subscription covers. Some attach it to the whole customer account, so usage on every cloud is billed through the one marketplace. Others limit it to deployments on the cloud where it was bought and bill the rest some other way. That difference decides what the purchase is worth against each commitment, so confirm it in writing with the vendor before choosing a model.

The six procurement models#

1. Direct contract with the database vendor#

The vendor invoices you directly. Small accounts usually pay on demand, monthly in arrears for metered usage. Larger accounts sign an annual or multi-year contract that prepays credits or commits to a spend amount, which usage then draws down across every cloud and region the account uses. Prepaid capacity drawn down by usage is the common shape for vendors such as Snowflake and MongoDB Atlas.

This spend counts toward your commitment with the vendor and nothing else. It does not draw down any cloud provider commitment, because the cloud provider never bills it. A buyer picks this model when no cloud commitment needs the drawdown, when one contract covering usage on every cloud matters more than where the spend is credited, or when volume pricing should aggregate all usage regardless of which cloud it runs on.

2. Cloud marketplace public listing, pay as you go#

The buyer subscribes to the vendor's listing in AWS Marketplace, Azure Marketplace, or Google Cloud Marketplace. The vendor meters usage, reports it to the marketplace, and the charge appears on the cloud provider's invoice at the published listing price. There is no negotiation and usually no minimum.

Whether it counts toward the cloud commitment depends on the listing and on your agreement. Azure Marketplace marks qualifying offers as Azure benefit eligible. On AWS and Google Cloud, eligibility of marketplace spend is set by the terms of your commitment agreement, and some agreements limit how much of the commitment marketplace purchases can satisfy. A buyer picks a public listing for pilots, small or unpredictable usage, and cases where adding the vendor as a new supplier would take longer than the project can wait, since the cloud provider is already an approved supplier. The cloud marketplace procurement entry covers the general mechanics.

3. Marketplace private offer#

The vendor creates an offer for your cloud account with negotiated price, term, payment schedule, and contract terms, and you accept it in the marketplace. Charges appear on the cloud provider's invoice. Most database private offers are a prepaid or committed amount with a defined rate for usage beyond it. Oracle Database@Azure, Oracle Database@AWS, and Oracle Database@Google Cloud are also transacted through the corresponding cloud marketplace, which is why they show up in the same planning conversations.

The same eligibility rules apply as for public listings, and directing negotiated database spend into a cloud commitment is usually the reason a buyer asks for a private offer at all. Confirm that the private offer itself is eligible, not just the vendor's public listing. A buyer picks this model when the spend is large enough to negotiate and one cloud's commitment needs the drawdown. See the AWS Marketplace private offer entry for how the AWS version works.

4. Channel or reseller private offers#

AWS Channel Partner Private Offers (CPPO), Azure multiparty private offers, and reseller-sold offers in Google Cloud Marketplace let a reseller or consulting partner set the final price. The vendor authorizes the partner, the partner adds its own margin and sometimes bundles services, and the charge still flows through the cloud marketplace invoice.

These purchases are generally treated like other marketplace transactions for commitment purposes when the offer is eligible, but eligibility is not automatic, so confirm it for the specific offer. A buyer picks this model when procurement policy routes software through an approved reseller, when a systems integrator is bundling implementation or managed services with the subscription, or when an existing partner relationship is worth keeping while finance still wants the cloud commitment drawdown.

5. The cloud provider's own managed database#

Amazon Aurora, Amazon DynamoDB, Azure Cosmos DB, Azure Database for PostgreSQL, Google AlloyDB, and Google Cloud Spanner are billed on the cloud invoice as first-party usage. Discounts come from the negotiated cloud agreement and, where the service offers them, from reserved capacity or committed use discounts.

First-party consumption is what cloud commitments are built to count, so this spend generally draws down the commitment without any eligibility question, apart from services your agreement specifically excludes. The trade is portability. Each of these services runs on its own cloud, so a multi-cloud estate needs a different database engine on each cloud, or a replication layer between them.

Some third-party services are sold as first-party services on one cloud. Azure Databricks is billed by Microsoft on the Azure invoice, which puts Databricks on Azure closer to this model than to a marketplace purchase, while Databricks on AWS and Google Cloud is bought from Databricks directly or through those marketplaces. A buyer picks this model when the workload lives on one cloud and simple commitment math matters more than running the same database everywhere.

6. Self-managed or bring-your-own-license#

The buyer licenses the database software, such as MongoDB Enterprise Advanced, Redis Enterprise Software, Confluent Platform, self-managed Elasticsearch, or a self-hosted CockroachDB edition, and runs it on virtual machines or Kubernetes in its own cloud accounts. That produces two bills: the license from the vendor, or from a marketplace bring-your-own-license listing, and compute, storage, and networking from each cloud.

The infrastructure portion counts toward each cloud's commitment where the workload runs, and it can use that cloud's reserved instances, savings plans, or committed use discounts. The license counts toward a cloud commitment only if it is bought through an eligible marketplace offer. A buyer picks this model when data residency, network isolation, or control requirements rule out a vendor-operated service, and when there is a team to own upgrades, backups, and failover.

A middle ground some vendors offer is bring your own cloud, where the vendor operates the service inside the buyer's cloud account. Infrastructure lands on the cloud bill and the management fee on the vendor's, so check how each part is billed and which commitment each part can count toward.

Comparison of the six models#

Deciding which cloud commitment to burn#

When the same database spend could go through more than one marketplace, five factors usually settle it.

• Shortfall risk. A commitment forecast to fall short is the most valuable place for eligible spend, because unconsumed commitment is typically paid for anyway. Compare each cloud's forecast with its commitment before choosing.
• Where the workload runs. Billing through the cloud that hosts most of the database usage keeps cost allocation and reporting coherent.
• Renewal timing. Spend that lifts a commitment due for renewal can support a larger commitment, and better terms, at the next negotiation. The cloud commitment benchmark compares how MACC, EDP, and Google Cloud commitments are structured.
• Eligibility limits. Check whether any agreement caps the share of the commitment that marketplace purchases can satisfy, and how much of that room is already used.
• Net price. Paying more for the database just to burn a commitment only makes sense if the alternative is a shortfall payment of a similar size. Compare the net cost of each route.

Some buyers split the purchase by cloud: one private offer on each marketplace, sized to the usage that runs on that cloud, so every commitment gets credit for its share. This only works if the vendor supports separate accounts or subscriptions per cloud, each billed through its own marketplace. Splitting has costs. Volume pricing may not aggregate across separate offers unless the vendor agrees to apply one price schedule to all of them. Each offer has its own prepaid balance that can expire unused independently. Moving a workload from one cloud to another can strand credits on the side it left. A common alternative is to keep most of the spend on one contract and add a smaller private offer on a second cloud only when that cloud's commitment is short.

Contract terms to check before signing#

• Commitment eligibility of the offer. On Azure, check whether the offer is Azure benefit eligible. On AWS and Google Cloud, confirm with the cloud provider's account team that the listing or private offer counts under your agreement and whether any cap applies. Get the answer from the cloud provider, not only from the database vendor.
• Overage pricing. Find out what rate applies once prepaid credits or the committed amount run out: the contracted rate, the public listing rate, or another schedule, and whether overage is billed through the same marketplace.
• Credit rollover and expiry. Check whether unused credits roll into a renewal, whether rollover requires renewing at the same or a higher amount, and what happens to the balance if the contract is not renewed.
• Multi-region and multi-cloud usage rights. Confirm that credits bought through one marketplace can be used by deployments on other clouds and in any region, and whether cross-region or cross-cloud replication and backups are priced differently.
• Egress outside the database bill. Traffic from applications on one cloud to a database on another, cross-cloud replication, and data extracts can generate data transfer charges on the cloud provider's bill for the application side, and the vendor may bill its own data transfer on top. The database price covers neither, so model them separately.
• Term alignment. If the database contract runs past the end of a cloud commitment, the later spend draws down nothing until that commitment is renewed.
• Switching channels mid-term. Ask whether prepaid credits from a direct contract can move to a marketplace private offer, or the reverse, without being forfeited.

Frequently Asked Questions#

Does buying a database through a cloud marketplace always count toward my cloud commitment?#

No. Eligibility depends on the specific listing or private offer and on the terms of your agreement with the cloud provider. On Azure, check whether the offer is marked Azure benefit eligible. On AWS and Google Cloud, confirm with your account team whether the purchase counts and whether a cap applies.

Can one marketplace purchase draw down commitments on two clouds?#

No. A marketplace transaction is billed by a single cloud provider, so it can only count toward that provider's commitment. To get credit on more than one cloud, buyers split the purchase into separate offers on each marketplace or keep part of the spend on a direct contract with the vendor.

Is a marketplace private offer more expensive than buying direct?#

Not inherently. A private offer carries whatever price the buyer and vendor negotiate, and the marketplace fee is deducted from the vendor's proceeds rather than added to the buyer's invoice, although vendors may account for it in their pricing. Compare the full terms, including overage rates, rollover, and support, rather than the unit price alone.

Should I use the cloud provider's own database instead of a cross-cloud vendor?#

If the workload runs on one cloud and is likely to stay there, a first-party service such as Amazon Aurora, Azure Cosmos DB, or Google AlloyDB keeps billing and commitment drawdown simple. If the same database has to run on several clouds, or portability is a requirement, a cross-cloud vendor avoids maintaining a different engine on each cloud. The procurement model follows from that architecture decision, not the other way around.

What happens to unused prepaid database credits at the end of the term?#

It depends on the contract. Some agreements let unused credits roll into a renewal, sometimes only if the renewal is the same size or larger, while others let them expire. Negotiate rollover terms before signing, and forecast usage on each cloud separately if the purchase is split across marketplaces.