In partnership with

Guest post by Jordi Espasa Clofent. He’s a master of FinOps procurement. Enjoy.

In the early days of cloud adoption, often the primary goal was speed. Such a tendency is still there and to prioritize a shorter Time To Market, organizations grant administrative permissions to Engineering because friction was and is seen as the enemy of innovation.

But as cloud ecosystems matured, a new, quieter risk emerged: the AWS Marketplace lack of governance.

For many organizations, the AWS Marketplace is a double-edged sword. It offers an incredible catalog of third-party software, from security firewalls to data visualization tools, that can be deployed with a single click and billed directly through your AWS invoice.

However, that same convenience creates a shadow procurement channel that bypasses every traditional organizational guardrail.

Wanna sponsor this newsletter? Give us a call

The challenge: The procurement fast-track

The challenge faced is systemic. Engineers with high-level administrative permissions could treat  the AWS Marketplace as an extension of their technical sandbox. They could subscribe to 3rd party services directly through the console, often unaware that they are entering the company into legally binding contracts.

By doing so, they are (presumably inadvertently) skipping the entire corporate procurement lifecycle. This created 4 major areas of risk:

  1. Security risk: Lack of a due when services are integrated into the organization systems without formal risk assessment. According to IBM’s Cost of a Data Breach Report, third-party software vulnerabilities are a leading entry point for breaches, costing companies millions.

  2. Legal risk: Terms and Conditions are accepted by engineers who lack the legal authority to bind the company. This creates  a major contractual debt,  where the company might unknowingly agree to unfavorable indemnity clauses or auto-renewal terms (the latter being a very common one almost all default T&Cs incorporate since it’s very supplier-beneficial).

  3. Data Privacy risk: Software being used that had not been vetted for GDPR, SOC2, or industry-specific regulatory requirements

  4. Commercial risk: Accepting prices, penalties, true-ups and payment terms that are not beneficial or even not compliant with the organizations policies.

In short, we have a financial open door where technical admin rights are being used as a blank check to procure 3rd party services, leading to a fragmented, uncompliant and unmanaged vendor landscape.

The hypothesis: Centralizing authority via identity and process

Procurement via Marketplace is a business transaction, not a technically eligible option. 

Separating the technical ability to deploy software from the legal authority to purchase it, we can close the compliance gap without slowing down engineering velocity. The fix is not about banning the Marketplace, which provides undeniable value in consolidating billing, but to move the purchase button from the hands of the many into the hands of a specialized few.

If the ability to buy in AWS Marketplace is restricted to the FinOps and Procurement teams, we can enforce guardrails. This would ensure that every dollar spent on the Marketplace is intentional, vetted, and correctly accounted for in the financial forecasts.

Validating the solution: Limited permissions and process in place

To test this hypothesis, a two-steps strategy that aligned technical reality with business necessity can be implemented:

1. Limited permissions

Using AWS Identity and Access Management (IAM), the power to buy in the Marketplace is restricted from Engineering roles. Such permissions are only granted to a tightly controlled group: The FinOps and Procurement teams. According to the AWS Marketplace Governance Guide, using fine-grained IAM policies is the first line of defense. As part of this restriction, organizations can also leverage the Private Marketplace feature. 

2. Process in place

Once the purchasing button is secured, we need a process to handle legitimate requests. A mandatory workflow where a Private Offer in the Marketplace could only be accepted once a Purchase Order (PO) is generated in the internal finance system. (whatever the particular ERP that is)

This aligns with the FinOps Foundation’s Cloud Procurement capability, which emphasizes that cloud spend should follow the same rigorous PO lifecycle as any other enterprise vendor. By requiring Procurement to be involved before signing a Private Offer, it is ensured that:

  • Legal had reviewed the End User License Agreement (EULA).

  • Security had verified the integration

  • Data Privacy has been reviewed.

  • Procurement had confirmed the budget exists for the multi-year commitment often found in Private Offers and all commercial terms are compliant with Finance requirements

The learning: Feedback loops are the secret sauce

There are two lessons learned from this transition:

  • The carrot and the stick tale. When it comes to commercial contracts, the risk is too significant (Security, Finance, Procurement, Data Privacy) to allow either ignorance or human error to be around. Limiting the permissions the most of the errors are out of the conversation at one: the stick takes precedence over the carrot.

  • Feedback loops are essential. Governance without communication is just a bottleneck. The Finops practitioner has to align and get the feedback and endorsement from multiple Personas to design a robust and compliant process.

Initially, Engineering might fear this would create a week-long delay for a five-minute task. However, that can be solved by creating a transparent Marketplace Request loop. When an engineer needs a tool, they just go follow the regular P2P process in place. 

This two step solution (restricted permissions a process) provides clarity and benefits. When Procurement and FinOps get involved early, we often discover that the company already has enterprise licenses for similar tools (e.g., a logging tool or a security scanner), preventing redundant spend. According to Gartner, by 2026, 40% of software will be purchased through cloud marketplaces. Without a feedback loop, organizations risk SaaS sprawl that is impossible to manage.

Is governance a bottleneck?

In the IT world overall (not just start-ups), governance is often viewed as a dirty word that kills agility. But unmanaged Marketplace access is a risky luxury that leads to security debt, legal exposure and financial leakage.

By treating the AWS Marketplace as a formal procurement channel rather than a technical feature, the Finops team is not just saving money but protecting the entire company's infrastructure and reputation. Governance isn't about saying No, it's about saying Yes through the right door, ensuring scalability and compliance as a foundation

Your Docs Deserve Better Than You

Hate writing docs? Same.

Mintlify built something clever: swap "github.com" with "mintlify.com" in any public repo URL and get a fully structured, branded documentation site.

Under the hood, AI agents study your codebase before writing a single word. They scrape your README, pull brand colors, analyze your API surface, and build a structural plan first. The result? Docs that actually make sense, not the rambling, contradictory mess most AI generators spit out.

Parallel subagents then write each section simultaneously, slashing generation time nearly in half. A final validation sweep catches broken links and loose ends before you ever see it.

What used to take weeks of painful blank-page staring is now a few minutes of editing something that already exists.

Try it on any open-source project you love. You might be surprised how close to ready it already is.

Wanna sponsor this newsletter? Give us a call

Keep Reading