Most platform teams think their job is to build infrastructure. They're wrong. Their job is to build infrastructure that other teams can consume without thinking about it.
The difference matters more than most organisations realise. A platform team that builds a beautifully architected AWS landing zone but makes it painful to consume has built a bottleneck, not a platform. And in a large enterprise (where dozens of product teams need to ship features against real deadlines) bottlenecks don't just slow you down, they breed shadow IT, workaround architectures, and the kind of ungoverned sprawl that keeps security teams awake at night.
The Provider to Consumer model fixes this. It's a shared responsibility framework that gives the platform team (the Provider) clear ownership of foundational infrastructure, while giving product teams (the Consumers) a fast, governed path to build and deploy. Neither side operates in isolation. Both sides have accountabilities, and the interfaces between them are deliberate, opinionated, and battle-tested.
Here's how it works, and why it's the pattern that separates enterprises that scale confidently from those that scale chaotically.
The Problem With "We'll Build It For You"
In too many enterprises, the cloud platform team operates as a service desk. Product teams raise a ticket > The platform team provisions a VPC > Another ticket > An IAM role gets created > Another ticket > A CI/CD pipeline appears three weeks later.
This model doesn't scale. It can't. Every request becomes a queue item. Every queue item becomes a lead time. Every lead time becomes a frustrated product manager asking why it takes six weeks to get a development environment when they could spin one up on a personal AWS account in twenty minutes.
The instinct to centralise everything and hand it out on request comes from good intentions (governance, security, cost control). But the execution model is fundamentally wrong. You're not providing a platform. You're providing a gatekeeping function that happens to run on AWS.
The Provider to Consumer model inverts this. Instead of building things for consumers, you build things that consumers can use themselves (within boundaries you've already defined).
What the Provider Actually Owns
The Provider is the cloud platform team. Their job is to provision and maintain the foundational layers that every product team needs (and to do it in a way that's repeatable, governed, and fast).
There are four core responsibilities.
Account Provisioning with CIS Baseline. Every new workload gets its own AWS account pattern, provisioned through automation with a CIS security (or other supported frameworks) baseline already applied. The consumer doesn't request a hardened account and wait. The account arrives hardened. Security isn't a follow-up step, it's baked into the provisioning pipeline. AWS Control Tower watches across the entire organisation, enforcing guardrails that the consumer doesn't need to think about because they can't violate them.
VPC Design and Provisioning. The Provider owns the network architecture. Every account receives a VPC built from a repeatable reference architecture, consistent CIDR allocation, subnet tiering, inspection architecture, and connectivity back to shared services. The consumer doesn't design their own network. They don't choose their own CIDR ranges. They don't decide whether they need a NAT gateway. The VPC arrives ready, and it's the same shape every time. This isn't about limiting creativity, it's about eliminating an entire category of networking incidents that happen when teams roll their own.
CI/CD Pipeline and Repository Provisioning. The Provider provisions a GitHub repository with industrialised GitHub Actions workflows already wired in. The PR workflow (plan on pull request, apply on merge) is pre-configured and opinionated. The consumer doesn't build their own pipeline from scratch. They don't decide how Terraform gets executed. They inherit a workflow that's been tested across dozens of teams and hundreds of deployments. It works. Use it.
Infrastructure as Code Modules. The Provider maintains a library of battle-tested Terraform (or Terragrunt/OpenTofu) modules for commodity services (compute, databases, storage, queues, load balancers), the building blocks that every product team needs. These modules encode the organisation's opinions about how things should be built - tagging standards, encryption defaults, logging configuration, IAM boundaries. A consumer deploying an RDS instance through a Provider module gets all of that for free. A consumer building their own from raw Terraform resources gets none of it, and that creates a governance gap that someone will eventually have to close.
What the Consumer Actually Owns
The Consumer is the product team, developers and DevOps engineers building features, services, and applications on top of the platform.
Their accountabilities are different from the Provider's, but they're not lesser. The Consumer owns the application. The Provider owns the platform. The boundary between them is the interface contract, and both sides have obligations to honour it.
Building in a Safe, Governed Zone. The Consumer operates within the account, VPC, and pipeline that the Provider has established. They don't need to understand how the VPC was designed (but they do need to place their resources in the correct subnets). The Provider exposes this through lookups - the Consumer queries for the right subnet by type (public, private, data/backend etc) and gets back the correct placement. The VPC configuration is locked. The lookup is available. This is the right trade-off.
Using the CI/CD Pipeline for All Infra Changes. No ClickOps, no console deployments - every infrastructure change goes through the PR workflow the Provider has established. Plan on pull request > review > approve > apply on merge > promote through environments. The Consumer uses this pipeline, they don't modify it, bypass it, or build an alternative alongside it. The pipeline is the governance boundary, and respecting it is what makes the model work. If there are exceptions where console access is unavoidable, then it's granted on a request/approval basis, it is also temporary.
Consuming Infra IaC Modules for Resource Provisioning. When the Consumer needs infrastructure, they reach for a Provider module first. Need an S3 bucket? There's a module. Need an ECS service? There's a module. Need an Aurora cluster? There's a module. These modules aren't suggestions, they're the supported path. Building outside them is possible but comes with additional review requirements, because you're stepping outside the governed envelope.
The Shared Responsibility in Practice
The diagram that captures this model cleanly shows an AWS account as a shared space with a clear dividing line. On the left: the Provider's contributions. On the right: the Consumer's usage of those contributions. In the middle: the interfaces that connect them.
At the account layer, the Provider provisions the account with the required security frameworks applied. The Consumer sees Control Tower guardrails watching over their environment. They build in a safe zone, not because they chose to be safe, but because the environment won't let them be unsafe.
At the network layer, the Provider delivers a repeatable reference VPC architecture. The Consumer gets lookup access to find the correct subnet for their workload placement. The config is locked. The information is accessible. The Consumer can read the network topology but can't rewrite it.
At the CI/CD layer, the Provider delivers an Infra GitHub Actions workflows. The Consumer uses them to create and promote through their PR-driven deployment workflow. Infrastructure changes flow through the same governed pipeline regardless of which team is making them.
At the IaC layer, the Provider delivers modules. The Consumer uses them. The module encodes the organisation's standards. The Consumer supplies their workload-specific configuration. The result is infrastructure that's both customised to the application and compliant with the organisation's baseline.
This isn't a hierarchy, it's a contract. The Provider promises a fast, secure, consistent foundation. The Consumer promises to build on that foundation rather than around it.
Why "Built for Consumability" Is the Whole Point
Here's the phrase that should be pinned above every platform team's desk: Build for Consumability.
The value of a platform isn't measured by how sophisticated the Provider's architecture is. It's measured by how quickly a Consumer can go from "I need an environment" to "I'm deploying code." If that journey takes six weeks and twelve tickets, the architecture doesn't matter. You've failed.
Fast request through to environment provisioning means a product team can go from approved request to fully provisioned, governed AWS account with VPC, pipeline, and IaC modules, ready to build, in minutes, not weeks (as long as the required information is provided to facilitate the process). This is what automation exists for. Not to make the platform team's life easier (though it does), but to make the Consumer's path frictionless.
Clear separation of accountabilities means nobody is confused about who owns what. The Provider doesn't debug application code. The Consumer doesn't redesign the VPC. When something goes wrong (and it will) the separation makes triage faster because the ownership boundaries are unambiguous.
Governed and opinionated do's and don'ts include fail-safes meaning the platform has opinions, and those opinions are enforced. You can deploy an RDS instance through the module. You can't deploy an unencrypted RDS instance because the module won't let you. You can create a security group. You can't open 0.0.0.0/0 to the internet because the guardrail catches it. These aren't restrictions on productivity, they're the reason the Consumer can move fast.
Industrialised VPC architecture means the network is solved. Every account gets the same proven design, with inspection, segmentation, and connectivity built in. The Consumer never has to become a networking expert to ship a feature.
Industrialised GitHub Actions means the infra deployment pipeline is solved. Every team gets the same PR workflow, the same plan-and-apply pattern, the same promotion gates. The Consumer never has to become an infra CI/CD expert to deploy safely.
Battle-tested IaC modules means the building blocks are solved. Every commodity service has a module that encodes security, tagging, logging, and best practices. The Consumer never has to become a Terraform expert to provision compliant infrastructure.
See the pattern? The Provider solves categories of problems once. The Consumer benefits from those solutions repeatedly. That's consumability.
The Feedback Loop That Makes It Better
The Provider to Consumer model isn't static. The best implementations include a feedback loop where Consumer teams report friction, request new modules, and flag gaps in the platform.
A Consumer team discovers they need a service that doesn't have a module yet? That's a signal to the Provider to build one. A module is too rigid for a legitimate use case? That's a signal to add a configurable parameter. The PR workflow doesn't handle a team's branching strategy well? That's a conversation worth having.
The Provider maintains the platform. The Consumer pressure-tests it. Over time, the platform gets better not because the Provider imagines what teams need, but because teams tell them, through usage patterns, through support requests, and through the occasional frustrated Slack message that starts with "why can't I just..."
Those messages aren't complaints. They're product feedback. And the platform teams that treat them that way build platforms that people actually want to use.
What Happens When You Get This Wrong
If the Provider builds without thinking about consumability, you get a technically excellent platform that nobody uses. Teams route around it. They build their own VPCs in accounts they shouldn't have access to. They set up their own pipelines because the official one is too slow or too rigid. Shadow infrastructure proliferates, and the governance that the platform was supposed to provide evaporates.
If the Consumer ignores the Provider's interfaces and builds from scratch, you get inconsistency. Every team's infrastructure looks different. Tagging standards vary. Encryption policies are applied ad hoc. When audit time comes (and it always comes) you're answering questions about fifty different implementations instead of one.
If neither side respects the boundary, you get the worst of both worlds: a platform team drowning in bespoke requests and product teams waiting in queues that shouldn't exist. This is the state most enterprises find themselves in before they adopt the model. It feels normal because everyone's used to it. It isn't normal. It's just common.
Why This Matters Now
Enterprises are scaling their AWS & general cloud footprints faster than ever. Hundreds if not thousands of accounts. Thousands of developers. Hundreds of 3rd party suppliers. Dozens of product teams with different tech stacks, different timelines, and different risk tolerances.
You cannot govern this with ticket queues and manual provisioning. You cannot secure this by reviewing every pull request centrally. You cannot maintain consistency by writing standards documents that nobody reads.
You can govern it by building a platform that's opinionated by default and consumable by design. You can secure it by encoding security into the modules and guardrails that teams use every day. You can maintain consistency by making the compliant path the easiest path.
The Provider to Consumer model isn't just an operating model. It's a force multiplier. Every investment the Provider makes in a module, a pipeline, or a guardrail pays dividends across every Consumer team that uses it. And when the platform is built for consumability, those Consumer teams don't just tolerate the platform, they depend on it.
Build for consumability. Build the interfaces. Define the boundaries. And then let your product teams build, fast, safe, and at scale.
Top comments (0)