Run the methodology with a senior advisor.
A senior Admodum advisor will walk the methodology through with your CIO, CFO, FinOps Lead or procurement team on a private call. Engagements run as fixed fee, contingency or annual retainer.
Twenty-two pages on the Google Cloud Enterprise Discount Program design: ramp economics, CUD mix across Compute, Spend-Based and Resource-Based, BigQuery edition selection, Workspace seat reconciliation and the Vertex AI and Gemini commercial scope inside the cumulative-spend envelope.
The Google Cloud Enterprise Discount Program is a multi-year cumulative-spend commitment between the buyer and Google Cloud, with a contracted minimum spend at each anniversary and an aggregate floor across the term. In exchange, Google offers a discount against on-demand pricing across the GCP catalogue (Compute, BigQuery, Storage and the broader catalogue), with the discount band scaled by the commitment depth.
The EDP exists because, for both parties, the cumulative-spend commercial wrapper resolves the per-product price negotiation surface. The buyer secures a discount band against the published rate card; the publisher secures a cumulative-spend floor that anchors the next-term revenue. The cumulative-spend mechanic also creates the dynamic on which this paper focuses: the gap between what the buyer commits to and what the buyer actually consumes.
The EDP commitment is not, in the buyer’s practical reality, contestable on a per-product basis. It is contestable on the commitment shape: the ramp, the year-on-year minimums, the cumulative floor and the regional / workload allocation. The shape is where the buyer’s leverage lies; the rate-card discount band is the publisher’s machinery for converting the shape into a discount the buyer accepts.
The EDP ramp curve is the year-on-year minimum spend the buyer commits to over the EDP term. The curve is not contractually a single number; it is a year-one anchor, a year-two midpoint and a year-three (or further) landing zone, with the cumulative floor as the binding aggregate.
Google Cloud’s preferred ramp curve aligns with the migration narrative its account team has co-authored with the buyer’s sponsor. The narrative typically assumes accelerated lift-and-shift, a measurable cost-out from on-premise, and a strong year-three consumption rate that absorbs the cumulative floor.
The narrative is the publisher’s plan, not the buyer’s plan. The narrative is built to maximise the cumulative floor.
The buyer’s ramp curve is built from the trailing-twelve-month GCP consumption read, the documented migration plan and the independent FinOps forecast for the next term. The trailing read is the baseline. The migration plan is the addition. The FinOps forecast is the sanity check. The three reads together produce the ramp curve the buyer commits to.
Committed Use Discounts (CUDs) are the per-resource commitment mechanic inside the GCP commercial framework. CUDs sit alongside the EDP cumulative-spend commitment: the EDP discount applies against on-demand and CUD pricing; the CUD discount applies against the published rate-card for the committed resource.
Compute CUDs commit to a specific machine type in a specific region for one or three years. They produce the deepest per-resource discount but carry the narrowest applicability (the committed machine type in the committed region only). Spend-Based CUDs commit to a hourly spend rate across the Compute Engine flexible family without specifying the machine type or region. The discount is smaller, but the commitment is flexible. Resource-Based CUDs commit to a specific resource type (for example, Memorystore or Cloud SQL) and operate similarly to Compute CUDs for the relevant service.
The CUD mix design balances the buyer’s desire for the deepest discount against the operational risk of being locked into a specific resource shape. A Compute CUD is at risk if the workload shifts to a different machine type; a Spend-Based CUD is not. A Resource-Based CUD is at risk if the workload retires the underlying service; a Spend-Based CUD covers any Compute spend that materialises in its place.
The Admodum CUD mix protocol begins with the trailing-period telemetry and the migration plan. Stable workloads against known machine types are sized into Compute CUDs. Variable workloads against the Compute Engine family are sized into Spend-Based CUDs. Service-specific commitments are sized into Resource-Based CUDs. The total CUD coverage is then sized against the EDP cumulative floor.
BigQuery is, for many GCP customers, the single largest line item inside the EDP. The BigQuery edition design is therefore one of the principal design decisions inside the EDP.
BigQuery sells in three principal editions. Standard covers core analytical workloads with a per-slot-hour rate. Enterprise adds customer-managed encryption keys, materialised view support and advanced query features. Enterprise Plus adds the highest-tier features including multi-region replication and the broadest advanced-feature set.
Each edition is sold through three principal commercial constructs. On-demand pricing (per-TB-scanned, the original BigQuery model). Slot Commitments (the per-slot-hour commitment, with one-year and three-year tiers). Autoscaler (the dynamic-scaling commercial model that sits between on-demand and Slot Commitments).
The BigQuery edition selection runs on the trailing-period workload read. Predictable batch workloads run cheaper on Slot Commitments at the Standard edition. Variable workloads with strong feature requirements run cheaper on Autoscaler at the Enterprise edition. Multi-region high-availability workloads land at Enterprise Plus with Slot Commitments.
The buyer’s position is rarely “one edition for the whole estate”. It is a workload-by-workload selection that maps the trailing telemetry into the appropriate edition / commercial framework combination. The result is the BigQuery commitment line inside the EDP.
Google Workspace is the productivity-suite side of the Google Cloud relationship. Workspace sells across Business Starter, Business Standard, Business Plus, Enterprise Standard and Enterprise Plus. Each tier carries its own storage limit, its own Meet capability and its own administrative feature set.
The Workspace seat reconciliation is the rationalisation of the seat mix against the trailing-period active-user evidence. Three patterns recur in the Admodum Workspace renewal engagements. Tier over-stretch, where Enterprise Plus seats sit against users with no Plus-level feature demand. Inactive seat retention, where seats sit provisioned against users who have not logged in for the trailing period. Suspended-account mass, where suspended accounts (typically departing users) sit chargeable against the seat-count until manually de-provisioned.
The reset at the EDP renewal window is the trailing-twelve-month active-user read, mapped onto the tier mix the active users actually consume. The result is a Workspace seat-band that maps the active user population, not the provisioned user population.
Gemini for Workspace and Vertex AI are the Google Cloud commercial AI envelope inside the EDP. Gemini for Workspace sells as a per-seat add-on against the Workspace seat band; Vertex AI sells as a consumption-priced service against the GCP rate card.
Gemini for Workspace SKUs (the per-seat Gemini add-on across Workspace tiers) are sold against the active Workspace seat. The buyer’s sizing exercise is the user-by-user rollout plan: which users will use Gemini for Workspace in the next term, what frequency, what use cases. The sizing is against the documented rollout, not the aspirational rollout.
Vertex AI sells as a consumption-priced service against trained model invocations, training compute, embedding generation, and the adjacent Gemini API consumption (per-input-token, per-output-token). The Vertex AI commitment inside the EDP is sized against the documented AI use cases, the per-use-case consumption profile, and the planned model selection. The IP indemnification posture, the data-residency clauses, the model-deprecation protection and the multi-vendor portability (against AWS Bedrock and Azure OpenAI) are examined as part of the commitment.
The Google Cloud Marketplace is the third-party SaaS purchase channel inside GCP. Marketplace purchases retire against the EDP cumulative-spend commitment, which makes the Marketplace a meaningful lever inside the EDP for buyers with substantial third-party SaaS catalogues.
The mechanic has two implications. First, the buyer can pull third-party SaaS purchases through the Marketplace to retire against the EDP commitment, accelerating the cumulative-spend retirement and absorbing the floor without incremental GCP-native spend. Second, the procurement discipline required to manage Marketplace purchases is non-trivial: each Marketplace SKU is an active commercial relationship between the buyer and the SaaS vendor, mediated by Google’s billing, and the buyer’s procurement function must remain in control of the underlying purchasing decision.
The Admodum Marketplace protocol begins with the buyer’s third-party SaaS catalogue, ranks the catalogue by Marketplace availability and current procurement channel, identifies the candidates for Marketplace migration, and sizes the retirement-against-EDP that the migration would produce. The retirement is then factored into the EDP commitment shape.
The exit architecture is the post-EDP position the buyer carries out of the term. Four exit patterns recur across the Admodum Google Cloud practice.
Pattern one: full EDP exit with workload migration to a different hyperscaler or on-premise. The principal cost is the egress charge against the data resident in GCP, the migration cost itself and the operational disruption. The pattern is rare. Pattern two: EDP non-renewal with a return to on-demand pricing inside GCP. The buyer continues on GCP without the cumulative-spend commitment; the discount band collapses to the published rate card; the buyer’s costs typically rise without an offsetting commitment commitment. Pattern three: EDP reset at a lower commitment, with the same product mix at a tier the trailing-period consumption actually requires. Pattern four: EDP renewal at the same or higher commitment, with a revised CUD mix, a revised BigQuery edition selection and a revised Vertex AI scope.
The egress economics, the data-residency carry-forward, the BigQuery dataset portability and the Workspace identity portability all feature in the exit architecture. The exit position is documented as part of the EDP preparation regardless of whether the buyer intends to exit; the credibility of the exit position is what disciplines the EDP renewal economics.
The Google Cloud EDP paper sits inside a four-paper Google Cloud reading list. The companion papers extend the methodology into the adjacent commercial mechanics:
The methodology in this paper is the methodology Admodum has applied across more than fifteen GCP EDP engagements. Each engagement is structured as fixed fee, contingency / gainshare or annual retainer, depending on the buyer’s posture at the commitment window.
A senior Admodum advisor will walk the methodology through with your CIO, CFO, FinOps Lead or procurement team on a private call. Engagements run as fixed fee, contingency or annual retainer.