Cost optimisation
This guide provides resources and tips to support cost management and optimisation in StackOps Elastic deployments. To get the estimated cost of your current deployments, refer to Pricing for more information.
Evaluating your deployments
There is no one-size-fits-all approach to knowing if your current setup is optimal, because every deployment has unique data usage patterns, retention needs, and sizing requirements. Here are some general tips you can follow:
- Use smaller deployment sizes for lower environments (e.g., Dev, Staging).
- Reserve larger deployments for production environments where performance is critical.
- Review your data ingestion volume and retention settings as they are major cost drivers.
- Optimise your central view deployments, if you have any. Refer to Optimise central view deployments for a full guide.
If you need to scale down your deployment, raise a service request to request a sizing change.
To get tailored guidance, raise a Deployment Optimisation Request. The StackOps team will hold a 1:1 cost clinic session to work with you to review your setup and identify ways to optimise it.
Considerations for deployment setup
Deployment sizing and resources is a core part of your Elastic costs. This section provides several considerations for choosing the right setup and ensuring that your deployment resources are not over-provisioned.
Number of deployments
It is recommended to maintain separate separate deployments for production and non-production environments. This approach offers better cost control and flexibility over monitoring and environment-specific tuning. Here is a comparison of the two approaches:
| Considerations | Combined deployment | Separate deployments |
|---|---|---|
| Sizing | The deployment must be sized for production requirements, forcing a higher capacity and longer data retention period for non-production data. | Non-production deployments can be downsized and configured for a shorter data retention period, reducing costs. |
| Autoscaling | Production-level autoscaling applies to all workloads, leading to higher costs for for non-production work like routine testing. | Autoscaling is enabled only for the production deployment, so non-production deployments avoid unnecessary scale-ups. |
| Environment management | Shared resources complicate cost attribution and increase the risk of non-production tests affecting production stability. | Separate deployments enable clear monitoring boundaries and simplified environment-specific management. |
In summary, a dedicated non-production deployment allows your team to test and optimise without risking production stability.
Autoscaling
Autoscaling is an Elastic feature that adjusts resources based on demand. To balance cost optimisation and resource allocation, autoscaling is enabled by default only for production deployments. Furthermore, to minimise sudden cost spikes, it does not scale up multiple tiers at once, but instead increases one tier at a time based on your usage.
Each deployment has a configured maximum size, so autoscaling will not exceed that limit. You can check the current and maximum size of your deployment in Console. In addition, it is possible to configure a maximum configuration on a single AZ basis to prevent auto-scaling beyond the specified configuration.
If your deployment is scaling up too aggressively, you can modify the autoscaling configuration in Console to better suit your budget.. Learn more in Upsizing StackOps Elastic deployments.
Hardware profiles
The CPU Optimised (ARM) profile generally offers a better performance-to-cost ratio than the CPU Optimised profile and is typically more cost-effective. However, certain workloads, such as machine learning inference, may perform better on the non-ARM CPU Optimised option. Since these hardware profiles are AWS offerings, we recommend reviewing AWS’s published performance and cost benchmarks to decide based on your specific use case.
Tools and support
- Cost Optimisation Options session — Access the recordings and slides (via intranet) or Q&A the for the session conducted on 22 August 2025.
- Pricing guide and calculator (via intranet) – Estimate costs based on your planned usage.
- Deployment Optimisation Request – Request for tailored guidance for your deployment setup, sizing, and cost efficiency.
- StackOps service request – Raise requests to the StackOps support team, such as downsizing changes.
- Billing and subscription support – Submit queries related to billing or subscription management.
Cost estimation FAQ
Usage costs
The assert text function falls under Browser Tests, which incurs a charge of USD 0.0123 per test in addition to USD 28 per location per month.
For example, monitoring 100 URLs at 1-minute intervals would result in a daily cost of approximately USD 1,771.20, excluding the location charge of USD 28.
Cost optimisation tip: Consider using Private Locations, which allow you to run Browser Tests without incurring the per-test and location charges.
It depends on how quickly the data needs to be ingested. Each API call incurs a cost, so frequency and volume of ingestion will impact overall expenses.
The only processes that help compress data are transform jobs and downsampling.
Refer to Elastic Documentation: Rollup Job API
WARNING: From 8.15.0, calling this API in a cluster with no rollup usage will fail with a message about deprecation and planned removal of rollup features. A cluster needs to contain either a rollup job or a rollup index for this API to be allowed to run.
StackOps has central monitoring in place and is aware of usage spikes and autoscaling activities. However, this information is currently not exposed to users. The team will explore ways to make such insights more accessible in the future.
Resource costs and storage
Yes. If you have no compliance or retention requirements to keep logs in StackOps Elastic beyond 7 days, you can safely skip the cold and frozen tiers.
Consider switching to Elastic Agent, which can help reduce ingestion costs.
Reducing storage helps reduce cost in terms of backup and traffic costs, but the main cost savings come via the node tier as it contributes to over 80% of overall cost.
If storage is at 40%, downsizing by one tier halves the resource, meaning usage will be 80% after downsizing. CPU and memory usage must also be considered when scaling down.
In general, there is no difference. However, there is a 3000 shard/node limit. Tenants with many shards can consider 2 AZs with lower configuration.
No. Elastic has a disk watermark threshold to prevent data corruption. When storage reaches this threshold, affected indices become read-only. You can still search and analyse existing data, but new logs cannot be ingested. To resume writing, either scale up your deployment or delete old/unneeded data.
Yes. There are two approaches:
- Back up to another cluster in Elastic – tested method for pausing or migrating: Data Migration Guide
- Self-managed snapshot repository – allows restoring snapshots later: Snapshot & Restore
- Note: From the UI, you can only restore snapshots to another active deployment, not a deleted one.
