Phase 1: Understanding the AWS Commercial Architecture

Effective AWS vendor management begins with mapping the commercial architecture — the set of agreements, commitments, and pricing mechanisms that together determine what the organisation actually pays for AWS services. Unlike traditional enterprise software where a single ELA or licence agreement governs all usage, AWS pricing flows through multiple parallel mechanisms that interact in complex ways.

The AWS Pricing Layer Stack

At the bottom is on-demand pricing — AWS's published list rates for every service. On-demand pricing is the baseline against which all other mechanisms are measured. No enterprise organisation with meaningful AWS usage should be paying on-demand rates across the majority of its compute spend.

The first layer of discount above on-demand is Reserved Instances and Savings Plans. These commitment-based instruments provide discounts of 30 to 75 percent on compute spend (EC2, Fargate, Lambda, RDS, SageMaker) in exchange for one-year or three-year usage commitments. This layer is entirely within the customer's control and requires no AWS negotiation — it is simply purchased through the console or API.

The second layer is the Enterprise Discount Programme (EDP), also referred to as a Private Pricing Agreement (PPA). An EDP is a negotiated contract where the organisation commits to a minimum annual spend on AWS in exchange for an additional percentage discount on top of on-demand rates. EDP discounts stack with Reserved Instances and Savings Plans discounts, creating a compounding effect. EDP discounts at the qualifying threshold of approximately $2 million or more in annual committed spend typically start at six to nine percent, scaling to approximately 15 to 20 percent for organisations committing $20 million or more annually.

The third layer is Private Pricing Agreements for specific services. A PPA for Amazon S3 might provide 15 percent off standard S3 storage rates in exchange for committing to a minimum monthly S3 spend. PPAs are available for high-volume services including S3, EC2, RDS, CloudFront, and data transfer, and are negotiated separately from the EDP.

Above this sits mandatory Enterprise Support, which is required for all EDP participants and is billed at 3 to 10 percent of monthly gross charges depending on spend tier. Understanding the full stack — on-demand baseline, RI/Savings Plans discounts, EDP percentage, service-specific PPAs, and mandatory support costs — is the prerequisite for any meaningful commercial optimisation.

Phase 2: EDP Negotiation Strategy

An EDP negotiation is not simply a discount discussion with an AWS account team. It is a structured commercial process that requires preparation, benchmarking, and understanding of what AWS values commercially from the relationship.

Pre-Negotiation Preparation

Effective EDP preparation requires 12 to 18 months of historical AWS spend data analysed at the service level. The purpose is to understand which services dominate spend, which are growing, and which are candidates for specific PPA negotiations alongside the EDP. AWS account teams will model EDP structures based on growth projections — having independent growth models based on your own roadmap data gives you the ability to challenge AWS's assumptions about what your committed spend should be.

Rightsizing and commitment optimisation should be completed before EDP negotiations begin. Signing an EDP based on current spend that includes significant waste — oversized instances, idle endpoints, excess reserved capacity — locks in that wasteful spend as the commitment baseline. Completing rightsizing first allows the EDP commitment to reflect optimised spend, and provides grounds for requesting a lower minimum commitment than AWS's initial proposal would suggest.

Benchmarking is critical. AWS publishes standard EDP discount structures, but actual negotiated terms vary significantly based on how account teams are incentivised, competitive pressure from Azure and Google Cloud, and AWS's assessment of the strategic value of the relationship. Independent benchmarking data on what similar-spend organisations have negotiated provides anchors for pushing discount percentages higher than AWS's opening position.

EDP Negotiation Levers

The primary negotiation lever in an EDP is committed spend. Higher commitments yield higher discounts. The decision between a one-year and a three-year term involves a meaningful discount differential — three-year terms typically secure approximately 15 percent discounts compared to roughly 10 percent for one-year deals at equivalent spend levels. The three-year premium is real, but so is the risk: committing three years of AWS spend to a platform with a rapidly evolving service portfolio carries strategic uncertainty that the additional discount should compensate for.

Secondary levers include: support cost structure (cap provisions and support credits, as described in our AWS Support Plan Negotiation guide); flexibility provisions for ramp-up periods in the first year; renegotiation rights triggered by material changes in the AWS pricing catalogue; credits for migration assistance or professional services; and carve-outs for new service categories (such as GenAI services) that were not in scope at the time of the original agreement.

Multi-Cloud Positioning as Leverage

AWS's commercial teams respond to credible multi-cloud alternatives. Organisations with meaningful Azure or Google Cloud footprints — or credible plans to develop them — have demonstrably stronger EDP negotiating outcomes than those with pure AWS commitments. Azure's competitive pricing for Windows-based workloads, Google Cloud's TPU advantage for AI/ML training, and the general cloud portability argument are all legitimate negotiating positions that AWS account teams are trained to respond to with commercial concessions.

The leverage is only credible if it is backed by genuine workload portability — organisations with significant AWS-proprietary service usage (DynamoDB, Kinesis, Step Functions, native Lambda integrations) have less credible multi-cloud positioning because the migration cost is real. Organisations running containerised workloads on EKS or compute-heavy workloads on standard EC2 have genuine portability and correspondingly stronger negotiating positions.

In one engagement, a global technology firm approaching EDP renewal had allowed commitment coverage to fall to 51% — well below the 70–80% target — resulting in a sustained on-demand overspend of approximately $3.4 million annually. Redress restructured the commitment portfolio in advance of renewal and renegotiated EDP terms using pacing data that demonstrated predictable coverage. The combined saving exceeded $4.1 million in year one. The advisory engagement fee was less than 4% of the first-year benefit.

Organisations that want independent analysis and negotiation support for AWS Marketplace strategy, EDP structuring, and procurement optimisation work with our AWS contract negotiation specialists. Redress Compliance is 100% buyer-side — no vendor commissions, no referral fees.

Need independent support for your AWS EDP negotiation?

We've supported 150+ enterprise AWS commercial negotiations. Buyer side only.
Talk to an Advisor →

Phase 3: Commitment Portfolio Governance

Post-signature EDP governance is where most organisations fail. The EDP discount is secured, and attention moves to the next commercial priority. Commitment portfolio management — Reserved Instances, Savings Plans, and EDP credit consumption tracking — becomes a background finance task rather than an active commercial programme. The result is commitment waste, coverage gaps, and EDP terms that erode in value as spend patterns change.

The Commitment Governance Calendar

Effective commitment governance follows a structured calendar. Monthly: review RI utilisation (target above 80 percent), Savings Plans coverage (target above 70 percent of eligible spend), and EDP credit consumption against the committed spend schedule. Quarterly: complete rightsizing analysis, review Savings Plans purchase recommendations from AWS Cost Explorer, and assess whether current commitment levels are appropriately sized for the next quarter's expected spend. Annually: full EDP performance review — did actual spend meet commitment, which services over- or under-performed against projections, and what does the renewal negotiation need to address?

Reserved Instances vs Savings Plans: The Ongoing Choice

The choice between Reserved Instances and Savings Plans is not a one-time decision made at EDP inception. As the workload evolves — adding Fargate containers, expanding Lambda usage, adopting new EC2 families — the optimal commitment instrument changes. Reserved Instances provide deeper discounts for stable, specific EC2 workloads; Savings Plans provide broader coverage across EC2, Fargate, Lambda, and SageMaker with less management overhead. A commitment portfolio that was optimally structured at EDP signing may become suboptimal 18 months later as the architecture modernises.

The quarterly commitment review should explicitly assess whether the current RI-to-Savings-Plans balance is appropriate for the current workload composition. Organisations that have materially adopted containerisation or serverless since their last RI purchase cycle should shift coverage toward Compute Savings Plans. Those with newly stable, high-volume EC2 workloads may benefit from Standard RI coverage for the additional discount depth.

Tracking EDP Credit Consumption

EDP agreements specify a minimum spend commitment, typically expressed as an annual total. AWS tracks consumption of this commitment through a credit mechanism. Organisations that fall below their minimum commitment by year-end may be required to pay the shortfall amount under the agreement terms — a significant financial exposure that requires active monitoring throughout the year.

Monthly EDP credit consumption tracking should be a standard finance reporting item for any organisation on an EDP. AWS Cost Explorer provides EDP utilisation dashboards, but many organisations supplement these with internal models that project year-end consumption based on current trajectory. The goal is to identify commitment shortfall risk at least 60 to 90 days before year-end, while there is still time to adjust consumption or negotiate with AWS about the commitment trajectory.

Phase 4: Data Egress Cost Management

Data egress is the most common surprise cost in enterprise AWS environments, accounting for 6 to 12 percent of typical bills yet remaining invisible in most cost planning models. Unlike compute costs — which are generally understood and covered by commitment instruments — egress charges accumulate based on data movement patterns that architects do not always account for during design.

Understanding the Egress Cost Landscape

AWS charges $0.09 per GB for data transferred from AWS to the internet in most regions. Cross-region data transfer between AWS regions costs $0.02 to $0.09 per GB depending on which regions are involved. Cross-AZ transfers within the same region cost $0.01 per GB in each direction — seemingly modest but significant in microservices architectures where hundreds of services communicate across Availability Zones continuously.

CloudFront distributions significantly reduce internet egress costs by caching content at edge locations — CloudFront origin-to-edge transfer is charged at lower rates than direct S3-to-internet or EC2-to-internet egress, and edge-to-user delivery via CloudFront incurs no additional egress charge from the AWS origin perspective. Organisations serving content to internet users without CloudFront are paying significantly more than necessary for egress.

Architecture Decisions That Drive Egress Costs

Several common architecture patterns generate egress costs that are entirely preventable with design awareness. Multi-region active-active architectures with synchronous cross-region database replication or service calls generate continuous cross-region transfer charges. Data analytics pipelines that transfer raw data from S3 to EC2 for processing, then transfer results back to S3, generate billable transfer if the EC2 instances are in a different AZ from the S3 bucket. Logging architectures that ship logs from EC2 to a centralised ELK stack or Splunk instance in another AZ generate per-GB cross-AZ transfer charges at every log event.

The egress cost analysis should be a mandatory component of any architecture review for new workloads. The question is not just "how much compute will this cost?" but "where does data flow, and what does each crossing of a region or AZ boundary cost?" In large-scale architectures, this analysis routinely identifies $50,000 to $200,000 in annual egress charges that can be reduced through architecture adjustments.

Phase 5: Support Plan Optimisation

Enterprise Support is a mandatory cost for EDP participants, billed at 3 to 10 percent of gross monthly charges. For organisations spending $500,000 per month, this support cost alone reaches $21,000 to $50,000 per month — a cost that must be managed actively to prevent it from eroding the value of the EDP discount.

The key governance actions for support plan optimisation are covered in detail in our AWS Support Plan Negotiation guide. Within the vendor management context, the critical principle is that support cost must be included in the total EDP value calculation from the start. An EDP discount of 12 percent that carries a mandatory support cost of 8 percent of gross charges provides a net commercial benefit of approximately 4 percent — a materially different picture than the headline discount implies.

The most commercially sophisticated AWS customers treat the EDP, support, Reserved Instances, Savings Plans, and PPAs as a single integrated commercial programme — not as separate line items managed by different teams. The interaction effects between these instruments are where the real value is created or destroyed.

Phase 6: Private Pricing Agreements for High-Volume Services

Private Pricing Agreements allow enterprises to negotiate service-specific discounts beyond the EDP percentage for services with high and predictable consumption. PPAs are available for Amazon S3, Amazon CloudFront, Amazon EC2, Amazon RDS, Amazon Redshift, and several other services where AWS has sufficient commercial interest in locking in volume commitments.

When to Pursue PPAs

PPAs are worth pursuing when: a specific service represents a significant proportion of total AWS spend (typically 10 percent or more); the consumption pattern is predictable enough to support a minimum monthly commitment; and the PPA discount on that service, combined with the EDP discount, generates a better blended rate than the EDP discount alone on that service category.

Amazon S3 is the most commonly negotiated PPA target because storage costs are stable and predictable, and organisations with petabytes of data generate S3 costs that justify a service-specific negotiation. CloudFront PPAs are valuable for media companies or enterprises with high CDN traffic volumes. RDS and Redshift PPAs are relevant for data-intensive organisations with large, stable database fleets.

Structuring PPA Terms

PPA terms should include minimum spend commitments that are set conservatively — below actual expected consumption — to avoid shortfall penalties. Like EDP commitments, PPA minimums should be set at 80 to 85 percent of expected consumption to provide a buffer for usage variability without sacrificing the commitment discount. Ramp provisions for PPA commitments that grow with new workloads protect against locking in a volume commitment before the associated workload fully scales.

Phase 7: Renewal Strategy

AWS EDP renewal is not a passive process. Renewal negotiations typically begin 90 to 120 days before EDP expiry, and AWS will present renewal terms based on actual spend growth and projected future spend. The renewal negotiation is an opportunity to recalibrate commitment levels, update service-specific PPA structures, renegotiate support cost provisions, and introduce flexibility for new workload categories that were not addressed in the original agreement.

Building the Renewal Case

The renewal case should be built from three inputs: actual EDP performance (did spend meet commitment, which services exceeded expectations, which underperformed); projected spend for the renewal term based on current roadmap; and competitive benchmarking of what similar organisations are receiving in current AWS negotiations. This data assembly — ideally completed 90 days before expiry — enables a structured, evidence-based renewal conversation rather than a reactive response to AWS's initial renewal proposal.

Renegotiating Support Cost Structure

EDP renewal is the primary opportunity to negotiate changes to the support cost structure. Cap provisions that limit support fees at a fixed monthly amount, support credits that reduce the effective support rate, and commitments on TAM engagement quality are all negotiable at renewal. Organisations that did not address support costs at the original EDP signing should make support cost restructuring a priority at renewal.

Term Length Decision

The renewal term length decision — one year versus two or three years — involves a familiar trade-off between discount depth and commitment flexibility. In the current cloud environment, where AWS service portfolios are evolving rapidly (new AI infrastructure, database migration tools, serverless compute expansion), three-year commitments carry more strategic risk than they did three years ago. The discount premium for three-year terms should be evaluated against the cost of being locked into commitment levels and structures that may not reflect the organisation's actual AWS footprint by year three.

Phase 8: FinOps and Commercial Alignment

The final element of a comprehensive AWS vendor management programme is the alignment between FinOps engineering and commercial procurement. In many organisations, the cloud engineering team manages Reserved Instances and Savings Plans independently of the procurement team that manages EDP negotiations and PPA structures. This separation creates coordination failures: commitment instruments purchased without knowledge of EDP carve-outs; EDP commitments sized without awareness of upcoming commitment expiries; and support cost structures not considered in total cost of ownership models.

The AWS vendor management programme should have a single owner responsible for the total commercial programme — including RI/Savings Plans coverage, EDP commitment tracking, support cost governance, PPA monitoring, and renewal strategy. This owner operates at the intersection of finance, engineering, and procurement, and is accountable for the Effective Savings Rate: the ratio of actual savings achieved versus the maximum achievable savings given the organisation's spend profile.

Playbook Summary: The 8-Phase AWS Vendor Management Programme

  • Phase 1 — Baseline: Map the full commercial architecture — on-demand baseline, RI/Savings Plans discounts, EDP terms, PPAs, support costs — and calculate the true net cost of each mechanism.
  • Phase 2 — EDP Negotiation: Prepare with 18 months of spend data, complete rightsizing before committing, benchmark against market rates, and negotiate all terms including support cost provisions.
  • Phase 3 — Commitment Governance: Run monthly coverage and utilisation reviews, quarterly rightsizing, and annual EDP performance assessment. Track EDP credit consumption against commitment trajectory from month one.
  • Phase 4 — Egress Management: Conduct architecture-level egress cost analysis for all significant workloads. Implement CloudFront for content delivery, optimise cross-AZ traffic patterns, and monitor egress by service monthly.
  • Phase 5 — Support Optimisation: Include support costs in total EDP value calculations. Negotiate cap structures and support credits. Right-size support tier across accounts. Define and monitor TAM engagement quality.
  • Phase 6 — PPA Strategy: Identify high-volume service candidates for PPAs. Structure PPA commitments conservatively with ramp provisions. Integrate PPA discounts with EDP blended rate modelling.
  • Phase 7 — Renewal Preparation: Begin renewal preparation 90 days before expiry. Build the renewal case from actual performance data, roadmap projections, and competitive benchmarking. Renegotiate support cost structure at every renewal.
  • Phase 8 — FinOps Alignment: Align FinOps engineering and commercial procurement under a single AWS commercial programme owner. Measure Effective Savings Rate as the primary performance indicator.