EKS Resource Sizing, Scaling and Cost Attribution

An anonymized Ampity engagement account describing resource sizing, scaling configuration, Spot usage and per-team cost attribution on AWS EKS. It separates recorded...

[Overview] Resource decisions and cost ownership on EKS

This anonymized account concerns an Ampity engagement with a B2B SaaS operator using AWS EKS. The recorded scope combined resource sizing, scaling configuration, Spot usage and per-team cost attribution. The purpose was to examine infrastructure spending without relaxing the service's reliability requirements.

The account describes the approach and its rationale. It does not establish an achieved cost reduction, improved availability, successful interruption recovery or a change in team behaviour. Those outcomes need supporting engagement records before they can be presented as results.

[Context] Requests, capacity and visibility

The source describes teams provisioning resources independently, requests above typical observed consumption, and development and staging capacity kept running for peak demand. It also describes static node counts rather than configured cluster autoscaling. These are qualitative descriptions from the engagement account, not a reconstructed inventory or a verified utilization baseline.

The account links those choices to an incentive imbalance: engineers experienced the consequences of insufficient capacity through incidents and pages, while infrastructure spending was less visible to individual teams. That is the recorded diagnostic hypothesis. The available narrative does not establish that incentives were the only cause, or that every high request was unnecessary.

A reader evaluating a similar environment should distinguish deliberate headroom from accidental excess. Startup demand, unusual traffic, recovery work and resource-intensive dependencies can justify capacity that looks idle over a narrow observation window. Investigating those possibilities is a proposed check, not work demonstrated by this case's supporting records.

[Diagnosis] A hypothesis that shaped the approach

The account's reasoning was that configuration changes alone might leave the reasons for conservative resource requests untouched. It therefore paired technical work with team-level cost visibility. This is a rationale for the chosen scope, not proof that reporting changed decisions or that savings would otherwise have disappeared.

The distinction matters when using the case. An attribution problem, an unsuitable scaling policy and genuine workload uncertainty require different responses. The source does not provide the evidence needed to rank their relative contribution here. The useful question is which decisions a team can explain and revisit, rather than whether over-provisioning can be assigned a single universal cause.

[Boundaries] Reliability remained a requirement

The recorded constraints were to retain EKS, existing deployment pipelines and monitoring while allowing gradual changes. Availability, handling demand changes and avoiding additional on-call burden were requirements. They are not evidence that the work met those requirements.

The account also calls for rollback capability. A rollback intention does not establish an implemented trigger, a working reversal path or recovery of a workload already affected by an interruption. Those details remain unverified.

[Decisions] Why a combined scope was chosen

The account records that a strict team-limits proposal was rejected because of concerns about reliability and team acceptance in this engagement. That reasoning is not an observed failure of the proposal. It does not show that resource limits or quotas necessarily cause incidents, and it does not establish how a differently designed policy would have performed.

VPA alone was also recorded as insufficient for the intended scope. The account sought to address pod sizing alongside scaling, capacity purchasing and attribution. That explains why several workstreams were considered together. It does not demonstrate that all were implemented with compatible policies, or that their combination produced a lasting improvement.

The chosen scope named VPA, HPA, Spot and team-level cost allocation. The source's claims of predictive scaling and automatic fallback are not carried forward as verified capabilities.

[Design] What the account describes, and what it leaves open

For resource sizing, the account describes a custom controller collecting resource usage and producing recommendations, together with VPA configuration tuned for the environment. It does not supply the controller implementation, recommendation history, VPA policies or update modes. No specific connection between that controller and HPA is established.

For horizontal scaling, the account names HPA and uses the term predictive. Neither the forecasting mechanism nor the configured metrics are supplied. This version therefore does not substitute a claim that reactive scaling was delivered. It retains only the recorded HPA workstream. In general, HPA adjusts desired replicas using configured observed metrics. Naming HPA does not establish a forecasting path. See the Kubernetes HPA documentation.

For capacity purchasing, the account describes Spot usage and an intended On-Demand fallback. It does not establish a reserved replacement pool, launch success, workload restart or restored service after an interruption. AWS documents interruption notices as best effort, normally two minutes before stop or termination, with no advance two-minute window for hibernation. That notice is not a guaranteed evacuation interval. See AWS Spot interruption notices.

On-Demand purchasing is not evidence that replacement capacity will be available. AWS documents launch failures from insufficient On-Demand capacity. The source does not identify fallback capacity arrangements or their test results. See EC2 launch troubleshooting.

For cost visibility, the account describes per-team allocation and weekly reports. It does not supply sample reports, allocation rules or evidence of changed team decisions. This version does not invent a measured requests-versus-consumption comparison or classify the reports as either enforcement or non-enforcement.

[Approach] Recorded rollout sequence

The source describes an initial instrumentation and allocation phase, followed by sizing and Spot changes in development environments and batch workloads, then a gradual production phase. This is the recorded sequence, not a verified release history.

The account includes automatic rollback on degraded reliability in its production rollout description. That remains an intended safeguard here. The trigger, configuration being reversed, decision owner, recovery conditions and any exercised rollback are not established. No delivery duration or successful production outcome is inferred from the sequence.

[Operating checks] Questions for a comparable system

The following checks are proposed reader guidance. They are not claims about tests performed during this engagement.

For each workload, inspect the actual controller policies before enabling automatic changes. VPA recommendations concern resource requests, with application depending on its configuration. HPA resource utilization targets use requests as the denominator, so changing requests can change the scaling signal even with unchanged consumption. The upstream VPA guidance cautions against using VPA and HPA on the same CPU or memory metric, while describing separate-resource or custom-metric combinations. Review the deployed versions and policies rather than assuming generic controller precedence. See the VPA overview and known limitations.

Before treating a workload as interruption tolerant, examine in-flight requests, partially completed jobs, acknowledgements, dependency reconnection and restart behaviour. A stateless service can still have work that is unsafe to abandon. Define what happens when useful advance notice is absent, and what evidence would show that the application recovered correctly.

For fallback, check launch permissions, quotas, scheduling constraints, startup dependencies and the capacity arrangements actually in place. Decide how the service behaves if replacement nodes cannot launch or workloads cannot become ready. A successful launch alone is not evidence that business operations resumed safely.

For a sizing change, identify which service indicators would stop further rollout and who can reverse the change. Check whether reversing configuration is sufficient or whether interrupted work needs a separate recovery action. Keep the intended safety rule separate from an observed successful recovery.

For attribution, assign responsibility for ownership changes, missing labels and shared costs. Stale mappings could misattribute spending and weaken the usefulness of reports. That is an operating risk to inspect, not an inevitable degradation or an observed result in this engagement. Review whether teams can understand and act on the allocation before treating visibility as accountability.

[Results boundary] No verified outcome is asserted

The original account includes quantitative results and broad success statements. Supporting measurement records are not available for this correction, so this account does not reproduce them. It also omits projected future spending, comparative savings for rejected alternatives and unrelated burst-load or message-delivery claims.

What remains is the recorded problem framing, constraints, workstreams and rollout rationale. The account does not yet support a measured-results case study.

[Applicability] Use the questions, not a savings promise

This account is useful when resource sizing, scaling policy, capacity purchasing and cost ownership need to be examined together. It does not establish a minimum spending threshold or prescribe a custom controller for every cluster.

A comparable team can begin by identifying the decision it cannot currently explain: why a request exists, which signal changes replicas, what happens after capacity is lost, or who owns a cost. Choose a bounded change and the evidence needed to judge it. Treat broader automation as a separate decision, especially where a simpler review process may address the immediate problem.

The lesson available from this record is a way to structure that investigation. Whether the engagement reduced cost or improved reliability remains an evidence question, not a conclusion supplied by the architecture labels.

Technical reference

Primary technical references were read directly on 17 October 2026: Kubernetes HPA documentation, the upstream VPA README and known-limitations document, AWS Spot interruption notices, and EC2 launch troubleshooting. Links accompany the relevant general mechanisms in the body. These sources clarify platform behaviour only. They do not establish deployed configuration, engagement execution, cost savings, reliability, fallback success, rollback success or team behaviour.