An internal developer platform: self-service golden paths your developers use.

IWhat an internal developer platform is (and is not)

An IDP is not one tool you install. It is the curated, self-service interface between your developers and your cloud: the paved roads that turn "how do I deploy this?" from a Slack question into a button.

Developers do the common things themselves (create a service, provision a database, get a preview environment, ship, see logs) through one consistent interface, without needing to understand the Terraform, IAM, VPC or CI/CD underneath. The platform team builds and owns the road; product engineers drive on it.

Example: a developer opens the portal, picks a template ("Go API on ECS Fargate"), names it and clicks create. The platform scaffolds a repo, wires the pipeline, provisions staging through infrastructure as code, registers the service in the catalog, and applies the right IAM, networking and dashboards.

An IDP is not "we bought a Kubernetes cluster", a wiki page of deploy steps, or your CI tool alone. It does not replace the platform team; it is the product that team ships.

IIThe building blocks of an IDP on AWS

An IDP is an assembly. You do not need every piece on day one, but a credible platform converges on this shape.

• Developer portal: One catalog where developers find services, create new ones from templates, and see ownership, docs and health. Backstage is the open-source default; Port and Cortex are common commercial portals.
• Golden-path templates: Opinionated starters ("Node service on ECS", "Python worker on Lambda") that generate the repo, pipeline, infrastructure code and catalog entry in one step. Most of the leverage lives here.
• Infrastructure-as-code modules: Reviewed Terraform, OpenTofu or CDK modules the templates call, so environments stay consistent and secure by default.
• CI/CD: GitHub Actions, GitLab CI or CodePipeline, pre-wired by the template. Argo CD for GitOps where Kubernetes is in play.
• Environment management: On-demand staging, preview environments per pull request, and production, created and torn down by the platform.
• Access and guardrails: IAM Identity Center, AWS Organizations and Control Tower guardrails, plus policy as code, so self-service does not mean anyone can do anything.
• Observability by default: Logs, metrics, traces and a dashboard for every service from day one: CloudWatch, Managed Prometheus and Grafana, X-Ray or OpenTelemetry, or Datadog.
• Secrets and config: Secrets Manager and Parameter Store wired in, so credentials are never copied by hand.

IIIPlatform engineering vs traditional DevOps

Platform engineering is what happens when "you build it, you run it" meets a company where every team would otherwise have to be an infrastructure expert.

DevOps put developers in charge of running what they build. That works at small scale. With dozens of engineers and many services, every team reinvents the same VPC, pipelines and monitoring, inconsistently.

Platform engineering puts that knowledge in a platform team that treats developers as customers and ships them a product (the IDP). Product teams still own their services in production, on a paved platform instead of bare AWS. CI/CD, infrastructure as code and observability are still the substance; what changes is who owns them and how they are delivered.

A good platform team runs the platform like a product: users, a roadmap, feedback and adoption metrics, not ticket approvals. If the paved road is the fastest way to ship, adoption is voluntary.

IVWhen an IDP is worth it (team-size signals)

Building an IDP too early is a classic over-engineering trap. Ask whether you feel the pain an IDP solves.

Rough bands: below about 10 engineers, a clean infrastructure-as-code repo, CI/CD and a short runbook are plenty. Between about 15 and 30 engineers with several services, a focused IDP usually pays for itself. Above that, the lack of one taxes every team. Symptoms matter more than headcount:

• Your DevOps engineer has become a human ticket queue for deploys, environments and access.
• A new service takes days of senior time, and the steps live in someone's head.
• Every team's infrastructure looks slightly different, so nothing is reproducible.
• Developers wait on the platform team for routine things like a database or a secret.
• Onboarding a new engineer to ship to production takes weeks, not days.

VBuild vs buy: Backstage vs commercial platforms

Once you need an IDP, the next choice is whether to build the portal on Backstage or buy a commercial platform.

Backstage, open-sourced by Spotify and now a CNCF project, gives you a service catalog, software templates, TechDocs and a large plugin ecosystem, with full control and no per-seat cost. It is also a real engineering project: a Node and React application you host, extend with plugins, integrate with AWS and keep upgraded.

Commercial platforms such as Port, Cortex, Humanitec and OpsLevel give you a hosted portal, catalog, scorecards and self-service actions, configured rather than coded. You pay per seat or per platform and work inside their model.

The choice is mostly about where you spend senior platform-engineering time. Most early and mid-stage startups are better served buying or partnering for the first version and revisiting "build" once platform engineering is a staffed function.

VIA reference IDP architecture on AWS

A portal at the top, golden-path templates that fan out into infrastructure code and CI/CD, a multi-account AWS foundation underneath, and observability through all of it.

The foundation is an AWS landing zone: Control Tower with Organizations, separate production, staging and sandbox accounts, IAM Identity Center for access, and Service Control Policies as outer guardrails. Most platforms standardize on one runtime so the golden path is singular: ECS on Fargate as the lower-effort default, or EKS (often with Argo CD) when you want the Kubernetes ecosystem.

A template generates the repo, a pipeline wired to build and deploy, and calls to versioned infrastructure modules (ECS service or EKS workload, load balancer target group, database, IAM roles, secrets). The same modules back every service, so consistency is structural.

VIIA rollout roadmap that does not stall

Many IDP projects try to do everything at once and ship nothing developers want. Treat it like a product launch: one great golden path, adopted by a real team, before a second one exists.

• Phase 0: discovery: Map how services get built and shipped today, find the workflow that hurts most, pick a pilot team, and decide build vs buy.
• Phase 1: one golden path: Ship one end-to-end paved road, for example "new HTTP service on ECS Fargate": template, repo, pipeline, staging and production through infrastructure code, logs and a dashboard. Make it better than doing it by hand.
• Phase 2: widen the paths: Add the next two or three most-requested paths (a worker, a cron job, a database-backed service), preview environments, and self-service for what used to be tickets. Onboard more teams and track adoption.
• Phase 3: productize: Scorecards ("every service has an owner, alerts and a runbook"), policy as code, better docs, and a roadmap driven by feedback.

VIIIHow CloudRoute gets your IDP built

You need an IDP because your senior engineers are overloaded, but building one takes senior engineers. CloudRoute matches you with one vetted AWS partner that has built internal developer platforms before and brings templates, modules and a reference architecture.

• You tell us your team size, stack and what hurts.
• We reply within 24 hours and match you with one vetted AWS partner with platform-engineering work that fits your runtime (ECS or EKS), region and Backstage-or-commercial preference. The partner reaches out within 5 business days.
• The partner runs discovery, agrees a phased rollout (one golden path first), and builds it.

You pay the partner for the platform build at its rates. If part of the work is a migration to AWS, a proof of concept, or a new workload on AWS (for example the platform for a new product), your matched partner can file MAP, POC or incremental workload (IW) funding when it qualifies and AWS approves.

For startups, partner-filed funding is typically $50K to $150K. Depends on the workload; AWS approves. AWS Activate credits are separate: you apply for them yourself, and they pay AWS usage, not partner fees. CloudRoute is free for startups. Partners pay CloudRoute a monthly membership plus 10% of AWS-approved funding.