aws-cloudformation
Supported resource AWS::EC2::VPCGatewayAttachment can't be imported to stack
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
@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.
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
Also hit this - and as part of stack refactoring. As with @AlexGurtoff this will likely cause production downtime
bump into this as well - down the road is there any cons of leaving this out of the import?
Workaround:
- create a dummy VPC with IGW, NAT GW, route tables (without IGW/NAT), subnets, etc. on the side
- Alter the CF template to attach the dummy-IGW to the dummy-VPC,
- apply
- 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. - Update the VPCAttachement to the original IGW/VPC combination. Apply the change set with the "keep updated resources" option.
- Wait for it to error.
- Delete the NAT, Clean up the IGW attachment
- Hit retry. I assume it suddenly is happy since VPCAttachement doesn't support drift detection.
- 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.
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.
