Incorporate new OR1 Instance Types into Capacity Plan

[chelma]

Description

AWS OpenSearch recently announced [1] a new instance type (OR1) [2][3] which is cost-optimized for "ingestion-heavy workloads". Given our project ingest lots of data with relatively few queries, updates, etc, the new instance type could offer substantial savings for our users.

We should add the new OR1 types into our capacity plan.

[1] https://aws.amazon.com/about-aws/whats-new/2023/11/or1-amazon-opensearch-service/ [2] https://docs.aws.amazon.com/opensearch-service/latest/developerguide/supported-instance-types.html [3] https://aws.amazon.com/opensearch-service/pricing/

Acceptance Criteria

• Incorporate OR1 types into the AIO capacity planning code OR provide an explanation of why they are not optimal

[chelma]

I took a look at the pricing for the new instances. In our use-case, we want as much EBS storage as possible for as cheaply as possible. The maximum EBS volume size is tied to the instance type/size. So really we want to get the instance type that maximizes EBS volume size while minimizing instance cost, and obeying the OpenSearch constraints on number of instances in the cluster, etc. Taking a look at our existing pricing plan compared to the new instance types:

EXISTING PLAN

instance_type       max_ebs_size_gb  max_nodes   $_per_gb_hr
------------------------------------------------------------
t3.small.search     100              2           $0.00036
t3.medium.search    200              6           $0.00037
r6g.large.search    1024             80          $0.00016
r6g.4xlarge.search  6*1024           80          $0.00022
r6g.12xlarge.search 12*1024          80          $0.00033

NEW INSTANCE TYPES BELOW

instance_type       max_ebs_size_gb  max_nodes   $_per_gb_hr
------------------------------------------------------------
or1.medium.search   400              80          $0.00026
or1.large.search    800              80          $0.00026
or1.xlarge.search   1.5*1024         80          $0.00027
or1.2xlarge.search  3*1024           80          $0.00027
or1.4xlarge.search  6*1024           80          $0.00027
or1.8xlarge.search  12*1024          80          $0.00027
or1.12xlarge.search 18*1024          80          $0.00027
or1.16xlarge.search 24*1024          80          $0.00027

It appears the new instance types only become cost-competitive for large OpenSearch clusters needing more than 480 TB of storage. Switching out the r6g.12xlarge.search type for or1.8xlarge.search does provide some modest cost savings (~18% on that line item).

[chelma]

The OR1 class of instances is graviton-based, which means we need the master nodes for such a cluster to be graviton as well, but our existing capacity planning code already does that for large clusters.

[chelma]

Code merged; acceptance criteria met. Resolving.