EC2 InvalidParameterCombination: Resolving Instance Configuration Errors

You are launching a new EC2 instance — or worse, your auto-scaling group is trying to launch one during a traffic spike — and it fails with this:

An error occurred (InvalidParameterCombination) when calling the RunInstances
operation: The instance type 't3.micro' is not supported in availability zone
'us-east-1e'. Please try another availability zone.

Or this variation:

An error occurred (InvalidParameterCombination) when calling the RunInstances
operation: Non-Nitro instance types do not support the 'gp3' EBS volume type
for the root volume.

Or perhaps the most confusing one:

An error occurred (InvalidParameterCombination) when calling the RunInstances
operation: The architecture 'arm64' of the specified instance type does not
match the architecture 'x86_64' of the specified AMI.

The InvalidParameterCombination error means you have specified a set of EC2 parameters that are mutually incompatible. AWS cannot launch the instance because the combination of instance type, AMI, availability zone, volume type, or other settings conflict with each other. The error message usually tells you what is wrong, but not always clearly.

Here is a complete guide to every common InvalidParameterCombination scenario and how to resolve each one.

Step 1: Understand What You Requested

Before debugging, get a clear picture of the launch parameters. If you used a launch template, inspect it:

aws ec2 describe-launch-template-versions \
  --launch-template-id lt-0abc123def456 \
  --versions '$Latest' \
  --query 'LaunchTemplateVersions[0].LaunchTemplateData.{
    InstanceType: InstanceType,
    ImageId: ImageId,
    SubnetId: NetworkInterfaces[0].SubnetId,
    EbsVolumes: BlockDeviceMappings[*].{
      Device: DeviceName,
      VolumeType: Ebs.VolumeType,
      Size: Ebs.VolumeSize
    },
    Placement: Placement
  }'

If you used an auto-scaling group, check its configuration:

aws autoscaling describe-auto-scaling-groups \
  --auto-scaling-group-names my-asg \
  --query 'AutoScalingGroups[0].{
    LaunchTemplate: LaunchTemplate,
    MixedInstancesPolicy: MixedInstancesPolicy,
    AvailabilityZones: AvailabilityZones,
    VPCZoneIdentifier: VPCZoneIdentifier
  }'

Root Cause 1: Instance Type Not Available in the Availability Zone

Not every instance type is available in every availability zone. Newer instance types like Graviton-based instances may not be in older AZs, and some specialized instances (like p4d GPU instances) are only available in specific zones.

Check which AZs support your instance type:

aws ec2 describe-instance-type-offerings \
  --location-type availability-zone \
  --filters Name=instance-type,Values=t3.micro \
  --query 'InstanceTypeOfferings[*].[Location, InstanceType]' \
  --output table

To see all instance types available in a specific AZ:

aws ec2 describe-instance-type-offerings \
  --location-type availability-zone \
  --filters Name=location,Values=us-east-1a \
  --query 'InstanceTypeOfferings[*].InstanceType' \
  --output text | tr '\t' '\n' | sort

The fix depends on your situation:

For single instances: Specify a different AZ in the --placement parameter or subnet selection
For auto-scaling groups: Use mixed instance types with multiple AZs:

{
    "MixedInstancesPolicy": {
        "LaunchTemplate": {
            "LaunchTemplateSpecification": {
                "LaunchTemplateId": "lt-0abc123def456",
                "Version": "$Latest"
            },
            "Overrides": [
                {"InstanceType": "t3.micro"},
                {"InstanceType": "t3a.micro"},
                {"InstanceType": "t2.micro"}
            ]
        },
        "InstancesDistribution": {
            "OnDemandPercentageAboveBaseCapacity": 0,
            "SpotAllocationStrategy": "capacity-optimized"
        }
    }
}

This gives the auto-scaling group multiple instance types to choose from, so it can find one available in each AZ.

Root Cause 2: AMI Architecture Mismatch

You cannot run an x86_64 AMI on an ARM (Graviton) instance, or vice versa. This commonly happens when teams switch to Graviton instances for cost savings but forget to update the AMI.

Check the AMI architecture:

aws ec2 describe-images \
  --image-ids ami-0abc123def456789 \
  --query 'Images[0].{
    Architecture: Architecture,
    Name: Name,
    PlatformDetails: PlatformDetails,
    RootDeviceType: RootDeviceType,
    VirtualizationType: VirtualizationType
  }'

Check which architectures the instance type supports:

aws ec2 describe-instance-types \
  --instance-types m7g.large \
  --query 'InstanceTypes[0].{
    InstanceType: InstanceType,
    SupportedArchitectures: ProcessorInfo.SupportedArchitectures,
    SupportedVirtualizationTypes: SupportedVirtualizationTypes
  }'

Common architecture mappings:

Instance Family	Architecture	Processor
m5, c5, r5, t3	x86_64	Intel/AMD
m5a, c5a, r5a, t3a	x86_64	AMD
m7g, c7g, r7g, t4g	arm64	AWS Graviton3
m6g, c6g, r6g	arm64	AWS Graviton2
a1	arm64	AWS Graviton (1st gen)

To find the right AMI for your target architecture:

# Find the latest Amazon Linux 2023 AMI for arm64
aws ec2 describe-images \
  --owners amazon \
  --filters \
    "Name=name,Values=al2023-ami-2023*" \
    "Name=architecture,Values=arm64" \
    "Name=state,Values=available" \
  --query 'sort_by(Images, &CreationDate)[-1].{
    ImageId: ImageId,
    Name: Name,
    Architecture: Architecture,
    CreationDate: CreationDate
  }'

# Find the latest Amazon Linux 2023 AMI for x86_64
aws ec2 describe-images \
  --owners amazon \
  --filters \
    "Name=name,Values=al2023-ami-2023*" \
    "Name=architecture,Values=x86_64" \
    "Name=state,Values=available" \
  --query 'sort_by(Images, &CreationDate)[-1].{
    ImageId: ImageId,
    Name: Name,
    Architecture: Architecture,
    CreationDate: CreationDate
  }'

If you use SSM Parameter Store for AMI lookups (recommended), use the architecture-specific paths:

# x86_64
aws ssm get-parameter \
  --name /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --query 'Parameter.Value' \
  --output text

# arm64
aws ssm get-parameter \
  --name /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-arm64 \
  --query 'Parameter.Value' \
  --output text

Root Cause 3: EBS Volume Type Incompatibility

Certain EBS volume types are not supported with certain instance types. The most common issue is using gp3 or io2 volumes with older instance types that do not support the NVMe interface.

Check which EBS features your instance type supports:

aws ec2 describe-instance-types \
  --instance-types m5.large \
  --query 'InstanceTypes[0].{
    InstanceType: InstanceType,
    EbsOptimized: EbsInfo.EbsOptimizedSupport,
    NvmeSupport: EbsInfo.NvmeSupport,
    EncryptionSupport: EbsInfo.EncryptionSupport
  }'

The general rules:

Nitro-based instances (m5, c5, r5, t3, and all newer families): Support all volume types including gp3, io2, and io2 Block Express
Non-Nitro instances (m4, c4, r4, t2, and older): Support gp2, io1, st1, sc1, and standard magnetic. May not support gp3 or io2 as root volumes
io2 Block Express: Only supported on specific instance types like r5b

To check if an instance is Nitro-based:

aws ec2 describe-instance-types \
  --instance-types t2.micro t3.micro m4.large m5.large \
  --query 'InstanceTypes[*].{
    InstanceType: InstanceType,
    Hypervisor: Hypervisor,
    NvmeSupport: EbsInfo.NvmeSupport
  }' \
  --output table

Nitro instances show Hypervisor: nitro while older instances show Hypervisor: xen.

Root Cause 4: Placement Group Constraints

Placement groups impose strict requirements on instance types. A cluster placement group requires all instances to be the same type, and partition placement groups have limits on the number of partitions per AZ.

# Check placement group details
aws ec2 describe-placement-groups \
  --group-names my-placement-group \
  --query 'PlacementGroups[0].{
    GroupName: GroupName,
    Strategy: Strategy,
    State: State,
    PartitionCount: PartitionCount
  }'

Common placement group constraints:

Cluster: All instances must support enhanced networking (ENA). Cannot mix instance types (in practice). Must be in the same AZ.
Spread: Maximum 7 instances per AZ per group. Not all instance types are supported.
Partition: Maximum 7 partitions per AZ. Instances within a partition can be different types.

If you get an InvalidParameterCombination with a placement group, check the instance type's network capabilities:

aws ec2 describe-instance-types \
  --instance-types c5.xlarge \
  --query 'InstanceTypes[0].{
    InstanceType: InstanceType,
    EnaSupport: NetworkInfo.EnaSupport,
    NetworkPerformance: NetworkInfo.NetworkPerformance,
    PlacementGroupStrategies: PlacementGroupInfo.SupportedStrategies
  }'

Root Cause 5: ENA and EBS-Optimized Flag Mismatches

Some instance types require Enhanced Networking Adapter (ENA) support in the AMI. If the AMI does not have the ENA driver, the launch fails.

Check if the AMI supports ENA:

aws ec2 describe-images \
  --image-ids ami-0abc123def456789 \
  --query 'Images[0].{
    ImageId: ImageId,
    EnaSupport: EnaSupport,
    SriovNetSupport: SriovNetSupport
  }'

Check if the instance type requires ENA:

aws ec2 describe-instance-types \
  --instance-types c5.large \
  --query 'InstanceTypes[0].{
    InstanceType: InstanceType,
    EnaRequired: NetworkInfo.EnaSupport
  }'

If EnaSupport is required for the instance type but the AMI shows EnaSupport: false, you need a different AMI. All modern Amazon-provided AMIs support ENA, but custom or old AMIs may not.

Similarly, some instance types are EBS-optimized by default (and it cannot be turned off), while for others it is optional. Specifying --ebs-optimized on an instance type that does not support it will fail:

# Check EBS optimization support
aws ec2 describe-instance-types \
  --instance-types t2.micro m5.large \
  --query 'InstanceTypes[*].{
    InstanceType: InstanceType,
    EbsOptimizedSupport: EbsInfo.EbsOptimizedSupport,
    EbsOptimizedDefault: EbsInfo.EbsOptimizedInfo.BaselineBandwidthInMbps
  }' \
  --output table

A Diagnostic Checklist

When you hit an InvalidParameterCombination, run through this checklist:

# 1. Check instance type availability in the target AZ
aws ec2 describe-instance-type-offerings \
  --location-type availability-zone \
  --filters Name=instance-type,Values=YOUR_INSTANCE_TYPE \
  --query 'InstanceTypeOfferings[*].Location' \
  --output text

# 2. Check AMI architecture matches instance type
aws ec2 describe-images --image-ids YOUR_AMI_ID \
  --query 'Images[0].Architecture'
aws ec2 describe-instance-types --instance-types YOUR_INSTANCE_TYPE \
  --query 'InstanceTypes[0].ProcessorInfo.SupportedArchitectures'

# 3. Check instance type capabilities
aws ec2 describe-instance-types \
  --instance-types YOUR_INSTANCE_TYPE \
  --query 'InstanceTypes[0].{
    Hypervisor: Hypervisor,
    Architectures: ProcessorInfo.SupportedArchitectures,
    EnaSupport: NetworkInfo.EnaSupport,
    NvmeSupport: EbsInfo.NvmeSupport,
    EbsOptimized: EbsInfo.EbsOptimizedSupport
  }'

# 4. Check AMI compatibility
aws ec2 describe-images --image-ids YOUR_AMI_ID \
  --query 'Images[0].{
    Architecture: Architecture,
    VirtualizationType: VirtualizationType,
    RootDeviceType: RootDeviceType,
    EnaSupport: EnaSupport
  }'

Prevention Best Practices

Use launch template validation before deploying. Test launches in a staging environment before updating production auto-scaling groups.
Use AWS Systems Manager Parameter Store for AMI IDs rather than hardcoding them. This lets you update the AMI independently of the launch template:

# Store the AMI ID in Parameter Store
aws ssm put-parameter \
  --name "/app/ami-id" \
  --value "ami-0abc123def456789" \
  --type String \
  --overwrite

# Reference in CloudFormation/CDK
# ImageId: !Sub '{{resolve:ssm:/app/ami-id}}'

Define multiple instance type overrides in auto-scaling groups. Never rely on a single instance type — it may not be available in every AZ:

# Update ASG with mixed instance types
aws autoscaling update-auto-scaling-group \
  --auto-scaling-group-name my-asg \
  --mixed-instances-policy '{
    "LaunchTemplate": {
      "LaunchTemplateSpecification": {
        "LaunchTemplateId": "lt-0abc123def456",
        "Version": "$Latest"
      },
      "Overrides": [
        {"InstanceType": "m5.large"},
        {"InstanceType": "m5a.large"},
        {"InstanceType": "m5n.large"},
        {"InstanceType": "m6i.large"}
      ]
    }
  }'

Validate instance type and AMI compatibility in CI/CD. Add a pre-deployment step that calls describe-instance-types and describe-images to verify compatibility before attempting a launch.
Use attribute-based instance type selection in auto-scaling groups (available since late 2021) to specify requirements instead of exact instance types:

{
    "InstanceRequirements": {
        "VCpuCount": {"Min": 2, "Max": 4},
        "MemoryMiB": {"Min": 4096, "Max": 16384},
        "CpuManufacturers": ["intel", "amd"],
        "InstanceGenerations": ["current"],
        "BurstablePerformance": "excluded"
    }
}

This lets AWS select from all compatible instance types, avoiding AZ availability issues entirely.

Stay on current-generation instances. The further back you go in instance generations, the more compatibility restrictions you encounter. Current-generation Nitro instances support all modern EBS volume types, all modern networking features, and are available in most AZs.

When Configuration Problems Recur

If your team repeatedly hits InvalidParameterCombination errors, the underlying issue is usually a lack of infrastructure-as-code practices. When instance configurations are defined in launch templates managed by CloudFormation or CDK, compatibility can be validated before deployment. When they are configured manually in the console, mistakes are inevitable.

We help teams adopt infrastructure-as-code and build validated, repeatable EC2 deployment pipelines. If configuration errors are slowing down your team or causing scaling failures during traffic spikes, schedule a free consultation — we will audit your EC2 configuration and launch templates and recommend improvements to prevent these errors permanently.