Before you sign an AWS EDP: a 2026 procurement checklist that keeps your exit option open

Key points:

• An AWS EDP, now called a Private Pricing Agreement (PPA), trades a spend commitment over a fixed term for a negotiated discount. The discount and terms are private, so nobody outside your deal can tell you "the" EDP rate. Anyone quoting a standard percentage is guessing.
• Read the commitment terms before the discount line. Commit to a baseline you would spend even if growth stalls, read the shortfall clause before the discount line, and ask how Marketplace purchases, Savings Plans and Reserved Instances count toward the number.
• Leaving AWS is cheaper on paper than it was in 2023. AWS waives internet data transfer out for customers moving all their data off AWS, and the EU Data Act bans switching charges, including egress, from 12 January 2027. Neither rule cancels a commitment you signed, because proportionate early termination penalties stay legal under the Data Act.
• Architecture decides whether the exit clause is usable. Workloads on Kubernetes, PostgreSQL, the S3 API and Terraform still burn down your AWS commitment, and they can move. Workloads wired into proprietary services burn it down too, and they mostly cannot.
• Qovery runs your apps on Kubernetes inside your own AWS account, so the EKS, EC2 and RDS spend lands on your AWS bill like any other usage, and the same deployments can run on GCP, Azure, Scaleway or an existing cluster. Qovery is also sold on AWS Marketplace, with the "Deployed on AWS" badge.

I sit in a lot of AWS conversations at Qovery, on our side and on our customers' side, and the pattern is always the same. Finance sees a discount, engineering sees a number they will be held to for three years, and nobody owns the question "what happens if we want to leave in year two?"

That question deserves an owner. The UK's competition regulator found that less than 1% of cloud customers switch provider each year (CMA final decision, July 2025), and multi-year commitments are part of why. A commitment you can't exit is fine if you never want to. Most companies I talk to want to keep the option, even if they never use it.

This is the checklist I would hand a procurement team before signing. It covers the contract, the money, the exit costs and the architecture, because good exit terms on top of an unportable stack still leave you stuck.

What exactly are you signing with an AWS EDP or Private Pricing Agreement?

An AWS Enterprise Discount Program, which AWS now calls a Private Pricing Agreement (PPA), is a private contract in which you commit to a minimum AWS spend over a multi-year term and AWS applies a negotiated discount to your eligible usage. The discount rates, the minimum, the term and the fine print are negotiated per customer and are not published.

AWS does not publish EDP or PPA rates. Its enterprise pricing page describes on-demand, Reserved Instances ("up to a 75% discount compared to on-demand pricing") and then sends enterprises to AWS Sales. The FinOps Foundation describes negotiated discounts the same way: often private, covered by non-disclosure terms, and not shared publicly.

So I will not quote discount percentages here, and you should be skeptical of anyone who does.

Confirm the common traits in your own draft rather than assume them. CloudForecast's 2026 EDP guide reports that terms of one to five years are standard, that the annual commitment for US organizations typically starts around $1 million, and that unused commitment is billed as a true-up at the end of the year or term, depending on how the contract is written.

What is on the checklist?

The checklist has ten items: commit size versus forecast, shortfall terms, term length, what spend counts, Marketplace drawdown, Savings Plans and RI interaction, growth ramps, exit costs, architectural lock-in, and a tested exit plan. Each one is a question procurement can put to AWS and to its own engineering team before signing.

How big should the commitment be compared to your forecast?

Size the commitment to the spend you are confident about even in a bad year, and let the forecast above that baseline stay on demand or on short-term Savings Plans. A discount on spend you never incur is worth nothing, and the shortfall is billed anyway.

Forecasts in cloud are consistently wrong in the expensive direction. Flexera's 2026 State of the Cloud report (published 18 March 2026, more than 750 respondents) put wasted cloud spend at 29%, the first increase in five years, driven partly by AI workloads and underused commitment discounts. If close to a third of spend is waste, a commit sized on today's bill may already include money you plan to cut.

Here is how I would size it:

• Start from 12 months of actual spend in Cost Explorer or the Cost and Usage Report, not the budget.
• Subtract the optimization work already planned (rightsizing, deleting idle environments, moving storage tiers).
• Model three scenarios: flat, planned growth and a bad year. Commit near the bad-year number.
• Add the known migrations only once they have a date and an owner.

If you are moving workloads onto AWS as part of the deal, pair the commitment with migration funding rather than inflating the commit. I wrote up how AWS credits, MAP and partner funding work for that phase, including what credits do not cover.

What happens if you fall short?

If your eligible spend comes in under the commitment, AWS bills the difference. Whether that happens every year or once at the end of the term depends on your contract, and that one clause matters more than a point or two of discount.

Ask for these in writing:

• Measurement period. Cumulative measurement over the whole term is friendlier than annual true-ups, because a slow year one can be absorbed by year three.
• Carry-forward or rollover. Overspend in one year counting toward the next, and shortfall rolling into a renewal instead of being billed immediately.
• What triggers the bill. Is the shortfall due if you terminate early, if you restructure accounts, or if an acquired company stays on another cloud?
• Interaction with renewal. Some teams cure a shortfall by renewing early with a bigger commit. That is how a single oversized deal becomes a decade.

Treat the shortfall as the price of leaving. If you would pay $400,000 in shortfall to move a workload off AWS in year two, that is your real exit fee, and it belongs in the business case next to egress.

How long should the term be?

Choose the shortest term whose discount still beats what you could get from published instruments alone. Longer terms usually earn better rates, and each extra year also extends the period in which leaving is expensive.

Compare the PPA against the public baseline first. AWS Savings Plans offer up to 72% off on-demand compute on one-year or three-year terms, with no negotiation. The FinOps Foundation's rate optimization capability describes the same split: published commitment discounts on one or three years, and negotiated discounts on top.

Ask what you expect your architecture to look like at the end of the term. If you can't describe year three with any confidence (an AI roadmap, an acquisition, a region you have not picked yet), keep the term short.

What spend counts toward the commitment?

Eligible AWS usage counts, and almost everything else needs to be confirmed by name. Get the list of what counts and what does not as an exhibit to the contract, not as an email from the account team.

Items to check one by one:

• AWS services. Most usage counts. Ask about anything billed differently, such as Support, training, Professional Services and region-specific or sovereign offerings.
• Taxes and credits. Credits reduce your bill, so ask whether they also reduce the spend counted toward the commit. AWS's promotional credit terms already exclude AWS Marketplace, some Support plans, Professional Services and any Savings Plan or Reserved Instance upfront fee from what credits can pay.
• Savings Plans and Reserved Instances. These are charges on your AWS bill. Ask whether their fees count toward the commit and whether the PPA discount applies on top of the Savings Plan or RI rate. CloudForecast's guide reports that the EDP percentage usually stacks on top of Savings Plans, RIs and Spot, but this is exactly the kind of term to see written down.
• Marketplace purchases. Covered in the next section, because the rules changed in 2025.

You can verify the discount once it is live. In the Cost and Usage Report line item columns, discounts appear as their own line item types, and NetUnblendedCost shows what you pay after discounts. Ask FinOps to build that report before signing, so you can check month one against the contract.

Do AWS Marketplace purchases count, and which ones?

Eligible AWS Marketplace purchases can draw down a PPA commitment, up to a cap, and since May 2025 the eligibility depends on whether the software is "Deployed on AWS". This is the cheapest way to fill a commitment, because you redirect SaaS spend you already have instead of creating new AWS usage.

AWS opened Marketplace to SaaS products hosted anywhere from 1 May 2025, and at the same time introduced a "Deployed on AWS" badge for products that run on AWS infrastructure. AWS says badged products "may qualify for additional AWS customer benefits", and non-badged listings do not get those benefits. In practice, the benefit buyers care about is commitment drawdown. CloudForecast reports that since 1 May 2025 a SaaS product only counts if it runs entirely on AWS, and that eligible Marketplace purchases retire the commit at full value, capped by default at 25% of the annual commitment.

What to do with that:

• List the SaaS tools you already pay for and check which ones sell on Marketplace with the badge.
• Negotiate the Marketplace cap at signing if you plan to route a lot of software spend through it.
• Ask vendors for private offers, so you keep negotiated pricing while the spend still counts.
• Marketplace spend raises your drawdown without adding AWS-specific dependencies, and software that also runs on other clouds is the best kind to route there.

How should growth ramps be structured?

Ask for a commitment that steps up year by year instead of a flat annual number. Year one is when your migration is least finished and your forecast least reliable, so a ramp puts the large numbers where you have the most information.

A ramp also helps exit planning. It keeps year one low, which is when you are most likely to discover that a workload belongs elsewhere. And it makes the later, bigger years conditional on growth that you can measure before committing to a renewal.

Tie ramps to milestones you control, such as "data platform migrated" or "region two live", rather than to calendar quarters. If a milestone slips, you want the conversation to start from a written plan, not from a shortfall invoice.

What will it cost to leave AWS later?

Leaving AWS has three cost lines: moving the data out, running two environments in parallel during the move, and whatever your commitment still requires you to pay. AWS's egress waiver and the EU Data Act shrink the first, cost-based pricing rules help with the second, and nothing removes the third except the contract you negotiate today.

Data transfer out

AWS includes 100 GB a month of free data transfer out to the internet, which AWS says already covers over 90% of its customers. Since 5 March 2024, customers moving all their data off AWS can ask AWS Support for credits covering the data transfer out for the migration. Outside the EU, AWS gives 180 days to complete the move, and you do not have to close your account. EU customers follow the AWS EU Data Act Addendum instead.

In the UK, the CMA's October 2026 update records that AWS put free switching and at-cost multi-cloud egress into a UK Customer Switching and Portability Addendum that applies automatically, extended the UK free-egress switching window from 90 to 180 days, and since October 2025 lets customers request credits for multi-cloud data transfers during the switching period.

The EU Data Act

The EU Data Act has applied since 12 September 2025. For cloud switching, it sets hard numbers:

• Article 25 caps the notice period to start a switch at two months, sets a 30-day transitional period (extendable by the customer, and up to seven months where the provider shows 30 days is technically unfeasible) and requires at least 30 days to retrieve your data afterwards.
• Article 29 allowed only reduced, cost-based switching charges from 11 January 2024 and bans switching charges altogether from 12 January 2027.
• Article 34 covers parallel use of several providers: egress charges are allowed only to pass on the provider's actual costs.

The Data Act separates switching charges from early termination penalties. As DLA Piper explains, the definition of switching charges excludes "standard service fees or early termination penalties", and fixed-term contracts with proportionate early termination penalties remain allowed. The EU's Digital Omnibus package would make that explicit; Greenberg Traurig notes (July 2026) that the Council's compromise text confirms proportionate early termination penalties in fixed-term contracts, and that the text is not final.

So the Data Act can make your egress free and your switch fast, and you can still owe the remaining commitment. Negotiate how a shortfall is calculated on early exit now, because "proportionate" will be argued about later.

Exit cost comparison

How do you keep architectural lock-in from cancelling out the exit terms?

Keep the critical path on open, portable building blocks (Kubernetes, PostgreSQL or MySQL, the S3 API, Kafka-compatible streaming, Terraform or OpenTofu), and buy them as AWS managed services. That spend still burns down your AWS commitment, and the workloads can move.

Portable choices burn down the commitment as well as proprietary ones do. EKS nodes, RDS for PostgreSQL storage and S3 requests are all AWS usage. The difference shows up at exit. A service on EKS with a Postgres database moves with a redeploy and a data migration, while a workflow built on proprietary APIs needs to be rewritten.

The CMA named the technical side of this directly. Its final decision found that technical barriers stem from "the differentiation of features and interfaces in cloud services", so customers "cannot easily compare, substitute, or integrate services from different providers." In October 2026, the CMA said its next areas of focus with AWS and Microsoft include reducing frictions to the portability of Kubernetes containers. Kubernetes is already the common runtime: the CNCF's annual survey found 82% of container users run it in production.

Two caveats from experience. Proprietary services are often the right call for a specific job, so the goal is to know where they are and what replacing them would cost, then keep them out of the parts you would need to move first. And portable building blocks only help if your deployment tooling is portable too. If every deploy depends on AWS-specific pipelines, the code moves and the operations do not.

Our AWS vs GCP vs Azure comparison covers how existing commitments, data gravity and team skills drive the cloud choice, and this breakdown of vendor lock-in covers egress, entrenchment and contract traps.

What does a credible exit plan look like?

A credible exit plan is one your team has partly executed: an inventory of what would move, the data volumes and the order of the move, and at least one production-like environment that has run on a second provider. A slide that says "multi-cloud ready" will not move the AWS account team.

What I would include:

1. Inventory. Every service, its data stores, its AWS-specific dependencies and its monthly spend. Mark each one "moves with redeploy", "moves with data migration" or "needs rewrite".
2. Data volumes and egress estimate. Total terabytes per store, and which stores would qualify for the switching waiver or the Data Act.
3. Move order. Stateless services first, then data, then the hard cases.
4. A drill. Once or twice a year, deploy a staging copy of one important application on another cloud or an on-premise cluster. Measure how long it takes and what broke.
5. Contract mapping. For each scenario (move 20%, move everything), what the commitment, shortfall and notice periods cost.
6. An owner. Someone in engineering who keeps the inventory current and reports to whoever owns the AWS relationship.

The drill is the part that changes negotiations. A team that can say "we ran checkout on GKE for a week last quarter" negotiates from a different place than a team that has never tried.

If price pressure is what pushes you to test this, our post on the Azure price increase in 2027 walks through the same portability decision from the other side of the market.

Where does Qovery fit in an AWS commitment?

Qovery keeps your spend on AWS and your workloads portable. Qovery is an Agentic DevOps platform that deploys and operates your applications on Kubernetes inside your own cloud account. Qovery runs the control plane; your applications, databases and data run in your AWS account, on your bill.

For an AWS commitment, that has three consequences:

• Your infrastructure spend stays AWS spend. EKS, EC2 nodes (with Karpenter on AWS), load balancers and the managed services you provision through Qovery Blueprints, such as RDS, are billed by AWS to your account. They count toward your commitment exactly as they would if your team ran them by hand.
• The Qovery subscription can go through AWS Marketplace. Qovery is sold on AWS Marketplace, and as of November 2026 the Qovery listing carries the "Deployed on AWS" badge, with private offers available. Whether and how much it draws down your commitment depends on your own PPA terms, so confirm it with your AWS account team.
• The same deployments can run elsewhere. Qovery deploys the same application definitions to AWS, GCP, Azure, Scaleway, or an existing Kubernetes cluster (EKS, GKE, AKS, Kapsule, k3s or on-premise). Your portability drill becomes "clone the environment onto another cluster" rather than a rebuild. Cross-cloud networking is not built in; you configure it with a VPN, Cilium Cluster Mesh, Tailscale or similar.

Qovery does not negotiate your AWS contract, and it does not migrate your data for you. It removes the part where portability needs a platform team you do not have: git-push deployments, environment cloning, preview environments per pull request, RBAC, audit logs and a Terraform provider for teams that keep everything in code. If you are planning an EDP and want to see what a portable setup on your own AWS account looks like, talk to us.

How do I run a portability drill with Qovery from Claude Code or Cursor?

Install the Qovery Agent Skills, then ask your coding agent to clone a staging environment onto a second cluster. The skills handle deployment; the MCP Server lets the agent read what already exists.

curl -fsSL https://skill.qovery.com/install.sh | bash

# 2. Connect the Qovery MCP Server to Claude Code (OAuth, read-only by default)
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

1. The install script adds the Qovery skills (qovery-onboard, qovery-deploy and others) to your agent. It asks nothing about your cloud yet.
2. The MCP command opens an OAuth sign-in to your Qovery organization. Read-only access lets the agent list your environments and services without changing them.
3. Then ask in plain language, for example "deploy a copy of our staging environment to our GCP cluster with Qovery". The agent asks you to approve each change before it deploys.

Setup guides: the AI agent quickstart and the Claude Code integration page.