EC2 to VPC: A transition worth doing.
blog.engineering.kiip.me
blog.engineering.kiip.me
Not true. You'd have to adjust your Security Group policies accordingly for that to be true.
"All [EC2] nodes are on a shared network, and are addressable to each other."
Misleading. You'd have to be clinically brain dead to allow this to happen by explicitly setting that policy in your Security Groups. You should also try to avoid Tweeting your admin login creds if this is an issue.
VPC has good features not available on EC2 but this perspective on it boils down to "I need a sandbox because I don't understand how firewalls work."
They all have internet routable ips/hostanames.
Proper use of security groups would address most of the concerns described in the post.
nodes in security group A (load balancer) can access nodes in security group B (app server)
My take from the blog post: VPC is a transition not worth doing, if you are a startup (we are on HN after all), since, and I quote: [it] requires a substantial amount of domain knowledge [and] VPC is far more complicated than EC2. Keep things simple, and stay focused. EC2 is perfectly adequate for most endeavors.
VPC is just basic networking, reinvented by AWS because they screwed up that part real bad in the first EC2 arch. VPC is not complicated, it probably takes half a day to figure it out. And compared to the ridiculous amount of time it takes to setup EC2 in the first place (when you come from classic datacenter), it's a good investment that's not going to show in the budget.
The point I meant to make was: Yes, you can use SGs to make your network secure on EC2, but its very easy to shoot yourself in the foot, which is evident if even larger companies on EC2 are making the mistake. VPC on the other hand provides a secure-unless-you-try-really-hard environment.
NOTE: Modified the post to hopefully make this more clear.
The primary advantage of VPC is that it provides a private, single-tenant network. The advantage here is that you don't need to rely on complicated SG policies to maintain security.
Although VPC is part of the same infrastructure, the two have very dramatically different network configurations, which makes then clearly distinct. The networking environment of VPC much more closely resembles what you would have if you were using physical infrastructure. This means you have control over the routing tables, DHCP, DNS, network topology, etc. These are all things which are out of your control on EC2.
Just because various famous companies failed to properly audit their security group settings doesn't mean it's rocket science. It just means that they didn't notice the problem in advance.
Write a script that captures your SG policies and writes them to a file in some nice parseable format. The dumbest possible version of that might be:
ec2-describe-group | sort > /home/MY_SG_SETTINGS
Write another script that runs the above command every hour and yells loudly if the output ever changes. Wire that script to (e.g.) Nagios.
Now, use the time you've saved not implementing VPC to write some tests that attempt to connect to various important ports from outside your security group. Log lots of scary warnings if they ever succeed. Wire those to Nagios, too.
Unless your security groups are numerous and complicated, or your developers demand the power to open and close arbitrary ports on arbitrary machines seven times per working day, this would seem adequate for most use cases.
I know there are use cases for VPC, but it doesn't feel like this is one.
However, depending on the systems your company uses and your configurations, one solution might be simpler than another. Network topologies tend to be very static. You might have a public subnet, and a few private subnets.
Over time, you might add or remove web servers to the public subnet, or add various services to the private subnets. Especially if you are using a Service Oriented Architecture (SOA), you might have many different services that need to interact with each other, but not with the public internet.
When you are using security groups, you need to make sure to have separate SG's for each category of machine (public, private) and then manage them at a service level, and manage the interaction between multiple SGs. For example, Web should be available on port 80 from the internet, but the DB should only be available on port XX accessible from the Web SG. But also accessible from the same port from a Service SG, etc.
So as you continue to iterate on your services and deploy new ones, you need to be constantly tweaking the security group configurations. With VPC, once you have a sane public/private topology you can forget about it.
Additionally, most SOAs try to provide some form of high availability. For us, that means cross region / cross AZ replication and availability. Doing cross AZ is fairly simple in both EC2 and VPC, but doing cross region in EC2 is a pure nightmare. You cannot apply a security policy across regions, so you have no simple way to allow your nodes to communicate.
Since VPC acts as a distinct private network, we can simply use site-to-site VPN configurations between our regions, and nodes can easily and freely communicate with each other. There is nothing to worry about, since the private subnets are connected over VPN, and are using hostnames that are only routable within our private network.
Don't get me wrong, security groups can be properly used to provide a totally secure environment where only trusted nodes are allowed to communicate. You can add monitoring and configuration testing easily as well. But once you try to scale up past a few servers, move to a SOA, and provide cross-region availability, VPC becomes the simpler alternative.
http://aws.amazon.com/vpc/faqs/#E13
I will certainly revisit this topic when ELB is inevitably available for VPC based customers.
Micro instances are also unsupported within a VPC, which is also a showstopper for some.
EC2 was enough for me to prototype my system to get 2 clients on board, but I needed VPC to accomplish the multiple VPN connections that I use ...
Also, my storage servers have no need to be addressable by my clients and/or the Internet at large. So while I could have done that with security groups, having them in a private subnet made things much easier ... and now I know that from an IP level the file storage cannot be found from outside of my VPC.
I'm sure if I sat down and thought about it I would come up with more ...
In particular, I would love to be able to create & sell managed loadbalancers, accelerators, component applications etc as DevPay billable AMIs. But that's not possible with VPC (and because I'm in Australia), so everyone using VPC has to reinvent a whole bunch of wheels to use it. It's a reduction of value all round.
So ingenious though the general concept of VPC is; two years on, it's still a half-baked product with a high opportunity cost.
The only groups/roles that allow external access are:
- proxy (80,443 /0)
- extranet (80,443 office-ips/32)
- admin (22 office-ips/32)
instances can do discovery thru' the ec2 api - looke for a machine wit the role they require.
Once an instance is booted and the packages are installed, it is maybe a minute or less to availability.