Ask most AWS engineering teams what slows them down, and you'll hear the same answers: waiting for infrastructure to be provisioned, hunting down the right Terraform module, trying to work out who owns a service, or simply not knowing where to start when spinning up a new workload. These aren't technical problems — they're organisational ones. And they compound silently, week after week, until engineers spend more time navigating internal bureaucracy than writing code.
The answer isn't more documentation or a stricter ticketing process. It's a developer self-service platform — and for teams running on AWS, Backstage and Crossplane together offer a compelling, production-tested foundation.
What Problem Are We Actually Solving?
Before reaching for a tool, it's worth being precise about the problem. The core issue in most AWS-heavy organisations is that platform teams and development teams are poorly coupled. Platform teams gate infrastructure provisioning through tickets or Confluence pages. Development teams waste time on undifferentiated work. The result: slow delivery, frustrated engineers, and platform teams drowning in repetitive requests.
A self-service developer portal changes this dynamic. Instead of raising a ticket to get an RDS instance or an S3 bucket with the right tags and IAM policies, developers interact with a curated catalogue of golden paths — pre-approved, pre-secured, pre-compliant infrastructure templates that they can invoke themselves. The platform team stops being a bottleneck and becomes an enabler.
Backstage: The Developer Portal Layer
Backstage, originally built by Spotify and now a CNCF-incubated project, provides the frontend experience for a developer portal. It gives you a software catalogue, a component discovery layer, and a plugin system that can surface almost anything your organisation needs — runbooks, CI/CD pipelines, cost data, on-call rotas, API documentation.
For AWS teams, the Backstage software catalogue becomes a single source of truth for every service, data pipeline, Lambda function, and ECS workload in the estate. Engineers can see what's deployed, who owns it, what its SLOs are, and how to contribute to it — without wading through AWS Console tabs or digging through Terraform state files.
Backstage's scaffolder plugin is where self-service really comes to life. You define software templates — think "create a new Node.js microservice on ECS with an RDS database, a CodePipeline, and Datadog monitoring" — and developers can provision the entire thing from a form in the UI. The scaffolder runs the template, creates the Git repository, opens a pull request, and triggers the pipeline. All within guardrails your platform team has defined.
Critically, Backstage doesn't do infrastructure provisioning itself. It orchestrates requests and surfaces information. For the actual provisioning, you need something underneath it — and that's where Crossplane enters.
Crossplane: Infrastructure as Code, the Kubernetes-Native Way
Crossplane extends Kubernetes with Custom Resource Definitions (CRDs) that represent cloud infrastructure. Instead of running Terraform pipelines, you declare an RDS instance or an EKS cluster as a Kubernetes manifest, and Crossplane's AWS provider reconciles that declaration against the real AWS estate — continuously, not just at apply time.
This matters for a few reasons. First, drift detection is built in. If someone manually changes a security group in the Console, Crossplane will reconcile it back. Second, the infrastructure lifecycle is tied to the Kubernetes control plane, which means RBAC, audit logging, and GitOps workflows all apply natively. Third, Crossplane supports composite resources — abstractions that hide the complexity of underlying AWS resources behind simpler, opinionated interfaces.
In practice, this means your platform team defines a PostgreSQLInstance composite resource that, under the hood, provisions an RDS instance with the right parameter group, subnet group, KMS encryption, and backup retention — all compliant with your organisation's standards. Developers request a PostgreSQLInstance without needing to understand any of the underlying detail. The abstraction layer is enforced at the API level, not in a wiki page that may or may not be up to date.
Wiring Backstage and Crossplane Together on AWS
The integration pattern looks roughly like this: Backstage scaffolder templates generate Kubernetes manifests (Crossplane claims) that are committed to a GitOps repository. Flux or Argo CD picks up those manifests and applies them to the cluster. Crossplane then reconciles the desired state against AWS, and status is fed back into Backstage via the Kubernetes plugin.
This gives you an end-to-end self-service loop: developer requests infrastructure in Backstage → manifest committed to Git → Crossplane provisions in AWS → status visible in Backstage. No tickets, no waiting, no manual steps. Platform team involvement is limited to maintaining the templates and composite resource definitions — a far more scalable model.
Running this on AWS, you'll typically deploy both Backstage (as a containerised application on ECS or EKS) and the Crossplane control plane (on EKS) within your platform account, with cross-account IAM roles allowing Crossplane to provision resources into workload accounts. Your AWS Landing Zone or Control Tower setup defines the account structure that Crossplane targets.
The Case for Golden Paths Over Golden Cages
One mistake organisations make when building developer portals is treating them as a compliance mechanism — a way to force developers onto approved paths through restriction. This produces resentment and workarounds. Engineers will find ways around a platform that feels like a prison.
The better framing is that golden paths should be the easiest path. If provisioning a compliant, production-ready microservice takes 90 seconds via the portal and three weeks of tickets via the alternative route, developers will use the portal without being told to. The platform wins on convenience, not coercion.
This means the templates need to be genuinely good. They need to include sensible defaults for monitoring, alerting, logging, and tagging. They need to produce infrastructure that developers are proud to own. If the scaffolded output is a mess that engineers immediately rework, the portal hasn't solved anything.
What Mature Platform Engineering Looks Like
Organisations that have invested properly in platform engineering see measurable improvements: reduced time-to-production for new services, fewer security incidents caused by misconfiguration, lower cognitive load on development teams, and platform teams that can scale their impact without scaling their headcount.
The metrics worth tracking are lead time for new service provisioning, developer satisfaction scores, mean time to recovery (MTTR), and the ratio of platform-team to development-team headcount over time. Done well, a strong internal developer platform lets a platform team of five support hundreds of engineers effectively.
How Kineticor Can Help
Building a developer self-service platform is a significant undertaking, and getting the architecture wrong early creates technical debt that's painful to unpick. Common pitfalls include over-engineering the Crossplane composite resources before you understand developer needs, misconfiguring the IAM trust relationships between the platform account and workload accounts, or building a Backstage deployment that becomes a maintenance burden rather than a productivity multiplier.
At Kineticor, we design and implement developer self-service platforms on AWS — from the Backstage software catalogue and scaffolder templates through to Crossplane composite resources and GitOps pipelines. We work within your existing AWS account structure and Landing Zone, and we leave your team in a position to own and extend the platform independently.
If you're ready to stop treating infrastructure requests as tickets and start treating them as a product, get in touch.