Backstage, Port, Cortex, and AWS Service Catalog: Different Tools, Different Control Planes

The fastest way to waste a platform engineering budget is to buy a portal when the real missing system is a control plane.

Situation

Platform engineering has become the operational answer to a familiar failure: every team needs infrastructure, delivery pipelines, ownership metadata, runtime visibility, documentation, and compliance evidence, but no one wants every service team to rebuild that machinery from scratch.

That pressure creates a crowded category. Backstage, Port, Cortex, and AWS Service Catalog are often discussed as if they are interchangeable developer portals. They are not. They sit at different points in the platform stack, encode different opinions about ownership, and automate different parts of the engineering lifecycle.

A developer portal is only the visible surface. The more important question is what system owns the desired state. Does it own software metadata? Golden path templates? Production readiness standards? Cloud product provisioning? Workflow execution? Compliance constraints?

Those answers determine whether the tool becomes a useful abstraction or another dashboard that teams stop trusting.

The Problem

Most platform programs start with a reasonable goal: make the paved road easier than the unpaved road. Then the backlog expands.

Application teams want service creation. Security wants evidence. Infrastructure wants standard AWS accounts, VPCs, databases, and IAM boundaries. Engineering leadership wants ownership, maturity, and reliability scorecards. Operations wants runbooks and service metadata. Developers want a single place to find the thing they need without filing a ticket.

One tool rarely owns all of that cleanly.

Backstage can give you an extensible internal developer portal, but it is a framework that your platform team must operate and extend. Port gives you a configurable catalog and self-service model, but its power depends on whether you model your platform domain well. Cortex is strong when the problem is service ownership, standards, and engineering quality, but it is not the same thing as a cloud provisioning product catalog. AWS Service Catalog can enforce approved infrastructure products inside AWS, but it is not a broad engineering portal by itself.

The failure mode is category confusion. Teams select based on screenshots, then discover they actually needed a different control plane.

The core question is: which system should own the workflow, and which systems should only project state from somewhere else?

Four Control Planes, Not One Portal

The clean way to compare these tools is by the control plane they imply.

flowchart TD
    A[platform need — reduce local reinvention] --> B[developer portal — discovery and entry points]
    A --> C[service catalog — ownership and metadata]
    A --> D[standards engine — scorecards and maturity]
    A --> E[cloud product catalog — governed provisioning]

    B --> F[Backstage — extensible portal framework]
    C --> G[Port — configurable software catalog and actions]
    D --> H[Cortex — service ownership and scorecards]
    E --> I[AWS Service Catalog — portfolios products constraints]

    F --> J[Git and plugins — implementation owned by platform team]
    G --> K[blueprints and actions — domain model driven workflows]
    H --> L[readiness rules — quality and operational standards]
    I --> M[CloudFormation products — approved AWS provisioning]

Backstage is best understood as a portal framework. Its center of gravity is composition: catalog entities, plugins, software templates, TechDocs, and integrations. It works well when the platform team wants to build a tailored developer experience and is willing to own the engineering effort behind that experience. Backstage is not a magic control plane. It becomes one only when connected to systems that can actually create, modify, and verify infrastructure or software state.

Port is closer to a configurable internal developer portal with an explicit domain model. The important primitive is the blueprint: teams define what kinds of entities matter, how they relate, and which actions developers can run against them. That makes Port attractive when the organization wants a flexible catalog over services, environments, resources, incidents, deployments, and approvals without building every portal primitive from source.

Cortex is strongest when the control plane is engineering standards. Its catalog, ownership model, scorecards, and production readiness workflows are aimed at answering questions such as: who owns this service, does it meet the reliability bar, is it missing runbooks, are dependencies visible, and which teams need to remediate risk? Cortex is less about provisioning the next database and more about making service quality measurable and accountable.

AWS Service Catalog is a different beast. It is a governed cloud provisioning control plane for AWS products. Administrators define portfolios, products, versions, launch constraints, and access rules. Developers or accounts consume approved products instead of hand-rolling unmanaged infrastructure. Its abstraction boundary is AWS governance, not the full software delivery lifecycle.

The architectural mistake is asking one of these systems to impersonate the others.

If Backstage is your front door, it may still call Port actions, Cortex scorecards, or AWS Service Catalog products behind the scenes. If Port is your primary portal, it may still synchronize service metadata from Git and expose AWS provisioning workflows. If Cortex is your engineering standards system, it may ingest catalog data and push teams toward remediation workflows elsewhere. If AWS Service Catalog governs infrastructure products, it may remain invisible behind a higher-level self-service flow.

The platform architecture should make that explicit.

In Practice

Context. Backstage documents its software catalog around entities such as components, APIs, resources, systems, groups, and users, commonly registered through catalog metadata files. TechDocs is documented as a docs-like-code system built into Backstage. The pattern is a portal that aggregates software knowledge and developer workflows around catalog entities, not a standalone infrastructure orchestrator. See the Backstage documentation for the Software Catalog and TechDocs.

Action. Use Backstage when you want an extensible portal shell and your platform team can maintain plugins, templates, authentication, catalog ingestion, and integration code. Keep the true source of infrastructure state in Git, CI systems, cloud APIs, or an IaC control plane. Let Backstage initiate workflows, but do not pretend the portal UI itself is the durable state machine.

Result. The result is a coherent developer entry point with custom fit. The tradeoff is operational ownership: the same extensibility that makes Backstage powerful also means the platform team owns upgrades, plugin compatibility, authorization decisions, and workflow glue.

Learning. Backstage is the right default when portal composition is the differentiator. It is the wrong default when the organization primarily needs a managed scorecard system or governed AWS product provisioning.

Context. Port documents its catalog around blueprints, entities, relations, scorecards, and self-service actions. That is a domain-model-first pattern: define the objects your platform cares about, then attach views, automation, and standards to those objects. See Port’s documentation for software catalog concepts and blueprints.

Action. Use Port when the main job is to model a platform domain across services, resources, environments, deployments, and ownership boundaries, then expose governed actions over that model. Treat blueprint design as architecture, not administration. A vague model produces a vague portal.

Result. The result is faster self-service over a catalog that can reflect more than code repositories. The risk is schema drift: if every team invents different entity types and action semantics, the portal becomes searchable clutter rather than an operating model.

Learning. Port works best when the platform team has a clear ontology for the engineering system.

Context. Cortex documents its product around catalogs, scorecards, ownership, engineering intelligence, and workflows. The documented pattern is continuous visibility into services and standards rather than cloud-native product launch alone. See the Cortex documentation.

Action. Use Cortex when the organization needs service ownership, maturity tracking, production readiness, and scorecard-driven remediation. Connect it to source control, incident systems, observability, and deployment metadata so standards are evaluated against real system behavior.

Result. The result is an accountability layer over engineering quality. The limitation is scope: a scorecard can expose that a service lacks a runbook or SLO, but another system still has to create, review, deploy, or enforce the fix.

Learning. Cortex is strongest as the standards control plane.

Context. AWS Service Catalog documents portfolios, products, constraints, and approved provisioning paths for AWS resources. AWS also documents multi-account and multi-region patterns using portfolios and StackSet constraints. See the AWS documentation for AWS Service Catalog and AWS Prescriptive Guidance for multi-account Service Catalog products.

Action. Use AWS Service Catalog when the platform needs approved AWS products with administrative control over who can launch what, under which constraints, and in which accounts or regions.

Result. The result is stronger cloud governance for repeatable AWS infrastructure. The tradeoff is boundary: it governs AWS product consumption, not the whole developer experience across docs, service health, ownership, and delivery standards.

Learning. AWS Service Catalog belongs near the cloud governance layer, even when launched through a higher-level portal.

Where It Breaks

Tool	Best Control Plane	Where It Fits	Where It Breaks
Backstage	Portal composition	Custom developer portal, plugins, docs, templates	Requires platform engineering ownership and integration work
Port	Catalog and actions	Flexible domain model, self-service workflows, relations	Weak model design turns into weak automation
Cortex	Standards and ownership	Scorecards, readiness, service quality, accountability	Does not replace provisioning or deployment systems
AWS Service Catalog	AWS provisioning governance	Approved cloud products, portfolios, constraints	Narrower than a full developer portal

The practical architecture is often layered. A company might use Backstage as the front door, Cortex as the standards engine, AWS Service Catalog as the governed AWS product launcher, and GitHub Actions or Terraform Cloud as the execution layer. Another company might use Port as the main portal and avoid building Backstage plugins entirely. A smaller team might need only Cortex for ownership and scorecards, because their provisioning flow is already standardized.

The decision should start with the broken workflow, not the tool category.

What to Do Next

• Problem: Developers cannot find services, docs, owners, APIs, and runbooks.
  Solution: Start with a portal and catalog strategy. Backstage is appropriate when customization matters; Port is appropriate when managed catalog modeling and actions matter.
  Proof: Measure search success, catalog coverage, ownership completeness, and stale metadata rate.
  Action: Define the minimum entity model before selecting plugins or templates.

• Problem: Teams create services that miss reliability, security, or operational standards.
  Solution: Add a standards control plane. Cortex is purpose-built for scorecards and service maturity; Port can also express scorecards if the catalog model is central.
  Proof: Track scorecard adoption, exemption volume, remediation time, and incident findings tied to missing controls.
  Action: Write five non-negotiable readiness checks before writing fifty nice-to-have checks.

• Problem: Cloud resources are provisioned inconsistently across AWS accounts.
  Solution: Use AWS Service Catalog or another IaC-backed provisioning control plane to expose approved products.
  Proof: Compare unmanaged resource creation, policy violations, account drift, and provisioning lead time.
  Action: Start with one high-volume product such as a standard database, queue, or service account baseline.

• Problem: The platform team is debating tools without knowing the source of truth.
  Solution: Draw the control planes first: portal, catalog, standards, workflow execution, and cloud provisioning.
  Proof: Every workflow should have one durable owner for desired state and clear integrations for projected state.
  Action: Choose the tool that owns the most painful control plane, then integrate the rest deliberately.