3 ms·

> why a NAT instance is needed in each subnet? I don't think it's strictly needed, but it's best practice because instances in each AZ remain independent from

by bhahn 10y ago

> why a NAT instance is needed in each subnet? I don't think it's strictly needed, but it's best practice because instances in each AZ remain independent from failures in other AZs. Were the AZ with the single NAT to go down, then instances in the other AZs wouldn't be able to communicate outside the VPC (ie. to the rest of the internet) There's also a side benefit of much lower latency using a NAT in the same AZ vs going across AZ (unscientific benchmark is 0.1ms in same AZ vs 0.3ms across AZ)

ivan_ah 10y ago
> Were the AZ with the single NAT to go down, then instances in the other AZs wouldn't be able to communicate outside the VPC (ie. to the rest of the internet) Oh I see. Though assuming app servers are wired up behind an ELB, the service will only be partially degraded (no app server outbound connectivity, like you said). The one-NAT per AZ is a more robust design but at $30/mo each (for NAT gateway) seems expensive ;) Even at $10/mo (small do-it-yourself NAT instance) it's not free.
vacri 10y ago
Note that this is only important if your use-case requires your servers to have constant, direct 'phone out' access. If you're using ELBs or similar as your link to the outside world for your use-case, a NAT isn't really necessary for constant access. We use a single micro NAT in each VPC, which is only used for system updates (no, I don't have a package cache yet...) and for when we're manually in the server troubleshooting. If there's an outage, well, there's not much we can do in that case, and the NAT isn't needed for production use. And if we really need that NAT back up, just spin up another one and modify the VPC. As you say, it's not strictly needed. It really depends on your use case. If your use-case suffers for the NAT being down, then you need HA on it. If it can wait, then no. With the new managed NAT in AWS, you may as well go with that if you need HA - it's cheapest is roughly twice the price of a micro anyway, and it's one less bit of clutter in your instance list.
- coredog64 10y ago
  If, for whatever reason, you can't run VPC endpoints then you also want the NAT to be able to reach S3 (and some other service endpoints)

by bhahn 10y ago

ivan_ah 10y ago

> Were the AZ with the single NAT to go down, then instances in the other AZs wouldn't be able to communicate outside the VPC (ie. to the rest of the internet) Oh I see. Though assuming app servers are wired up behind an ELB, the service will only be partially degraded (no app server outbound connectivity, like you said). The one-NAT per AZ is a more robust design but at $30/mo each (for NAT gateway) seems expensive ;) Even at $10/mo (small do-it-yourself NAT instance) it's not free.

vacri 10y ago

Note that this is only important if your use-case requires your servers to have constant, direct 'phone out' access. If you're using ELBs or similar as your link to the outside world for your use-case, a NAT isn't really necessary for constant access. We use a single micro NAT in each VPC, which is only used for system updates (no, I don't have a package cache yet...) and for when we're manually in the server troubleshooting. If there's an outage, well, there's not much we can do in that case, and the NAT isn't needed for production use. And if we really need that NAT back up, just spin up another one and modify the VPC. As you say, it's not strictly needed. It really depends on your use case. If your use-case suffers for the NAT being down, then you need HA on it. If it can wait, then no. With the new managed NAT in AWS, you may as well go with that if you need HA - it's cheapest is roughly twice the price of a micro anyway, and it's one less bit of clutter in your instance list.

coredog64 10y ago
If, for whatever reason, you can't run VPC endpoints then you also want the NAT to be able to reach S3 (and some other service endpoints)