CameleeringCameleering / FinOps
Cameleering · code efficiency and cloud cost
Code efficiency as a FinOps lever
FinOps teams rightsize instances, buy commitments and switch off what is idle. Few of them change the software, yet the software decides how much memory and CPU every instance needs in the first place. This page shows how to turn measured milliseconds and megabytes into instances and dollars, with the arithmetic in full and its limits stated.
No claim without a number.
The lever FinOps rarely pulls
Workload optimization and waste reduction is the single top current priority in the FinOps Foundation's State of FinOps 2026, from 1,192 respondents covering more than $83 billion of cloud spend [1].
of infrastructure and platform spend is wasted, by respondents' own estimate in Flexera's 2026 State of the Cloud report, up slightly after five years of decline [2].
The FinOps Framework's Usage Optimization capability asks for resources that are properly selected, correctly sized, run only when needed and highly utilized, and says engineering does most of the work [5]. It talks about infrastructure and architecture; it does not name the efficiency of the code itself. That is the gap this page is about: rightsizing fits the instance to the software, while code efficiency shrinks what the software needs.
From milliseconds and megabytes to money
The worked examples below use one measured comparison: the same integration routes on Apache Camel 4.23 on Java 21 and on Cameleer, the first Cameleering project, on identical cloud machines (the ledger). Prices are public on-demand list prices in us-east-1, checked on 2026-11-12. Each example says what it leaves out.
1. Memory decides how many instances fit on a node
| route, peak memory (measured) | Apache Camel (JVM) | Cameleer |
|---|---|---|
| direct call through a route | 399 MB | 7 MB |
| HTTP into Kafka (Cameleer's highest) | 328 MB | 67 MB |
| integrations that fit in 8 GiB, by peak memory alone, direct route | 20 | 1,024 |
| the same, HTTP into Kafka | 24 | 122 |
Arithmetic, not a measurement: 8,192 MiB divided by peak memory. It ignores CPU, the operating system and the orchestrator's own overhead, so real density is lower on both sides. The point is the ratio: depending on the route, 5 to 51 times as many integrations per node, which is fewer nodes for the same work.
2. Cold starts are billed on AWS Lambda
Since 1 August 2025, AWS Lambda bills the initialization phase of on-demand functions at the normal duration rate [6], and duration is rounded up to the nearest millisecond at $0.0000166667 per GB-second on x86 [7].
| per million cold starts, 512 MB function | startup | initialization cost |
|---|---|---|
| Apache Camel on Java 21 | 1.1 s | $9.17 |
| Cameleer | 3 ms | $0.03 |
Arithmetic: startup × 0.5 GB × $0.0000166667 × 1,000,000. The startup times were measured on cloud virtual machines, not inside Lambda; Lambda adds its own sandbox start on both sides. For JVM functions AWS also offers SnapStart, which cuts startup differently.
3. Execution time and memory: what each request is billed
Lambda bills every invocation for its execution time, rounded up to the millisecond, times the memory setting. Both come from the same measured scenario, a REST API reading and answering JSON, on identical cloud machines (BENCHMARKS).
| REST API with JSON | Apache Camel (JVM) | Cameleer |
|---|---|---|
| execution time per request, p99 (measured) | 6.3 ms | 2.6 ms |
| billed duration, rounded up to the millisecond | 7 ms | 3 ms |
| peak memory (measured) | 402 MB | 19 MB |
| smallest memory setting with room for that peak | 512 MB | 128 MB (the minimum) |
| duration cost per million invocations | $0.0583 | $0.0063 |
Arithmetic: billed seconds × memory in GB × $0.0000166667 × 1,000,000; about 9 times less per request. Both sides also pay $0.20 per million requests. Caveats: the times were measured on cloud virtual machines over the network, not inside Lambda, and the p99 is used on purpose as a pessimistic duration: it comes from a closed-loop driver at saturation, so it includes queueing that a lightly loaded function would not see. Lambda gives a function CPU in proportion to its memory, so at 128 MB a CPU-bound route runs slower than on a full VM: measure the duration at each setting before you pick one.
4. A month of requests: the Lambda compute bill
One example month: 10 million requests, one in a hundred a cold start, each side at its own memory setting from example 3.
| 10 million requests, 100,000 cold starts | Apache Camel (JVM), 512 MB | Cameleer, 128 MB |
|---|---|---|
| execution time (duration) | $0.58 | $0.06 |
| cold starts (initialization: 1.1 s against 3 ms) | $0.92 | $0.0006 |
| compute bill | $1.50 | $0.06 |
Arithmetic on the measured numbers above and list prices: the compute bill is 23 times smaller. The per-request fee, $2.00 for 10 million requests, is the same on both sides and left out. Change the mix and the ratio moves: the more cold starts, the larger the gap; a route that waits on a slow database spends most of its time waiting, on either runtime.
5. Always-on containers pay for memory and vCPUs every hour
On AWS Fargate (Linux, x86), memory costs $0.004446 per GB-hour and a vCPU $0.04048 per hour [8], about $3.25 per GB and $29.55 per vCPU for a 730-hour month.
- Memory: 100 integrations that each need 391 MB less (399 MB against 8 MB) save about $127 a month at list price. Memory is cheap per unit; the larger effect is the node count in example 1.
- CPU: Cameleer handled 1.7 to 8.7 times Apache Camel's throughput on the same CPUs. At twice the throughput, the same load needs half the vCPUs: one fewer vCPU is about $29.55 a month, per vCPU, before any commitment discount.
Azure Container Apps (consumption plan, eastus) charges $0.000024 per active vCPU-second and $0.000003 per GiB-second [9], so the same reasoning holds there.
How to bring this into a FinOps practice
| step | what to do |
|---|---|
| 1. Rank by cost | Take the top services by spend from your cost reports. Efficiency work pays where the bill is. |
| 2. Measure the software | For each one: startup, idle and peak memory, CPU per request, throughput at the target p99. The method page says how. |
| 3. Translate | Turn each number into the unit you are billed in: GB-seconds, vCPU-hours, instances per node. Show the arithmetic, as above. |
| 4. Pick the change | A setting, a smaller default, a removed layer, a different runtime, or a rewrite when the numbers justify it (when a rewrite pays off). |
| 5. Measure again and rightsize | Rerun the same measurement, then lower requests, limits and memory settings to match. Without this step the software gets smaller and the bill does not. |
| 6. Guard | Put the budgets in CI so a regression fails the build before it reaches the bill. |
Common questions
Does code efficiency belong in FinOps?
It is the input FinOps usually takes as fixed. FinOps rightsizes infrastructure to fit the software; code efficiency changes how much the software needs. The FinOps Framework's Usage Optimization capability already says engineering does most of that work, and making the code need less is the part of it that rightsizing cannot reach.
Is memory saving worth it when memory is cheap?
Per gigabyte, often not much: on AWS Fargate a gigabyte costs about $3.25 a month at list price. The larger effects are density (how many services fit on a node, so how many nodes you run), cold-start time that serverless platforms now bill, and CPU, which costs about nine times as much per unit as memory on Fargate.
Does AWS Lambda bill cold starts?
Yes, for on-demand functions since 1 August 2025: the initialization phase is billed at the normal duration rate, rounded up to the nearest millisecond. Functions with custom runtimes, container images or provisioned concurrency already paid for it.
Will a smaller Lambda memory setting always save money?
Not always. Lambda gives CPU in proportion to memory, so a smaller setting can make a CPU-bound function run longer. Measure the duration at each setting and pick the cheapest one that meets your latency target.
Are these savings guaranteed?
No. The worked examples are arithmetic on measured numbers and public list prices, and each states what it ignores. Your saving depends on your workload, discounts and whether you rightsize after the software gets smaller.
Sources
Checked on 2026-11-12.
- FinOps Foundation, State of FinOps 2026.
- Flexera, 2026 State of the Cloud Report.
- Datadog, State of Cloud Costs 2024, press release, 13 June 2024.
- CAST AI, 2025 Kubernetes Cost Benchmark Report, 5 March 2025.
- FinOps Foundation, FinOps Framework: Usage Optimization.
- AWS, "AWS Lambda standardizes billing for INIT Phase", 29 April 2025.
- AWS, AWS Lambda pricing.
- AWS, AWS Fargate pricing.
- Microsoft, Azure Container Apps pricing and the Azure Retail Prices API.
- Cameleer measurements: the ledger and BENCHMARKS.