Run the methodology with a senior advisor.
A senior Admodum advisor will walk the methodology through with your CIO, CFO, sourcing or FinOps team on a private call. Engagements run as fixed fee, contingency or annual retainer.
Thirty pages on Enterprise Discount Program ramp design, the Savings Plans and Reserved Instance mix, the Marketplace channel pivot, Bedrock and SageMaker commitment scope, MAP credit treatment, egress economics and the exit-architecture posture the buyer carries into renewal.
The Enterprise Discount Program is the commercial container inside which AWS exchanges a multi-year consumption commitment for a discount tier applied across the buyer’s eligible spend. The construct exists because AWS reads predictable annual consumption as worth more than spot demand, and because the buyer reads price certainty as worth more than rate-card optionality.
The EDP is structured as a three-year (occasionally five-year) commitment to a defined annual consumption envelope. The commitment ramps year-on-year against a documented growth forecast. The discount tier is applied across the eligible consumption categories and is layered above, not below, the rate-card price reductions AWS publishes during the term.
The eligible-consumption scope is the boundary the buyer must read carefully. EC2, S3, EBS, RDS, networking and most native AWS services fall inside the eligible scope. Marketplace spend, support tiers and certain higher-margin services sit outside the default scope and require negotiated inclusion. The buyer who signs the EDP without contesting the eligible-scope boundary has already conceded the commitment’s economic envelope.
The shortfall clause defines what happens when the buyer’s consumption underruns the committed envelope. Most EDPs are written with a true-up obligation: any unconsumed commitment is billable at the close of the year. The construct of the shortfall, the protections the buyer writes against forecast risk and the carry-forward language that softens a single-year underrun are the three clauses on which the EDP’s real economics turn.
The ramp curve is the buyer’s longest leverage point. AWS will model a steep ramp that anchors growth to the seller’s narrative; the buyer will model a flatter ramp that anchors growth to the consumption record. The EDP’s value is decided where the two curves are reconciled.
The first input to the ramp is the buyer’s actual twelve-month consumption record, scoped to the EDP-eligible categories, reconciled across linked accounts, normalised for one-off events (migrations, decommissions, region launches) and corrected for any inflated rate-card readings the Cost Explorer view applies. The baseline is the floor the year-one ramp begins from.
The growth forecast is the curve from baseline to year-three commitment. The forecast must be defensible against documented programmes: planned migrations, application launches, region expansions, mergers and acquisitions, data-platform builds. The buyer who signs a year-three commitment that assumes growth without naming the programmes that deliver it has signed an instrument the buyer cannot defend at year three.
The carry-forward construct lets the buyer apply unconsumed commitment from year one against the year-two obligation, subject to a cap. Where AWS resists explicit carry-forward, the equivalent protection is a documented true-down right that lets the buyer adjust the year-two ramp if year-one consumption underruns the forecast by a defined threshold. Both protections are negotiable. Neither is automatic.
Savings Plans and Reserved Instances live inside the EDP envelope as discount instruments on top of the EDP discount tier. The mix the buyer designs across Compute Savings Plans, EC2 Instance Savings Plans, Standard RIs and Convertible RIs defines how much of the consumption envelope the buyer locks at the lowest rate and how much remains exposed to on-demand price.
Compute Savings Plans apply to EC2, Fargate and Lambda across instance families, regions and tenancies. They are the most flexible instrument and the least discounted of the three Savings Plan variants. EC2 Instance Savings Plans constrain the buyer to a single instance family in a single region but deliver the deepest Savings Plan discount. Reserved Instances apply to specific service categories (RDS, OpenSearch, ElastiCache, Redshift) where the Savings Plans instrument does not extend.
The mix is not a single decision. The buyer who applies one-year Convertible Compute Savings Plans across the production estate, three-year Standard RIs across stable database workloads and on-demand against the bursty surplus, captures the deepest blended discount with the least exposure to consumption variance. The mix runs at portfolio level, refreshed quarterly, against the actual consumption shape.
The buyer who treats the Savings Plans portfolio as a once-a-year procurement decision typically over-commits by twelve to twenty percent and absorbs the cost of unused commitment across the three-year term. The buyer who treats it as quarterly portfolio management captures the deepest blended discount and preserves the optionality on the bursty surplus.
AWS Marketplace allows the buyer to apply EDP-eligible spend against third-party software purchased through the AWS billing channel. The Marketplace channel pivot is the highest-leverage decision inside the EDP envelope for buyers with material third-party software spend.
The pivot is straightforward in concept. A third-party SaaS or software product purchased through Marketplace counts against the EDP commitment, draws down the buyer’s commitment obligation and earns the EDP discount tier on the eligible portion of the price. A third-party product purchased through a direct contract counts against the buyer’s third-party budget, does not draw down the EDP commitment and does not earn the EDP discount.
The pivot is harder in execution. Not every third-party product is available on Marketplace. Not every Marketplace listing carries the same channel-of-record protocol. Not every third-party publisher will honour an enterprise discount on Marketplace as the publisher does on direct contract. The buyer’s Marketplace channel-pivot programme must therefore be designed product-by-product, with the publisher’s commercial concession negotiated in parallel to the AWS channel-of-record arrangement.
Where the pivot works, the buyer reduces the EDP shortfall risk by a material proportion of the commitment, captures the EDP discount tier on third-party spend that would otherwise carry no AWS discount and concentrates the buyer’s billing relationship inside a single channel. Where the pivot fails, the buyer carries the worst of both worlds: the EDP commitment without the drawdown, and the third-party spend without the discount.
Generative-AI consumption inside AWS runs through Bedrock (foundation-model invocation) and SageMaker (custom-model training and inference). Both are EDP-eligible. Both carry pricing models that resemble none of the historical AWS consumption categories the buyer has prior experience with.
Bedrock’s pricing is per-token, with the rate set by the foundation model selected. The consumption forecast for Bedrock is therefore not a compute forecast; it is a use-case forecast that must be reconciled against the buyer’s AI roadmap, the model selection inside each use case and the throughput assumptions behind each application. The buyer who anchors a Bedrock commitment to top-down adoption targets without bottom-up use-case scoping is committing to a forecast the buyer cannot operationally defend.
SageMaker’s pricing is per-instance-hour for training and inference, with a separate charge structure for the MLOps layer. The commitment design must therefore reconcile training-job patterns (sporadic, GPU-heavy, time-bounded) with inference patterns (sustained, throughput-driven, latency-sensitive). The two patterns are licensed differently and committed differently.
The evaluation-credit treatment is the third Bedrock and SageMaker variable. AWS routinely offers credits to incentivise early adoption, particularly for net-new generative-AI workloads. The buyer should accept the credits, but should not allow the credits to inflate the year-one consumption baseline that anchors the year-two commitment ramp.
The Migration Acceleration Program offers AWS-funded credits and partner-funded services to defray the cost of migrating workloads from on-premises (or from another hyperscaler) onto AWS. MAP credits sit inside the EDP envelope and require the buyer to read three separate accounting boundaries.
The first boundary is what the credit covers. MAP credits typically fund a defined percentage of the post-migration AWS run-rate over a defined window (commonly twenty-four to thirty-six months), capped at a defined dollar value. The credit is earned against documented migration milestones (assessment, mobilisation, migration, optimisation) and is invoiced into the buyer’s AWS bill as a credit line.
The second boundary is what the credit does to the commitment. The MAP credit reduces the buyer’s gross AWS bill but does not reduce the buyer’s EDP commitment obligation. The buyer who structures the EDP ramp around the gross AWS spend and the migration plan around MAP-credited spend can find that the EDP year-two commitment exceeds the actual cash outlay by the full MAP credit, with the consequence that the EDP discount is partially offsetting the buyer’s own credits.
The third boundary is the partner-services overlay. The partner who runs the migration earns a partner-services credit funded by AWS and accounted separately from the run-rate credit. The buyer should examine the partner-services commercial terms with the same independence the buyer applies to the EDP itself. A partner whose remuneration is tied to faster migration is not a partner whose advice is aligned to the buyer’s long-run consumption efficiency.
Egress is the single largest architectural lock-in inside the AWS commercial relationship. The egress rate per gigabyte is published, is rarely discounted, and is excluded from most EDP discount tiers. The buyer who designs an architecture without an egress cost frame has designed the architecture that AWS prefers.
Egress costs accrue on data leaving an AWS region, leaving the AWS network or crossing a CDN boundary outside the AWS perimeter. Inside a region, between availability zones, the charge is small but non-zero. Inter-region egress is materially priced. Internet egress is priced at the headline rate. The architectural decisions that minimise egress (single-region deployment, in-region CDN, in-AWS data processing) are the decisions that maximise lock-in.
The buyer who builds in multi-region resilience, multi-cloud data platforms or hybrid on-premises integration accepts a higher egress charge in exchange for architectural optionality. The optionality has a cost; the cost is the price of leaving. The egress economics therefore translate directly into the EDP renewal posture: the buyer with low-egress architecture has limited credible BATNA, and the EDP renewal terms reflect that. The buyer with high-egress architecture has retained the option to repatriate and the EDP renewal terms reflect that as well.
The exit architecture is the position the buyer carries into EDP renewal. It is not a repatriation programme. It is the set of architectural choices, data-portability protections and commercial alternatives that allow the buyer to credibly walk away from a portion of the AWS commitment if the renewal terms are unfavourable.
The architectural protections sit inside the deployment design: portable container orchestration, neutral data formats, open identity protocols, infrastructure-as-code in vendor-neutral tooling, data residency outside AWS-proprietary storage formats. The protections do not prevent AWS adoption. They preserve the option to move a defined portion of the estate to another platform without architectural rewrite.
The commercial alternatives sit inside the procurement record: an Azure baseline contract, a GCP baseline contract, a colocation contract or a hyperscaler-agnostic managed-service contract held by the buyer’s strategic sourcing function. The alternatives do not need to be exercised; they need to be available. The EDP renewal negotiation in which the AWS seller knows that no alternative exists is a negotiation the seller controls.
The buyer who has costed a repatriation programme, has documented a partial multi-cloud strategy and has held a credible workload-by-workload portability map walks into the EDP renewal with a different commercial posture than the buyer who has not. Both buyers may end up renewing on AWS. Only one of them renews on the buyer’s terms.
AWS does not audit consumption in the publisher sense. AWS bills consumption against meters the AWS platform itself operates. The buyer’s verification exercise is therefore not an audit-defence exercise; it is a meter-trust exercise that runs continuously across the EDP term.
The meter trust runs three checks. The first is reconciliation: the Cost Explorer view, the Cost and Usage Report, the billing console statement and the AWS account-team-supplied dashboard should reconcile to the same total. Where they do not, the buyer must understand which view is authoritative and which is partial.
The second is rate verification: the rates applied to each line item should match the EDP discount tier, the applicable Savings Plan or RI and the rate-card price reductions AWS has published since signature. Where the actual blended rate diverges from the modelled blended rate, the buyer must identify which lines are mis-rated and contest them inside the AWS billing dispute window.
The third is third-party instrumentation: a vendor-independent consumption-observability tool (running on the buyer’s account, reading the CUR, reconciling against tagged cost allocation) is the protection against single-source verification risk. The buyer who relies exclusively on the AWS console for consumption truth is the buyer who has not separated the meter from the bill.
The buyer-side defence at commitment reconciliation, at year-end true-up or at renewal commitment recalibration is built from these three checks. Where the buyer has the consumption record reconciled across three independent views, the AWS account team’s commitment-recalibration narrative is contestable line-by-line. Where the buyer relies on a single view, the reconciliation is a presentation the buyer receives rather than a negotiation the buyer leads.
The AWS EDP paper sits inside a broader cloud-commitment reading list. The companion papers extend the methodology to adjacent hyperscaler and cloud-platform mechanics:
The methodology in this paper is the methodology Admodum has applied across forty-one AWS EDP engagements inside the firm’s engagement history. 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, sourcing or FinOps team on a private call. Engagements run as fixed fee, contingency or annual retainer.