What is an AWS Private Pricing Agreement?
An AWS Private Pricing Agreement (PPA) is a custom-negotiated commercial contract between an organisation and AWS. The customer commits to a minimum level of AWS spend over a 1, 3, or 5-year term. In exchange, AWS applies a negotiated discount across AWS services, sometimes uniformly across all services, sometimes weighted toward specific high-spend services.
Three things define a PPA.
A minimum annual commitment expressed in dollars. Typically starting around 500K USD per year, with strategic pricing breaks at higher commitment levels.
A term length of 1, 3, or 5 years. Longer terms generally yield larger discounts.
A discount structure applied to in-scope services. Discounts do not stack with other AWS discount mechanisms like Savings Plans or Reserved Instances, but those mechanisms can run in parallel and contribute to commitment retirement.
Outside the PPA itself, two adjacent commitments are mandatory: enterprise-grade support for the duration of the contract, and acceptance that the commitment can only ratchet upward, never down, across renewal cycles.
What changed when AWS rebranded EDP as PPA?
The short answer is that nothing material changed. AWS rebranded the Enterprise Discount Program (EDP) as the Private Pricing Agreement (PPA), and now uses PPA as the umbrella term for all privately negotiated pricing contracts.
The longer answer is mildly more interesting:
| Aspect | EDP (legacy) | PPA (current) |
|---|---|---|
| Original scope | Cross-service, organisation-wide flat discount | Originally service-specific; now used as umbrella term for all private pricing |
| Commit structure | Annual minimum spend, 1 to 5 year term | Annual minimum spend, 1 to 5 year term, identical |
| Marketplace retirement | Portion of commit (set in agreement) | Portion of commit (set in agreement), eligibility tightened May 2025 |
| Enterprise Support requirement | Mandatory | Mandatory, identical |
| What is in the contract | Discount terms, commitment, EBA building blocks | Discount terms, commitment, EBA building blocks, identical |
If your previous contract said EDP and your renewal says PPA, the only practical change is the language on the cover page. AWS account teams now use PPA in all new commercial paperwork, but many customer-side procurement teams still call it EDP. Both terms refer to the same thing.
One subtle distinction is worth knowing. Historically, EDP implied a broad cross-service discount, while PPA was service-specific. Today, AWS PPAs can be either. If you have an existing EDP with a flat cross-service discount, you can sometimes negotiate a separate service-specific PPA on top, for example a deeper discount on EC2 and S3 specifically. Discounts do not stack on the same service, but you can structure a hybrid where each service uses whichever agreement gives the better rate.
Who qualifies for an AWS PPA?
AWS does not publish a hard minimum spend requirement for a PPA, and account teams are typically not authorised to share benchmark figures. In practice, the thresholds break down as follows:
| Annual AWS Spend | PPA Eligibility | What to expect |
|---|---|---|
| Below 250K USD | Generally not available | Use Savings Plans and Reserved Instances. AWS will likely decline a PPA conversation. |
| 250K to 500K USD | Edge case | Possible via a Solution Provider partner (Partner-Led PPA) with bundled commit. Direct AWS engagement is rare at this level. |
| 500K to 1M USD | Yes, but modest discount | Enters the formal qualification range. Discount expectations should be modest. Partner-Led structure usually delivers better total value. |
| 1M to 5M USD | Yes, meaningful discount territory | Strategic pricing breaks at 1.5M, 2M, and 5M. Discounts become commercially significant. |
| 5M USD and above | Yes, full negotiating power | Custom terms, larger discounts, and additional incentives such as migration credits, Marketplace allowances, training credits. |
Beyond spend, three structural prerequisites apply.
Workload architecture matters. Some negotiated benefits require that both your application and control plane are fully hosted on AWS. Hybrid or multi-cloud workloads can complicate certain incentives.
Forecastable usage matters. AWS will ask for spend projections across the term. If your usage is volatile or you are mid-migration, a PPA is harder to size accurately.
Contract timing matters. AWS PPA agreements must typically be signed by the 20th of a month to begin on the 1st of the next month. Late signatures push start dates by a full month.
How are AWS PPA discounts shaped?
AWS does not publish PPA discount rates, and account teams are instructed not to share benchmark data. Discounts are negotiated as part of each agreement, with the outcome shaped by four levers in combination.
Spend baseline. The starting point is current AWS run rate, not aspirational future spend. Customers who try to negotiate based on optimistic three-year projections rather than current burn typically receive lower discounts than customers who anchor to verified actuals.
Growth trajectory. AWS values predictable growth above absolute size. A customer at 2M with credible 50 percent year-over-year growth can sometimes negotiate better terms than a customer at 4M with flat growth, because the lifetime contract value differs.
Commitment willingness. Term length and commit size are levers. Longer terms (3 or 5 years) and higher commits reach progressively better tiers. The marginal discount per dollar of commit is non-linear, with strategic pricing breaks at specific commit levels.
Timing within AWS's fiscal cycle. Account team incentives shift quarterly. Q4 (calendar) and Q1 (AWS fiscal year) tend to produce more aggressive discount offers than mid-year. Renewals timed to these periods often deliver better outcomes.
Industry insights suggest discounts can range from around 5 percent for commits starting near 500K with 1-year terms, up to 20 percent or more for commits exceeding tens of millions with longer terms. These are estimates derived from observed deals, not published rates. The exact figure for any organisation is private to that contract and varies with the four levers above.
Three observations matter more than absolute numbers.
The marginal discount per dollar of commit is non-linear. Going from 1.4M to 1.5M can reach a noticeably better tier; going from 2.5M to 3M typically does not. Strategic commit sizing means committing exactly to the next break, not above or below it.
Term length matters but only when usage is predictable. Five-year deals deliver the deepest discounts but require the most reliable usage forecasting. Many SMBs over-estimate their five-year confidence.
Account team timing matters. Q4 and Q1 of AWS's fiscal year tend to produce the most aggressive discount offers, especially on the last working days of the quarter.
Does AWS Marketplace spend count toward PPA commitment?
One of the most underused mechanics in AWS PPAs is Marketplace commitment retirement. AWS allows a portion of annual PPA commitment to be retired through qualifying AWS Marketplace SaaS purchases. The exact percentage is negotiated as part of the PPA itself and varies by deal. In TechNative's experience, the typical allowance is around 25 percent of annual commit, but this is not a published standard.
The math, when the allowance is structured at 25 percent: a customer with a 4M annual PPA commit can route up to 1M of qualifying SaaS purchases through AWS Marketplace, and that 1M counts toward the commit. Software the organisation was going to buy anyway (observability platforms, security tools, sales intelligence software, data infrastructure) pulls double duty against the AWS commitment.
Three rules govern eligibility.
The product must be eligible. AWS tightened the eligibility criteria for Marketplace retirement in May 2025. Only SaaS products fully deployed on AWS qualify. SaaS products with components running outside AWS (hybrid or multi-cloud architectures) no longer count toward commitment retirement. Before routing software procurement through Marketplace as a retirement strategy, verify with the vendor that their product meets the post-May-2025 fully-on-AWS deployment criterion.
The deal must be structured correctly. Whether a Marketplace transaction retires PPA commitment depends on the offer type, the contract structure, and how the AWS account hierarchy is configured. Renewals accepted on the wrong account or under the wrong offer type can fall outside the eligibility envelope. The customer pays the same and uses the same software, but the spend does not count.
The timing must align with the PPA term. A three-year Marketplace renewal accepted eighteen months into a PPA can lock the enterprise into a misaligned term structure. At PPA renewal, there is no flexibility to renegotiate the Marketplace contract jointly. This forecloses commercial power.
Three practical implications.
Marketplace strategy should be designed before signing the PPA, not afterward. The commit size should account for the planned Marketplace retirement so that the negotiated allowance is fully utilised.
Procurement processes typically need redesign. Routing third-party SaaS through Marketplace requires governance, approval flows, security review, contract terms, that most SMBs have not built. This is the focus of a separate guide on AWS Marketplace governance.
Standard AWS service-tier discounts and promotional credits do not count toward commitment retirement. Only actual cash spend on AWS services and qualifying Marketplace SaaS counts.
Why is Enterprise Support mandatory under an AWS PPA?
Every PPA carries an obligatory enterprise-grade support enrolment. The payer account and all linked accounts must be on AWS Enterprise Support, or an equivalent Partner-Led Support arrangement, for the duration of the contract.
The cost is non-trivial. AWS Enterprise Support is priced as a percentage of monthly spend:
| Monthly AWS Spend | Enterprise Support Rate |
|---|---|
| Up to 150K USD | 10% |
| 150K to 500K USD | 7% |
| 500K to 1M USD | 5% |
| Above 1M USD | 3% |
| Minimum monthly fee: 5K USD |
For a customer at 1M annual AWS spend (around 83K per month), Enterprise Support adds roughly 100K per year. If the negotiated PPA discount was at the lower end of typical ranges, Enterprise Support consumes a significant portion of the discount itself.
For SMBs and mid-market customers in the 500K to 2M range, this is the single most important number to model before signing a PPA. There is one structural alternative, Partner-Led Support, available only through Advanced or Premier tier AWS Solution Provider partners, which we cover in detail in our guide on Partner-Led Support.
What happens if you do not hit your PPA commitment?
PPA commitments are floors, not targets. If actual AWS spend over the year falls below the committed amount, the customer pays the difference as a shortfall payment. Critically, the negotiated discount does not apply to the shortfall, meaning you pay full undiscounted price for the gap between actual and committed.
Two structural rules amplify this risk.
Commitments only ratchet upward. If you committed 2M in year one, year two cannot commit less. PPAs are designed to grow with the customer, not flex with their reality.
Shortfall is calculated at the year-end true-up. Mid-year burn rates that look healthy can be misleading if a major workload is decommissioned in Q4 or a migration is delayed.
Standard mitigation strategies are: under-commit at first signing and renegotiate upward at renewal, build Marketplace retirement into the commit plan, and for organisations with volatile usage, negotiate flexibility provisions or shortfall insurance through a partner.
The biggest mistake in first PPAs is setting the commit based on optimistic growth forecasts. The second-biggest is committing five years on a usage profile that will only stay stable for two.
AWS-Led or Partner-Led PPA: which structure fits European SMBs?
Every PPA can be signed in one of two structures, directly with AWS (AWS-Led) or through an AWS Solution Provider partner (Partner-Led). The choice is not just a price comparison. It is a decision about capability, control, and commercial position, with different optimal answers at different scales.
Why this is not just a price comparison
At low commit levels (below 5M annual spend), the price math typically favours Partner-Led structures because mandatory Enterprise Support consumes a meaningful portion of the negotiated discount. Partner-Led Support, available only through Advanced or Premier Tier partners, removes that cost.
At high commit levels (10M and above), the price math shifts. AWS Enterprise Support's 3 percent rate above 1M monthly spend becomes competitive with most partner pricing, particularly if the customer does not value the partner's adjacent services. AWS becomes a top three cost driver alongside payroll and marketing, and direct alignment with AWS commercial teams becomes mission-critical.
Between those points, the decision is not about price; it is about capability and growth trajectory.
Three thresholds, three different decisions
| Annual spend | Growth trajectory | Recommended commercial structure | Where partner value sits |
|---|---|---|---|
| Below 5M USD | Stable or growing | Partner-Led PPA | Reseller, managed services, FinOps, governance |
| Around 5M with growth toward 10M | Trajectory matters more than current spend | Partner-Led PPA continues, but the orientation window opens | Reseller plus managed services, with active skill gap analysis underway |
| 10M USD and above | Established or growing | Direct AWS commercial agreement | Managed services, FinOps, governance, audit. Reseller relationship typically winds down. |
The middle threshold deserves attention. Customers approaching 5M annual spend with a credible trajectory toward 10M are not yet at the decision moment. They are in the orientation window. This is the right time to begin the strategic work, not the right time to choose the final commercial structure.
In the orientation window, the questions are: where should AWS expertise sit in the organisation, in-house or sourced through partner managed services? What is the FinOps maturity gap and how is it closed? What does AWS Organizations structure need to look like to support direct engagement at scale? What does procurement integration require? These questions take 12 to 24 months to answer well. Starting them six weeks before a PPA renewal is too late.
Four decision criteria for the 10M+ enterprise
For enterprises approaching or exceeding 10M annual AWS spend, four questions determine the optimal commercial structure.
Do we have AWS expertise in-house for 24x7 operations, governance, and FinOps?
Can we manage billing complexity, including forecasting and chargeback?
Can we organise Marketplace procurement centrally and under control?
Do we expect to grow past 10M annual spend?
Four times yes points toward direct AWS commercial agreement and Enterprise Support purchased from AWS. Gaps in any of these capabilities point toward a hybrid model: direct AWS commercial agreement combined with partner-led managed services, FinOps, and operations.
Three partnership layers, not one
A point worth making explicit because it is often misunderstood: shifting from Partner-Led PPA to direct AWS commercial agreement at higher scales does not end the partner relationship. It changes the layer.
The TechNative partnership model has three layers, and they are stackable, not exclusive.
The reseller layer is where TechNative is the contract counterparty for AWS spend. Most relevant for SMB and mid-market customers below 10M annual spend.
The managed services layer is where TechNative operates the AWS estate, 24x7 operations, governance, security posture, incident response, monitoring. This continues regardless of who holds the commercial reseller relationship.
The consultancy layer is where TechNative delivers advisory, audit, FinOps assessment, transition projects, skill gap analysis, training. Particularly relevant during orientation windows.
A customer at 12M annual spend may sign a direct PPA with AWS (no reseller relationship), engage TechNative as managed services partner (ongoing operations), and use TechNative consultancy for the annual FinOps audit (time-bounded). All three at once, none mutually exclusive.
The decision to "go direct with AWS" is a decision about the reseller layer only. The other two layers can continue or grow during such a transition.
Reality check
A good partner advises actively on this, including telling the customer when the right answer is direct AWS engagement on the commercial side. The wrong choice is not partner versus AWS, and ending the reseller relationship at higher scales does not mean ending partnership entirely.
The real risk is lack of governance, not partner structure. Most enterprises that struggle with PPA outcomes do not struggle because they picked the wrong commercial structure. They struggle because nobody owns the commit forecast, the Marketplace retirement strategy, the renewal pipeline, or the FinOps function. Whoever holds the reseller relationship is far less consequential than whether someone owns those decisions.
Two honest notes
The 10M threshold is not absolute. Some organisations at 8M already have the in-house capability to run direct engagement well. Some at 15M still benefit from Partner-Led structures because their internal FinOps function is immature. Use the four decision criteria, not the spend number, to determine the right structure.
The reseller relationship has value beyond pricing. A good Solution Provider partner delivers consolidated billing across AWS and third-party software (CPPO), local-language support, time-zone alignment, and bundled FinOps. Customers who shift to direct AWS purely to "save the partner margin" frequently underestimate what they are giving up. The savings analysis should include the full cost of replacing those services with internal hires or alternative vendors.
What does this mean for European SMBs and mid-market?
The PPA programme was designed for large US enterprises. It works for European SMBs and mid-market organisations, but several factors change the calculus.
Smaller commits hit the steepest Enterprise Support tier. A 500K to 1M annual spend lands squarely in the 10 percent ES tier, which can erase the entire negotiated PPA discount if not addressed. Partner-Led Support typically resolves this for organisations in this range.
Currency exposure matters. AWS PPAs are typically denominated in USD. EUR or GBP-based organisations carry FX risk over multi-year terms. Some Solution Provider partners can structure local-currency invoicing on top of the underlying USD AWS contract, which absorbs FX volatility.
Local-language operations (Dutch, French, German) are not a default feature of AWS Enterprise Support but are standard for most European Solution Provider partners.
FinOps maturity is typically lower than in US peers. Most European mid-market organisations do not have a dedicated FinOps function in-house. A Partner-Led PPA where FinOps is included as standard service often delivers better outcomes than an AWS-Led PPA where the customer is expected to operate FinOps themselves.
Marketplace retirement requires deliberate procurement design. Many European SMBs already buy SaaS tools that could qualify for retirement but are routed outside Marketplace. The retirement allowance is unused in a majority of first-time PPAs we encounter.
The decision framework is straightforward. If annual AWS spend is at or approaching 500K to 1M, growth is reliably forecastable for 1 to 3 years, and the organisation values multi-year budget certainty, a PPA, typically Partner-Led, becomes commercially attractive. Below those thresholds, Savings Plans and Reserved Instances usually deliver better risk-adjusted savings.
If annual AWS spend is approaching or exceeding 5M with credible growth trajectory toward 10M, the orientation window opens. This is the right time to start the strategic work on in-house versus managed capability, FinOps maturity, AWS Organizations design, and procurement integration. The decision moment arrives 12 to 24 months later.