When working with the AWS EC2 API (particularly describe-instances
), you'll encounter reservation IDs before seeing actual instance IDs. This architectural design reflects how EC2 internally manages instance launches:
# Sample describe-instances response structure
{
"Reservations": [
{
"ReservationId": "r-1234567890abcdef0",
"Instances": [
{
"InstanceId": "i-1234567890abcdef0",
# ... other instance details
}
]
}
]
}
The reservation ID becomes particularly important in these scenarios:
- Bulk launches: When using
RunInstances
withMaxCount
> 1 - Auto Scaling Groups: Instances launched in the same scaling event
- Spot Fleets: Multiple spot instances requested simultaneously
# Launching multiple instances in one request
aws ec2 run-instances \
--image-id ami-0abcdef1234567890 \
--count 3 \
--instance-type t3.medium
# All 3 instances will share the same reservation ID
For robust instance filtering in your snapshot automation:
import boto3
def get_running_instances():
ec2 = boto3.client('ec2')
response = ec2.describe_instances(Filters=[{'Name': 'instance-state-name', 'Values': ['running']}])
instances = []
for reservation in response['Reservations']:
for instance in reservation['Instances']:
instances.append(instance['InstanceId'])
return instances
Key differences:
Reservation ID | Reserved Instance |
---|---|
API response structure | Billing discount model |
Tracks launch requests | Capacity reservation |
Ephemeral | 1-3 year commitment |
- Terminated instances may temporarily appear in reservations
- Spot instances can have complex reservation patterns
- Cross-account sharing affects reservation visibility
When working with AWS EC2's describe-instances
API call, you'll notice the response structure groups instances under "Reservations". This isn't about Reserved Instances (the billing concept) - it's an implementation detail of EC2's launch architecture.
# Sample describe-instances response structure
{
"Reservations": [
{
"ReservationId": "r-1234567890abcdef0",
"Instances": [
{
"InstanceId": "i-1234567890abcdef0",
# ... other instance details
}
]
}
]
}
A single reservation ID can represent multiple instances in these scenarios:
- Bulk launches: When using
RunInstances
withMaxCount
> 1 - Auto Scaling Groups: Instances launched together in a scaling event
- Spot Fleets: Multiple spot instances requested simultaneously
# Launching multiple instances in one request
aws ec2 run-instances \
--image-id ami-0abcdef1234567890 \
--count 3 \
--instance-type t3.medium
# These 3 instances will share one ReservationId
When processing describe-instances
output, you need to:
- Iterate through the Reservations array first
- Then process each Instance within the reservation
# Python example processing describe-instances response
import boto3
ec2 = boto3.client('ec2')
def get_running_instances():
response = ec2.describe_instances(Filters=[{'Name': 'instance-state-name', 'Values': ['running']}])
instance_ids = []
for reservation in response['Reservations']:
for instance in reservation['Instances']:
instance_ids.append(instance['InstanceId'])
return instance_ids
Key behaviors to understand:
- A reservation ID persists through instance stops/starts
- Terminating all instances in a reservation doesn't immediately clear the reservation from API responses
- Reservation IDs are region-specific
The reservation ID essentially represents the initial launch context of your instances, which is why it appears in monitoring and API responses even though it's not a concept you typically interact with directly in most workflows.