EC2::Subnet cannot be updated if `Ipv6CidrBlock` is not set, although the property is not required

[thomas11]

Name of the resource

AWS::EC2::Subnet

Resource Name

No response

Issue Description

When an EC2::Subnet is created without Ipv6CidrBlock being set, subsequent updates fail with "Invalid request provided: Property Ipv6CidrBlock cannot be empty."

According to the CF docs, this property should not be required. Which makes sense, since the subnet may have no IPv6 configuration.

Expected Behavior

A subnet not using Ipv6CidrBlock can be updated via Cloud Control, such as editing its tags.

Observed Behavior

Any update, even if unrelated to IPv6, fails with "Invalid request provided: Property Ipv6CidrBlock cannot be empty."

Test Cases

aws cloudcontrol create-resource --type-name "AWS::EC2::VPC" --region us-east-1 --desired-state '{"CidrBlock":"10.0.0.0/16"}'

aws cloudcontrol create-resource --type-name "AWS::EC2::Subnet" --region us-east-1 --desired-state '{"VpcId":"vpc-073a212b11863d7d5","CidrBlock":"10.0.1.0/24"}'

This succeeds. Now perform an update to the Subnet, unrelated to CIDR blocks, like adding a tag:

aws cloudcontrol update-resource --type-name "AWS::EC2::Subnet" --identifier subnet-0a0cf18d7852f8212 --region us-east-1 --patch-document '[{"op":"add", "path":"/Tags", "value":[{"Key":"New","Value":"Tag"}]}]'

The result is this failure with Property Ipv6CidrBlock cannot be empty:

{
    "ProgressEvent": {
        "TypeName": "AWS::EC2::Subnet",
        "Identifier": "subnet-0a0cf18d7852f8212",
        "RequestToken": "29f2920e-c50f-4e1f-a42e-6a623e19d3fc",
        "Operation": "UPDATE",
        "OperationStatus": "FAILED",
        "EventTime": "2024-02-19T20:18:17.508000+01:00",
        "StatusMessage": "Invalid request provided: Property Ipv6CidrBlock cannot be empty.",
        "ErrorCode": "InvalidRequest"
    }
}

Other Details

No response

[amazon-chizever]

As a work-around, you can append the following string: {"op":"remove", "path":"AssignIpv6AddressOnCreation"} to the patch document for the mutation. This is safe even for subnets with this parameter set to true, as it only removes the key from the update API payload, it does not actually remove the configuration from the subnet.

[amazon-chizever]

This issue has been resolved.