Supported resource AWS::EC2::VPCGatewayAttachment can't be imported to stack

[AlexGurtoff]

Name of the resource

Other

Resource Name

AWS::EC2::VPCGatewayAttachment

Issue Description

Existing resource AWS::EC2::VPCGatewayAttachment can't be imported to stack. There is a weird error with such description: READ operation is not supported

Expected Behavior

Reffering to: https://docs.aws.amazon.com/cloudcontrolapi/latest/userguide/supported-resources.html and https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-supported-resources.html Resource is supported by import. So, I should be able to import this resource into my cloudformation stack.

Observed Behavior

Existing resource AWS::EC2::VPCGatewayAttachment can't be imported to stack. There is a weird error with such description: READ operation is not supported

Test Cases

I used such template file to import this resource:

Resources:
...
  VpcVPCGWBF912B6E:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      InternetGatewayId:
        Ref: VpcIGWD7BA715C
      VpcId:
        Ref: Vpc8378EB38
    DeletionPolicy: Retain
    Metadata:
      aws:cdk:path: CommonVpcStack/Vpc/VPCGW
...

And here is the import.json file that I provide with the template when creating a change set:

...
{
    "ResourceType":"AWS::EC2::VPCGatewayAttachment",
    "LogicalResourceId":"VpcVPCGWBF912B6E",
    "ResourceIdentifier": {
        "AttachmentType":"IGW",
        "VpcId":"vpc-xxxxxxxxxxxxxxxxx"
    }
},
...

I removed redundant information from it

Other Details

No response

[thodorisit]

@AlexGurtoff , after experiencing the same unexpected behavior and reaching out to the AWS support, it seems that the VPCGatewayAttachment resource cannot be imported at the moment, even though it's documented that it's supported. It's a reported bug.

As a workaround, it was suggested to create the VPCGatewayAttachment via Cloudformation directly.

[AlexGurtoff]

As a workaround, it was suggested to create the VPCGatewayAttachment via Cloudformation directly.

@thodorisit Yeah, but in this case I need to detach the old VPCGateway, and this will require deleting all ENIs, and this in turn will cause our system to downtime... So, I hope that the CFN team will add support for importing this resource

[kajm]

Any update on this? I'm experiencing the same issue

[smee30]

Also hit this - and as part of stack refactoring. As with @AlexGurtoff this will likely cause production downtime

[hongruiloop]

bump into this as well - down the road is there any cons of leaving this out of the import?

[bitte-ein-bit]

Workaround:

1. create a dummy VPC with IGW, NAT GW, route tables (without IGW/NAT), subnets, etc. on the side
2. Alter the CF template to attach the dummy-IGW to the dummy-VPC,
3. apply
4. Block the dummy-IGW attachment by activating the NAT GW and IGW in the respective subnets. To be sure, I launched a private instance and pinged Google. You can try manually detaching the IGW. If you get the error Network vpc-xxxx has some mapped public address(es). Please unmap those public address(es) before detaching the gateway. you are good to continue.
5. Update the VPCAttachement to the original IGW/VPC combination. Apply the change set with the "keep updated resources" option.
6. Wait for it to error.
7. Delete the NAT, Clean up the IGW attachment
8. Hit retry. I assume it suddenly is happy since VPCAttachement doesn't support drift detection.
9. clean up the dummy VPC with all resources in it.

Are there issues down the road? Most likely. One potential issue will appear when VPCAttachement supports drift detection. The physical ID of the VPCAttachment is IGW|vpc-dummy-vpc-id. That's the only delta I was able to detect.

If it ever becomes an issue, the chances are high that it can also be imported. You can use a similar hack to make it disappear from the stack. Remove the VPCAttachement from the stack while it's being blocked due to active public IPs.

[ralish]

The lack of support for this resource is particularly troublesome as it can't be trivially recreated. Detaching an IGW from a VPC requires all public IP addresses to also be removed. Bringing the IGW attachment under the management of a CloudFormation template is thus often a lot of work, which may entail extended downtime. This feels like a resource for which support for importing should be prioritised given there isn't really any acceptable workaround.