The 3 Cloud Leaks Every Kubernetes Bill Hides
Your AWS invoice shows what you spent, never what you wasted. Here are the three Kubernetes cost leaks hiding in every EKS bill — and how to spot them.
Core 02 · CI/CD & Environments
Turn any running workload into a reusable blueprint.
Capture a workload that already runs — spec, config, dependencies — as a versioned, parametrized blueprint. Then let any team self-serve it to any cluster from a golden-path catalog. No rewrite, no copy-pasted YAML.
- ✓ From a live workload
- ✓ Versioned & parametrized
- ✓ Self-serve catalog
01
Inspect
Read a running workload's spec, config & dependencies.
02
Capture
Snapshot it into a versioned blueprint — no hand-written YAML.
03
Parametrize
Expose env, replicas & resources as safe inputs.
04
Reuse
Publish to a catalog — any team, any cluster, self-serve.
How a blueprint is made
From a running service to a self-serve template
1
Inspect
Start from what already runs
Point Atmosly at a live workload. It reads the deployment, services, config, and dependencies as they actually exist — no greenfield manifest required.
- Reads real specs, not idealized templates
- Captures config maps, secrets refs & dependencies
deploy/checkout-apiread
+ svc, configmap, hpa✓
dependencies · 3resolved
2
Capture & version
Snapshot into a versioned blueprint
Atmosly captures the workload as a blueprint with a version. Update the source and cut a new version — every deploy traces back to a known, reviewable definition.
- Versioned — no snowflake one-off manifests
- Diffable history between blueprint versions
blueprint · checkout-apiv3
changed · replicas, limitsvs v2
published✓
3
Parametrize
Expose the knobs that matter — and only those
Decide what's configurable: environment, replicas, resources, image tag. Everything else stays locked to the golden path, so self-serve never means free-for-all.
- Typed inputs with sane defaults & bounds
- Everything else stays on the golden path
input · environmentenum
input · replicas (1–6)default 2
locked · security ctx✓
4
Publish
Drop it in the catalog for self-serve
Publish the blueprint and any team can deploy it to any cluster — through the same guardrails and audit trail as everything else. No ticket, no platform-team bottleneck.
- Self-serve from a catalog — no ticket queue
- Deploys run through guardrails + audit trail
catalog · checkout-api v3live
deployed by · 4 teams✓
targets · 6 clusters✓
What a blueprint gives you
Golden paths, not copy-pasted YAML
The reusable, governed building block that turns one good setup into the standard everyone ships.
Versioned & diffable
Every blueprint carries a version with a readable history. Promote v3, compare it to v2, roll back if you need to — the same discipline as code, for deploys.
checkout-api · v3current
diff vs v2 · replicas, limits2 changes
Parametrized, within bounds
Expose exactly the inputs a team should touch — environment, replicas, resources — with types, defaults, and bounds. Everything else stays locked to the golden path.
replicas (1–6)default 2
security contextlocked
Self-serve catalog
Any team deploys from the catalog without filing a ticket or waiting on the platform team.
Any cluster, any cloud
One blueprint targets EKS, GKE, AKS or on-prem — no per-environment fork.
Guardrails built in
Every self-serve deploy runs through the same policy checks and audit trail as the rest of the platform.
Pairs with the Pipeline Builder
A blueprint is the deployable unit your pipelines promote and your preview environments clone — capture it once, and the rest of the CI/CD core reuses it everywhere.
The payoff
What changes when deploys are blueprints
Any service
becomes deployable CD — no rewrite
Self-serve
teams ship without a platform-team ticket
Versioned
every deploy traces to a reviewable definition
0
copy-pasted snowflake manifests
Same control plane
Workload Blueprints is one of three cores
Capture, ship, and run share one UI, one audit trail, and one permissions model.
Questions
What teams ask about blueprints
How is a blueprint different from a Helm chart?
A blueprint is captured from a workload that already runs, not authored from scratch — so it reflects reality on day one. It carries golden-path defaults, typed inputs with bounds, and the platform's guardrails, and it can wrap Helm charts where you already use them.
Does capturing a blueprint change my running workload?
No. Capture is a read of the live spec — it produces a reusable definition without touching what's running. Changes only happen when someone deploys the blueprint, through the usual guardrails.
Is self-serve safe for non-platform teams?
Yes — that's the point of parametrizing. Teams only touch the inputs you expose, with types and bounds you set; everything else stays locked to the golden path. Every deploy still runs through guardrails and lands in the audit trail.
Can I version and roll back blueprints?
Yes. Blueprints are versioned with a diffable history. Promote a new version, compare it to the last, and roll back if needed — every deploy traces to a specific, reviewable version.
From the blog
View all posts →
The latest on golden paths
Cost Intelligence
PlatformPortal IDP vs Execution IDP: The Difference That Actually Matters
Portal IDPs show developers a button; execution IDPs run the action. Learn the difference, four tests to classify any IDP, and which one your team needs.
Cost IntelligenceKubernetes Cost Allocation: Showback vs Chargeback (2026 Guide)
Kubernetes cost allocation turns a shared cluster bill into per-team numbers. Learn showback vs chargeback, idle/shared-cost splitting, and the maturity path.
Make your best setup the standard.
Connect a cluster, read-only to start. Capture a running service as a blueprint and see it ready to self-serve in minutes. Free, no sales call.