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?
Most of the usefulness of this service is that you need a NAT gateway if you want instances to be created with private IPs only but also be able to access the internet. The IPv4 point isn't wrong but it misses the mark, I think.
You could put them in super restrictive security groups, sure, but some people just want to say "these don't have a public IP, so it checks off this box" and those people are going to be super happy with this.
There's also the comments about checking off other boxes like central points for IDS, etc.
> [...] but some people just want to say "these don't have a public IP, so it checks off this box" and those people are going to be super happy with this.
Which basically would mean that they are incompetent. A private IP address doesn't really do anything for you security-wise. An IP address being private is simply a convention adhered to by people assigning addresses--that does not in any way guarantee that one cannot send packets to those addresses from outside your network or forward packets from those addresses out of your network, so it doesn't obviate the need for you to filter at the borders of your network, and if you do filter, you might as well filter "public addresses".
The only difference between private and public addresses is that private addresses are potentially assigned to more than one network/machine, which makes it difficult to make those networks/machines communicate with one another in case you ever need to, and to make the world communicate with them because the world in general can't distinguish between the multiple instances of the same address, and thus usually doesn't really know who to talk to.
> Which basically would mean that they are incompetent. A private IP address doesn't really do anything for you security-wise.
And yet is a requirement for many compliance policies.
For PCI Compliance (ie to store and transmit credit cards), any machines storing consumer info (ex the database) need to be in a private subnet that does not have direct access to or from the internet.
That's the sort of thing that private subnets and NAT in Amazon's VPC was really made to cover.
Could you give your database with millions of credit card records a public IP, and just firewall it to be secure? Sure. But you don't need to, and a core part of compliance is not taking risks you don't need to take. You can accidentally add a bad firewall rule, you can leave some sort of hole that makes it easy to punch through. It's much harder to accidentally make your database accessible from the public internet through a NAT.
What this new service means is that, instead of having a server in every region whose sole job it is to accept outgoing connection requests for package upgrades, I can use this service.
Why do I not just have those connections go through the web server? Because PCI requires one role per server.
Why do I not just use a micro instance instead of this more expensive service? Because then I have one more server I have to maintain and test for compliance.
For people that have security policies and compliance requirements to meet, this service makes life a small amount simpler, and is worth the price.
> And yet is a requirement for many compliance policies.
I didn't claim there aren't any incompetent people out there.
> For PCI Compliance (ie to store and transmit credit cards), any machines storing consumer info (ex the database) need to be in a private subnet that does not have direct access to or from the internet.
"Not having access to the internet" != "private address range". A private address range does not prevent someone external from accessing your machine. That people think that is a dangerous misconception.
Also, private address ranges make it much, much harder to reason about your firewall's correctness.
For a network with several hundred instances where each instance has a public IP, the borders of your network become quite wide. You now need to audit several dozen security groups.
When you setup a private subnet, there are a lot less security groups, and access points in general, which makes it much easier to audit and maintain reasonable security for.
This is especially true where unprofessional people start and stop instances (say developers) and don't have the same security mind-set, making it a risk of human-error that causes services which normally should be protected to be open to the world.
Well, then you have to make it so that new instances automatically contain your packet filter. You have to think outside what the current implementation easily supports, which obviously reflects the limitations of the current network setup, and think about what would be possible if those limitations didn't exist. And it's obviously technically possible to automatically deploy the same packet filter to each VM that gets added to your network range ...
Also, as I said, the point is not that a central firewall cannot ever be a good solution--but with the current limitations, you have no other choice even when it doesn't really make much sense.
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.
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.
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.
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.
> 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.
You would like stateful packet filtering w/o NAT even more, I suspect. You've probably never gotten a chance to work in an environment where that's possible. It's nice to have one layer of complexity (NAT) removed from the equation and to work with only packet filters. (It's nice not to have to worry about split-horizon DNS, for example.)
I like NAT, too; but just because I like solving the problems it creates. It gets especially funny when you're overloading the public IP address with a one-to-many ratio with internal IP address for outgoing traffic and then you add PAT for incoming traffic.
It gets even better when you're only using one IP address for that one-to-many NAT (and it usually is the firewall's external interface IP address because, well, we're lazy), all your internal users are requesting the same external and you run out of ephemeral ports without even realizing.
I also like when someone architected an application where the server running it has to request different resources from different external sites and, for some weird reason, has to present itself with different IP addresses. Oh the joy.
So many NATs and so many scenarios. It is lovely how different vendors come up with all sorts of names and acronyms: NAT, PAT, SNAT, DNAT, DIP, MIP, you name it! If we didn't have NAT we would have to invent it :)
Why would you miss it when it's gone? I pretty much wish it had never been invented, so I'd be curious if there is any big advantage that I am missing ...
> 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.
Nope, you wouldn't. You might still want to think abstractly in terms of a network boundary, but you absolutely do not necessarily need one point where it's all implemented. Depending on the architecture and your needs, you could also, for example, have an instance of the same packet filter on each machine.
I am not saying that there is no place for that kind of architecture, but the current state of affairs with IPv4 severely limits the options as to how to implement what you actually need. In a way, even the concept of "a private network" is a bad idea. Sure, you may want to limit access to some services for some clients and such--but really, the mere distinction of "inside" vs "outside" causes many problems in today's network operations. What if you interconnect you "internal network" with some other "internal network" because someone "external" to you needs to access some service that's "internal" to you? That becomes pretty hairy pretty fast, with NAT in particular--when it's actually pretty easy conceptually when you have a globally unique address space.
That is not the same level of isolation. What you describe is of course possible and exactly how non vpc ec2 works, but nobody recommends that for serious setups.
I guess I wasn't necessarily talking just about EC2, but network setups in general, where more distributed firewalls might often be a good choice, were it not for the problems that NAT brings.
Actually having a packet filter per machine would be an extreme case, obviously, but the same problem occurs when you have multiple gateways to different networks, or maybe you are multihomed, or you have multiple locations with their own internet uplinks ... having to maintain NAT state and generally ensuring reachability despite the NAT tends to get complicated fast if you have multiple independent filters/NAT gateways, while that's reasonably easy to maintain without NAT.
That's the point. It's crazy that instead of getting IPv6 working in AWS, Amazon chose to build a NAT gateway service instead.
The forward thinking way to deal with IPv4 shortages would be for Amazon to support IPv6 end to end, and offer IPv4 connectivity via ELB or a NAT64 Gateway so that the non-IPv6 internet can reach your servers.
A relative few of the biggest elephant customers of theirs are deploying IPv6 or even have it on a roadmap. There is a gigantic amount of money that can't be ignored by catering to these lumbering giants of Faustian bureaucracy that will be multiple decades behind current technologies and continue to fall even further behind despite any "cloud transformations" that they spend a small country's GDP on. This is a potentially dangerous path for AWS as they need engineers to work on both up to date technology and other engineers on outdated, obsolete legacy technologies that few engineers would prefer to work on. The good news about outdated technology should be that every competent engineer should understand something about why it's obsolete in some respect, but the truth is that few engineers on even HN understand the shortcomings of, say, COBOL and Fortran 77 over Java 7 and C# 5.0.
I don't think it's that crazy. Switching to IPv6 is painful. It's a fine standard, and better than IPv4 in most every way, ignoring transaction costs. But IPv4 + NAT persists because it's a smoother path - the same reason why HTML 5 won out against XHTML 2.0.
A lot of the need for this design is for backwards compatibility with existing corporate network designs that will likely be on IPv4 for perhaps another decade or two longer. Most corporate networks despise changes and seek to gain stability of their environment through minimizing changes.
My current contract customer absolutely wants this and requires it, in fact, for compliance with internal security policies (nevermind the litany of security issues using IPv4 in the first place). The limitations of this solution include the fact that we're unable to get much control of these instances because we use third party software galore on these type of NAT instances like IDS, firewalling, caching / proxying, and traffic shaping. So unfortunately, all this new service does for us is let us separate out one of like 12 functions to a (granted, high availability) service and in the interest of saving money on not creating 25+ instances for these 12 services it's not unheard of to collapse these into 3-4 load balanced / distributed much larger instances for the sake of easier manageability. But for a lot of folks, I can imagine this is a great service that meets their needs sufficiently well.
> 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.
I find this pretty typical of AWS TBH. You could ask the similar questions about other service like:
Why can I make IAM policies for EC2 that key in on tags, but not other services?
Why can I filter on tag for some resources in the console but not all? Why don't ALL resources support tags?!
IAM would be way less of a PITA if you could put resources into groups.. Hey, if they had tag support for all of their resources and you could restrict access to them like ec2 that would be like resource groups...
Why can't I pay more to just scale ELB's up?
Why don't ELB's support connection draining...(this has been addressed but was the most complained about ELB shortcoming for a long time).
Etc. Etc. Etc.
But hey, things are not so bad and have really improved quite a bit in all fairness.
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 :)
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 .
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.
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
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.
