By Most organisations arrive at their AWS commercial arrangement by accretion. An account was opened years ago, spend grew, someone signed a support plan, a reseller appeared at some point, and software started being bought through Marketplace because it was faster than procurement. None of it was wrong at the time. Together it forms a structure nobody designed.
The structure is made of five decisions. This page states what each one is, what it depends on, and where the detailed answer lives.
| Decision | The question | Reversible? |
|---|---|---|
| Buying channel | Contract direct with AWS, or through a partner? | Yes, with effort |
| Commitment | Sign a private pricing agreement, or stay on standard pricing? | No, once signed |
| Support | AWS Enterprise Support, or a partner-led model? | Yes, at renewal |
| Software | How is third-party software purchased and governed? | Yes |
| Reporting | What schema carries cost data, and who reads it? | Yes, at rework cost |
The middle row is the one that constrains the others.
Decision one: direct or through a partner
The instinct is to treat this as a price comparison, which misreads how European AWS reselling works. In most structures the partner is remunerated by AWS rather than through a markup on your list price, so the question is not whether the partner costs more. It is what the partner does that AWS does not, and whether that is worth giving up a direct commercial relationship.
What a partner adds varies more than the market admits. Consolidated invoicing in local currency and local entity. Commercial negotiation on your side of the table rather than the vendor's. Engineering capacity you would otherwise hire. Support that answers in your timezone and your language. Access to funding programmes that require partner involvement to claim.
None of that is automatic, and a partner that provides only billing consolidation is providing very little.
The detailed comparison, including the six value layers and the cases where direct engagement genuinely wins, is in AWS reselling for European SMBs and mid-market: when partner value beats direct engagement.
Decision two: commitment shape
This is the decision that constrains the rest, and it is the least reversible.
A private pricing agreement trades a multi-year spend commitment for a discount. The mechanics matter more than the headline percentage: what counts toward the commitment, what happens if you undershoot, how much of the commitment can be retired through Marketplace purchases, and what support obligation the agreement carries.
That last point is where organisations get caught. The agreement can require a support tier, and the cost of that tier is a real part of the deal that rarely appears in the discount arithmetic presented alongside it.
Availability starts around $500,000 to $1,000,000 of annual spend depending on structure, which means most smaller estates are not choosing between standard pricing and a private agreement. They are choosing when to start the conversation.
The full treatment, including who qualifies, how discounts are shaped, what the support requirement costs, and how to choose between a partner-led and a direct structure, is in AWS Private Pricing Agreement (PPA): a complete guide for European SMBs and mid-market.
Decision three: the support model
Support looks like an operational choice and behaves like a commercial one, because the agreement above may require a support tier as a condition.
Once that requirement exists, the question becomes which model satisfies it. AWS Enterprise Support is the default answer. Partner-led support is the alternative, and in European structures it can satisfy the same requirement while changing what you get for the money: named engineers who know the estate, response in local hours, and a commercial relationship where escalation is a phone call rather than a ticket queue.
The comparison is not about which is better in the abstract. It is about what the requirement actually is, what each model costs against it, and what the difference buys in practice.
That analysis is in Partner-Led Support: the European AWS PPA alternative to mandatory Enterprise Support.
Decision four: how software gets bought
AWS Marketplace is not a procurement convenience. In many agreements, spend through Marketplace counts toward the private pricing commitment, which makes the buying channel a commercial instrument.
That creates an opportunity and a control problem at the same time. The opportunity is that software you were buying anyway can retire commitment. The control problem is that private offers can be accepted by individuals who are not part of the procurement process, at terms nobody reviewed, on an account nobody is watching. Legacy private offer flows are being phased out, which changes the governance surface again.
Four control layers keep procurement discipline intact without blocking the speed that makes Marketplace useful in the first place. They are set out in AWS Marketplace governance for enterprise: how to protect procurement discipline and PPA eligibility.
Decision five: how you will see the cost
The four decisions above determine what you pay. This one determines whether anyone can tell.
Cost data arrives in a provider-specific schema by default. The FinOps Open Cost and Usage Specification offers a normalised alternative, which matters if you run more than one provider or if a downstream tool expects it. It matters much less if you are single-cloud and your existing allocation model already answers the questions finance asks.
Two pieces cover this from different directions. FOCUS: the FinOps specification that needs a culture to work covers what the specification is and why standardised data alone changes nothing. What does FOCUS adoption cost, and when is it not worth it? covers the pipeline cost, the rework cost, the version gap between the specification and the AWS export, and the cases where adopting it does not pay this year.
The order, and why it is not arbitrary
The five decisions have dependencies, and taking them out of order is the most common and most expensive mistake.
Commitment shape comes first, because it is the only irreversible one and because it may impose a support obligation. Deciding support before knowing whether an agreement will require a particular tier means either buying twice or renegotiating.
Buying channel is decided alongside commitment rather than before it, because in a partner-led structure the agreement and the channel are the same conversation. Choosing a partner first and a commitment later gives away negotiating position; choosing a commitment first and a partner later can strand you in a structure the partner cannot serve.
Software buying comes after commitment, because whether Marketplace spend retires the commitment is a term of the agreement and not a property of Marketplace.
Reporting comes last and can be rebuilt at any point. It is the only one of the five where deferring the decision costs nothing but time.
What changes with scale
Below roughly $500,000 in annual spend, the commitment decision is usually not live. The live decisions are the buying channel and the support model, and both are reversible, which means the right posture is to choose something reasonable and revisit it annually rather than to over-analyse.
Between roughly $500,000 and several million, all five are live simultaneously, and this is where sequencing errors are most expensive. It is also the range where the commitment conversation typically starts before the organisation has decided what it wants from it.
Above that, the decisions stop being sequential and become a portfolio: multiple agreements, multiple entities, and a governance layer that has to hold them together. The individual guides still apply; the coordination problem becomes the harder part.
A worked sequence
The following is an illustration of the order, not a case study. Take an estate at roughly $800,000 of annual AWS spend, growing, with a small platform team and no dedicated FinOps capability.
Step one, before any vendor conversation: establish what the spend actually is. Committed against on-demand, which workloads are stable enough to commit, and what the growth curve looks like over the term being discussed. A commitment is a bet on a forecast, and an organisation that cannot state its forecast is negotiating blind. This step is unglamorous and it determines the value of everything after it.
Step two: open the commitment conversation knowing the support question. Ask what support obligation the agreement carries before discussing discount percentage. The discount is the number everyone anchors on; the obligation is the number that changes the net position. Both belong in the same model.
Step three: decide the channel in the same conversation. Whether the agreement is signed direct or through a partner changes who negotiates on your behalf, who invoices you, and in which currency and entity. Deciding this after terms are agreed means re-opening terms.
Step four: model the support options against the obligation. Only now is there enough information. The requirement is known, the term is known, and the two support models can be compared against the same obligation rather than against each other in the abstract.
Step five: check what Marketplace spend retires. If software purchases count toward the commitment, the commitment is effectively smaller than it looks, and the governance controls become financially material rather than administratively tidy.
Step six: design the reporting. Last, deliberately. It is the only reversible decision with no vendor on the other side of it.
An organisation that runs these in reverse, which is the common pattern, typically arrives at step two having already committed to a support model and a channel, with less to negotiate and less room to move.
The questions to ask at each decision
A short checklist is more useful than a long framework. These are the questions where a vague answer is itself the finding.
Buying channel. What does the partner do that AWS does not, stated as specific activities rather than adjectives? Who negotiates on our behalf when interests diverge? In what entity and currency are we invoiced? What happens to the relationship if we grow past the partner's capability?
Commitment. What counts toward the commitment and what does not? What happens if we undershoot? What proportion can be retired through Marketplace? What support obligation does this carry, and what does that obligation cost? What is the exit position at end of term?
Support. What obligation are we actually satisfying? What response times apply, in which timezone, in which language? Who is the named contact, and do they know our estate? What escalates to AWS directly regardless of model?
Software. Who can accept a private offer today? Does that spend count toward the commitment? What review happens before acceptance? How do we find out about an offer accepted without review?
Reporting. Which consumer is waiting for this data, and in what schema? Which existing reports break if the schema changes? Who reconciles old against new, and for how long?
Every one of those questions has a concrete answer. If the answer that comes back is directional rather than specific, that is the part of the arrangement to look at first.
Three failures worth naming
Discovering the support obligation after signing. The discount was modelled, the support requirement was not, and the net position is worse than the pre-agreement baseline. This is avoidable with one question asked earlier.
Optimising the reversible decisions and rushing the irreversible one. Weeks spent comparing support tiers, days spent on a multi-year commitment. The analysis effort should be weighted by how hard each decision is to undo.
Treating the five as five procurements. Different owners, different quarters, no shared view. Each decision is defensible in isolation and the combination is not. This is the structure by accretion described at the top of this page, and it is the normal state rather than an unusual failure.
Where to go next
If a commitment conversation is imminent, start with the private pricing guide, because everything else follows from its terms.
If spend is below the private pricing threshold, start with the reselling comparison and the support comparison, since those are the two decisions actually available to you.
If the estate is already running and the question is why the numbers are hard to explain, start with the reporting pieces.
TechNative is an AWS partner and a FinOps Foundation Implementation Partner working with European SMB and mid-market organisations on exactly these five decisions. If you want an outside read on the structure you have now, get in touch.
