nice article, but I do not agree! What is bad about an IGW? Can you tell me any event, occurance, any north-corean hacker attack exploiting the IGW in a VPC. I never heard anything about that. It's difficult. Probably you know how to introduce a post installation of some NAT service in a VPC or anything the like just by trespassing the IGW, which is not feasable anyway. You can savely build a reference architecture with the hybrid part (private routable network from your DC) workload subnets and public subnets even with an IGW attached. There is nothing harmful about that. A real pure hybrid-cloud does not need an IGW, but you will learn very quickly, that insufficient VPN hybrid cloud connections without any access to some Internet Proxy, will render the idea to forget about an IGW to rubble. As soon as you want to do patching or upgrading. How to access public Linux repos without Internet access, not to mention Windows. I wouldn't condemn the IGW. It's a good and useful component and it will be required sooner or later and it has nothing to do with a security flaw. No myth about IGWs please :-)
Nothing is bad about an IGW; its a great service to use when your OIA will go directly from your VPC as mentioned in the article. The suggestion is when your patterns are internal facing or have routing to other gateways, the IGW becomes unnecessary to leave associated to your VPC as its not being used in the pattern.
Often we see enterprises with default configurations of IGWs attached to internal facing VPCs. Unknowingly there has been accidental subnet assignments to the IGW or routing table updates to the wrong gateway that have exposed the VPC unnecessarily. Cleaning up unneeded resources in general is helpful to reduce cost, complexity (as there are less resources to manage) and reduce risk of resources being used for the wrong purpose.
When it comes to network resources which provide a doorway to the public internet, yes you can lockdown the boundary with security groups, NACLs, route tables, etc, but with the simplicity of creation of these resources, it is more appropriate to scope down your configurations for the intended workload. You can simply re-create purposely when your workload needs OIA directly in your VPC. Similar advice I would give if I saw an unassociated security group with 0.0.0.0/0 ingress rule(s). You could 1) leave the security group and ensure its never associated until needed, 2) remove the offending rule, 3) delete the group altogether. Would be simpler to clean-up the rule or remove the group altogether; recreate when needed.
Hi Bob,
nice article, but I do not agree! What is bad about an IGW? Can you tell me any event, occurance, any north-corean hacker attack exploiting the IGW in a VPC. I never heard anything about that. It's difficult. Probably you know how to introduce a post installation of some NAT service in a VPC or anything the like just by trespassing the IGW, which is not feasable anyway. You can savely build a reference architecture with the hybrid part (private routable network from your DC) workload subnets and public subnets even with an IGW attached. There is nothing harmful about that. A real pure hybrid-cloud does not need an IGW, but you will learn very quickly, that insufficient VPN hybrid cloud connections without any access to some Internet Proxy, will render the idea to forget about an IGW to rubble. As soon as you want to do patching or upgrading. How to access public Linux repos without Internet access, not to mention Windows. I wouldn't condemn the IGW. It's a good and useful component and it will be required sooner or later and it has nothing to do with a security flaw. No myth about IGWs please :-)
Nothing is bad about an IGW; its a great service to use when your OIA will go directly from your VPC as mentioned in the article. The suggestion is when your patterns are internal facing or have routing to other gateways, the IGW becomes unnecessary to leave associated to your VPC as its not being used in the pattern.
Often we see enterprises with default configurations of IGWs attached to internal facing VPCs. Unknowingly there has been accidental subnet assignments to the IGW or routing table updates to the wrong gateway that have exposed the VPC unnecessarily. Cleaning up unneeded resources in general is helpful to reduce cost, complexity (as there are less resources to manage) and reduce risk of resources being used for the wrong purpose.
When it comes to network resources which provide a doorway to the public internet, yes you can lockdown the boundary with security groups, NACLs, route tables, etc, but with the simplicity of creation of these resources, it is more appropriate to scope down your configurations for the intended workload. You can simply re-create purposely when your workload needs OIA directly in your VPC. Similar advice I would give if I saw an unassociated security group with 0.0.0.0/0 ingress rule(s). You could 1) leave the security group and ensure its never associated until needed, 2) remove the offending rule, 3) delete the group altogether. Would be simpler to clean-up the rule or remove the group altogether; recreate when needed.