
New Managed NAT Gateway for AWS - tiernano
https://aws.amazon.com/blogs/aws/new-managed-nat-network-address-translation-gateway-for-aws/
======
zAy0LfpBZLC8mAC
Isn't that completely crazy? IPv6 has been ready for production use for ...
about ten years? And yet, people still build (and ostensibly are willing to
buy) products that only exist in order to work around the shortcomings of
IPv4?

~~~
jo909
Of course you are right.

But if you want to build a comparable architecture with IPv6, where a private
Network is fully isolated from the public Internet except for a very
controlled gateway, you would still need a Firewall/Router capable of handling
all the traffic.

Isolated (to a certain degree), private networks will not go away with IPv6,
as they are a convenient security mechanism.

So the name for the box will change, but not it's fundamental duty of allowing
controlled traversal over network boundaries.

~~~
NetStrikeForce
And you are right, too.

But isolation doesn't mean translation. It is crazy that we have to use
translation to overcome problems with IP space scarcity, but I guess we all
got used already.

~~~
themartorana
I don't know. I _LIKE_ NAT. It's easy for me to reason about, easy to read and
understand. I know it has a litany of shortcomings, and I'm not in a huge
corporate network, but I'm going to miss it when it's gone.

~~~
iigs
I also strongly like NAT. In roughly descending order:

1) It fails safe. Virtually all device misconfigurations result in failure to
pass traffic, rather than being passed accidentally.

2) You get full control of your external signature (at that protocol level).
When Comcast and AT&T realize that they can charge for more than a single /128
on their consumer networks we'll see a lot of wailing and gnashing of teeth on
/r/technology, and it will be completely inane to those of us that saw the
same companies attempt the same BS with NAT detection in the late 90s.

3) I would like to be able to implement dual stack in networks that I'm
responsible for with as much similarity as possible. Having to reason
independently more than needed about how IPv4 and IPv6 behave is needless
difficulty.

4) IPv6 allocations today are asininely large. We're going to have 30-45 years
of overallocation and then be out again, and in the interim we'll have a whole
host of new braindead protocols in the manner of FTP and VOIP. The collective
lessons we've learned about NAT will have (for all intents and purposes) been
lost and we'll get a bunch of new shoddy hacks for dealing with them (passive
FTP and NAT-T).

5) If it's a useful tool, by the user's estimation, why can't I have it? The
internet grew up on what amounted to "be a good peer and we can all get
along", but on this specific topic it quickly dissolves into STOP LIKING
THINGS I DONT LIKE, YOU CAN'T HAVE IT, I'M TELLING THE IETF.

~~~
zAy0LfpBZLC8mAC
> 1) It fails safe. Virtually all device misconfigurations result in failure
> to pass traffic, rather than being passed accidentally.

I don't see that, nor that it would even be an advantage.

> 2) You get full control of your external signature (at that protocol level).
> When Comcast and AT&T realize that they can charge for more than a single
> /128 on their consumer networks we'll see a lot of wailing and gnashing of
> teeth on /r/technology, and it will be completely inane to those of us that
> saw the same companies attempt the same BS with NAT detection in the late
> 90s.

How do you prevent people from coming up with stupid ideas by implementing
some stupid ideas yourself? Is that a general rule you follow? Wherever
companies could conceivably some day screw up some product, you do it for them
now?

> 3) I would like to be able to implement dual stack in networks that I'm
> responsible for with as much similarity as possible. Having to reason
> independently more than needed about how IPv4 and IPv6 behave is needless
> difficulty.

So, you prefer to keep things broken forever if that means that things don't
change?

> 4) IPv6 allocations today are asininely large. We're going to have 30-45
> years of overallocation and then be out again,

What's your evidence for that? Seems like a completely baseless claim to me.

> and in the interim we'll have a whole host of new braindead protocols in the
> manner of FTP and VOIP.

So, NAT is good because protocols that don't work well with NAT are braindead
because they don't work well with NAT?

I mean, I see your point if there is any risk that we might run out of
addresses, but if we don't, what exactly is braindead about those protocols?

> 5) If it's a useful tool, by the user's estimation, why can't I have it?

You obviously _can_ have it. Just as you _can_ cut your head off if you think
that's useful to you.

But all things considered, do the advantages actually outweigh the
disadvantages.

------
benley
Anyone else find it somewhat baffling that it's taken until now for a NAT
service to arrive on AWS?

I'm happy to have it available of course, definitely not going to complain.
I've just long wondered why it wasn't a thing since the early days of VPC.

~~~
cheeseprocedure
I wonder the same, though the engineering under the hood is more interesting
than I thought:

[http://perspectives.mvdirona.com/2015/12/vpc-nat-gateways-
tr...](http://perspectives.mvdirona.com/2015/12/vpc-nat-gateways-
transactional-uniqueness-at-scale/)

> The connections are managed by a fault-tolerant co-operation of devices in
> the VPC network fabric. Each new connection is assigned a port in a robust
> and transactional way, while also being replicated across an extensible set
> of multiple devices. In other words: the NAT gateway is internally
> horizontally scalable and resilient.

Maybe it just wasn't a priority.

~~~
hrez
So it's very similar to VPC Internet Gateway, only with upcharge of $0.045/Gb
on traffic.

------
Rapzid
At first I was really excited. Then I realized that, of course, CloudFormation
support is not ready because AWS is terrible at cross-service strategy. I
opened the comments at the bottom and was pleased to see people shouting for
CloudFormation support :)

~~~
nzoschke
CloudFormation Custom Resources can help with this.

You can make a Lambda Function that can call the raw API, and have a
CloudFormation resource call that for create, update and delete.

It's a really powerful strategy for extending what CloudFormation can do.

~~~
Rapzid
Yeah, certainly _could_ but.. Treating AWS resources as "custom" resources to
hack around their long complained about CloudFormation turnaround? Ugh.. Then
I have to reason about how to extract that custom resource out and replace it
with the RightWay™ once it's added, which may just not even be possible... If
it came to that I would rather throw in my efforts with the Terraform
community(which I want to do anyway) who have already added this functionality
it seems
[https://github.com/hashicorp/terraform/pull/4381](https://github.com/hashicorp/terraform/pull/4381)
.

~~~
nzoschke
Terraform is an awesome user space tool.

I've been using the CF custom resource to manage a ton of stuff (hundreds of
clusters and thousands of apps) and it's excellent.

It's amazing that the service supports custom anything, and the create, update
delete pattern is perfect.

Replacing a custom resource with the right resource can be challenging. My
strategy is to not do it.

Create all new stacks the new way and have good tools to migrate parameters
and data from an old stack to a new stack.

------
mattbillenstein
This seemed to be something that was missing from their VPC offering -- I'll
probably use it, but you still need an instance with a public ip for
administration into the other instances on the private subnets if you're not
using an ipsec VPN AFAICT.

------
Pirate-of-SV
Would be nice with a low end alternative as well. At the moment I'm running
the NAT instance on a t2.micro at $0.013/hour (On demand). The price of this
service starts at $0.045

~~~
jake_morrison
Annoyingly expensive. I wonder if they have a goal of restricting the number
of VPCs, as you basically can't run a VPC without NAT to access other AWS
services like S3.

But the t2.nano instances will make a DIY solution cheaper.

~~~
hrez
What makes it expensive for any significant traffic is "data processing" fee.
But for S3 alone you can get away without NAT by using VPC endpoint.

------
geoah
I'll now just wait for a terraform resource for this! :D

~~~
geoah
[https://github.com/hashicorp/terraform/pull/4381](https://github.com/hashicorp/terraform/pull/4381)

~~~
Gigablah
Aaaand it's merged!

