A Singapore Government Agency Website

Cost optimisation options Q&A (22 Aug 2025)

The following questions were raised by users during the StackOps Elastic Cost Optimisation Options session held on 22 August 2025.

Costs and deployments

For the first year of pricing, from 1 Sep ‘25 to 31 Aug ’26, you will receive a 7% discount on your Elastic usage monthly charges.

  • Browser monitor: USD 0.0123 per test run (charged based on the frequency you configure)
  • Lightweight monitor (HTTPS, TCP, etc.): USD 28 per month flat rate, regardless of the number of monitors you create

Note: These charges apply when using public locations.

Egress traffic costs $0.032 per GB, and snapshot storage costs $0.033 per GB per month.

For a detailed breakdown and examples, refer to Elastic documentation:
Elastic Cloud Billing Dimensions

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.

Yes, documentation is available here: Private Location Synthetic Monitoring Setup

If there is no use case for creating your own workspace, the default is fine.

StackOps Elastic will be rolling out v8.19 soon, which has long-term Elastic support. There is no change in pricing.

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.

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.

It is possible to configure a maximum configuration on a single AZ basis to prevent auto-scaling beyond the specified configuration.

Consider switching to Elastic Agent, which can help reduce ingestion costs.

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. A comparison table of ingestion methods for StackOps Elastic tenants is available here: Data Ingestion Methods

The price shown will be in USD.

You can view your Elastic consumption trends via your Dashboard. Steps are documented here: Monitor Your Usage

Assuming StackOps Elastic is right-sized, costs are estimated based on the volume of ingested logs and the Elastic features used. They do not correspond directly to your AWS costs.

Storage and retention

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.

Yes. There are two approaches:

  1. Back up to another cluster in Elastic – tested method for pausing or migrating: Data Migration Guide
  2. 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.

Yes, but you need the Elastic Agent ID to filter the index and delete the data.

One or more agents can be used for ingesting data, and a separate agent for APM traces.

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.

Yes, it will still be charged.

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.

It is use-case specific. If tenants want to pull day 1 of the log group, they should use “beginning.” If there is no use case for day 1 logs, starting from “end” is recommended.

Configuration and usage

Deployment scale up/down is handled by the StackOps support team. You can raise a service request for this.

Check the Elastic Agent metrics dashboard. If you notice a queue building up, this indicates an ingestion problem. There isn’t a separate Elasticsearch or Kibana server.logs for this purpose.

It is possible to pipe both production and non-production logs to the same deployment.

Yes. A project can have multiple workflows. Usage reporting may be complex if multiple workflows exist.

It depends on your metrics. Some metrics in CloudWatch arrive slightly slower. This latency tells the Elastic Agent to check these metrics with a delay. Without this latency, the Elastic Agent might assume the metrics do not exist.

Most of them do. The integration has hardcoded specific CloudWatch metric namespaces, but a few integrations do not use this approach.

Yes. The default CloudWatch integration can pull custom metrics in addition to the built-in ones. Alternatively, you can use a custom AWS integration for more specialised metric ingestion.

Elastic provides lightweight, purpose-built agents for each system being observed. There isn’t a single universal agent like Dynatrace OneAgent, so some configuration per system may be required.

The Automatic Import feature is currently designed for the Elastic Security solution. Additional AI-driven import capabilities for other pipelines are planned in the roadmap.

If you know which logs are important and they usually arrive consistently, you can create alerts that trigger when no documents are ingested for a specified period.

Chat with me!
Bot Launcher