This is expected behaviour, see the code comment here

Internet gateways are free AWS resources. Is there a concern with this approach you could share?

Plus one here.

We have a problem where this is an issue for security compliance. In my circumstance, we have a highly protected resource that has automated security compliance tests run against it. The automatically created IGW violates these tests :(

thanks for the feedback, we'll get this triaged

I started looking into this. The one caveat of this is that it would result in a breaking change (at least for typescript, need to check the other SDKs) because the internetGateway output of the VPC would change to being optional (

Additionally, while most users will want an IGW, there's only few use cases for using the output of it. The main one being the creation of routes for the public subnets, but that's done internally in the component (

So to summarize:

• this breaking change would only affect users with advanced VPC setups
• rather minor fix for the breaking change

Based on that reasoning, most users shouldn't be affected by the breaking change of allowing to toggle the internet gateway on/off. And if they are, it's an easy enough fix.

I'm gonna add an optional toggle to enable/disable the IGW and add some guardrails so users don't end up in scenarios where they have public subnets but no IGW as that would break internet connectivity.

@mjeffryes @t0yv0 @corymhall thoughts about this approach?

I'm gonna add an optional toggle to enable/disable the IGW and add some guardrails so users don't end up in scenarios where they have public subnets but no IGW as that would break internet connectivity.

We should be able to just do this automatically based on the subnet configuration the user passes in. If they have public subnets then create an IGW, otherwise do not.

I'm gonna add an optional toggle to enable/disable the IGW and add some guardrails so users don't end up in scenarios where they have public subnets but no IGW as that would break internet connectivity.

We should be able to just do this automatically based on the subnet configuration the user passes in. If they have public subnets then create an IGW, otherwise do not.

But that would mean that resources are getting deleted after making this change. I'd argue that this is an even bigger breaking change

For example:

• User creates VPC with internal subnets only in this stack; right now this creates an IGW
• In another stack (or manually) they create public subnets using that IGW
• User upgrades provider
• IGW gets deleted and connectivity is broken

What we need here is some sort of feature flag. Since I don't think we have a good way of doing global feature flags in components (unless there is a way that I am unaware of), maybe we can accomplish it by adding the toggle as a deprecated property.

/**
  * @default true
  * @deprecated This will be removed in the next major release and an internet gateway
  * will only be created if the VPC is configured with public subnets.
  */
createDefaultInternetGateway?: bool

The reason I don't want to just add a toggle is that it would degrade the API experience. At least with a deprecated property we are only temporarily degrading it.

Yeah feature flags would be great here!

API wise I agree with you, I was worried about a customer nuking their connectivity. But I found that there's actually protection for that: an IGW can only be deleted if there's no EIPs referencing that.

I'm a bit worried about the signals that adding that parameter as a deprecated property is sending. We'd have to make the change in a major version release (because of the changes to the outputs of the component) and then directly queue up the next breaking change. Given that there's protection around disruptive actions, it might be better to just go for the change without the toggle.