New Managed NAT Gateway for AWS
aws.amazon.com
aws.amazon.com
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.
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.
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.
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.
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.
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.
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.
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.
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 :)
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.
Im not saying that nat is good, but isolation is.
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.
As long as significant part of the net is only reachable by IPv4, most businesses can't walk away from it.
Not to mention, AWS still doesn't have IPv6 support (except for ELB).
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.
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.
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.
http://perspectives.mvdirona.com/2015/12/vpc-nat-gateways-tr...
> 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.
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.
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.
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.
But the t2.nano instances will make a DIY solution cheaper.