Pricing briefing Q&A (14 Jul 2025)

Billing will be based on the subscription account. All deployments under the same subscription account will be aggregated for billing. However, the preliminary invoice will break down charges by individual deployment, so you can see line-item details.

No, invoices are not available yet. Currently, the dashboard only displays the usage and consumption trends in ECU, where 1 ECU = 1 USD.

The first invoice will be issued in October 2025, reflecting charges from September 2025 onwards, and will be denominated in SGD. If you’re listed as a billing or subscription admin, you’ll receive an email notification when the invoice is ready.

Also, note that any discount offered by StackOps will not be visible in the dashboard, because the dashboard reflects raw consumption data from Elastic. The discount will be applied directly in the invoice.

While there isn’t a promo code to key in, StackOps is already offering built-in discounts for this year:

7% discount on Elastic usage (credits) No Service Management Fee (SMF) charged for 2025 These incentives are automatically applied, so you’re already benefiting from a “promo” without needing to do anything.

When you first create the subscription account, you’ll need to enter billing details — such as your sub-business unit and cost centre. Once that’s set up, billing will be handled automatically in the backend.

Yes, you can change the Billing Admin in Console only if you are a Subscription Admin. If you are logged in as any other role, make sure to switch to the Subscription Admin role to change the Billing Admin.

You can view your deployment size in Console. Go to StackOps > Deployment Details > Sizing info.

Billing is prorated by the hour when the deployment size changes.

Charges apply only when there’s a change in deployment size, and costs are prorated hourly.

Yes, refer to Other Elastic cost considerations in the Sizing and Pricing documentation via intranet (Use a GSIB or COMET device).

No, we don’t offer any saving or reservation plans similar to those used by cloud providers (like reserved instances or committed use discounts).

In Phase 2, a Service Management Fee (SMF) will be introduced. We’ve had communicated earlier that the SMF will be capped at a maximum of 20%.

No, the ABLR waiver is primarily targeted at GovTech subscriptions using StackOps Elastic. Other agencies need to apply for the waiver individually, following their own approval processes.

The ABLR waiver renewal is currently under review. Updates will be shared once the approval process is completed.

Yes. You can estimate costs using the details shown for your StackOps Elastic deployments on your dashboard. Go to the dashboard in the Console portal, select your deployment, and choose the desired time period (e.g., May, June) to view your usage and estimated monthly costs.

The costs are shown in Elastic Consumption Units (ECUs), where 1 ECU = 1 USD. You can use this as a basis to calculate and plan your ERR budget.

The dashboard displays Elastic Consumption Units (ECUs), where 1 ECU = 1 USD. However, the actual invoice issued to agencies will be in SGD.

In the dashboard, you’ll see Elastic Consumption Units (ECUs) not the dollar value in USD. This reflects your actual usage. While it’s not displayed as a currency, 1 ECU is equivalent to 1 USD for calculation purposes.

For existing deployments:

1. Go to the Console dashboard, select your StackOps Elastic deployment, and choose a time period (e.g., May or June) You’ll see usage shown in Elastic Consumption Units (ECUs), where 1 ECU = 1 USD.
2. Use the StackOps Elastic pricing estimator (intranet resource) to estimate monthly cost and plan your budget.

Do note that your StackOps Elastic cost may change month on month due to changes in your monitoring needs.

For new subscriptions:

• Use the StackOps Elastic pricing estimator (intranet resource) to estimate costs and plan your budget.

There are two possible approaches:

• If your partner agency is already a StackOps Elastic subscriber:

  • They can download the cost dashboard report and share it with you.
  • Alternatively, they can grant you access by adding you as a Technical Admin, allowing you to view the dashboard directly.

• If your partner agency is not yet a subscriber:

  • Use the Use the StackOps Elastic pricing estimator (intranet resource) to estimate monthly cost and plan your budget.

You can view this info from Console. To view this info, go to StackOps > Deployment Details > Sizing info section.

The Cloud Element Calculation Sheet is meant to help you estimate data size based on your system’s inputs. It does not provide exact pricing, but it supports the sizing step in your cost estimation process.

The CPU Optimised (ARM) profile generally offers a better performance-to-cost ratio 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, it’s recommended to review AWS’s published performance and cost benchmarks to decide based on your specific use case.

Separating production and non-production deployments is more cost-efficient and flexible.

If you combine both into a single instance:

• You’ll need to size the deployment to meet production requirements, which means higher capacity and longer data retention—even for non-production activities
• Full monitoring and autoscaling will be applied regardless of whether your workload is for testing or live use.
• As a result, overall costs are higher because you’re paying production-level prices for non-production work

When you separate them:

• You can use smaller instance sizes and shorter data retention for non-production, which greatly reduces cost
• Autoscaling is enabled only for production, so non-production deployments avoid unnecessary scale-ups
• You also get the benefit of clearer monitoring boundaries and easier environment management

Recommendation: Keep separate deployments for production and non-production. This gives you better control over costs, monitoring, and environment-specific settings.

Currently, sizing changes are done by submitting a support request (SR). However, we are working on a self-service feature that will allow you to adjust the sizing directly through the portal.

It’s recommended to keep separate deployments for prod and non-prod. Use lower data retention and smaller sizing for non-prod to optimise costs.

Every deployment has unique data usage patterns, retention needs, and sizing requirements—so there’s no one-size-fits-all approach.

• To get tailored help, you can raise a support request (SR). The StackOps team can work with you through a 1:1 cost clinic session to review your setup and identify ways to optimise.

Common tips:

• Use smaller instance sizes for lower environments (e.g., dev, staging).
• Reserve larger instances for production environments where performance is critical.
• Review your data ingestion volume and retention settings—these are major cost drivers.

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.

Although billing officially starts on 1 September ‘25, we strongly encourage all users to delete unused instances, by 31 July ‘25 to:

• Monitor actual usage in August ‘25
• Avoid accidental charges
• Prepare for billing in September

It’s recommended to have separate deployments for production and non-production environments. A dedicated non-production deployment allows your team to test and optimise more effectively.For cost optimisation, we recommend using smaller instance sizes and setting a shorter data retention period for non-production environments.

Autoscaling is enabled by default only for production deployments. It does not scale up multiple tiers at once—it increases one tier at a time, based on your usage. This helps avoid sudden jumps in cost.

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 the deployment details via the Console.

If your deployment is scaling up too aggressively, you can raise a support request (SR) to adjust the autoscaling configuration to better suit your budget.

If you’re facing security concerns with the Elastic Agent image, the best approach is to raise a support ticket. Our team will assess the issue and advise on the next steps.

Yes, you can. But note that non-production instances do not have the same level of monitoring and have shorter data retention compared to production ones.

It’s okay if you’re doing testing or trying things out. But if you need full production-level monitoring, it’s better to use a production instance.

Production instances receive stricter monitoring compared to non-production ones. Our Level 1 operations team actively monitors production instances and behind the scenes alerts. For production environment we have more stringent alert rules in place and the data retention period for production logs is longer — for example, audit logs from central monitoring are retained for up to one year, whereas non-production logs are typically kept for less than three months.

If you go into Explorer mode and view the logs, you’ll also see that audit logs from our central monitoring are available for your production deployment. For details, refer to How to review audit trails.

No, you don’t need to install the Elastic Agent. You can use OpenTelemetry to ingest data into StackOps Elastic directly.

It depends on the type of integration you’re using. For example, if you’re using APM, then one of the coordinating or APM server nodes will be impacted. The rest of the components — such as hot data nodes — should remain largely unaffected.

No, Elastic version upgrades in StackOps are not automatic. When a new version becomes available, we will announce it and provide a process for users to initiate the upgrade.

That said, we’re actively working on a self-service feature that will allow you to trigger upgrades directly from the interface. This feature is still in progress and will be rolled out in a future update.

This is something we’re currently discussing with Elastic. The goal is to eventually move towards a single agent based on OpenTelemetry, supporting APM, infra monitoring, and logging — often referred to as a zero-code implementation.

Right now, it’s still under exploration, but the direction is to adopt open standards and unified agents in the future.