TechNative Insights

AWS Private Pricing Agreement (PPA): a complete guide for European SMBs and mid-market

TechNative — Wed, 13 May 2026 09:36:30 GMT

AWS Private Pricing Agreement (PPA): a complete guide for European SMBs and mid-market

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.

Partner-Led Support: the European AWS PPA alternative to mandatory Enterprise Support

TechNative — Wed, 13 May 2026 09:36:30 GMT

Partner-Led Support: the European AWS PPA alternative to mandatory Enterprise Support

AWS Enterprise Support is mandatory under a Private Pricing Agreement. For European SMBs, this can add 5 to 10 percent to the AWS bill, often eroding the very discount the PPA was meant to deliver. Partner-Led Support is an AWS-recognised alternative.

Why Enterprise Support is mandatory under a PPA

An AWS Private Pricing Agreement (formerly Enterprise Discount Program, or EDP) is a custom-negotiated contract where a customer commits to a minimum AWS spend over one to five years in exchange for discounted pricing. The mechanics have not changed since the rebrand from EDP to PPA; only the name has.

One condition has remained constant across both names: every account under the PPA must be enrolled in an enterprise-grade support plan for the full duration of the contract. This is not a recent change; it has been a structural requirement of the programme. AWS does not waive it as part of negotiation.

The cost of that support, however, is not 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

A worked example. A European SMB signs a PPA at 1M annual commit (around 83K per month). Negotiated PPA discount: a percentage of spend that varies by deal. Enterprise Support cost: roughly 10 percent of monthly spend, or about 100K per year. The customer effectively gives back a meaningful portion of the negotiated discount through mandatory support, before any other costs are considered.

What AWS Partner-Led Support actually is

AWS Partner-Led Support (PLS) is a programme operated through the AWS Solution Provider track. It allows qualifying AWS Partners to define and deliver their own support offering, backed by AWS tooling, AWS escalation paths, and AWS Diagnostic Tools, rather than reselling AWS Support unchanged.

Three things to know about PLS.

Eligibility is restricted. Only AWS Partners at the Advanced or Premier Tier of the AWS Partner Network can deliver Partner-Led Support. The vast majority of resellers do not qualify.

It is structurally different from "AWS Resold Support". Resold Support is a pass-through of AWS Enterprise Support through a partner's billing relationship. PLS is the partner's own support product, underpinned by AWS.

It satisfies the PPA support requirement, but only under a Partner-Led PPA, not an AWS-Led PPA signed directly with AWS.

Partner-Led Support vs AWS Enterprise Support: feature comparison

Capability	AWS Enterprise Support	Partner-Led Support
24x7 case handling	AWS Cloud Support Engineers	Partner support team, AWS-backed
15-minute response on critical cases	Direct from AWS	Via partner SLA, AWS escalation backed
Designated Technical Account Manager	AWS-employed TAM	Partner TAM, with access to AWS specialist TAMs
Access to AWS Diagnostic Tools	Yes	Yes
AWS Trusted Advisor (full)	Yes	Yes
Pricing model	Fixed percentage of spend, 5K minimum	Custom, set by partner
500 AWS Training Credits per year	Yes	Not standard (partners often substitute their own training)
AWS Incident Detection and Response (bundled)	Available as add-on	Typically not bundled
Local-language support (Dutch, French)	Limited; primarily English	Available where partner operates locally
Coverage of partner stack (DevOps tooling, third-party software)	Out of scope	Often included by partner
FinOps and cost optimisation included	Limited (TAM guidance)	Often bundled or available as adjunct

Two honest notes for buyers comparing the two.

If your team relies heavily on the 500 annual AWS Training Credits, that is a real entitlement you would lose under PLS. Some partners offer equivalent training, but it is not the same programme.

If you operate at AWS Enterprise Support's largest tier (well above 1M per month), the 3 percent direct rate may be competitive with most partner pricing, particularly if you do not value the partner's adjacent services. At that scale, the decision shifts from a price comparison to a strategic question about commercial structure, capability, and growth trajectory, covered in detail in the PPA complete guide.

When Partner-Led Support makes sense for European SMBs

The customer profile where Partner-Led Support typically delivers the strongest economics is the European SMB entering its first PPA. The reasons are structural.

Smaller spend means a higher Enterprise Support percentage. The 10 percent tier (up to 150K per month) hits SMBs hardest. A partner-set price is usually lower in absolute terms.

SMBs benefit more from bundled FinOps and cost optimisation than from raw AWS support hours. Most do not have a dedicated FinOps function in-house.

Local-language support and time-zone alignment matter more for SMBs without a 24x7 cloud operations team.

The partner's broader service stack (managed services, well-architected reviews, security posture monitoring) typically replaces multiple line items in an AWS direct relationship.

What to look for in a European partner offering PLS

Not every AWS reseller can offer Partner-Led Support. Before signing a Partner-Led PPA, verify:

AWS Partner Tier. Advanced or Premier in the AWS Partner Network. Verify on the AWS Partner Directory.

FinOps competency. For PPA work, look specifically for FinOps Foundation Implementation Partner status. This is a rigorous, separately-audited credential.

Geographic alignment. Local presence, local language, EU data handling.

Segment fit. For SMBs, look for partners with the AWS SMB Competency, which is awarded to partners with a track record of delivering to mid-market clients specifically.

Transparent pricing model. The partner should be able to show you exactly what their PLS includes and excludes versus direct Enterprise Support.

Three partnership layers, not just reseller

A point worth making explicit because it is often misunderstood: the partner relationship under a PLS arrangement has three layers, and they are stackable, not exclusive.

The reseller layer, where the partner is the contract counterparty for AWS spend and the customer's AWS bill flows through the partner.

The managed services layer, where the partner operates the AWS estate, including 24x7 operations, governance, security posture, and incident response.

The consultancy layer, where the partner delivers advisory, audit, FinOps assessment, transition projects, skill gap analysis, and standalone reviews of existing or proposed AWS commercial agreements.

A Partner-Led PPA typically combines all three layers, but customers can engage partners on subsets. A customer who later shifts to a direct AWS commercial agreement can keep the managed services and consultancy layers entirely. Going direct with AWS is a decision about the reseller layer only, not about ending the partnership.

AWS Marketplace governance for enterprise: how to protect procurement discipline and PPA eligibility as legacy private offers phase out

TechNative — Wed, 13 May 2026 09:36:30 GMT

AWS Marketplace governance for enterprise: how to protect procurement discipline and PPA eligibility as legacy private offers phase out

AWS Marketplace governance is changing in a way most enterprises have not yet absorbed. The legacy generation of private offers is in maintenance mode. Every renewal of an existing Marketplace contract from this point forward must be restructured into one of the modern offer types: Private Offers, Channel Partner Private Offers (CPPO), or Manufacturer Private Offers (MPPO). Existing legacy contracts continue to run until expiry, but the path forward is one-way.

What is the AWS Marketplace legacy-to-modern offer transition?

For most of the past decade, enterprise software renewals on AWS Marketplace ran through a relatively stable structure. The legacy private offer generation gave finance, procurement, legal, and security teams a known surface to govern: a vast majority of large software deals followed a predictable pattern, and enterprise procurement processes had grown around that pattern.

That generation is now in maintenance mode. AWS continues to honour existing legacy contracts until they expire, but no new private pricing deals are created in the legacy structure. The development effort and the commercial innovation has moved entirely to the modern offer types.

The modern offer types are three:

Private Offers are direct ISV-to-buyer agreements with custom pricing, terms, and EULAs. The ISV creates the offer, the buyer accepts it through the AWS Marketplace console.

Channel Partner Private Offers (CPPO) allow an authorised AWS channel partner to resell an ISV's product to an end buyer with custom pricing and terms layered on top. The ISV authorises the partner with a wholesale cost; the partner adds margin and creates the customer-facing offer. The buyer's contractual relationship is with the channel partner, not the ISV.

Manufacturer Private Offers (MPPO) support a similar pattern for hardware and physical product manufacturers, less relevant for typical SaaS-heavy enterprise renewals.

In practice, the moment an enterprise renews a major software contract through Marketplace from this point forward, the renewal will use one of these modern types. The transition is not optional and not avoidable.

Why is the Marketplace transition a governance problem, not just a technical one?

If the modern offer types were simply a UI refresh of the legacy structure, this guide would not exist. The reason it does is that the modern transaction mechanisms differ from the legacy ones in ways that quietly bypass the governance controls many enterprises had built around the old structure.

Three differences matter most.

Acceptance flow changes. In the legacy model, large enterprise renewals often followed a known multi-stakeholder approval path before any acceptance happened in AWS. In the modern model, a Private Offer arrives in the AWS Marketplace console of a designated buyer account. Whoever has subscription rights in that account can technically accept the offer immediately, no different from accepting a small PAYG subscription. Without explicit IAM constraints, an engineer can accept an 800K renewal with the same number of clicks as ordering a startup tool.

Visibility shifts to AWS-native tools. Legacy private offers had built-in handshakes with enterprise procurement processes that many organisations had institutionalised over years. The modern offer types put visibility into the AWS Marketplace console, AWS Organizations, and the procurement integration layer, if configured. Finance and procurement teams that have not been onboarded to those tools lose the line of sight they previously had.

EDP and PPA alignment becomes the buyer's responsibility. This is the most consequential difference, and the one most often missed.

What is the PPA eligibility risk at every Marketplace renewal?

Marketplace spend can contribute to AWS Private Pricing Agreement commitment retirement. In TechNative's experience, the typical allowance is 25 percent of the annual commit, but the exact percentage is set as part of the PPA itself, negotiated between the customer and AWS, and not published. Different enterprises have different allowances based on their commit size, growth trajectory, and negotiating position.

The mechanism only works when three conditions hold for the Marketplace deal:

The product is eligible. Since May 2025, AWS tightened eligibility criteria for Marketplace SaaS retirement. Only SaaS products fully deployed on AWS qualify. SaaS with hybrid or multi-cloud architecture no longer counts. Products that previously qualified may not anymore.

The deal is 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. A renewal accepted on the wrong account, under the wrong offer type, or without proper attribution to the PPA can fall outside the eligibility envelope. The customer pays the same amount and uses the same software, but the spend does not count toward the commit.

The timing aligns 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 that an aligned renewal cadence would preserve.

The cumulative effect across an enterprise estate is significant. An organisation with multiple ISV contracts running on Marketplace, renewing one or two per quarter without governance, can find at PPA renewal that a substantial portion of their Marketplace spend over the prior term did not retire commitment as it should have. The enterprise paid for the software, paid for the AWS commit shortfall, and got no commercial credit for the overlap.

This is the governance cost of letting renewals happen without procurement and FinOps oversight.

What are the four AWS Marketplace control layers?

AWS provides four control layers in Marketplace. Used together, they reconstruct the governance the legacy generation gave for free.

Layer one: Private Marketplace experiences

Private Marketplace is AWS's catalogue control mechanism. It operates as default-deny: only products explicitly approved by an administrator are visible to a given audience.

Two architectural choices distinguish AWS Private Marketplace from naive catalogue restrictions.

Multiple experiences per organisation, each with its own approved product list. Different OUs or accounts can have different catalogues. A development account can have a wide catalogue for experimentation. A production account can have a narrow catalogue limited to vetted, contracted vendors.

Audience hierarchy aligned with AWS Organizations. When the organisation structure changes, governance follows automatically. There is no parallel hierarchy to maintain.

For an enterprise migrating off legacy Marketplace, Private Marketplace is the foundation. It defines what shows up in the Marketplace console for each part of the organisation, ensuring that renewals of approved products are visible and renewals of unapproved or duplicated products require an explicit governance decision.

Layer two: IAM and role separation

The second layer separates the right to deploy a Marketplace product from the right to subscribe to one. This is conceptually simple and operationally critical.

In a well-governed environment, end users in development and test accounts can subscribe to products approved in their Private Marketplace catalogue. In production accounts, only a small set of designated procurement officers can initiate subscriptions or accept private offers. These officers act on behalf of the organisation, authorised to accept legal terms and commit budget.

The relevant managed policies are AWSMarketplaceManageSubscriptions for subscription rights and AWSPrivateMarketplaceAdminFullAccess for catalogue administration. Both should be tightly scoped, particularly in production.

For renewals specifically, this layer ensures that an 800K Private Offer from an ISV does not land in an engineer's console with a single-click accept button. The offer goes to a procurement officer's account, where the controlled process can run.

Layer three: Mandatory purchase orders

The most consequential governance capability of late 2025 became generally available in December 2025: mandatory purchase order enforcement at the moment of subscription.

Before this capability, enterprises that wanted PO discipline on Marketplace had two unsatisfying options: rely on training and policy (engineers comply when they remember to), or implement full procurement integration (multi-week project). Neither option blocked an unauthorised subscription at the point of sale.

Mandatory purchase order enforcement closes the gap. When configured, the AWS Marketplace subscription flow refuses to complete unless the buyer enters a purchase order number. The enforcement is granular:

By offer type, requiring POs only for private offers, only for public offers, or both.

By pricing type, requiring POs for contract pricing, pay-as-you-go pricing, or both.

With custom messaging that explains the policy, expected PO format, and where to obtain a PO.

For enterprises governing renewals, the most useful configuration is typically requiring POs on private offers and contract pricing while leaving public PAYG flows lighter for experimentation. This catches the high-stakes deals (renewals, new contracts, anything legal-significant) without creating friction on small developer subscriptions.

A practical detail: if mandatory POs are enabled for PAYG public offers, AWS Marketplace subscriptions through service consoles like Amazon EC2 will be blocked because those consoles do not provide a PO entry field. Buyers must subscribe directly through Marketplace. For most enterprises this is desired behaviour but requires advance communication.

Layer four: Procurement system integration

For enterprises that already operate a centralised purchase-to-pay system, AWS Marketplace integrates with Coupa and SAP Ariba via cXML, the industry-standard procurement protocol.

The integrated flow starts with the user browsing AWS Marketplace from within their procurement system through a PunchOut session. They select a product, the details copy back into the procurement system as a purchase requisition, the standard internal approval workflow runs, and the resulting purchase order transmits to AWS via cXML. The Marketplace subscription is then created programmatically, with the user receiving an email confirming the agreement is live.

Three benefits matter for enterprises with mature procurement.

Existing approvals are reused. The same chain that approves any vendor purchase approves a Marketplace purchase.

Spend visibility consolidates. Marketplace spend appears in the procurement system alongside all other vendor spend, not as a separate AWS-bill line item that finance has to reconcile.

Compliance and audit are simplified. Auditors examining procurement records find Marketplace purchases in the same system as everything else, with the same approval trail.

Two implementation notes. AWS Marketplace and Amazon Business require separate PunchOut integrations even though they are both AWS-affiliated. cXML invoicing is currently supported only for Coupa, not Ariba. Pay-as-you-go products through the integration do not produce PO-associated cXML invoices, and the AWS Purchase Order Management feature should be used in those cases.

Procurement system integration is complementary to Private Marketplace. Mature enterprises typically run both, with Private Marketplace ensuring users only see approved products and procurement integration ensuring the PO and approval trail lives in the existing financial system.

Three governance maturity models

Marketplace governance is not binary. Organisations choose how much control to apply based on risk tolerance, regulatory environment, and operational maturity. Three models capture the realistic spectrum.

Model	Posture	Typical configuration	Trade-off
Fully Open	High risk	Default IAM permissions, basic cost monitoring, no Private Marketplace	Maximum agility for engineering, minimum control for finance and security. Suited only to early-stage organisations with low compliance burden.
Fully Restricted	Low agility	Strict IAM, manual approval for every subscription, narrow Private Marketplace, no PAYG access	Strong compliance position, but the friction drives shadow IT. Engineers find ways around the controls.
Controlled Access	Recommended	Private Marketplace with OU-aligned experiences, IAM role separation by environment, mandatory POs on private offers and contract pricing, procurement system integration where mature	Balanced. Engineering teams keep velocity in development and test; finance and security retain control where it matters. Requires ongoing maintenance of approved catalogues.

The Controlled Access model is what AWS itself recommends and what mature enterprises converge on. It is more involved to configure than the other two, but the operational outcome is better for both speed and risk.

Two critical governance moments in Marketplace procurement

Approval is not a one-time event. Even when a product is allowed in the organisation, that does not mean every team can deploy it everywhere under any conditions. AWS Marketplace governance distinguishes two moments.

Approving the offer decides whether a product is allowed in the organisation at all. Does it meet security requirements, does it introduce unnecessary cost, does it fit the target architecture, does procurement need to be involved before contracts are signed. The control plane is Private Marketplace experiences and the curation of approved product lists.

Approving the usage decides how an approved product can actually be used. Who can deploy it, in which accounts, under which technical conditions, against which budget. The control plane is IAM permissions, AWS Organizations service control policies, AWS Config rules, cost allocation tags, and procurement-driven PO requirements.

The two moments require different controls and different organisational owners. Approving the offer typically sits with central governance or procurement. Approving the usage typically sits with cloud engineering, FinOps, or platform teams. Treating them as a single decision is a common failure mode that produces either over-restriction or under-control.

What enterprises should do before the first major renewal

The transition from legacy to modern Marketplace creates a window in which governance gaps become visible at every renewal. A practical sequence to close those gaps:

Inventory current Marketplace contracts. List every existing legacy private offer, the renewal date, the annual value, the ISV, and the responsible business owner. Many enterprises discover at this step that the inventory is incomplete because legacy procurement records were never fully consolidated.
Map contracts against PPA coverage. For each Marketplace contract, identify whether the spend currently retires PPA commitment, whether eligibility could be improved by restructuring (for example as a CPPO through an authorised channel partner), and whether the renewal date aligns with or drifts from the PPA term.
Identify commitment gaps. The map produced in step two will show two things: spend that should be retiring commitment but is not, and renewal cadences that will leave the next PPA negotiation under-informed about future Marketplace spend.
Restructure deals at renewal. As each contract approaches renewal, design the new structure to maximise PPA eligibility, align the term with the PPA, and route the transaction through the appropriate offer type (Private Offer direct, CPPO via channel partner, depending on commercial preference and partner relationship).
Configure the four control layers. Private Marketplace, IAM separation, mandatory POs, procurement system integration. Each step closes a piece of the governance gap that opened when legacy was deprecated.
Migrate from legacy Private Marketplace console if not already done. The 17 March 2026 deadline is hard. Organisations using Private Marketplace without AWS Organizations integration lose access to the management interface on that date.
Implement monitoring on usage, commitments, and renewals. A FinOps-led dashboard showing Marketplace spend, PPA eligibility, upcoming renewals, and commit trajectory makes governance ongoing instead of point-in-time.
Communicate the new model. Engineering teams need to understand what changed and why. Procurement teams need to understand the new approval surface. Without communication, governance becomes the obstacle that drives shadow IT.

For enterprises with multiple major Marketplace renewals in 2026, this sequence is best started before the first renewal arrives, not after.

When does partner support add value in Marketplace governance?

Enterprises with strong in-house FinOps teams, mature AWS Organizations setup, and existing procurement integration may be able to execute this sequence themselves. Many cannot, particularly mid-market enterprises in BeNeLux where dedicated FinOps and AWS commercial expertise is rare in-house.

The right partner brings three capabilities to a Marketplace governance programme:

FinOps Foundation Implementation Partner experience for designing the eligibility mapping and PPA alignment. This is specialised work and not part of standard cloud architecture practice.

AWS Advanced or Premier Tier Consulting Partner status for accessing the Channel Partner Private Offer mechanism, which is unavailable to lower-tier partners. CPPO is often the right structure for mid-market enterprise renewals where consolidated billing and bundled services add value beyond the underlying ISV product.

Active monitoring and renewal management as a standing service. Marketplace governance is not a project; it is a process. The enterprises that get this right have someone watching the renewal pipeline continuously, not reviewing it once a year.

The honest framing: a good partner advises actively on this, including telling the customer when the right answer is direct AWS engagement rather than partner-led. The real risk is lack of governance, not partner structure.

FOCUS: the FinOps specification that needs a culture to work

TechNative — Wed, 13 May 2026 09:36:30 GMT

FOCUS: the FinOps specification that needs a culture to work

The FinOps Open Cost and Usage Specification (FOCUS) is the most important standardisation effort in cloud financial management since the FinOps Foundation framework itself. It promises to end the era where every hyperscaler has its own billing format, its own column names, its own assumptions about what counts as "spend". For organisations operating on AWS, Azure, or GCP (and especially those operating on more than one), FOCUS removes a category of work that has consumed FinOps teams for years.

Specification adoption alone, however, does not produce FinOps outcomes. A standardised data set in the hands of teams that lack the culture to act on it is just cleaner data going to waste.

What FOCUS actually is

FOCUS is a vendor-neutral specification for cloud cost and usage data. It is published and maintained by the FinOps Foundation, currently at version 1.2, with active contributions from AWS, Microsoft, Google, Oracle, IBM, and a growing list of ISVs and end users.

The specification defines three things.

A common schema for billing and usage records. Column names like BilledCost, EffectiveCost, ResourceId, ServiceName, ProviderName, and dozens of others, each with a precise definition of what the value represents. Where AWS calls a service "EC2" and Azure calls it "Virtual Machines", FOCUS provides a unified ServiceName column that uses normalised values. Where AWS bills in different time granularities than GCP, FOCUS specifies how usage periods are reported.

Strict definitions of cost concepts. The specification distinguishes between billed cost (what appears on the invoice), effective cost (what the customer actually pays after discounts and credits), and list cost (the undiscounted public price). These distinctions matter for chargeback, showback, and rate optimisation analysis. Without them, FinOps teams have spent years arguing about which cost is the "real" cost.

Allocation and tagging conventions. FOCUS standardises how resource attributes (tags, labels, cost categories) are exposed in the data, so that allocation logic written for one cloud works for another with minimal modification.

The practical effect: a FinOps team working on a FOCUS-compliant data set can write a single chargeback model that applies across AWS, Azure, and GCP, instead of three parallel models with provider-specific transformations.

The major hyperscalers all support FOCUS exports natively. AWS provides FOCUS-compliant Cost and Usage Report exports through the standard CUR mechanism. Microsoft Azure exports FOCUS data through Cost Management exports. Google Cloud Billing supports FOCUS through BigQuery exports. SaaS vendors are following: Datadog, Snowflake, MongoDB, and others are publishing FOCUS-compliant cost feeds, which collapses third-party software spend into the same analytical surface as raw cloud spend.

For organisations on a single cloud, FOCUS still matters, but the urgency is lower. The specification mainly removes future migration friction (if and when a multi-cloud strategy emerges) and aligns internal terminology with industry-standard vocabulary.

For multi-cloud organisations, FOCUS is the difference between a FinOps practice that scales and one that drowns in data engineering.

Why FOCUS alone is not enough

Specification provides direction. Direction is necessary, but it is not behaviour.

The teams that struggle with cloud cost are rarely struggling because their data is in the wrong format. They are struggling because the data, however well-formatted, does not change what happens in their organisation. Engineering teams continue to provision oversized resources because that is what they have always done. Finance teams continue to receive surprising bills because they are not invited into architecture decisions. Procurement teams continue to negotiate without usage data because nobody hands it to them.

FOCUS does not solve any of these problems by itself.

What FOCUS does is remove a specific class of friction: the friction of getting clean, comparable data into the hands of people who could act on it, if they were structurally able to. Once that friction is gone, the question shifts from "can we see what is happening" to "are we willing and able to do something about it". And that question is cultural, not technical.

The diagnostic is straightforward. An organisation that adopts FOCUS, builds dashboards on top of it, and finds nothing changing in cost trajectory has a culture problem, not a data problem. The data is now telling them clearly what was previously fuzzy. The fact that nothing changes means the data was never the bottleneck.

Two failure modes are common. Some organisations adopt FOCUS, produce beautiful dashboards, and treat the dashboards themselves as the deliverable. Cost reviews happen, charts are presented, and nobody is empowered to make changes. The dashboards become a status ritual rather than a decision tool. Other organisations adopt FOCUS, identify cost optimisation opportunities, and find that engineering teams cannot or will not act on the recommendations because the incentive structure rewards feature delivery over cost discipline. In both cases, the specification did its job; the culture did not.

Five cultural enablers that make FOCUS work in practice

Five behaviours determine whether FOCUS adoption produces change. These are not optional extras; they are prerequisites for the specification to deliver value beyond cleaner reports.

Specification and behaviour must align. A standardised data format is direction; team behaviour is what follows direction. If the data shows that team A is overspending by 30 percent but team A faces no consequences and receives no support to change, the data is decorative. Alignment means leadership commits to acting on what the data reveals, even when acting is uncomfortable. This is the foundational enabler. Without it, the others are exercises in form over substance.

Focus means saying no. The word "focus" is not accidental in the specification name. To focus is to choose, and choosing requires excluding. Teams adopting FOCUS need to develop the cultural muscle to deprioritise things that the data shows are not worth the cost. This is harder than it sounds, because saying no often means refusing requests from peers, leaders, or other teams. Organisations where saying no is socially expensive will struggle to act on FOCUS data even when the data is clear.

Psychological safety to challenge scope. When FOCUS data reveals that a planned project will cost more than its expected return, someone needs to be able to say so without career risk. The same applies in reverse: when FOCUS data reveals that an under-funded project is delivering disproportionate value, someone needs to be able to advocate for more investment. Both directions require that team members can challenge decisions without being labelled as obstructionist or insufficiently committed. Without psychological safety, FOCUS data becomes politically inconvenient and quietly ignored.

Decision-making clarity. Who decides what is in scope and what is not. Who has the authority to deprioritise a project the data shows is unprofitable. Who can approve an investment the data shows would pay back. Most organisations are vague about this, and vagueness becomes a vacuum where decisions either default to "continue as before" or escalate endlessly. FOCUS surfaces decisions that need to be made; the organisation needs a clear answer about who makes them.

Outcome metrics, not output metrics. Output metrics measure activity (number of dashboards built, percentage of resources tagged, number of cost reviews held). Outcome metrics measure result (change in unit economics, accuracy of cost forecasting, percentage of cloud commit retired efficiently). FOCUS makes outcome measurement possible because the data is consistent across periods and providers. Organisations that continue to measure FinOps maturity by output metrics after adopting FOCUS are missing the point of the adoption.

These five enablers reinforce each other. An organisation with strong alignment but weak psychological safety produces compliance behaviour that drains creativity. An organisation with strong psychological safety but unclear decision-making produces lots of debate without resolution. The five together produce a FinOps culture that can actually use what FOCUS provides.

How does FOCUS implementation work in AWS environments?

For AWS-centric organisations, the path to FOCUS adoption runs through three artifacts.

The Cost and Usage Report (CUR) is the foundational data export. AWS now provides FOCUS-compliant CUR exports as a standard option. New CUR configurations can be set up directly in FOCUS format; existing CURs can be re-configured. The data lands in S3 in standardised Parquet or CSV format, ready for ingestion into analytical tools.

AWS Cloud Intelligence Dashboards are the canonical visualisation layer for AWS cost data. The dashboards (CUDOS, Cost Intelligence Dashboard, KPI Dashboard) are open-source, maintained by AWS, and increasingly aligned with FOCUS column names. Organisations that adopt the Cloud Intelligence Dashboards on FOCUS-compliant CUR exports get a working FinOps reporting environment with relatively little custom development.

For multi-cloud organisations, the architectural pattern is to land FOCUS-compliant exports from each provider in a common analytical store (typically S3 or another object store), use a query engine like Athena or BigQuery on top, and build dashboards that operate on the unified schema. Because all providers expose data in FOCUS format, the query layer does not need provider-specific logic.

Three implementation considerations matter for AWS organisations.

Cross-account FOCUS data access requires careful IAM design. CUR exports land in a single S3 bucket in a designated payer account, but FinOps teams typically need to query the data from a separate analytics account. This is a standard cross-account data access pattern, but it must be designed before the analytical work begins.

Athena and Parquet remain the cost-optimal query layer for FOCUS data on AWS. CSV exports work but are slower and more expensive at scale. Parquet exports with partitioning by billing period reduce query cost by orders of magnitude.

The AWS Marketplace dimension matters for organisations using Marketplace SaaS purchases against PPA commit retirement. Marketplace spend appears in CUR with specific identifying fields; FOCUS-compliant CUR preserves these. The combination allows FinOps teams to track Marketplace contribution to PPA retirement directly, which is critical for the strategic work covered in our guide on AWS Marketplace governance.

What is the accountability gap in FinOps FOCUS adoption?

FOCUS does something subtle that is easy to miss in the technical excitement: it makes accountability possible at a much finer granularity than before.

Before FOCUS, allocating cost to a specific team or product required custom transformations, often with assumptions baked in. With FOCUS, the data exposes cost per resource, per tag, per allocation dimension in a standardised way. A team can be shown, with high precision, what their share of the cloud bill is.

This precision is necessary, but not sufficient.

Showing a team their cost is only useful if the team has authority to act on the cost. If engineering teams see their EC2 spend but cannot make instance-type decisions, the visibility produces frustration rather than optimisation. If product teams see their feature-level cost but cannot deprioritise expensive features, the visibility produces resentment rather than realignment.

The accountability gap is the distance between visibility and authority. FOCUS adoption that closes the gap produces results. FOCUS adoption that widens the gap (more visible cost, no more authority to act) produces FinOps theatre.

Closing the gap requires explicit decisions in three areas.

Where in the organisation does decision authority over cloud spend actually sit. Engineering, finance, product, platform; usually all four claim partial ownership. FOCUS data forces the question because the data is now precise enough to assign cost to specific teams.

What incentives reward acting on cost data. Bonus structures, performance metrics, team objectives. If engineering performance is measured purely on feature velocity, no amount of cost transparency will change behaviour.

How escalation works when cost decisions are contested. The team that wants to optimise a service often differs from the team that owns it. FOCUS data exposes these conflicts; the organisation needs a clear path to resolve them.

Organisations that do this work alongside FOCUS adoption see real outcomes. Organisations that adopt FOCUS hoping the data alone will drive change tend to be disappointed.

When does partner support add value in FOCUS adoption?

The technical work of adopting FOCUS on AWS is not the hard part. CUR configuration, dashboard deployment, and query layer setup are well-documented patterns that competent cloud engineering teams can execute in a few weeks.

The harder work is the cultural and organisational work that makes FOCUS adoption produce results. This is where partner support typically adds the most value, particularly for European mid-market organisations where dedicated FinOps capability is often absent in-house.

The TechNative partnership model has three layers, and FOCUS adoption typically engages all three.

The reseller layer, where TechNative is the contract counterparty for AWS spend. For organisations on a Partner-Led PPA, FOCUS-compliant data is part of the standard reporting that TechNative provides, and the cultural enablers are reinforced through quarterly cost reviews and FinOps coaching.

The managed services layer, where TechNative operates the AWS estate. This is where FOCUS data becomes operational: monitoring on cost trajectory, anomaly detection on spend patterns, automated alerts when teams approach budget thresholds. The data is only useful if someone is paid to watch it daily; managed services partners are typically that someone.

The consultancy layer, where TechNative delivers FinOps Foundation Implementation Partner work. This includes the cultural and organisational work that makes FOCUS adoption stick: skill gap analysis, decision-making framework design, training (FinOps Foundation Certified Practitioner and FinOps Fundamentals), measurement methodology for outcome metrics, change management support during the cultural transition.

A common engagement pattern: an organisation adopts FOCUS technically (often in a few weeks of engineering effort), then engages TechNative consultancy to design the cultural and organisational changes that turn the data into outcomes. The technical work is one-off; the cultural work is ongoing.

AWS reselling for European SMBs and mid-market: when partner value beats direct engagement

TechNative — Wed, 13 May 2026 09:36:30 GMT

AWS reselling for European SMBs and mid-market: when partner value beats direct engagement

The decision to engage with an AWS reseller, work directly with AWS, or combine the two is one of the most consequential commercial choices in cloud strategy. It shapes pricing access, governance discipline, operational support, and the speed at which an organisation can move from cloud strategy to cloud outcome. For European SMBs and mid-market organisations, the decision is rarely a simple price comparison. It is a question about control, capability, and where in the organisation cloud expertise should sit.

What an AWS reseller actually is

AWS works with multiple partner types, each with different commercial roles.

Resellers sell AWS services as authorised intermediaries, typically consolidating billing, support, and adjacent services into a single relationship. The customer's AWS bill flows through the reseller, who manages the commercial relationship with AWS on the customer's behalf.

Consulting partners provide advisory and implementation services without necessarily holding the reseller relationship. They help with architecture, migration, well-architected reviews, and project work, often working alongside whoever holds the commercial AWS relationship.

Managed services providers (MSPs) operate cloud infrastructure on behalf of customers, providing 24x7 monitoring, incident response, governance, and security operations. AWS Premier Tier MSPs hold a specific AWS competency for this work.

ISVs build and sell software products that run on AWS, often distributing through the AWS Marketplace.

System integrators combine products and services from multiple vendors into integrated solutions, particularly for enterprise customers.

The most relevant partner type for SMB and mid-market organisations is the AWS Solution Provider Partner at Advanced or Premier Tier, who typically combines reselling, consulting, and managed services into a single relationship. This combination is what most people mean when they say "AWS partner".

When this combined model adds value:

Limited internal cloud governance, where the organisation lacks the capability to manage billing complexity, multi-account architecture, FinOps, security operations, and AWS commercial structuring on its own.
Limited purchasing weight with AWS directly, where the spend is too low to interest AWS account teams or the organisation lacks the negotiation expertise to extract optimal terms.
Limited AWS network reach, where the organisation cannot easily access AWS funding programmes, assessments, technical specialists, or insider knowledge of AWS roadmap and pricing structures.

Organisations strong in all three areas often do better with direct AWS engagement plus selective partner engagement for specific needs. Organisations weak in even one area typically benefit from a full reseller relationship.

What you actually get: six layers of partner value

A good reseller relationship delivers value in six distinct layers. Each can be evaluated separately, and not every customer needs every layer in equal measure.

Technical expertise

A reseller partner with depth in cloud engineering brings infrastructure-as-code patterns, observability tooling, security architecture, and performance tuning expertise that would otherwise need to be built or hired in-house.

The practical effect: faster time to production through proven patterns and templates, fewer iterations from concept to working architecture, and reduced trial-and-error in early cloud adoption. For SMBs and mid-market customers building their first or second production AWS workload, this acceleration is often the single largest source of partner value.

FinOps and cloud cost management

A reseller partner with FinOps Foundation Implementation Partner credentials brings billing reconciliation, chargeback methodology, cost allocation design, and forecasting capability. This is rare in the partner landscape, with only a handful of partners in BeNeLux holding this specific certification.

The practical effect: invoices validated against usage data each month, costs allocated to teams or business units in a way that supports accountability, and forecasting accuracy that materially improves multi-year budget planning. For organisations approaching PPA territory, this is the work that makes a PPA actually deliver on its promise rather than producing shortfall payments.

Support and operational reach

A reseller partner with managed services capability provides first-line and second-line support, with optional 24x7 coverage. Specialist knowledge across scalability, databases, security, and FinOps sits in the partner's team rather than requiring full-time hires.

The practical effect: faster escalation paths into AWS through the partner network, reduced mean time to resolution on incidents, and access to specialist expertise that would not be cost-effective to maintain in-house. The 24x7 dimension is particularly important; a single in-house engineer cannot reasonably provide 24x7 coverage, and a team of three to five for true continuity is rarely affordable below the 5M annual spend threshold.

Commercial structure and pricing

A reseller partner brings access to volume discounts and consolidated purchasing power that smaller customers would not achieve directly. For larger customers, the partner brings expertise in structuring Partner-Led PPAs, optimising commitment levels, and aligning Marketplace contracts with PPA term structure.

The practical effect for smaller customers: better pricing through aggregated purchasing. For larger customers approaching 1M to 5M annual spend: structured deals that maximise PPA eligibility for Marketplace retirement, term alignment that preserves negotiating position at renewal, and optimal mix of Reserved Instances, Savings Plans, and on-demand spend.

The expertise asymmetry matters. An AWS account team conducts dozens of PPA negotiations per year across many customers. A specialist partner conducts dozens of PPA negotiations per year specifically structured for SMB and mid-market customers. A customer negotiating their first PPA does it once. The asymmetry of expertise produces better outcomes when the customer is represented by the specialist rather than negotiating directly.

Funding and AWS programmes

A reseller partner provides access to AWS funding programmes that exist to accelerate adoption but that most customers do not know about. These include Migration Acceleration Program (MAP) funding for enterprise migrations, partner funding for proofs of concept and architecture reviews, AWS Activate credits up to roughly 100K USD for qualifying startups, and various competency-specific funding mechanisms.

The practical effect: reduced engineering effort and lower initial costs for migrations, PoCs, and assessment work. AWS funding programmes typically require partner involvement to qualify, which means customers operating direct miss out on a substantial source of cost offset.

Assessments and reviews

A reseller partner with the right competencies delivers structured assessments that produce actionable findings: AWS Well-Architected Reviews, AI readiness assessments, Cost Analysis and OLA (Optimization and Licensing Assessment), Marketplace spend analysis, security posture reviews, and FinOps Maturity Scans.

The practical effect: faster access to AWS-credentialed assessment frameworks that the customer would otherwise need to commission separately. Many of these assessments are partner-funded, meaning the customer pays a fraction of the standalone consulting cost.

What is the hidden TCO of managing AWS in-house?

The argument for building cloud capability in-house typically reduces to "we want control" or "we will save the partner margin". Both are reasonable instincts, but the TCO calculation is more complex than the salary line item suggests.

A genuine TCO calculation for in-house FinOps, security, or platform engineering capability includes more than salary and benefits. It includes employer social charges, holiday backup, sickness coverage, knowledge continuity during turnover, training, tooling, and the full operational obligations of running a 24x7 capability. European labour markets impose significantly higher continuity costs on employers than the US labour environment that most cloud capability content implicitly assumes. For mid-market organisations, the break-even threshold for in-house capability is meaningfully higher once these costs are honestly accounted for.

Six TCO components that in-house business cases routinely under-count:

Continuity buffer. A single specialist is a single point of failure. Genuine 24x7 coverage with vacation, sickness, and turnover absorption requires three to five people, not one. The break-even threshold for the team rather than the individual is materially higher.

Sickness and absence. European employment law extends sickness coverage well beyond US norms. A specialist out for an extended period is a multi-quarter financial commitment, not a six-week problem. During the absence, the capability the role was hired to provide is effectively unavailable.

Turnover and rotation. FinOps, cloud security, and platform engineering are mobile specialisms with average tenure in a role of 18 to 24 months. Onboarding a replacement to full productivity on the customer's specific stack takes 3 to 6 months. The gap between departure and replacement productivity is often nine months of effective capability loss per rotation.

Knowledge concentration. Institutional knowledge in a specialist team of one lives in that one person. Departure or extended absence destroys the knowledge entirely. A partner has the knowledge distributed across multiple specialists and structured documentation.

Tooling and licensing. FinOps tooling, security platforms, observability, and analytical infrastructure carry licence costs that are often quoted at enterprise scale and become uneconomic at SMB and lower mid-market scale.

Specialisation depth. A single in-house specialist must cover all aspects of their domain at acceptable depth. A partner has specialists who go deep on specific aspects (PPA structuring, Marketplace governance, FOCUS implementation, multi-account architecture) without each individual needing to be a generalist.

The aggregate effect is that the break-even threshold for in-house capability sits substantially higher than the naïve salary calculation suggests. For most European mid-market organisations, a serious in-house FinOps capability is not commercially defensible below roughly 5M annual AWS spend. Below that threshold, partner-led FinOps is typically both cheaper and more effective.

How do account dynamics differ between partner-led and direct AWS?

For customers below roughly 3M to 5M annual AWS spend, a dedicated local AWS account manager is rarely available. AWS allocates account management resources based on spend tiers, and SMB customers typically receive coverage from a centrally-located team rather than a regional account manager with local presence.

A reseller partner amplifies AWS reach in this segment. The partner provides direct interaction with AWS specialists, facilitates access to short whiteboard sessions and architecture reviews, and translates strategic direction into executable workstreams. The combination of a centralised AWS team plus a locally-present partner delivers an experience similar to what larger customers receive from a dedicated regional account manager.

The practical effect: faster translation from strategy to execution, more responsive access to AWS technical specialists, and clearer commercial communication when negotiating new structures or evaluating new AWS services.

For customers above 5M annual spend, a dedicated AWS account manager typically becomes available, and the amplification value of a partner shifts. The partner relationship continues to add value in technical execution, FinOps, and managed services, but the account access dimension becomes less differentiated.

When direct AWS engagement makes sense

Three thresholds shape the partner-versus-direct decision.

Below 5M annual AWS spend. Partner-Led structures typically deliver better total economics. Partner-Led PPA replaces mandatory Enterprise Support cost with Partner-Led Support, bundles FinOps and managed services as standard, provides amplified AWS reach, and removes the operational burden of in-house specialist hiring. Direct AWS engagement at this scale is technically possible but rarely produces better outcomes.

5M to 10M annual AWS spend, growing. This is the orientation window. The decision is not yet made; the work is to prepare for it. Skill gap analysis, in-house versus managed strategy evaluation, FinOps maturity development, AWS Organizations structure design for scale, procurement integration assessment. The decision moment arrives 12 to 24 months later, not at the next renewal.

Above 10M annual AWS spend. Direct AWS commercial agreement becomes commercially competitive. AWS becomes a top-three cost driver alongside payroll and marketing, justifying dedicated governance and direct alignment. At this scale, internal capability is typically mature enough to manage billing complexity, 24x7 operations, and FinOps function in-house, though the question of whether to do so versus continuing to source through partner managed services remains open.

Four decision criteria distinguish customers who should genuinely go direct from those who should stay Partner-Led even at higher scales:

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. Gaps in any of these capabilities point toward a hybrid model: direct AWS commercial agreement combined with partner-led managed services, FinOps, and operations.

What does a hybrid AWS reseller model look like?

The most common structure for organisations growing past the 10M threshold is hybrid. The commercial relationship moves direct to AWS, but the partner relationship continues across managed services and consultancy.

Three partnership layers, stackable rather than exclusive.

The reseller layer is where the partner is the contract counterparty for AWS spend. Most relevant for SMB and lower mid-market customers, typically below 10M annual spend.

The managed services layer is where the partner operates the AWS estate, including 24x7 operations, governance, security posture, incident response, and monitoring. This continues regardless of who holds the commercial reseller relationship. A customer signing a direct PPA with AWS can still engage the partner for ongoing operations.

The consultancy layer is where the partner delivers advisory, audit, FinOps assessment, transition projects, skill gap analysis, training, and standalone reviews of existing or proposed AWS commercial agreements. Time-bounded engagements rather than ongoing service.

A customer at 12M annual spend signing a direct PPA with AWS may engage the partner as managed services partner for ongoing operations and as consultancy for the annual FinOps audit. All three layers in stack, but only the reseller layer has changed compared to the previous Partner-Led arrangement.

A good partner advises actively on this transition, including telling the customer when the right answer is direct AWS engagement on the commercial side. The real risk is lack of governance, not partner structure.

Choose for control, not for discount

The recurring failure mode is choosing the partner relationship structure based on price comparison rather than control over commercial and operational outcomes. Control here means more than governance or oversight; it means active orchestration of who decides what, when, and how, across the entire AWS estate. The discount calculation is straightforward and tempting; the control calculation is harder and more important.

Five principles to apply when evaluating the choice.

Discount without governance leads to overspend. A 5 percent discount on a 100K compute bill that was never needed is still 100 percent too much. Optimisation always beats negotiation. The most expensive AWS resource is the one nobody is using and nobody is monitoring.

Expertise and AWS network reach are usually more valuable than price. For organisations below 5M annual spend, the partner's ability to access AWS programmes, accelerate technical work, and amplify account reach typically delivers more economic value than the partner margin would have saved if removed.

Capability transfer matters at every scale. A good partner relationship builds customer capability over time. Over 24 months, a partner that does not transfer knowledge has failed even if the technical work was successful. Partners that build customer capability eventually argue themselves out of the reseller layer at higher scales, but earn the consultancy and managed services layers in return.

The right structure depends on capability, not preference. Whether to go direct, Partner-Led, or hybrid is a question about what the organisation can do well in-house, not a question about which structure feels more independent. Organisations that go direct without the in-house capability to support it tend to discover the gap painfully at the first PPA renewal or the first major incident.

The real risk is lack of governance, not partner structure. Most organisations that struggle with PPA outcomes do not struggle because they picked the wrong commercial structure. They struggle because no one 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.