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.
When fleet auto scaling policies maintain more active instances than are required to support current usage—particularly during off-peak hours—organizations incur unnecessary compute costs. Fleets often remain oversized due to conservative default configurations or lack of schedule-based scaling. Tuning the scaling policies to better reflect usage patterns ensures that streaming infrastructure aligns with actual demand.
AppStream fleets often default to instance types designed for worst-case or peak usage scenarios, even when average workloads are significantly lighter. This leads to consistently low utilization of CPU, memory, or GPU resources and inflated infrastructure costs. By right-sizing AppStream instances based on actual workload needs, organizations can reduce spend without compromising user experience.
When AppStream builder instances are left running but unused, they continue to generate compute charges without delivering any value. These instances are commonly left active after configuration or image creation is completed but can be safely stopped or terminated when not in use. Identifying and decommissioning inactive builders helps reduce unnecessary compute costs.
