Hacker News new | past | comments | ask | show | jobs | submit login

I can think of a couple reasons--not necessarily good reasons, but reasons. One would be a belt-and-suspenders approach: if you think of Security Groups as a network-layer firewall, having host firewalls can be a good second layer of defense in case of misconfiguration or hacking at the network firewalls. That said, it increases complexity and management labor, which can be a net loss--depends on the environment.

A second reason would be for consistency: if you have a mixed environment with some stuff in the cloud and some not (I know, I know, who would ever be so gauche as to not host everything in the cloud? \s), you may want everything configured the same regardless of hosting. In that case, you're trying to reduce your complexity by increasing homogeneity, even if that creates some redundancy for stuff hosted in the cloud.

Third reason would be for achieving specific effects. Security groups is effectively just a stateful ACL, blocking traffic at the layer 3/4 level. It's good, but not terrifically fine-grained. You can use netfilter/iptables to put in NAT, port-level forwarding and translation, complex tricks like port-knocking, and protocol-specific filter tricks. Most of those may fall more into the category of "no one does this in large production environments", but even those large environments will have odd stuff that works better with iptables/netfilter than by trying to do it with ACLs in Security Groups.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: