I would suggest that instead of trying to maintain shared state (which IP addresses are blessed) across all of your nodes, you look into using ipsec. Those internal interfaces aren't for security, they're to segment cheap/fast network traffic internal to the dc from expensive/slow/metered traffic that hits the Internet.
Perhaps, but at the same time, you shouldn't be using IP addresses as a security mechanism. Assume the connection between your hosts is compromised, and code accordingly, with encrypted/authenticated connections between hosts.
Not that I want to wade into the "don't use D.O." part of this argument, but, in practice, nobody does this. Virtually every deployment environment I've ever seen with more than 4 hosts in it would be fatally compromised by an attacker who could reach any IP address in that environment.
A VPC is analogous to a physical network, not a subnet. Nobody uses them that way because it's not easy to grok, but you can treat a VPC as a physical network complete with your own numbering and ACL policies.
If you're doing that defense in depth on a physical network, I'm impressed by your dedication but would avoid your work for wasting resources.
it's analogous to a vlan, and it's not that much work to maintain ACLs if the vlans aren't supposed to talk to each other, which they're not, that's the whole point.
We have a lot of interesting stuff coming up later this year around networking. Some of it will be behind the scenes, but it is going to open up a lot of new possibilities for user-facing features. We're looking to give users a lot more control over their network while maintaining our focus on UX simplicity.
Might be a good time to mention we're hiring network engineers as well:
That link is for "a software engineer on the Network team", not network engineer. Did you post the wrong link or just use bad working? I'm a network engineer but I'm not a "developer" by any means -- and there's a helluva difference!
Hey! Guess I miss-typed a bit, and it's too late to fix. We have two separate teams, a Networking team and a SWE-Networking team. It seems we don't have a proper "network engineer" posting up right now, but if you know someone interested they should still get in touch (http://do.co/1mf6HgB).
https://en.wikipedia.org/wiki/Opportunistic_encryption