An IDP turns your AWS account into a product your engineers self-serve against: push code, get an environment, ship to prod — without filing a ticket or reading a 40-page runbook. This page covers what an IDP is, the building blocks, build-vs-buy (Backstage vs commercial), a reference AWS architecture, and the team-size signals that say it's time — then how to get one built by a vetted AWS partner, often AWS-funded.
An IDP is not a single tool you install. It is the curated, self-service interface between your developers and your cloud — the set of paved roads that turn "how do I deploy this?" from a Slack question into a button.
Strip away the buzzwords and an internal developer platform is one idea: developers should be able to do the common things — spin up a service, provision a database, get a preview environment, ship to production, see their logs — by themselves, through a consistent interface, without needing to understand the Terraform, the IAM policies, the VPC layout, or the CI/CD wiring underneath. The platform team builds and owns the road; product engineers drive on it.
The canonical mental model: an IDP sits on top of your existing infrastructure and exposes a small number of golden paths (also called paved roads) — the supported, opinionated way to do a thing. You can always drop down to raw AWS, but the golden path is so much faster and safer that almost everyone takes it. That is the whole game: make the right way the easy way.
Concretely: a developer shipping a new microservice opens the portal, picks a template ("Go API on ECS Fargate"), names it, and hits go. Behind that one action the platform scaffolds a repo, wires the CI/CD pipeline, provisions a staging environment via Infrastructure-as-Code, registers the service in the catalog, and applies the right IAM, networking, and dashboards. The developer never opened the AWS console.
It is equally important to say what an IDP is not. It is not "we bought a Kubernetes cluster," a wiki page of deploy instructions, or your CI/CD tool by itself. And it is not a replacement for the platform team — it is the product that team ships internally. The infrastructure still exists; the IDP is the experience layer that makes it self-service.
If a new backend engineer can go from "I have code" to "it is running in production behind a load balancer, with logs and metrics" on their first week, without a senior engineer doing it for them, you have an internal developer platform. If that journey requires a ticket, a meeting, or tribal knowledge — you have infrastructure, but not yet a platform.
An IDP is an assembly, not a product — the components that, wired together, produce self-service. You do not need all of them on day one, but a credible platform converges on this shape. Mapped onto AWS, the building blocks look like this:
A common failure mode is shipping only the guardrails (restrictive IAM and policy) without the paved road (the fast, supported way to get work done). Developers feel that as friction with no upside and route around it. A real IDP leads with the paved road — faster than doing it by hand — and the guardrails come along for free, baked into the path.
"Platform engineering" is not a rebrand of DevOps. It is a response to what happened when DevOps scaled past a handful of teams — the answer to "you build it, you run it" colliding with "every team now has to be an infrastructure expert."
The original DevOps idea was to dissolve the wall between dev and ops: developers own running what they build. That works beautifully at small scale. But as an organization grows to dozens of engineers and many services, "every team owns its own infrastructure" turns into every team reinventing the same VPC, CI/CD, and observability — badly, inconsistently, and at the cost of actual product work. Cognitive load explodes.
Platform engineering is the next move: instead of each team owning infrastructure from scratch, a dedicated platform team treats internal developers as customers and ships them a product — the IDP — that abstracts the undifferentiated heavy lifting. Product teams still own their services in production, but on top of a paved platform instead of bare AWS. It is "you build it, you run it" with a much better road to run on.
The cultural shift matters as much as the tooling. A good platform team runs the platform like a product — users, a roadmap, feedback loops, adoption metrics, an obsession with developer experience — not as a gatekeeping ops team that approves tickets. If the platform is mandatory and bad, developers resent it; if it is genuinely the fastest way to ship, adoption is voluntary and near-total. That distinction — product mindset vs gatekeeper — separates platform engineering from a renamed ops team.
Traditional DevOps: infrastructure knowledge is distributed across product teams; each team wires its own pipelines and infra; consistency depends on discipline and copy-paste; the "ops" person becomes a shared bottleneck for anything non-standard.
Platform engineering: infrastructure knowledge is concentrated in a platform team that productizes it; product teams consume golden paths; consistency is the default because it is baked into templates and modules; the team scales by improving the product, not by personally unblocking tickets.
The honest nuance: platform engineering does not replace DevOps practices — CI/CD, IaC, observability, automation are still the substance. It changes who owns them and how they are delivered, from "every team, by hand" to "a platform team, as a product." Small teams should do good DevOps first; platform engineering is what you graduate into.
Building an IDP too early is a classic over-engineering trap — months spent on a platform for three engineers who would have been fine with a README and a Makefile. The right question is not "should we have an IDP?" but "are we feeling the pain an IDP solves?"
The decision is best made on signals, with headcount as a useful proxy. Roughly: below ~10 engineers, a clean IaC repo plus CI/CD plus a short runbook is plenty and an IDP is premature. Between ~15 and ~30 engineers with multiple services, the pain usually crosses the line and a focused IDP pays for itself quickly. Above ~30–50, the absence of a platform is a compounding tax on every team. These are bands, not thresholds — a 12-person team shipping 20 services may need it sooner than a 40-person team with one monolith.
More reliable than headcount are the symptoms. If you recognize several of these, you are past the point where an IDP starts paying back:
The ROI of an IDP comes from amortizing platform work across many developers and services; with few of either, you pay the build cost and capture little of the benefit. Do excellent boring DevOps first — versioned IaC, one good pipeline, sane observability — and revisit the IDP when the team-size signals above start firing.
Once you have decided you need an IDP, the next fork is whether to build the portal on open-source Backstage or buy a commercial platform. There is no universally right answer — only a right answer for your team's size, control needs, and appetite for owning a platform-as-a-product.
Backstage — open-sourced by Spotify, now a CNCF project — is the default "build" option: a framework for your own developer portal with a service catalog, software templates (the scaffolder), TechDocs, and a large plugin ecosystem. The upside is total control and no per-seat cost. The honest downside is that Backstage is itself a real engineering project — a Node/React application you run, write and maintain plugins for, integrate with your AWS estate, and keep upgraded. Teams routinely underestimate that it is a platform you operate, not a product you install.
Commercial platforms — Port, Cortex, Humanitec, OpsLevel, and opinionated PaaS-style layers — sell faster time-to-value: a hosted portal, catalog, scorecards, self-service actions, and integrations out of the box, configured rather than coded. The trade is per-seat or platform pricing and less ultimate control — you work inside their model. For many teams, especially those without spare platform engineers, that trade is worth it: a working platform in weeks beats a bespoke one in quarters.
There is a spectrum in between, too — some teams run Backstage as the portal but lean on managed building blocks (managed CI/CD, Argo CD, Grafana) so they are not operating everything. The meta-point: build-vs-buy is mostly about where you spend your scarcest resource — senior platform-engineering time. Building on Backstage spends it on the platform; buying spends money to preserve it for product. Most early-to-mid-stage startups are better served buying or partnering for the first version, and revisiting "build" only once platform engineering is a deliberate, staffed function.
There is no single blueprint, but a pragmatic, widely-used shape exists — opinionated enough to be real, flexible enough to adapt. The reference architecture layers cleanly: a portal at the top, golden-path templates that fan out into IaC and CI/CD, a multi-account AWS foundation underneath, and observability threaded through all of it.
Under everything sits an AWS landing zone — Control Tower with Organizations, separate accounts for production / staging / sandbox with per-team isolation, IAM Identity Center for access, and Service Control Policies as the outer guardrails. That is what makes self-service safe: a developer creating a service lands in the right account with the right boundaries automatically. On top, most platforms standardize on one compute path so the golden path is singular — ECS on Fargate as the lower-overhead default, or EKS when you want the Kubernetes ecosystem (often with Argo CD for GitOps). The IDP exposes this as "deploy a service"; developers need not know whether a task definition or a Deployment is underneath.
A golden-path template (Backstage's scaffolder or a commercial equivalent) generates a repo from a starter, a CI/CD pipeline (GitHub Actions / CodePipeline) wired to build and deploy, and a call to versioned Terraform/OpenTofu or CDK modules that provision the service's infrastructure — ECS service or EKS workload, ALB target group, RDS or DynamoDB if needed, IAM roles, Secrets Manager entries. The same modules back every service, so consistency is structural. The portal then surfaces all of it: developers create and discover services and see ownership and health, and every service registers automatically with CloudWatch logs and dashboards, metrics via Managed Prometheus/Grafana or Datadog, and traces via X-Ray/OpenTelemetry — provisioned by the template, not bolted on later.
| Layer | What it does | Representative AWS / tooling choice |
|---|---|---|
| Developer portal | Self-service front door + service catalog | Backstage (OSS) · Port · Cortex |
| Golden-path templates | Scaffold repo + pipeline + infra in one action | Backstage scaffolder · commercial self-service actions |
| IaC modules | Reusable, reviewed infrastructure building blocks | Terraform / OpenTofu · AWS CDK |
| CI/CD | Build, test, deploy on the paved path | GitHub Actions · GitLab CI · CodePipeline/CodeBuild · Argo CD |
| Compute runtime | Where services run | ECS on Fargate · Amazon EKS · App Runner |
| Foundation / RBAC | Multi-account isolation + guardrails | Control Tower · Organizations · IAM Identity Center · SCPs |
| Observability | Logs, metrics, traces by default | CloudWatch · Managed Prometheus/Grafana · X-Ray/OTel · Datadog |
| Secrets & config | Consistent credential/config injection | Secrets Manager · Parameter Store |
The graveyard of IDP projects is full of platforms that tried to do everything at once, took a year, and shipped nothing developers wanted. Treat the IDP like a product launch, not an infrastructure migration: the roadmap that works is narrow, fast, and adoption-driven — one golden path that is genuinely great, adopted voluntarily by a real team, before a second one exists.
Measure the platform by adoption and developer lead time, not by how much you built. If teams choose the golden path because it is the fastest way to ship — and the time from "new service" to "in production" drops from days to minutes — the IDP is working. If you had to mandate it, something on the paved road is still slower than going around it; fix that before adding scope.
Building an IDP well needs senior platform-engineering time you probably do not have spare — the whole reason you need the IDP. CloudRoute routes you to a vetted AWS partner who builds it, frequently AWS-funded for credit-eligible companies, so you pay $0 or close to it.
The catch with platform engineering is circular: you need an IDP because your senior engineers are overloaded, but building one needs senior engineers, and a dedicated platform team is slow, expensive, and hard to hire. CloudRoute's answer is to route you to an AWS partner who has built internal developer platforms before — a team that arrives with battle-tested golden-path templates, IaC modules, and a reference architecture, and adapts them to your stack instead of inventing yours from scratch.
The funding piece is what most teams do not realize. For credit-eligible companies — typically institutionally-funded startups — this kind of build is frequently delivered through AWS partner-funding programs: the partner is paid via AWS, and your underlying AWS usage during the build runs against Activate credits, so the build often costs the customer $0 or low cost. We will be honest about it: AWS-funded applies to credit-eligible engagements. If you are not credit-eligible, it becomes a vetted-partner referral that skips the hiring-and-vetting slog — still a strong outcome, just not free.
If you are also early enough to qualify for AWS credits, line those up in parallel — the credits fund the AWS spend the new platform runs on, and CloudRoute can route both the credit application and the partner who builds the IDP.
The honest framing: building on Backstage spends your scarcest resource (senior platform time) to maximize control; buying spends money to preserve that time. Here is how the two compare on the axes that actually decide it.
| Variable | Build on Backstage (OSS) | Buy a commercial IDP |
|---|---|---|
| Time to first golden path | Weeks–months (you build the portal too) | Days–weeks (configure, not code) |
| Up-front cost | Engineering time, no license | Per-seat / platform subscription |
| Ongoing cost | You operate + upgrade it (real, recurring) | Subscription + lighter ops |
| Control / customization | Total — it is your codebase | High but bounded by their model |
| Plugin / integration ecosystem | Large, open, DIY to wire | Curated, supported out of the box |
| Best fit | Teams with a staffed platform function | Teams that need value fast without spare platform engineers |
| Lock-in risk | Low (open-source, yours) | Moderate (vendor model + data) |
| Who maintains it | You | Largely the vendor |
Situation: Two senior engineers had effectively become a full-time platform help desk — most of their week went to spinning up environments, wiring pipelines for new services, and handling access requests. Each team's infra had drifted into a different shape, so nothing was reproducible. Standing up a new service took 2–3 days of senior time. They had no spare capacity to build a platform precisely because of the queue. Credit-eligible (institutional Series-A) and already on AWS at ~$6K/month.
What CloudRoute did: Routed within ~20 hours to a UK-based AWS partner with a platform-engineering and Backstage track record. The partner ran a one-week discovery, then shipped a single golden path first — "new HTTP service on ECS Fargate" via a Backstage scaffolder template → repo → GitHub Actions pipeline → staging+prod through shared OpenTofu modules → CloudWatch logs and a Grafana dashboard by default — on top of a tidied Control Tower landing zone. Phase 2 added a worker template, per-PR preview environments, and self-service database provisioning. The engagement was delivered through AWS partner funding alongside the team's Activate credits.
Outcome: New-service creation dropped from 2–3 days of senior time to roughly 10 minutes of self-service. The two senior engineers got most of their week back for product. By week 10, three of four teams were on the golden path voluntarily. Because the company was credit-eligible, the platform build was AWS-funded and the customer paid $0 for the engagement; ongoing AWS spend ran against Activate credits.
build window: ~10 weeks · golden paths shipped: 4 · lead-time-to-prod: days → minutes · cost to customer: $0 (credit-eligible)
CloudRoute routes you to a vetted AWS partner who ships your golden paths — Backstage or commercial. For credit-eligible companies the build is often AWS-funded, so you pay $0. No hiring slog, no platform built from a blank repo.