Commitment Groups – the 5-minute guide

1️⃣ What is a commitment group?

A commitment group is the set of AWS resources that can be covered by one right-sized reservation. All usage and reservations assigned to the same group share identical commercial attributes (region, engine, licence model, etc.). When you purchase a Reserved Instance (RI) or Savings Plan, its benefit automatically applies to every resource inside the matching commitment group. If two resources fall into different commitment groups, they require separate reservations.

2️⃣ High-level cheat-sheet

Service	What must match to share an RI?	Can you mix sizes?
Amazon RDS	Region · Engine · Edition* · Licence model · Instance family (db.r6g)	Yes except Oracle licence-included & SQL Server
Amazon ElastiCache	Region · Cache engine (Redis or Valkey) · Instance family (cache.r6g)	Yes
Amazon Redshift	Region · Node type (ra3.xlplus, dc2.large)	No – each node type is its own group

*Edition is only relevant for Oracle & SQL Server.

If that's all you needed – great! Want the nitty-gritty? Keep reading 👇

---

3️⃣ Amazon RDS — full details

Two instances sharing the same properties below (a.k.a. grouping keys), can be covered by the same reservation.

3.1 Grouping keys

1. Region – RIs never cross regions.
2. Engine – Aurora MySQL, Aurora PostgreSQL, MySQL, PostgreSQL, MariaDB, Oracle, SQL Server.
3. Edition – only for Oracle & SQL Server (Enterprise, Standard Two, Web…).
4. Licence model – license-included, bring-your-own-licence (BYOL) or no licence required.
5. Instance family – e.g. db.r5, db.m6g.
6. Instance size – only when size-flexibility is not allowed (see below).

3.2 Size-flexibility (the RI magic)

AWS lets most RDS engines trade sizes inside the same family:

Engine / licence model	Can mix sizes?	Why
Aurora MySQL / Aurora PostgreSQL	✅	Designed for flexible pooling.
MySQL, PostgreSQL, MariaDB	✅	Standard RDS rule.
Oracle BYOL	✅	Licence handled outside the RI.
Oracle license-included, any SQL Server edition	❌	Licence cost depends on vCPU count – must match exactly.

Example A single db.r5.large RI covers: • 1 db.r5.large • 1/2 db.r5.xlarge • 1/4 db.r5.2xlarge

…but cannot cover db.r6g.large or any SQL Server instance.

---

4️⃣ Amazon ElastiCache — full details

ElastiCache reservations follow simpler rules than RDS. Two cache nodes can share the same reservation when they match on:

1. Region – reservations never cross regions.
2. Cache engine – Redis, Valkey or Memcached (Redis & Valkey belong to the same pool – see 4.3).
3. Instance family – for example cache.r5, cache.m6g. Size-flexibility applies automatically inside the family, so cache.r5.large and cache.r5.xlarge can reuse the same reservation.

4.1 Size-flexibility

ElastiCache supports size-flex for all engines. One cache.r5.large RI therefore covers: • 1 cache.r5.large • ½ cache.r5.xlarge • ¼ cache.r5.2xlarge

…but it cannot cover a Graviton family like cache.r6g.large.

4.2 Quick examples

Scenario	Same group?	Why
cache.r5.large (Redis) vs cache.r5.xlarge (Redis)	✅	Same region, engine + family – size-flex allowed.
cache.r5.large (Redis) vs cache.r5.large (Memcached)	❌	Engine differs.
cache.r5.large (Redis) vs cache.r6g.large (Redis)	❌	Family differs.

4.3 Normalisation units per engine

AWS applies different normalisation factors depending on the cache engine. Redis OSS and Memcached share the same baseline, while Valkey gets a 20 % discount – lower units let a Redis reservation cover more Valkey nodes (AWS docs).

Node size	Redis / Memcached units	Valkey units
micro	0.5	0.4
small	1	0.8
medium	2	1.6
large	4	3.2
xlarge	8	6.4
2xlarge	16	12.8
4xlarge	32	25.6
6xlarge	48	38.4
8xlarge	64	51.2
10xlarge	80	64
12xlarge	96	76.8
16xlarge	128	102.4
24xlarge	192	153.6

Example A Redis OSS reservation for one cache.r7g.4xlarge (32 units) can fully cover the same Valkey node (25.6 units) and still has 6.4 spare units – enough to cover one cache.r7g.xlarge Valkey node in the same family.

---

5️⃣ Amazon Redshift — full details

Redshift reservations follow the simplest rules of all. Unlike RDS and ElastiCache, there is no size-flexibility – each node type is its own commitment group.

5.1 Grouping keys

1. Region – reservations never cross regions.
2. Node type – the full node type (ra3.xlplus, dc2.large, ds2.xlarge).

That's it. No engine variants, no licence models, no instance families.

5.2 No size-flexibility

Each Redshift node type forms its own commitment group. A reservation for ra3.xlplus cannot cover ra3.4xlarge or any other node type.

5.3 Node type families

Redshift has three main node type families:

Family	Optimised for	Example types
RA3	Managed storage (separate compute & storage)	ra3.xlplus, ra3.4xlarge, ra3.16xlarge
DC2	Compute-intensive (SSD-backed)	dc2.large, dc2.8xlarge
DS2	Storage-intensive (HDD-backed, legacy)	ds2.xlarge, ds2.8xlarge

5.4 Quick examples

Scenario	Same group?	Why
ra3.xlplus (us-east-1) vs ra3.xlplus (us-east-1)	✅	Same region + node type.
ra3.xlplus (us-east-1) vs ra3.4xlarge (us-east-1)	❌	Different node types.
ra3.xlplus (us-east-1) vs ra3.xlplus (eu-west-1)	❌	Different regions.
dc2.large vs ra3.xlplus	❌	Different node types (different families).