The Instance Reportcompute desk — instances & pricing
instance-report — /var/log/compute

$ report --compute ready

Cloud instances, read against the workload you actually run.

The Instance Report documents compute patterns — how a workload scales, what it costs in relative terms, and the failure mode that bites first. No vendor pitches, no wishful pricing.

30 instances indexed  4 workload classes   updated 2026-11-01

Workload type

Workload classes

04 Cloud Computing ls ./cloud-computing 13 Containers ls ./containers 07 Edge Computing ls ./edge-computing 06 Serverless ls ./serverless

Cloud Computing

ls -l ./cloud-computing →
Cloud Computing2026-10-13 Cloud Compute in 2026: Stop Overpaying for On-Demand VMs workloadGeneral-purpose cloud compute instances running long-lived services and batch jobs runtimePersistent virtual machines with hourly or per-second billing, optionally interrupted scalingHorizontal for stateless tiers, vertical for stateful or legacy components, event-driven for queue workers costOn-demand is the highest relative tier; committed and interruptible options sit progressively lower ops Moderate; requires capacity planning, commitment tracking, and interruption handling On-demand compute is the default setting of the cloud era, and defaults are where money quietly disappears. Cloud Computing2026-10-13 AWS vs. Azure vs. GCP: Pick the Right Cloud for Compute workloadGeneral-purpose compute workloads (web/API services, batch jobs, data processing) deployed on cloud virtual machines and managed compute platforms runtimeLong-running virtual machine instances plus managed container and serverless execution environments scalingHorizontal auto-scaling of instance fleets, with vertical resizing for individual instances and event-driven scaling for serverless functions costMid-to-premium relative cost; committed-use and spot-style discounts materially lower effective rates ops Moderate to high, driven by identity, networking, and infrastructure-as-code sprawl across accounts and regions Choosing a cloud for compute is less about picking a winner and more about matching a provider's defaults to the shape of your workload. Cloud Computing2026-10-13 Cloud Cost Control: Why You Must Stop Paying On-Demand in 2026 workloadLong-running, always-on cloud compute instances (virtual machines) for steady-state applications runtimePersistent virtual machine instances with continuous uptime scalingHorizontal scaling with manual or auto-scaling groups; vertical scaling by resizing instances costOn-demand pricing is the highest relative cost tier; committed-use discounts can reduce costs by roughly 30-70% ops Moderate: requires capacity planning, commitment management, and monitoring On-demand pricing for cloud compute instances is the default billing model, but it is also the most expensive way to run steady-state workloads. Cloud Computing2026-10-13 Spot and Graviton: Two Ways You're Overpaying AWS workloadFault-tolerant batch, stateless web, and queue-driven compute jobs runtimeContainerized or VM-based long-running and short-lived processes scalingHorizontal, with event-driven bursts for queue workers costLow to moderate relative to on-demand baseline pricing ops Moderate to high due to interruption handling and capacity diversity Two of the most common ways teams overspend on cloud compute are not exotic mistakes.

Containers

ls -l ./containers →
Containers2026-10-13 EKS vs. Fargate vs. EC2: The Real Cost of Running Containers on AWS workloadContainerized applications and microservices runtimeManaged Kubernetes control plane with three compute options: managed node groups, serverless container runtime, and self-managed virtual machines scalingHorizontal pod and node scaling, often event-driven via autoscalers costManaged node groups and serverless container runtime carry a control-plane and per-pod premium; self-managed virtual machines are the lowest raw compute cost but highest operational overhead ops High for self-managed virtual machines, moderate for managed node groups, low for serverless container runtime Running containers on a major cloud provider usually comes down to a choice between three broad execution models. Containers2026-10-13 Containers on EKS: Busting the Managed Kubernetes Cost Myth workloadContainerized long-running services and batch jobs scheduled onto a managed Kubernetes control plane runtimeContainer runtime orchestrated by Kubernetes, with the control plane operated by the provider scalingHorizontal pod autoscaling plus cluster-level node autoscaling; event-driven for queue workers costModerate to high relative cost, driven by control plane fees, idle node capacity, and data transfer ops Moderate to high, since the control plane is managed but workloads, networking, and capacity remain operator concerns Managed Kubernetes has a reputation problem. Containers2026-10-13 Stop Overpaying for Containers: Pick the Right Compute, Not the Hype workloadContainerized stateless and long-running services packaged as OCI-style images runtimeContainer runtime on shared or dedicated compute hosts, orchestrated by a scheduler scalingHorizontal pod or task replication, with optional event-driven and vertical adjustments costLow to moderate when right-sized; high when over-provisioned or idle ops Moderate to high, driven by scheduling, networking, storage, and image lifecycle management Containers have become the default packaging format for modern services, and that success has created a quiet cost problem. Containers2026-10-13 Run Containers Without Wasting Money: A Blunt Guide to Compute Choices workloadLong-running containerized services (APIs, web apps, background workers) runtimeContainer runtime on a host operating system, orchestrated or standalone scalingHorizontal (replica count) with some vertical headroom adjustments; event-driven for queue workers costModerate; dominated by idle reserved capacity and over-provisioned replicas ops Moderate to high, driven by orchestration, networking, and observability overhead Containers solved a packaging problem and quietly created a capacity problem. Containers2026-10-15 Cut Container Costs with Spot Instances and Kubernetes workloadContainerized stateless and batch microservices orchestrated by Kubernetes runtimeLong-running pods and short-lived jobs scheduled on ephemeral nodes scalingHorizontal, driven by replica counts and autoscalers reacting to demand costLow relative to on-demand capacity, with interruptible pricing that can be a fraction of standard rates ops Moderate to high, requiring taints, tolerations, disruption budgets, and graceful shutdown handling Running containerized workloads on interruptible compute is one of the most reliable ways to reduce the largest line item in a Kubernetes bill: the worker nodes themselves. Containers2026-10-18 Containers on AWS vs Azure vs GCP: Which Compute Home Wins? workloadContainerized stateless and stateful application workloads (microservices, batch jobs, web APIs) runtimeManaged container orchestration control plane scheduling OCI-compatible container images onto pooled compute nodes scalingHorizontal, node-pool and pod-level autoscaling, with event-driven and schedule-based triggers costModerate to high; control plane fees plus per-node compute, with discounts for committed or spot capacity ops Moderate to high, depending on managed versus self-managed control plane and networking choices Choosing a compute home for containers is less about brand loyalty and more about matching an orchestration control plane to the shape of your workload. Containers2026-10-21 Containers: Stop Overprovisioning, Start Saving with Spot and Serverless workloadContainerized stateless and batch-oriented application workloads runtimeContainer runtime with a scheduler; serverless container execution for event-driven tasks scalingHorizontal and event-driven, with vertical tuning of per-container resource requests costLow to moderate relative cost when rightsized and using interruptible capacity ops Moderate, rising to high without consistent rightsizing and capacity-class policies Containers changed how teams package and ship software, but they did not change the underlying economics of compute. Containers2026-10-23 Containers on AWS vs Azure vs Google: Which Compute Really Wins? workloadContainerized stateless web services and API backends, plus batch jobs, scheduled tasks, and event-driven workers runtimeManaged container orchestration on a control plane that schedules containers across a pool of worker nodes or serverless-style per-request execution units scalingHorizontal and event-driven: replica counts, node pool sizes, and per-request execution units all expand and contract with demand, with some vertical tuning of node instance size costMid to high relative cost; control plane fees are modest, but worker capacity, idle headroom, and data transfer dominate the bill ops Moderate to high: cluster upgrades, networking, identity, autoscaling tuning, and observability all require ongoing attention Containers on the three largest public clouds look similar at the surface: you package an image, push it to a registry, and ask a control plane to run it. Containers2026-10-24 Containers on Spot: Is the 90% Discount Worth the Risk? workloadStateless containerized microservices and batch jobs runtimeContainer runtime with orchestrator-managed scheduling scalingHorizontal, event-driven and queue-based costLow to very low relative cost, often a fraction of on-demand rates ops High due to interruption handling and capacity volatility Spot capacity is a pricing model where you bid on unused compute at a steep discount, often quoted as up to ninety percent off on-demand rates. Containers2026-10-25 ECS Fargate vs EKS on EC2: The Container Bill Nobody Warns You About workloadContainerized microservices and batch jobs runtimeManaged serverless containers vs. self-managed containers on virtual machines scalingHorizontal (automatic or manual) costServerless: higher per-unit compute; VM-based: lower per-unit but with fixed node costs ops Serverless: low; VM-based: high When teams adopt containers, they often face a fork in the road: use a fully managed serverless container service or orchestrate containers on virtual machines. Containers2026-10-26 Do Containers Need Servers? The Fargate vs EC2 Decision workloadContainerized stateless web services and API backends runtimeManaged container execution without direct host or cluster management scalingHorizontal, event-driven task scaling costModerate to high per-unit cost, lower fixed overhead ops Low for managed container execution, high for self-managed clusters The question in the title sounds almost philosophical, but it is really a procurement and operations question dressed up in architecture language. Containers2026-10-27 Containers: Should You Run Them on VMs, Fargate, or Kubernetes? workloadContainerized application workloads (stateless services, APIs, batch jobs, and small stateful components) packaged as OCI-style images runtimeContainer runtime on a host operating system: either a full virtual machine with its own kernel, a managed per-task micro-VM/sandbox, or a shared container runtime scheduled across a cluster of nodes scalingHorizontal and event-driven: replicas or tasks are added or removed based on CPU, memory, request concurrency, queue depth, or custom metrics; vertical scaling is limited to per-task size limits costVM-hosted containers are typically the cheapest per unit of steady compute but carry idle-capacity waste; managed per-task container services cost more per unit but bill only for running tasks; Kubernetes on self-managed nodes sits between the two and adds control-plane and node overhead ops Low for managed per-task services, moderate for VM-hosted containers with a small orchestration layer, high for self-managed Kubernetes clusters with networking, storage, upgrades, and multi-tenant concerns Containers package an application and its dependencies into a single image that runs consistently across environments. Containers2026-10-28 Stop Overprovisioning: Why Your Containers Need Spot, Not On-Demand workloadstateless containerized web services and background workers runtimecontainer runtime on a cluster scheduler scalinghorizontal, event-driven autoscaling costlow relative to on-demand capacity, with interruption risk ops moderate to high Most teams running containers in the cloud start with the safest possible capacity: on-demand instances that stay up until you delete them.

Edge Computing

ls -l ./edge-computing →
Edge Computing2026-10-13 Edge Computing Isn't a Product—It's a Discipline. Stop Buying It Blind. workloadLatency-sensitive, location-dependent request processing and local data reduction runtimeContainerized or function-based execution on distributed nodes close to end users or devices scalingHorizontal across edge locations, with event-driven bursts and limited vertical headroom per node costModerate to high relative to centralized compute once bandwidth, device management, and staffing are included ops High Edge computing gets sold like a product. Edge Computing2026-10-13 Edge Computing: Stop Hoarding Cloud, Put Compute Where It Counts workloadLatency-sensitive, data-intensive workloads such as interactive web applications, real-time analytics, and IoT data processing that benefit from being placed close to end users or data sources. runtimeContainerized or serverless functions running on lightweight nodes at the network edge, often orchestrated by a central control plane. scalingEvent-driven and horizontal scaling, where compute instances are added or removed based on incoming request volume or data events. costModerate to high relative to centralized cloud, due to distributed infrastructure and management overhead, but can reduce data transfer and latency costs. ops High, because of the need to manage, update, and monitor many geographically dispersed nodes with limited on-site personnel. Edge computing is a model for placing compute resources closer to where data is generated or consumed, rather than funneling everything to a centralized data center. Edge Computing2026-10-13 Edge Computing Showdown: AWS Outposts vs. Azure Stack vs. Google Anthos workloadLatency-sensitive and data-residency-constrained workloads running at or near the network edge, such as industrial telemetry, retail point-of-sale, and local inference runtimeManaged container or virtual-machine runtime extended from a central cloud control plane into customer or partner facilities scalingHorizontal at the edge site, bounded by local hardware; centrally coordinated across many sites costHigh relative to equivalent central-region capacity, driven by hardware, shipping, and site overhead ops High, because operators must manage physical sites, power, cooling, and network links alongside software Edge computing platforms are the cloud providers' answer to a simple problem: some workloads cannot tolerate the round trip to a distant region, and some data cannot legally or practically leave a local site. Edge Computing2026-10-13 Edge Compute: Run AI Where Your Data Lives workloadLatency-sensitive AI inference and data preprocessing near the point of data capture runtimeContainerized or function-based runtime on small-footprint edge nodes, with optional periodic sync to a central control plane scalingEvent-driven and horizontal across many distributed nodes, with limited vertical scaling per node costModerate per-node cost, higher than centralized batch compute per unit of work, but lower data egress and latency-related costs ops High, due to physical distribution, heterogeneous hardware, and remote update and observability challenges Edge compute for AI means placing the execution of models and data processing close to where data is generated, rather than shipping everything to a centralized region. Edge Computing2026-10-16 Edge Computing Is a Lie: Run Your AI at the Core, Not the Edge workloadAI inference and model serving workloads runtimeContainerized or process-based model servers, often GPU-accelerated scalingHorizontal across core regions with event-driven request routing costModerate to high, dominated by accelerator and data egress costs ops High due to distributed state, versioning, and observability gaps Edge computing has become one of the most repeated phrases in infrastructure marketing, and like many repeated phrases, it has drifted far from what it originally meant. Edge Computing2026-10-19 Edge Computing for the Rest of Us: A Blunt Answer workloadLatency-sensitive data processing and request handling close to end users runtimeContainerized or function-based execution at distributed edge locations scalingEvent-driven and horizontal across edge nodes costModerate to high relative to centralized cloud, with potential savings from reduced data transfer ops High due to distributed deployment, monitoring, and updates Edge computing is often presented as a revolution, but for most teams it is a practical response to a specific set of constraints. Edge Computing2026-10-22 Edge Computing Is a Latency Problem, Not a Location Religion workloadLatency-sensitive request/response and stream processing workloads that benefit from execution near end users or data sources runtimeContainerized or function-based execution on distributed nodes, often with regional control planes and local data caching scalingEvent-driven and horizontal scaling across distributed nodes, with capacity shaped by geographic demand and data locality costModerate to high relative cost per compute unit compared with centralized regions, driven by distribution, management overhead, and smaller node sizes ops High, due to many small sites, heterogeneous hardware, remote updates, and limited on-site staff Edge computing is often framed as a question of where computation should live: in a massive centralized data center, in a regional cloud, or on a small device close to the user.

Serverless

ls -l ./serverless →
Serverless2026-10-13 Serverless Isn't Free: The Real Cost of Lambda and How to Escape It workloadEvent-driven functions and short-lived request handlers runtimeManaged function execution with per-invocation billing scalingEvent-driven horizontal scaling with per-request concurrency costLow at idle, steep and non-linear at sustained high volume ops Low to moderate for code, high for cost governance Serverless computing is often introduced with a simple promise: you pay only for what you use, and you use nothing when no one is calling your code. Serverless2026-10-13 Serverless Compute: Is AWS Lambda Still the Best Default in 2026? workloadEvent-driven and request-response application workloads such as APIs, webhooks, scheduled jobs, and lightweight data transforms runtimeManaged function execution model where individual functions are invoked on demand and billed per invocation and execution duration scalingEvent-driven horizontal scaling, where the platform provisions concurrent execution instances automatically in response to incoming events costLow to moderate at low and spiky traffic; can become moderate to high at sustained high utilization compared with continuously running instances ops Low for deployment and patching; moderate for observability, concurrency control, and cost governance at scale Serverless compute has matured from a novelty into a default choice for a large class of application workloads. Serverless2026-10-13 Serverless Compute Isn't Dead—It's Just Not What You Think workloadEvent-driven functions and short-lived compute tasks runtimeManaged, ephemeral execution environments scalingEvent-driven, horizontal, automatic costPay-per-invocation, low baseline cost, variable with volume ops Low to moderate Serverless compute often gets dismissed as a niche tool for simple tasks, but that view misses its broader role in modern cloud architecture. Serverless2026-10-14 Serverless Is Not the Cost Killer You Think It Is workloadEvent-driven, bursty request-response workloads such as API backends, webhooks, and scheduled jobs runtimeFunction-as-a-Service (FaaS) execution model where code runs in short-lived, stateless containers scalingEvent-driven horizontal scaling, often with automatic concurrency limits and cold starts costVariable, pay-per-invocation and per-GB-second; can be cost-effective for low or sporadic traffic but expensive at sustained high utilization ops Low for basic deployment, but moderate to high for observability, debugging, and managing stateful dependencies Serverless computing has gained a reputation as a cost-saving panacea, promising that you only pay for what you use and never for idle capacity. Serverless2026-10-17 Serverless Showdown: AWS Lambda vs Azure Functions vs Cloud Functions workloadEvent-driven, short-lived request/response and background functions (HTTP APIs, queue consumers, scheduled jobs, glue logic) runtimeManaged function execution: code uploaded as a unit, invoked per event, with a platform-managed language runtime and per-invocation lifecycle scalingFully managed horizontal, event-driven scaling with per-invocation concurrency; no vertical sizing exposed to the developer costLow to moderate at low and spiky volume; can become the highest-cost option at sustained high utilization compared with reserved capacity ops Low for the platform itself, moderate overall because observability, IAM, packaging, and dependency limits move complexity into the application and pipeline Function-as-a-service platforms let you deploy a single unit of code that the provider runs on demand, in response to an event, without you provisioning or patching a server. Serverless2026-10-20 AWS Lambda vs Azure Functions: My Take After Years of Comparing workloadEvent-driven, short-lived functions triggered by HTTP requests, queue messages, schedules, or storage events runtimeManaged function runtime with per-invocation execution and automatic lifecycle handling scalingEvent-driven horizontal scaling, with instances added and removed automatically per concurrent event costLow relative cost for spiky or low-volume traffic; can climb toward always-on compute pricing under sustained high concurrency ops Low for basic deployments, moderate once networking, observability, and concurrency controls are added Comparing managed function platforms across two major clouds is less about picking a winner and more about understanding how each one shapes the way you build.