Cost Optimisation Strategies for Platform Engineering Teams

Platform engineering promises to accelerate delivery and reduce complexity, but if not approached deliberately, it can quickly become a cost sink.

Why? Too often, teams over-provision resources, duplicate capabilities, and adopt managed services that silently drive costs up in the quest to fulfil that promise. 

In an era of tighter budgets and higher expectations, platform teams are under pressure to show the business value of their platforms. They are being asked a tricky question: What’s the ROI of your platform?

It’s no longer enough to “just” improve developer experience. That experience has to come with financial discipline and cost-efficient platform engineering. 

The December 2023 CNCF FinOps Microsurvey revealed that Kubernetes has driven up cloud spend for nearly half (49%) of those surveyed. Now, with AI taking the world by storm in the past year and platform teams implementing AI capabilities, what would the following report say?

This article examines the hidden costs in platform engineering and explores cost-optimisation strategies to maintain a lean approach without compromising innovation.

The hidden costs of internal developer platforms

In the early stages of the platform, it is lean. Teams move fast, adoption grows, and the value is obvious.

However, as the platform matures, costs begin to emerge in ways nobody had planned for. And in most cases, it is due to decisions made early on in the platform journey.

Let’s unpack three major hidden costs:

Portal-first platforms can be deceptively expensive

Teams often start by building or buying a developer portal to improve discoverability and self-service.

But here’s the trap: a portal is only as valuable as what it surfaces. And to make it actually useful, you’ll likely need to integrate five or more additional tools:

• GitOps engine

• Secrets manager

• CI/CD tooling

• Policy as code

• Audit/logging layer

Each of these tools introduces operational, financial, and maintenance overhead.

Before you know it, you’re not just managing a portal, you’re managing a full-blown ecosystem that’s still missing a platform orchestrator. And the cost (both in cloud spend and engineering effort) snowballs.

Over-provisioning: The silent budget killer

We’ve all been guilty of over-provisioning before. Over-provisioning is not peculiar to platform engineering. Most of the time, we default to generous resource requests “just to be safe.”

And in the early days of a platform, it works. The cost feels negligible. The focus is on unblocking teams and delivering features fast.

But that convenience compounds into cost.

Platforms solve the infrastructure access and request challenge. Speed is no longer the problem.

But speed alone at scale is not enough. Accountability is required because infrastructure that is provisioned without management becomes fragile, expensive, and opaque.

The moment infrastructure can be requested by anyone, anytime, without governance or feedback, your cloud estate becomes a black hole for budget.

Duplicate services across teams

Shadow IT is not a new challenge in software development. If developers don’t trust the platform enough to use it or service discoverability is limited, they will find a way to achieve their goals. 

Additionally, in cases where there is no collaboration between the platform team and specialist teams (e.g., observability team), existing processes can be duplicated on the platform. 

These duplications not only drive up costs but also create maintenance burdens and inconsistent developer experiences, which defeats the very purpose of a centralised platform.

Now, how would you tackle these hidden costs? The following are three strategies:

Strategy 1: Start with or trim what you have

If you are just starting out building your platform, congratulations!! This marks the beginning of an exciting journey with significant potential for value addition to your organisation. But like any transformation, it’s easy to get caught up in building from scratch.

Before you spin up new compute resources or subscribe to new services, remember your organisation has been running on existing compute and services before now. Pause and ask:

• What do we already have that can be reused or extended?

• Underutilised compute environments? Approved tooling? Internal services?

Suppose you’ve been in this business for at least a day. In that case, you’ve likely seen platform teams provision separate Kubernetes clusters for every development team in the name of autonomy or isolation. 

While this might be a core requirement for some organisations, it's not for most. This approach can quickly become costly.

A minimal AWS EKS cluster, for example, costs around $164/month in compute and control plane fees. Multiply that by six teams, for example, and you’re looking at nearly $12,000 per year, just in baseline infrastructure before adding storage, observability, or support overhead.

With Kubernetes cost optimisation in mind, a smarter and more scalable approach is to run a shared, highly available EKS cluster and assign isolated namespaces to each team.

With proper RBAC, resource quotas, and policy enforcement tools like OPA Gatekeeper or Kyverno, teams still retain autonomy, while the platform team manages only one cluster. This shared model reduces annual spend on cost, operations, visibility, and governance.

Sometimes, the most impactful thing a platform team can do isn’t build something new; it’s extend what already works. 

Strategy 2: Use and manage managed services

Managed services are one hidden cost I didn’t mention earlier in this article. Some engineers can swear that the most significant cost in managed services is “compute,” while others will say it is “storage/data.” Regardless of which you think it is, they need to be managed. 

This is not to say that you shouldn’t use managed services. At Syntasso, we encourage organisations to continue pushing towards higher abstractions and removing custom solutions that can be substituted for commodity options available from third-party providers. 

There is no need to reinvent the wheel, especially when no compliance or governance requirements are in place. 

The most efficient organisations are constantly on the lookout for where their custom solutions are no longer a differentiator. Instead, they are dragging their team down with high maintenance and high cost when a commodity service can be substituted from the industry.

As you push for higher abstractions, it's critical to remove unused features in your platform to avoid bloat over time. 

The goal is to keep your platform "thin," meaning it remains minimal but powerful, offering just enough to support your teams while avoiding unnecessary complexity and cost.

Strategy 3: Design for composability to avoid bloat

In the last strategy, we discussed removing unused features of the platform to prevent bloat over time. In reality, it is easier said than done. Especially when platform features have intertwined dependencies. This results in platform teams leaving unused features running. 

An internal developer platform must be composable not only because of its platform engineering cost management, but also because it enables co-creation with developers that increases platform adoption. 

You can do so by providing sane defaults with base manifests that teams can customise using patterns like Kustomize overlays. As your platform evolves, you can introduce CRDs for provisioning external resources, for example, using Crossplane to create an S3 bucket when requested through Backstage.

But as always, don’t reinvent the wheel. Platform engineering frameworks like Kratix enable the creation of Promises (contracts between your platform and your development teams), so you don’t need to create a new CRD or deploy an operator every time. 

Each Promise defines exactly what your platform provides as-a-service, and can be combined with another promise to create Compound Promises. With this approach, you can create entire stacks on demand via your platform, leveraging institutional knowledge.

An example of a Compound Promise

The above Compound Promise has dependencies of two Promises, knative and postgres, that it uses to offer a platform service to developers. The two Promises designed based on institutional knowledge can be reused across the entire platform, saving time and ensuring continuous compliance.

Build visibility and cost awareness into the culture

Ultimately, cost optimisation isn’t a one-time cleanup; it’s a cultural discipline. Platform teams must implement observability and reuse into every layer of the platform. 

From limiting resource sprawl to eliminating duplicated tooling, these practices ensure your platform not only scales technically but also economically.

Internal developer platforms that are thin, composable, and co-created with developers using frameworks like Kratix don’t just improve experience; they maximise ROI.