You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hey @BrandonALXEllisSS - thanks for trying out this project. You can read more about NAT gateway usage here, but in their usage in this example, they're meant to provide outbound connections to the internet. When they're placed in a private subnet, it effectively disallows inbound connections, but egress from the subnet can still take place. In the route tables, we only allow inbound traffic from the public subnet to the IGW and from the public subnet to the private subnet. This way, traffic coming from a public CIDR range can not make inbound requests to the private network, but resources in that private network can still open connections to the public internet using the NAT.
An IGW on the other hand allows bi-lateral networking from the internet, and thats why we route to it from the public subnet.
I am not familiar with the latest and greatest on AWS networking though (NAT gateways are a pretty old, non-redundant construct in AWS), so if you have recommendations for improving this I'm all ears! Thanks again for trying out Boundary.
thierryturpin
added a commit
to thierryturpin/boundary-reference-architecture
that referenced
this issue
Feb 18, 2022
In the AWS example, the NAT gateways are placed in private subnets, meaning none of the outbound traffic from the NAT gets routed to the IGW.
I thought it's common practice to put the NAT gateway in a public subnet so that it's routed to the IGW automatically...?
Is there something I'm missing?
The text was updated successfully, but these errors were encountered: