Running an outdated OpenSearch version on AWS triggers extended support charges that increase your monthly instance costs by a fixed percentage. This FinOps policy identifies OpenSearch domains running versions eligible for extended support and recommends upgrading to a current, fully supported version to eliminate that surcharge.
Use this policy when auditing OpenSearch infrastructure costs in IaC reviews, FinOps sprints, or CI/CD pipelines.
Why This Policy Matters
AWS charges an additional fee for OpenSearch Service domains running versions that have reached end of standard support. This fee applies automatically. There is no opt-out unless you upgrade the engine version.
The cost increase is not a one-time charge. It compounds across every instance in your domain, every month, for as long as the outdated version remains in use.
How It Helps Reduce Costs
Extended support pricing adds a per-node surcharge on top of your existing instance cost. This applies to every data node, dedicated primary node, and UltraWarm node in your domain.
Teams running multiple OpenSearch domains across environments (dev, staging, production) can accumulate significant waste from this single configuration issue. Upgrading to a supported version removes the surcharge entirely.
Potential Savings
Consider a single m7g.medium.search instance running at approximately $49 per month under standard pricing.
If that instance is under extended support, the monthly cost increases by approximately 18%, adding around $8.82 per month per node.
A domain with 3 data nodes and 3 dedicated primary nodes (6 nodes total) would incur an additional $52.92 per month, or over $635 per year, from extended support fees alone. Multiply that across multiple domains or accounts and the waste grows quickly.
Implementation Guide
Infrastructure-as-Code Example (Terraform)
The following examples show a non-compliant OpenSearch domain configuration and the corrected version.
Non-compliant configuration (triggers extended support charges):
resource "aws_opensearch_domain" "example" {
domain_name = "my-search-domain"
engine_version = "OpenSearch_1.3"
cluster_config {
instance_type = "m7g.medium.search"
instance_count = 3
}
ebs_options {
ebs_enabled = true
volume_size = 20
}
}OpenSearch 1.3 is no longer under standard support. This configuration will incur extended support charges automatically.
Compliant configuration (avoids extended support charges):
resource "aws_opensearch_domain" "example" {
domain_name = "my-search-domain"
engine_version = "OpenSearch_2.17"
cluster_config {
instance_type = "m7g.medium.search"
instance_count = 3
}
ebs_options {
ebs_enabled = true
volume_size = 20
}
}Upgrading engine_version to a currently supported release eliminates the extended support surcharge. The instance type, node count, and storage configuration remain unchanged.
Identifying Which Versions Trigger Extended Support
AWS publishes the list of OpenSearch and Elasticsearch versions that have entered extended support. As of 2025, versions under extended support include:
- Elasticsearch 1.5, 2.3, 5.x, 6.x, 7.x
- OpenSearch 1.0, 1.1, 1.2, 1.3
Check the AWS OpenSearch Service documentation for the current list, as new versions enter extended support on a rolling schedule.
Manual Step-by-Step Instructions
- Audit existing domains. List all OpenSearch Service domains across your AWS accounts. Use the AWS CLI:
aws opensearch list-domain-names --query 'DomainNames[*].DomainName' --output text- Check engine versions. For each domain, retrieve the current engine version:
aws opensearch describe-domain \
--domain-name <your-domain-name> \
--query 'DomainStatus.EngineVersion'- Compare against the extended support list. Cross-reference each version against the AWS extended support schedule.
- Plan the upgrade path. OpenSearch upgrades must follow a supported upgrade path. You cannot skip major versions in some cases. Use the AWS console or API to check available upgrade options:
aws opensearch get-compatible-versions \
--domain-name <your-domain-name>- Test in non-production first. Apply the version upgrade to a dev or staging domain before touching production.
- Apply the upgrade in Terraform. Update engine_version in your Terraform configuration and run terraform apply. AWS will perform an in-place blue/green upgrade.
- Validate and monitor. Confirm the domain is healthy post-upgrade. Check cluster health, index availability, and application behavior.
- Update your IaC baseline. Once upgraded, enforce the compliant version via policy-as-code to prevent regressions.
Best Practices
- Pin to a specific supported version in Terraform rather than relying on defaults. This prevents unintentional drift.
- Automate version audits as part of your CI/CD pipeline so every pull request is checked before merge.
- Track AWS end-of-support announcements for OpenSearch versions and schedule upgrades at least 90 days before a version enters extended support.
- Use Infracost in your pull request workflow to surface extended support cost impacts before infrastructure changes are applied.
- Upgrade dev and staging environments first to validate compatibility and reduce production upgrade risk.
- Document your upgrade schedule in your FinOps backlog so cost reduction work is tracked and measurable.
Tools and Scripts to Help Implement
Infracost detects this policy automatically and is available in the free trial. When Infracost scans your Terraform configuration, it identifies OpenSearch domains running versions under extended support and calculates the cost impact, including the extended support surcharge.
This allows FinOps and platform engineering teams to:
- See the cost difference between compliant and non-compliant configurations directly in pull requests
- Block or flag infrastructure changes that introduce extended support costs
- Track outstanding violations across all repositories and measure reduction over time
Infracost integrates with GitHub, GitLab, Bitbucket, and Azure DevOps. Teams can use it to enforce this policy as a pre-merge gate, ensuring no new non-compliant OpenSearch domains are deployed.
Examples of Impact
Example 1: Single-domain engineering team
A team running one OpenSearch domain with 3 m7g.medium.search data nodes on OpenSearch 1.3 pays approximately $147 per month for compute. With extended support charges at 18%, that adds $26.46 per month, or $317.52 per year, for no additional capability. Upgrading to OpenSearch 2.17 removes that cost entirely.
Example 2: Multi-account platform environment
A platform team manages 8 OpenSearch domains across development, staging, and production accounts. Each domain uses 2 nodes averaging $60 per month per node. If all 8 domains are on extended support versions, the additional monthly cost is approximately $172.80, or $2,073.60 per year. Upgrading all domains to supported versions eliminates this spend with no change to instance sizing or storage.
Considerations and Caveats
- Upgrade compatibility. Not all applications are compatible with newer OpenSearch versions. Validate API and plugin compatibility before upgrading production workloads.
- Upgrade path restrictions. AWS requires following a supported upgrade sequence. Some version jumps require intermediate upgrades. Plan accordingly.
- Downtime risk. OpenSearch upgrades on AWS use blue/green deployments, which minimizes downtime. However, some upgrade scenarios may cause brief disruptions. Test upgrade procedures in lower environments first.
- Index compatibility. Older index formats may require reindexing after a major version upgrade. Check AWS documentation for index compatibility requirements.
- Extended support may be intentional. In rare cases, teams may temporarily accept extended support costs while completing a long-term migration. If so, track the cost explicitly in your FinOps reporting and set a firm upgrade deadline.
- New versions entering extended support. AWS periodically moves additional versions into extended support. A domain that is compliant today may become non-compliant in the future without a proactive upgrade strategy.