Kubernetes Cost Anomaly Detection: Catch Spikes Early
How to detect Kubernetes cost anomalies early, investigate spend spikes, and stop budget surprises before they hit the bill.
Internal Developer Platform (IDP)
Internal Developer Platform for Kubernetes & cloud infrastructure
Atmosly automates Kubernetes deployments, cloud infrastructure provisioning, CI/CD and environment management in one platform — so developers self-serve on golden paths and the platform team sets the guardrails once.
- ✓ Developer self-service infrastructure
- ✓ RBAC & policy-as-code guardrails
- ✓ Any Kubernetes — cloud or self-hosted
Running an enterprise rollout? Book a demo →
AI Kubernetes operations
CI/CD & environment management
Infrastructure provisioning & governance
What's included in the platform
✓Any Kubernetes (EKS · GKE · AKS · self-hosted)
✓GitOps
✓CI/CD pipelines
✓Terraform-based provisioning
✓Self-service infrastructure
✓Environment cloning
✓RBAC & audit trails
✓Policy as code
✓Cost optimization
✓AI SRE & remediation
The platform
One control plane for every cluster you already run
Clusters, deploys, integrations, security posture and cost in a single view — the platform reads your existing Kubernetes estate read-only, so this is populated on day one without changing anything.
Atmosly
Workspace
DashboardClustersApplication blueprintsEnvironmentsPipelinesCloud resources
Observability
SecurityMarketplaceAuditGuardrail
Dashboard
Here's what's happening across your 4 clusters.
Active clusters
4
Critical alerts
5
Deploys (recent)
13
Identified savings / mo
$339
Clusters4 connected · EKS · GKE
payments-prodap-south-1 · default
nodes7
CPU15%
MEM59%
$239/mo
web-gke-euus-central1-a · default
nodes2
CPU15%
MEM45%
$337/mo
checkout-stagingus-east-1 · default
nodes6
CPU11%
MEM47%
$442/mo
platform-non-prodap-south-1 · non-prod
nodes1
CPU8%
MEM36%
$108/mo
Integrations53/53 connected
AWS
prod-paymentsasia-south2
14m agoAWS
prod-webasia-south1
14m agoAWS
data-platformus-west-1
14m agoGCP
analytics-prodeurope-west1
14m agoGCP
sandboxus-central1
14m agoCluster security healthcompliance scan · CIS · PCI DSS · SOC 2
Org-wide scoreAcross 4 clusters
0Critical
30High
79Medium
9Low
Atmosly dashboard. Cluster names, cloud account identifiers and regions anonymised for this page.
Definition
What is an internal developer platform?
An internal developer platform (IDP) is the self-service layer between developers and infrastructure.
It brings together the tools, automation, workflows and guardrails developers need to build, deploy and operate software without managing the underlying infrastructure themselves.
A good IDP provides self-service environments, application delivery, infrastructure provisioning, observability and operational workflows, while platform teams define the standards, security policies and guardrails behind them.
The goal isn't to hide infrastructure from developers. It's to remove the repetitive complexity around it, so developers can follow proven paths without becoming experts in every underlying tool.
Read the full internal developer platform guide →01
Developer self-service
Give developers the ability to provision environments, deploy applications, and access platform services without waiting on the platform team.
02
Golden paths
Provide opinionated, reusable workflows for common tasks so teams don't have to design infrastructure and deployment processes from scratch.
03
Platform automation
Automate the work behind the developer experience — infrastructure provisioning, deployments, configuration, environment creation, upgrades and lifecycle management. An IDP isn't just a collection of buttons: the automation behind those buttons is what makes it a platform.
04
Guardrails and governance
Enforce RBAC, security policies, approved configurations, secrets management, compliance and cost controls without making developers manage these manually.
05
Developer experience
Give developers a consistent interface and workflow across infrastructure, deployments and environments, hiding unnecessary underlying complexity while keeping the important controls accessible.
The problem
Why platform engineering teams need an internal developer platform
Without a platform layer, infrastructure work concentrates in one team and every developer request becomes a queue. These are the symptoms teams describe before they adopt an IDP.
Developers wait days for infrastructure
A new namespace, a managed database, a test environment — each one is a ticket, a Terraform review and a context switch for someone else. Lead time to production is dominated by waiting, not building.
The platform team becomes a ticket queue
Senior DevOps and SRE engineers spend their week on provisioning requests, access changes and deployment babysitting instead of the automation that would remove the requests.
Every deployment needs a DevOps engineer
Kubernetes manifests, Helm values, pipeline YAML and rollout strategy live in a handful of heads. Nobody else can ship confidently, and nobody can ship on a Friday.
Environments are created by hand
Staging drifts from production, preview environments are too expensive to keep, and reproducing a bug means recreating a stack from memory and a stale README.
Cloud governance is inconsistent
Each team wires RBAC, secrets, network policy and tagging its own way. Security posture is discovered during an audit rather than enforced at provisioning time.
Cloud spend grows faster than traffic
Over-provisioned requests and limits, idle node groups and forgotten environments accumulate because no single system sees allocation, utilization and ownership together.
Platform architecture
Internal developer platform features
Three layers on one control plane: infrastructure provisioning, application delivery and Kubernetes operations. Each one is a working capability — not an integration point you have to implement, staff and maintain.
Layer 01 — Provision
Self-service infrastructure provisioning inside guardrails
Import any Kubernetes cluster — EKS, GKE, AKS, DigitalOcean, Linode or self-hosted, including private clusters whose endpoints are not exposed to external traffic — then let developers request clusters, node groups, managed databases, caches and add-ons from curated infrastructure blueprints. Every provisioning action is scoped by RBAC, checked against policy-as-code, audited and reversible, so self-service infrastructure never becomes an unbounded cloud bill.
- Kubernetes clusters, cloud resources & add-ons from reusable blueprints
- Curated Helm marketplace — versioned, deployed and tracked per cluster
- Approval gates, scoped RBAC and audit trail on every infrastructure action
- Integrates with your secret manager — AWS Secrets Manager and Google Secret Manager today, HashiCorp Vault support coming
postgres-15 · managed database
team: payments · policy passed
redis-cache · blueprint
team: growth · policy passed
gpu-node-group · eks
approval gate · platform team
blueprint
build
deploy
promote
clone: production → preview-417
full environment · isolated namespace
workload → deployment blueprint
existing service · nothing rebuilt
Layer 02 — Deploy
CI/CD, GitOps and environment management
Turn any running Kubernetes workload into a reusable deployment blueprint, ship it through visual or GitOps pipelines with one-click rollback, and clone an entire environment — workloads, config, dependencies — for previews and per-tenant stacks on demand. Developers get a paved road from commit to production instead of a blank pipeline file.
- Workload → blueprint → continuous delivery, with no pipelines to rebuild
- On-demand preview and per-tenant environments cloned from production
- Visual pipeline builder plus Git-driven GitOps deployment and rollback
- Environment promotion, post-deploy hooks and scheduled deployment windows
Layer 03 — Operate
AI-powered Kubernetes operations, security and cost
Astra, our AI SRE agent, detects incidents, performs root cause analysis and proposes automated remediation. Continuous scanning keeps CIS Benchmark, PCI DSS and SOC 2 posture current and catches configuration drift live. Cost intelligence attributes Kubernetes spend by team, namespace and service and recommends right-sizing. This is the layer a developer portal cannot provide — the platform acts on what it observes.
- AI incident investigation, root cause analysis and reversible remediation
- Continuous Kubernetes security posture: CIS · PCI DSS · SOC 2 · drift detection
- Kubernetes cost optimization, right-sizing and showback by team
- Idle resource cleanup and utilization-based recommendations, not static alerts
api · CrashLoopBackOff
AI SRE · OOMKilled · remediation proposed
security · CIS drift detected
2 controls · remediation queued
cost · right-sizing applied
requests & limits · platform-wide
Category comparison
Internal developer platform vs internal developer portal
The two terms get used interchangeably, and it costs teams entire quarters. A portal is a catalog and a user interface. A platform is the execution layer that provisions infrastructure and deploys applications. You need the second one to remove work.
| Capability | Developer portalA catalog and UI over your tools | Developer platformThe execution layer, working out of the box |
|---|---|---|
| Service catalog & ownership | Aggregates service metadata, owners, docs and scorecards. | Inventory of every workload, cluster and environment it operates. |
| Infrastructure provisioning | Self-service actions call Terraform modules and pipelines you write and maintain. | Provisions EKS and GKE clusters, node groups, managed databases and add-ons — and imports any conformant cluster you already run: AKS, DigitalOcean, Linode, on-prem or self-hosted. |
| Application delivery | Triggers the CI system you built; the pipeline logic stays yours. | CI/CD and GitOps pipelines with environment promotion and one-click rollback. |
| Environment management | Not in scope — links out to whatever creates environments. | Clones full environments on demand for previews and per-tenant stacks. |
| Day-2 operations | Reports what is deployed and what broke. It does not remediate. | AI root cause analysis, automated remediation, security posture and cost optimization. |
| Onboarding an existing service | Register it in the catalog, then build the plugin that acts on it. | Reads a running workload and turns it into a reusable deployment blueprint. |
| Cost to stand up | 4–6 platform engineers and roughly a year of plugin work, then permanent upkeep. | Import a cluster read-only; first golden path running the same week. |
| Typically | Backstage · Port · Cortex | Atmosly |
Already invested in a portal? Atmosly coexists with Backstage or Port — the portal stays the front door and software catalog while Atmosly executes provisioning, deployment and operations behind it.
Implementation
How teams use Atmosly as their Kubernetes developer platform
Four common implementations of developer self-service — all on standard Kubernetes, Helm and GitOps, on the clusters you already run.
No rebuild requiredExisting workloads become blueprints as-is.
Read-only to startImport a cluster before anything is changed.
01
Self-service environments for every pull request
Clone a full production-shaped environment per branch — workloads, dependencies and configuration — so reviewers test against a real stack instead of a shared staging tier. Environments expire automatically, so preview infrastructure never becomes permanent cloud spend.
02
Standardizing delivery across many teams
Capture the deployment pattern your best-run service already uses as a workload blueprint, then make it the golden path other teams deploy on. New services inherit pipeline, probes, resource policy and rollback behaviour by default — nobody starts from an empty YAML file.
03
Per-tenant infrastructure for SaaS
Provision an isolated environment, database and namespace per customer from one blueprint, with cost attributed per tenant and policy applied identically to each. Onboarding a new tenant stops being a bespoke script someone has to remember to run.
04
Governed platform engineering at enterprise scale
Give business units self-service inside scoped RBAC and approval gates, with SSO, continuous CIS, PCI DSS and SOC 2 posture, drift detection and audit evidence collected as a by-product of normal operation — not assembled the week before a review.
Benefits & build vs buy
Benefits of an internal developer platform — without a year of platform work
Building a usable IDP in-house means staffing a platform engineering team and waiting roughly a year for golden paths, then maintaining the portal, plugins and Terraform modules forever. Atmosly delivers the same developer self-service and infrastructure governance on the Kubernetes clusters you already run.
4–6 eng
to build and staff a DIY internal developer platform
~12 mo
before developers see real self-service golden paths
Any cluster
Provisions EKS & GKE — imports AKS, DigitalOcean, Linode and self-hosted Kubernetes
Day one
self-service provisioning and deployment on your existing cluster
Shorter lead time to production
Developers provision infrastructure and deploy applications themselves on golden paths, so time from commit to production stops being dominated by waiting on another team.
Fewer DevOps tickets
Environment requests, access changes and routine deployments move to self-service inside guardrails — the platform team returns to automation instead of queue duty.
Consistent governance and spend
One place where RBAC, policy-as-code, security posture and cost attribution apply to every team, cluster and cloud — instead of six teams doing it six ways.
Questions
Internal developer platform FAQs
What is an internal developer platform (IDP)?
An internal developer platform is the self-service layer between developers and infrastructure. It gives engineers golden paths to provision environments, ship code, and run services on their own, while the platform team encodes the standards, security, and guardrails centrally. The goal is developer autonomy without every request becoming a ticket.
What's the difference between a portal IDP and an execution IDP?
A portal IDP — such as Backstage, Port, or Cortex — is a catalog and dashboard that sits on top of other tools and visualizes them. It shows you things but still relies on the pipelines, scripts, and operators you build and maintain. An execution IDP like Atmosly does the work itself: it provisions, ships, and runs your clusters directly, so the platform is the thing operating, not a front door to a stack you still have to assemble.
Is Atmosly an alternative to Backstage or Port?
Yes, for teams that want the platform to actually run things rather than just catalog them. Backstage and Port are portals you staff and build behind; Atmosly ships with the execution layer — CI/CD, environment cloning, provisioning, AI SRE, security, and cost — already working. It can also coexist: Atmosly powers the workflows while a portal stays the front door.
How does Atmosly compare to Port and Humanitec?
Port is a portal and software catalog with self-service actions and scorecards; the actions call pipelines and infrastructure-as-code you own and maintain. Humanitec is a platform orchestrator focused on workload deployment and resource definitions, usually combined with a separate portal and your own CI. Atmosly covers the full path in one platform — provisioning cloud infrastructure, deploying Kubernetes workloads through GitOps and CI/CD, cloning environments, enforcing policy-as-code, and running clusters with AI-assisted operations, security and cost intelligence.
Should we build or buy an internal developer platform?
Building a usable IDP in-house typically means a dedicated platform team and roughly a year before developers see golden paths — then it becomes a permanent cost center to maintain. Buying gives you the same self-service and governance in days, on the clusters you already run, and frees your engineers to work on the product. Atmosly is built for the buy path: import a cluster read-only and adopt capabilities at your own pace.
Do we need a platform team to run an IDP on Atmosly?
No. Atmosly delivers the operations, delivery, and provisioning a platform team would build, as software you can set up yourself. Smaller teams run it without a dedicated platform hire; larger teams use it to scale a small platform team across many clusters instead of growing headcount at the same rate.
Does an IDP replace our existing CI/CD and tools?
It doesn't require ripping anything out. Atmosly runs on standard Kubernetes, GitOps, and Helm and can ingest what you already have — it reads a running workload and turns it into a deployable blueprint, so nothing gets rebuilt. You add the platform alongside your stack and adopt it workload by workload.
Which clouds and Kubernetes distributions does Atmosly support?
Atmosly provisions EKS and GKE clusters natively, and imports any conformant Kubernetes cluster you already run — AKS, DigitalOcean, Linode, on-prem or self-hosted. That includes private clusters whose endpoints are not exposed to external traffic: an outbound in-cluster agent connects them, with no inbound ports. It runs on standard Kubernetes primitives, Helm and GitOps, and provisions cloud resources such as managed databases, caches, node groups and add-ons alongside your workloads.
What's the difference between an internal developer platform and a PaaS?
A PaaS (like Heroku or Cloud Run) abstracts the infrastructure away entirely — you give it code, it runs it, and you give up control of the underlying platform. An internal developer platform keeps you on your own Kubernetes and cloud, but adds the self-service layer and golden paths on top, so you get developer convenience without losing portability, governance, or cost control. We cover this in depth in Internal Developer Platform vs PaaS.
What are golden paths in an internal developer platform?
A golden path is a paved, opinionated route from code to production that the platform team blesses — the supported way to provision an environment, ship a service, or clone a stack. Developers follow it self-service instead of inventing their own setup, and the standards, security, and guardrails are baked in. See Golden Paths in Platform Engineering for the full pattern.
How does an IDP enforce security and governance?
Governance is encoded once by the platform team and applied to every self-service action: scoped RBAC per team and environment, policy-as-code on what developers can provision, approval gates on sensitive resources, secrets management, full audit trails, and continuous Kubernetes security posture checks against CIS Benchmarks, PCI DSS and SOC 2 controls with drift detection.
What should an internal developer platform include?
At minimum, self-service provisioning, a paved code-to-production path, and centralized guardrails. An execution IDP like Atmosly goes further and includes the running of it too: cluster and cloud-resource provisioning, CI/CD and environment cloning, an AI SRE for operations, continuous security posture, and cost intelligence — all under one control plane, so the platform operates the stack rather than just cataloging it.
How long does it take to set up an IDP with Atmosly?
Minutes to first value, not months. You connect an existing cluster read-only and immediately see Atmosly work on your own workloads — versus the roughly 12 months and 4–6 engineers a DIY platform typically takes to reach golden paths. You then adopt capabilities at your own pace, workload by workload, with nothing to rip out.
From the blog
View all posts →
The latest on platform engineering
Kubernetes
AI SREPagerDuty for Kubernetes: Why Detection-to-Page Is Only Half the Loop
PagerDuty solves getting the right human awake. It does not solve what that human does next, which is where nearly all incident time goes. This covers the split between routing and diagnosis, what actually belongs in each layer, and why replacing your pager is the wrong move.
AI SREKubernetes Postmortem Template (And How to Auto-Capture the Evidence)
Half the evidence a Kubernetes postmortem needs is gone within an hour of the incident. Here is a template you can copy, the commands that capture the perishable data while it still exists, and the rewrite rule that keeps causes blameless.
Stop building the platform. Start shipping on one.
Connect a Kubernetes cluster read-only and see the internal developer platform work on your own workloads — provisioning, deployment and operations, in minutes. Free, no sales call.