Amazon OpenSearch – Consider Graviton Instances

The Amazon OpenSearch Graviton policy flags Amazon OpenSearch Service domains that run x86 instance types such as m5.xlarge.search and recommends the AWS Graviton equivalent, such as m6g.xlarge.search. Graviton instances cost less per hour than x86 instances with the same vCPU count and memory, and AWS reports faster indexing and query performance on them. Apply this policy to any aws_opensearch_domain whose data or dedicated master nodes use an x86 instance type with a Graviton equivalent.

Why This Policy Matters

How It Helps Reduce Cloud Costs

Amazon OpenSearch Service bills each node by the hour for as long as the domain runs. Search and log analytics domains usually run around the clock, so the hourly instance rate becomes a fixed monthly cost.

AWS Graviton processors are Arm-based CPUs designed by AWS. Amazon OpenSearch Service supports Graviton2 instance families (M6g, C6g, R6g, R6gd) and Graviton3 families (M7g, C7g, R7g, R7gd).

For the same size, a Graviton instance matches the x86 instance on vCPU count and memory. An m6g.xlarge.searchand an m5.xlarge.search both have 4 vCPUs and 16 GiB of memory.

AWS benchmarks on Amazon OpenSearch Service report up to 38% higher indexing throughput and up to 40% better query performance on Graviton2 compared with M5, C5, and R5 instances. Results vary by workload and instance size.

Amazon OpenSearch Service is a managed service, so the processor architecture is invisible to clients that call the OpenSearch REST API. This makes the Graviton switch one of the lowest-effort cost changes available for a search tier.

Potential Savings

The Amazon OpenSearch Graviton policy saves money because the Graviton instance costs less per hour than the x86 instance it replaces.

Monthly figures assume 730 hours at US East (N. Virginia) on-demand rates. Prices vary by region and purchase option, and storage is billed separately.

Moving one m5.xlarge.search node to m6g.xlarge.search saves about $20 per month, or roughly $237 per year. A domain with six data nodes multiplies that saving by six, because every node in the domain changes type.

Graviton3 (m7g) costs slightly more per hour than Graviton2 (m6g) but still less than m5. Teams choosing between them should weigh the hourly rate against the Graviton3 performance gain for their workload.

Implementation Guide

Infrastructure-as-Code Example (Terraform)

The following examples show an Amazon OpenSearch Service domain on x86 instance types, and the corrected configuration on Graviton.

Non-compliant configuration: OpenSearch domain on m5 data nodes and r5 master nodes

resource "aws_opensearch_domain" "logs" {
  domain_name    = "app-logs"
  engine_version = "OpenSearch_2.13"

  cluster_config {
    instance_type            = "m5.xlarge.search"
    instance_count           = 6
    dedicated_master_enabled = true
    dedicated_master_type    = "r5.large.search"
    dedicated_master_count   = 3
    zone_awareness_enabled   = true

    zone_awareness_config {
      availability_zone_count = 3
    }
  }

  ebs_options {
    ebs_enabled = true
    volume_type = "gp3"
    volume_size = 500
  }
}

resource "aws_opensearch_domain" "logs" {
  domain_name    = "app-logs"
  engine_version = "OpenSearch_2.13"

  cluster_config {
    instance_type            = "m5.xlarge.search"
    instance_count           = 6
    dedicated_master_enabled = true
    dedicated_master_type    = "r5.large.search"
    dedicated_master_count   = 3
    zone_awareness_enabled   = true

    zone_awareness_config {
      availability_zone_count = 3
    }
  }

  ebs_options {
    ebs_enabled = true
    volume_type = "gp3"
    volume_size = 500
  }
}

resource "aws_opensearch_domain" "logs" {
  domain_name    = "app-logs"
  engine_version = "OpenSearch_2.13"

  cluster_config {
    instance_type            = "m5.xlarge.search"
    instance_count           = 6
    dedicated_master_enabled = true
    dedicated_master_type    = "r5.large.search"
    dedicated_master_count   = 3
    zone_awareness_enabled   = true

    zone_awareness_config {
      availability_zone_count = 3
    }
  }

  ebs_options {
    ebs_enabled = true
    volume_type = "gp3"
    volume_size = 500
  }
}

This configuration pays the x86 hourly rate on nine nodes for the same vCPU count and memory a Graviton instance provides at a lower price. This is a common source of wasted spend in search domains created before Graviton instance types were available.

Compliant configuration: OpenSearch domain on m6g data nodes and r6g master nodes

resource "aws_opensearch_domain" "logs" {
  domain_name    = "app-logs"
  engine_version = "OpenSearch_2.13"

  cluster_config {
    instance_type            = "m6g.xlarge.search"
    instance_count           = 6
    dedicated_master_enabled = true
    dedicated_master_type    = "r6g.large.search"
    dedicated_master_count   = 3
    zone_awareness_enabled   = true

    zone_awareness_config {
      availability_zone_count = 3
    }
  }

  ebs_options {
    ebs_enabled = true
    volume_type = "gp3"
    volume_size = 500
  }
}

resource "aws_opensearch_domain" "logs" {
  domain_name    = "app-logs"
  engine_version = "OpenSearch_2.13"

  cluster_config {
    instance_type            = "m6g.xlarge.search"
    instance_count           = 6
    dedicated_master_enabled = true
    dedicated_master_type    = "r6g.large.search"
    dedicated_master_count   = 3
    zone_awareness_enabled   = true

    zone_awareness_config {
      availability_zone_count = 3
    }
  }

  ebs_options {
    ebs_enabled = true
    volume_type = "gp3"
    volume_size = 500
  }
}

resource "aws_opensearch_domain" "logs" {
  domain_name    = "app-logs"
  engine_version = "OpenSearch_2.13"

  cluster_config {
    instance_type            = "m6g.xlarge.search"
    instance_count           = 6
    dedicated_master_enabled = true
    dedicated_master_type    = "r6g.large.search"
    dedicated_master_count   = 3
    zone_awareness_enabled   = true

    zone_awareness_config {
      availability_zone_count = 3
    }
  }

  ebs_options {
    ebs_enabled = true
    volume_type = "gp3"
    volume_size = 500
  }
}

The functional change is the instance_type and dedicated_master_type values. Both must change together, because Amazon OpenSearch Service does not allow Graviton and non-Graviton instances in the same domain.

Step-by-Step Fix Instructions

1. Search Terraform code for instance_type and dedicated_master_type values on aws_opensearch_domainresources that use x86 families such as m5, r5, or c5.

2. Check shared modules, .tfvars files, and variable defaults. The instance type often sits in a variable "instance_type" default rather than in the resource block.

3. Confirm the engine version meets the Graviton minimum. AWS requires Elasticsearch 7.9 or later, or any OpenSearch version, for M6g, C6g, and R6g instances.

4. Pick the Graviton instance with the same size suffix, for example m5.xlarge.search to m6g.xlarge.search, or r5.large.search to r6g.large.search.

5. Change every x86 node type in the domain, including dedicated master nodes, and run terraform plan. Confirm the plan shows an in-place update to cluster_config, not a domain replacement.

6. Apply the change to a non-production Amazon OpenSearch Service domain first. A data node instance type change runs as a blue/green deployment, so watch cluster health, indexing rate, and search latency in Amazon CloudWatch until it completes. A dry run of the domain update in the AWS console or API shows whether a change will trigger blue/green.

7. Roll the change to production during a low-traffic period.

8. Add Infracost to CI/CD so new x86 instance types are flagged in pull requests before they merge.

Best Practices

• Default new Amazon OpenSearch Service domains to Graviton instance types in shared Terraform modules, and require a stated reason to use an x86 instance type.

• Migrate development and staging domains first. These carry the least risk if a plugin or performance issue appears.

• Review reserved instances before migrating. An Amazon OpenSearch Service reserved instance applies to one instance type, so time the switch with the reservation end date.

• Upgrade older Elasticsearch domains to OpenSearch or Elasticsearch 7.9 or later before the instance change.

• This policy targets instance type only. Right-sizing an over-provisioned domain is a separate decision that often saves more than the architecture change.

Tools and Scripts

How does Infracost detect x86 Amazon OpenSearch instance types automatically?

The Amazon OpenSearch Graviton policy is available in Infracost, including in the free trial. Enable FinOps policies in Infracost Cloud and run Infracost in CI/CD. Each pull request that adds or changes an aws_opensearch_domain with an x86 instance type then gets a finding in the PR comment.

The same Infracost pull request comment shows the estimated monthly cost of the change. Reviewers see what a six-node m5.xlarge.search domain costs before it merges, not on next month's AWS bill.

Engineers can dismiss a finding in the pull request with a reason, for example a workload that has not been benchmarked on Graviton yet. FinOps teams can see those dismissals and the reasons behind them.

Infracost Cloud also tracks the percentage of issues fixed, the open issues that remain, and the new issues prevented in pull requests. This lets platform and FinOps teams burn down existing x86 OpenSearch domains over time and report measurable progress.

To find x86 Amazon OpenSearch Service instance types in a Terraform codebase:

grep -rnE '(m5|r5|c5|m4|r4|c4)\.[0-9]*x?large\.search' --include="*.tf" --include="*.tfvars"

grep -rnE '(m5|r5|c5|m4|r4|c4)\.[0-9]*x?large\.search' --include="*.tf" --include="*.tfvars"

grep -rnE '(m5|r5|c5|m4|r4|c4)\.[0-9]*x?large\.search' --include="*.tf" --include="*.tfvars"

To list running Amazon OpenSearch Service domains and their node types with the AWS CLI:

for d in $(aws opensearch list-domain-names --query "DomainNames[].DomainName" --output text); do
  aws opensearch describe-domain --domain-name "$d" \
    --query "DomainStatus.{domain:DomainName,data:ClusterConfig.InstanceType,master:ClusterConfig.DedicatedMasterType}" \
    --output table
done

for d in $(aws opensearch list-domain-names --query "DomainNames[].DomainName" --output text); do
  aws opensearch describe-domain --domain-name "$d" \
    --query "DomainStatus.{domain:DomainName,data:ClusterConfig.InstanceType,master:ClusterConfig.DedicatedMasterType}" \
    --output table
done

for d in $(aws opensearch list-domain-names --query "DomainNames[].DomainName" --output text); do
  aws opensearch describe-domain --domain-name "$d" \
    --query "DomainStatus.{domain:DomainName,data:ClusterConfig.InstanceType,master:ClusterConfig.DedicatedMasterType}" \
    --output table
done

If a domain is managed by Terraform, change instance_type in code rather than in the AWS console. Otherwise the next terraform apply sets the old instance type again.

Examples of Impact

Savings from the Amazon OpenSearch Graviton policy scale with node count, because the code change per domain is one or two attributes.

Illustrative example: a production log analytics domain. A platform team runs six m5.xlarge.search data nodes and three r5.large.search dedicated master nodes. Moving to m6g.xlarge.search and r6g.large.search cuts on-demand cost by about $160 per month, roughly $1,900 per year, with no client code changes.

Illustrative example: a multi-environment search fleet. A team runs 12 r5.large.search nodes across development, staging, and production domains. Switching all of them to r6g.large.search saves about $165 per month at US East on-demand rates, and the non-production domains become a low-risk first step.

(These are illustrative scenarios, not specific customer accounts.)

Considerations and Caveats

The Amazon OpenSearch Graviton switch is low risk for most domains, but engine versions, domain-wide instance rules, and reservations are where it goes wrong.

• Minimum engine version. M6g, C6g, and R6g instances require Elasticsearch 7.9 or later, or any OpenSearch version. Older Elasticsearch domains need an engine upgrade first.

• No mixed architectures. Amazon OpenSearch Service does not allow Graviton and non-Graviton instances in the same domain. Data nodes and dedicated master nodes must move together.

• Blue/green deployment. A data node instance type change creates a new set of nodes and migrates shards before removing the old ones. AWS bills both node sets for the first hour, and large domains can take hours to finish, so schedule the change for a quiet period.

• Reserved instances do not move. Reserved instances bought for an x86 instance type keep billing until they expire, even after the domain moves to Graviton.

• Provider-specific. This policy targets Amazon OpenSearch Service through the aws Terraform provider. Self-managed OpenSearch on EC2 falls under the EC2 Graviton policy instead.

Related Policies and Concepts

• AWS EC2 - consider using Graviton instances: the Compute-group policy for moving x86 EC2 instances, including self-managed OpenSearch clusters, to Arm-based Graviton types.

• Amazon RDS - consider using Graviton instances: the same Graviton cost change applied to aws_db_instanceclasses such as db.m6g.

• Amazon ElastiCache - consider using Graviton instances: the Graviton cost change for cache nodes, often migrated alongside search tiers.

• Amazon OpenSearch - consider using latest generation instances for m family instances: the generation upgrade for general-purpose OpenSearch nodes, a fallback when a domain cannot move to Graviton yet.

• OpenSearch - consider upgrading version to avoid extended support costs: an engine upgrade is often needed before a Graviton switch, since older Elasticsearch versions do not support Graviton instances.

Frequently Asked Questions (FAQs)

Is this policy supported in Infracost?

Yes. The Amazon OpenSearch Graviton policy is supported in Infracost and available in the free trial. Infracost flags OpenSearch domains that use x86 instance types in pull request comments. The team can then switch the instance type before merge.

Can this policy be customized?

Yes. Teams choose which Infracost policies are enabled in Infracost Cloud, including the Amazon OpenSearch Graviton policy. Engineers can also dismiss a specific finding with a stated reason, such as a workload not yet benchmarked on Graviton. FinOps teams can review that reason.

Does Infracost automatically fix violations?

No. Infracost reports each Amazon OpenSearch Service instance type that has a Graviton equivalent and shows the cost of the change in the pull request. Changing the instance type and testing the domain on Graviton is a decision the team makes and applies.

Is this policy cloud-agnostic?

No. The Amazon OpenSearch Graviton policy targets Amazon OpenSearch Service through the aws Terraform provider. Search services on Azure and Google Cloud use their own instance tiers and resource names, and none of them use AWS Graviton processors.

Do applications need code changes to use Amazon OpenSearch Graviton instances?

Usually not. Applications reach Amazon OpenSearch Service through its REST API, so client code is not compiled for the node's processor. The Amazon OpenSearch Service domain must still run Elasticsearch 7.9 or later, or any OpenSearch version.

Can I mix Graviton and x86 instances in one Amazon OpenSearch Service domain?

No. Amazon OpenSearch Service does not allow Graviton and non-Graviton instances in the same domain. Data nodes and dedicated master nodes must all move to Graviton instance types in the same change.

How often should I review Amazon OpenSearch Service instance types?

Teams running Infracost in CI/CD get an Amazon OpenSearch Graviton check on every pull request that touches an OpenSearch domain. For domains already running, a quarterly review of Amazon OpenSearch Service instance types is a reasonable cadence for most teams.