search

aws-cloudformation / cloudformation-coverage-roadmap

The AWS CloudFormation Public Coverage Roadmap
https://aws.amazon.com/cloudformation/
Creative Commons Attribution Share Alike 4.0 International
1.11k stars 56 forks source link

AWS::EC2::VPNConnection - #624

Open theuniv-code opened 4 years ago

theuniv-code commented 4 years ago

Performing an update to AWS::EC2::VPNConnection resource, except for Tags property triggers a Replacement behavior for this resource leading to issues for end consumers of this VPN connection. We need a better logic to handle the VPN changes since this is a regular activity at the service for customers, and handling the resources the way it's being done invalidates the resource's usefulness.

Link to Public doc: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-vpn-connection.html

Kreinoee commented 3 years ago

Can add that modifying is possible in the console without replacing the resources, so it should be possible for cloud formation to do the same.

kddejong commented 3 years ago

Agreed, can we get a little more detail on what properties you are changing? Some properties can't be modified without replacement so it would be nice to narrow this done. https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ModifyVpnConnection.html makes it look like certain attributes can be modified on the VPN Connection itself. Like Transitioning between An existing transit gateway to a new transit gateway.

I'm also wondering if you are changing anything in these sub properties. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-vpnconnection-vpntunneloptionsspecification.html

thanks for the additional details.

ZalmnS commented 2 years ago

If you decide later on in a Stack's lifespan that you would like to switch between using a VPNGatewayID to a TransitGatewayID it requires the whole Resource to be completely replaced.

However, if you attempt to make this change manually through the Web Console (VPC Service>Site-To-Site VPN Connections), the Same VPN ID maintains while the switch between a VPNGatewayID and a TransitGatewayID takes place.

The differences between the two are can be found here, quote: https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html#concepts "Virtual private gateway: A virtual private gateway is the VPN endpoint on the Amazon side of your Site-to-Site VPN connection that can be attached to a single VPC.

Transit gateway: A transit hub that can be used to interconnect multiple VPCs and on-premises networks, and as a VPN endpoint for the Amazon side of the Site-to-Site VPN connection."

To summarize, if you were attempting to move away from using Virtual Private Gateways and had in the past used Virtual Private Gateways to do one-to-one connections for your on-prem Site-to-Site VPN's, a Transit Gateway is a more scalable and feasible option as you wouldn't have to setup separate tunnels on the on-prem side.

craigjbass commented 1 year ago

Hello, we have run into this issue, which has made it impossible to use CloudFormation to provision VPN Site-to-site Connections for our government customers.

This is quite a big problem because VPN Site-to-site connections manage "Outside" Public IP(s) internally, rather than allowing the attachment of Elastic IP(s). This means that to ensure that the Public IP(s) do not change (requiring a change request to be lodged with the customer), the VPN Connection has to be modified in place.

Given CloudFormation replaces the VPNConnection resource for any change, we'd get assigned new Public IP(s). If provision many CloudFormation stacks for many customers, we'd be forced to submit change requests to hundreds of CAB process boards if we want to change common configuration between them

To summarise CloudFormation is unusable for our use case around VPN Site-to-site.