Cloud Run allows users to allocate up to 8 GB of memory per container instance. If memory is overestimated — often as a buffer or based on unvalidated assumptions — customers pay for more than what the workload consumes during execution. Unlike in VM-based environments where memory might be shared or underutilized without direct cost impact, in Cloud Run, you're billed precisely for what you allocate. This inefficiency often results from: * Defaulting to high memory values for “safety” * Not using monitoring tools to assess actual memory usage * Lack of clear ownership over service tuning
Cloud Functions scale to zero when idle. When invoked after inactivity, they undergo a "cold start," initializing runtime, loading dependencies, and establishing any required network connections (e.g., VPC connectors). These cold starts can dramatically increase execution time, especially for functions with: * High memory allocations * Heavy initialization logic * VPC connector requirements If cold starts are frequent, customers may be paying for unnecessary compute time — particularly in latency-sensitive workloads — without receiving proportional value.
VM-based Committed Use Discounts in GCP offer cost savings for predictable workloads, but they are rigid: they apply only to specified VM types, quantities, and regions. When organizations evolve their architecture — such as moving to GKE (Kubernetes), Cloud Run, or autoscaling — usage patterns often shift away from the original commitments. Because GCP lacks flexible reallocation options like AWS Convertible RIs or Savings Plans, underutilized commitments lead to sustained, silent waste. This is especially common when workload changes go uncoordinated with finance or centralized planning.
Recursive invocation occurs when a Lambda function triggers itself directly or indirectly, often through an event source like SQS, SNS, or another Lambda. This loop can be unintentional — for example, when the function writes output to a queue it also consumes. Without controls, this can lead to runaway invocations, dramatically increasing cost with no business value.
Multi-AZ deployment is often essential for production workloads, but its use in non-production environments (e.g., development, test, QA) offers minimal value. These environments typically do not require high availability, yet still incur the full cost of redundant compute, storage, and data transfer. This results in unnecessary spend without operational benefit.
When a Lambda function processes messages from an SQS queue but fails to handle certain messages properly, the same messages may be returned to the queue and retried repeatedly. In some cases, especially if the Lambda is also writing messages back to the same or a chained queue, this can create a recursive invocation loop. This loop results in high invocation counts, prolonged execution, and unnecessary costs, particularly if retries continue without a termination strategy.
OCI Compute instances incur cost based on provisioned CPU and memory, even when the instance is lightly loaded. Instances that show consistently low usage across time—such as those used only for occasional tasks, test environments, or forgotten workloads—may be overprovisioned relative to their actual needs.
If an AWS WorkSpace has been provisioned but not accessed in a meaningful timeframe, it may represent waste—particularly if it is set to monthly billing. Many organizations leave WorkSpaces active for users who no longer need them or have shifted roles, leading to persistent charges without corresponding business value. Even in hourly mode, costs can accrue if WorkSpaces are left in a running state.
Storing raw JSON or CSV files in S3—especially when written frequently in small batches—leads to excessive scan costs in Athena. These formats are row-based and verbose, requiring Athena to scan and parse the full content even when only a few fields are queried. Without columnar formats, partitioning, or metadata-aware table formats, queries become inefficient and expensive, especially in high-volume environments.
Photon is enabled by default on many Databricks compute configurations. While it can accelerate certain SQL and DataFrame operations, its performance benefits are workload-specific and may not justify the increased DBU cost. Many pipelines, particularly ETL jobs or simpler Spark workloads, do not benefit materially from Photon but still incur the higher DBU multiplier. Disabling Photon by default and allowing it only where proven beneficial can reduce cost without degrading performance.
