EC2 InvalidParameterCombination: Instanz-Konfigurationsfehler beheben

Sie starten eine neue EC2-Instanz — oder schlimmer, Ihre Auto-Scaling-Gruppe versucht, während eines Traffic-Spikes eine zu starten — und es schlägt fehl:

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.

Oder diese Variante:

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.

Oder vielleicht die verwirrendste Version:

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.

Der InvalidParameterCombination-Fehler bedeutet, dass Sie EC2-Parameter angegeben haben, die untereinander inkompatibel sind. AWS kann die Instanz nicht starten, weil die Kombination aus Instanztyp, AMI, Availability Zone, Volume-Typ oder anderen Einstellungen in Konflikt steht. Die Fehlermeldung sagt meist, was falsch ist — aber nicht immer deutlich.

Hier ist ein vollständiger Leitfaden zu jedem häufigen InvalidParameterCombination-Szenario und wie Sie jedes einzelne beheben.

Schritt 1: Verstehen, was Sie angefordert haben

Bevor Sie debuggen, verschaffen Sie sich ein klares Bild der Launch-Parameter. Falls Sie ein Launch Template verwendet haben, inspizieren Sie es:

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
  }'

Falls Sie eine Auto-Scaling-Gruppe verwenden, prüfen Sie deren Konfiguration:

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

Ursache 1: Instanztyp in der Availability Zone nicht verfügbar

Nicht jeder Instanztyp ist in jeder Availability Zone verfügbar. Neuere Instanztypen wie Graviton-basierte Instanzen sind möglicherweise nicht in älteren AZs vorhanden, und spezialisierte Instanzen (wie p4d GPU-Instanzen) sind nur in bestimmten Zonen verfügbar.

Prüfen Sie, welche AZs Ihren Instanztyp unterstützen:

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

Um alle Instanztypen in einer bestimmten AZ zu sehen:

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

Die Lösung hängt von Ihrer Situation ab:

Für einzelne Instanzen: Geben Sie eine andere AZ im --placement-Parameter oder der Subnetzauswahl an
Für Auto-Scaling-Gruppen: Verwenden Sie gemischte Instanztypen mit mehreren 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"
        }
    }
}

Das gibt der Auto-Scaling-Gruppe mehrere Instanztypen zur Auswahl, sodass sie in jeder AZ einen verfügbaren finden kann.

Ursache 2: AMI-Architektur-Mismatch

Sie können ein x86_64-AMI nicht auf einer ARM-Instanz (Graviton) ausführen — und umgekehrt. Das passiert häufig, wenn Teams zur Kosteneinsparung auf Graviton-Instanzen wechseln, aber vergessen, das AMI zu aktualisieren.

Prüfen Sie die AMI-Architektur:

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

Prüfen Sie, welche Architekturen der Instanztyp unterstützt:

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

Häufige Architektur-Zuordnungen:

Instanzfamilie	Architektur	Prozessor
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 (1. Gen.)

Um das richtige AMI für Ihre Zielarchitektur zu finden:

# Das neueste Amazon Linux 2023 AMI für arm64 finden
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
  }'

Falls Sie SSM Parameter Store für AMI-Lookups verwenden (empfohlen), nutzen Sie die architekturspezifischen Pfade:

# 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

Ursache 3: EBS-Volume-Typ-Inkompatibilität

Bestimmte EBS-Volume-Typen werden von bestimmten Instanztypen nicht unterstützt. Das häufigste Problem ist die Verwendung von gp3- oder io2-Volumes mit älteren Instanztypen, die die NVMe-Schnittstelle nicht unterstützen.

Prüfen Sie, welche EBS-Features Ihr Instanztyp unterstützt:

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

Die allgemeinen Regeln:

Nitro-basierte Instanzen (m5, c5, r5, t3 und alle neueren Familien): Unterstützen alle Volume-Typen einschließlich gp3, io2 und io2 Block Express
Nicht-Nitro-Instanzen (m4, c4, r4, t2 und älter): Unterstützen gp2, io1, st1, sc1 und Standard-Magnetic. Unterstützen gp3 oder io2 möglicherweise nicht als Root-Volumes
io2 Block Express: Nur auf bestimmten Instanztypen wie r5b unterstützt

Um zu prüfen, ob eine Instanz Nitro-basiert ist:

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-Instanzen zeigen Hypervisor: nitro, während ältere Instanzen Hypervisor: xen anzeigen.

Ursache 4: Placement-Group-Einschränkungen

Placement Groups stellen strikte Anforderungen an Instanztypen. Eine Cluster-Placement-Group erfordert, dass alle Instanzen denselben Typ haben, und Partition-Placement-Groups haben Limits für die Anzahl der Partitionen pro AZ.

# Placement-Group-Details prüfen
aws ec2 describe-placement-groups \
  --group-names my-placement-group \
  --query 'PlacementGroups[0].{
    GroupName: GroupName,
    Strategy: Strategy,
    State: State,
    PartitionCount: PartitionCount
  }'

Häufige Placement-Group-Einschränkungen:

Cluster: Alle Instanzen müssen Enhanced Networking (ENA) unterstützen. Instanztypen können nicht gemischt werden (in der Praxis). Müssen in derselben AZ sein.
Spread: Maximal 7 Instanzen pro AZ pro Gruppe. Nicht alle Instanztypen werden unterstützt.
Partition: Maximal 7 Partitionen pro AZ. Instanzen innerhalb einer Partition können verschiedene Typen haben.

Prüfen Sie bei einem InvalidParameterCombination mit einer Placement Group die Netzwerkfähigkeiten des Instanztyps:

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

Ursache 5: ENA- und EBS-Optimized-Flag-Mismatches

Einige Instanztypen erfordern Enhanced Networking Adapter (ENA)-Unterstützung im AMI. Wenn das AMI den ENA-Treiber nicht hat, schlägt der Start fehl.

Prüfen Sie, ob das AMI ENA unterstützt:

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

Prüfen Sie, ob der Instanztyp ENA erfordert:

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

Wenn EnaSupport für den Instanztyp required ist, das AMI aber EnaSupport: false zeigt, benötigen Sie ein anderes AMI. Alle modernen von Amazon bereitgestellten AMIs unterstützen ENA, aber benutzerdefinierte oder alte AMIs möglicherweise nicht.

Ähnlich sind einige Instanztypen standardmäßig EBS-optimiert (und es kann nicht ausgeschaltet werden), während es bei anderen optional ist. Das Angeben von --ebs-optimized bei einem Instanztyp, der es nicht unterstützt, schlägt fehl:

# EBS-Optimierungs-Unterstützung prüfen
aws ec2 describe-instance-types \
  --instance-types t2.micro m5.large \
  --query 'InstanceTypes[*].{
    InstanceType: InstanceType,
    EbsOptimizedSupport: EbsInfo.EbsOptimizedSupport,
    EbsOptimizedDefault: EbsInfo.EbsOptimizedInfo.BaselineBandwidthInMbps
  }' \
  --output table

Eine Diagnose-Checkliste

Wenn Sie auf einen InvalidParameterCombination stoßen, gehen Sie diese Checkliste durch:

# 1. Instanztyp-Verfügbarkeit in der Ziel-AZ prüfen
aws ec2 describe-instance-type-offerings \
  --location-type availability-zone \
  --filters Name=instance-type,Values=IHR_INSTANZTYP \
  --query 'InstanceTypeOfferings[*].Location' \
  --output text

# 2. AMI-Architektur passt zum Instanztyp
aws ec2 describe-images --image-ids IHR_AMI_ID \
  --query 'Images[0].Architecture'
aws ec2 describe-instance-types --instance-types IHR_INSTANZTYP \
  --query 'InstanceTypes[0].ProcessorInfo.SupportedArchitectures'

# 3. Instanztyp-Fähigkeiten prüfen
aws ec2 describe-instance-types \
  --instance-types IHR_INSTANZTYP \
  --query 'InstanceTypes[0].{
    Hypervisor: Hypervisor,
    Architectures: ProcessorInfo.SupportedArchitectures,
    EnaSupport: NetworkInfo.EnaSupport,
    NvmeSupport: EbsInfo.NvmeSupport,
    EbsOptimized: EbsInfo.EbsOptimizedSupport
  }'

# 4. AMI-Kompatibilität prüfen
aws ec2 describe-images --image-ids IHR_AMI_ID \
  --query 'Images[0].{
    Architecture: Architecture,
    VirtualizationType: VirtualizationType,
    RootDeviceType: RootDeviceType,
    EnaSupport: EnaSupport
  }'

Best Practices zur Prävention

Verwenden Sie Launch-Template-Validierung vor dem Deployment. Testen Sie Starts in einer Staging-Umgebung, bevor Sie Produktions-Auto-Scaling-Gruppen aktualisieren.
Verwenden Sie AWS Systems Manager Parameter Store für AMI-IDs anstatt sie hardzukodieren:

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

Definieren Sie mehrere Instanztyp-Overrides in Auto-Scaling-Gruppen. Verlassen Sie sich nie auf einen einzigen Instanztyp — er ist möglicherweise nicht in jeder AZ verfügbar.
Validieren Sie Instanztyp- und AMI-Kompatibilität in CI/CD. Fügen Sie einen Pre-Deployment-Schritt hinzu, der describe-instance-types und describe-images aufruft, um die Kompatibilität vor einem Startversuch zu verifizieren.
Verwenden Sie attributbasierte Instanztypauswahl in Auto-Scaling-Gruppen, um Anforderungen statt exakter Instanztypen zu spezifizieren:

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

Das lässt AWS aus allen kompatiblen Instanztypen auswählen und vermeidet AZ-Verfügbarkeitsprobleme vollständig.

Bleiben Sie bei aktuellen Instanzgenerationen. Je weiter Sie in Instanzgenerationen zurückgehen, desto mehr Kompatibilitätseinschränkungen begegnen Ihnen. Aktuelle Nitro-Instanzen unterstützen alle modernen EBS-Volume-Typen, alle modernen Netzwerkfeatures und sind in den meisten AZs verfügbar.

Wenn Konfigurationsprobleme wiederkehren

Wenn Ihr Team wiederholt auf InvalidParameterCombination-Fehler stößt, liegt das zugrunde liegende Problem meist am Fehlen von Infrastructure-as-Code-Praktiken. Wenn Instanzkonfigurationen in Launch Templates definiert sind, die von CloudFormation oder CDK verwaltet werden, kann die Kompatibilität vor dem Deployment validiert werden. Bei manueller Konfiguration in der Konsole sind Fehler unvermeidlich.

Wir helfen Teams bei der Einführung von Infrastructure-as-Code und dem Aufbau validierter, wiederholbarer EC2-Deployment-Pipelines. Wenn Konfigurationsfehler Ihr Team verlangsamen oder Skalierungsprobleme während Traffic-Spikes verursachen, vereinbaren Sie eine kostenlose Beratung — wir auditieren Ihre EC2-Konfiguration und Launch Templates und empfehlen Verbesserungen, um diese Fehler dauerhaft zu verhindern.