How edge computing and serverless change carbon accounting

Moving compute closer to users changes where energy is consumed and how often infrastructure sits idle. Edge architectures reduce network distance and can cut repeated long haul data transfer. At the same time they may increase the number of active locations, cause duplication of cached state, and create additional platform overhead when functions run briefly or cold starts are frequent. Serverless changes who controls resource efficiency. The platform owner may run infrastructure more densely, but function invocation patterns and memory sizing still determine actual energy use for your workload.

Emission sources to include in any comparison

A robust assessment must include the following components and treat boundaries consistently.

• Compute energy measured as CPU and memory active time multiplied by device power draw and PUE for the hosting facility.
• Cooling and facility overhead captured through power usage effectiveness, sometimes reported by providers.
• Network energy from last mile to backbone, including repeated transfers between edge and origin.
• Client device work when moving compute changes how much work runs on user devices.
• Operational and embodied impacts only when comparing long lived hardware lifecycle differences; usually out of scope for short term architecture choices.

Why simple heuristics often fail

Simple rules such as move everything to the nearest edge to save carbon ignore three common failure modes. First, fragmentation increases idle resources. Distributing a workload across many small locations can replicate cached data and require more machines to stay warm. Second, function invocation overhead matters. Short lived functions with high cold start probability raise compute time per request relative to a persistent service. Third, network path inefficiencies can appear when edge locations need to contact a central origin frequently, increasing overall network transfer and negating local savings.

Practical decision rules that predict direction of change

1. Cacheable large payloads delivered to many users are strong candidates for edge or CDN delivery because saved network distance typically outweighs duplicate storage overhead.
2. Small payloads with frequent roundtrips to a central database usually benefit from centralised hosting. Moving compute to many edge locations can multiply origin calls and increase network energy.
3. Burst driven or highly spiky workloads can be more efficient on central serverless platforms that rely on pooled resources. Edge serverless may create many short lived containers that increase per request overhead.
4. Geographic distribution of users is decisive. If users are concentrated, central region hosting is often lower carbon. If users are widely distributed, edge locations can reduce cumulative network energy.
5. Latency improvements that reduce client work can change the balance. When moving compute to the edge eliminates expensive client side processing or reduces active device time, total emissions can fall even if server energy rises.

A repeatable measurement workflow

Assessments that rely on estimates alone rarely settle the question. The following workflow is designed to produce audit friendly comparisons.

1. Define system boundary and scenarios including what is included in compute, network and client device work and whether embodied impacts are in scope. Specify a representative traffic distribution by geography and a realistic request mix.
2. Gather baseline telemetry for the current architecture. Capture request counts, function durations, CPU or vCPU seconds, memory allocation time, and bytes transferred per network leg. Use provider metrics where available and supplement with application level timing instruments.
3. Model energy from compute by converting CPU and memory usage to energy. When provider published energy metrics exist prefer those. Otherwise convert active CPU seconds to watt seconds using a vetted CPU power draw estimate and add memory power where significant. Multiply compute energy by facility PUE to capture cooling and overhead.
4. Model network energy by multiplying bytes transferred by an appropriate energy intensity per byte for the network segments in scope. Where provider network energy intensities exist use them. Otherwise use conservative literature derived values and document the source and uncertainty.
5. Convert to carbon using grid factors that match the electrical grid where energy was consumed. Apply location specific emission factors for each hosting location and report the factors used and their vintages.
6. Compare architectures by running the same request mix through each architecture or by projecting measured per request energy across the traffic profile. Include sensitivity analysis for cache hit rates, cold start frequency and user distribution.
7. Validate with a live A B test where possible and safe. Use short controlled rollouts that toggle routing between central and edge implementations and measure real differences in billing metrics and latency. Interpret changes carefully and re run metrics after caches warm and traffic stabilises.

How to handle elements with weak public data

Providers do not always publish per vCPU wattage or precise network energy per byte. When direct data are not available adopt two practices. First, use conservative assumptions and show a range rather than a single number. Second, prioritise relative comparisons using the same assumption set for both architectures so the direction of change is robust even if absolute numbers are uncertain.

Qualitative scenarios that illustrate the rules

Three short scenarios show how the decision rules apply in practice.

Static assets at global scale Static media cached widely is a clear win for edge delivery. Network energy per user is lowered because long haul transfers are avoided and origin load is reduced. The main caution is duplication of storage at edge caches which typically has small marginal energy cost relative to saved transfer.

Personalised API calls that require a central database Moving the API to the edge can increase carbon because each edge location may call the central database more often. A better approach is to keep core data logic central and push only noncritical personalization to edge caches or use short lived aggregated updates.

IoT telemetry ingestion If devices connect from many regions and per message size is small, centralised ingestion with regional ingress points and efficient batching is often preferred. A design that surfaces processing at local edge nodes can help when pre filtering avoids sending most raw telemetry to the origin.

Optimisations to reduce emissions for edge serverless deployments

Design choices that commonly lower carbon while preserving correctness.

• Use durable caches for repeated reads so edge compute does not repeatedly call origin services.
• Batch and aggregate group many small operations into fewer larger operations to reduce per request overhead and network chatter.
• Reduce cold start frequency by tuning concurrency and keeping critical functions warm when savings outweigh the cost of warm instances.
• Right size memory and compute pick resource allocations that match actual peak compute needs rather than default large allocations which increase energy per invocation.
• Prefer CDN for static content use edge compute only when transformation or personalization requires it.
• Measure after deployment collect the same telemetry used in the modelling step to confirm the direction and magnitude of change.

Reporting choices and transparency

When publishing results make the following items explicit. The system boundary, the provider metrics used, the grid emission factors and their dates, cache hit rates and cold start assumptions, and any estimated energy intensities with sources. Presenting ranges from sensitivity analysis improves credibility. Avoid single point claims such as absolute tonne numbers without disclosing methods used to derive them.

When to prefer experimentation over modelling

Models are necessary when live tests are impractical, for example if changes require customer facing rollout or complex migration. However when a low risk A B test is possible it usually provides the most reliable signal. Start with short duration pilot rollouts, gather billing and telemetry metrics, and then widen scope if the measured emissions direction matches the model.

Decisions about where to run code should be driven by measured workload characteristics and a transparent accounting method. Using the workflow and decision rules above helps teams avoid counterproductive moves and focus optimisation effort where it reduces real emissions without compromising product quality.