I've been studying subnetting and of course there's plenty I'm confused about. One issue is as follows: my company uses AWS. For our VPC let's say we have a private network address of 10.2.0.0 /16 CIDR. My question is this: I have a feeling that they can offer this private address to other companies as well. How is this possible? I realize I'm confused about something deeper, but then again, that's precisely why I'm asking this question. Thanks!
It's exactly the same way that any company can use, and reuse, the same private addresses. The private addresses don't get routed where they can conflict with each other.
I my company uses private addresses internally, and your company uses the same private addresses internally, there is no conflict since our two companies can only communicate through a different network, and the same private addresses in each company get translated to different addresses before reaching the other company.
A single company can do the same thing internally. NAT is not just to connect to the Internet, it can be used inside a company, too.
The real way this is done in Amazon is different from how you might imagine, as common solutions don't scale. They did a talk in 2013 about this at re:Invent, which you can watch on YouTube:
However, the more general answer is "IP addressing is a matter of perspective." More specifically, if your hosts never want to talk to the hosts of someone else who was allocated the same IP space, no one cares that you have the same IP addresses. If you do, and you want to talk to each other, then through the use of some mechanism like NAT, you will change the IP addresses of the the hosts in network A from the perspective of network B.
I don't know exactly how amazon does it but I can easilly see a few ways to engineer this.
The key thing to remember is that IP addresses only matter to IP routers and endpoints. An ethernet switch with VLANSs doesn't care if VLAN1 and VLAN2 have overlapping IP ranges, all it cares about is which vlan the packet is on and which MAC address it is flowing between. So if each companies virtual private cloud had it's own VLANs and it's own routers connecting those VLANs then it would not be not a problem for those virtual clouds to have overlapping IP space. Routers
Routers can be partitioned into smaller virtual routers using "vrfs" Linux can do the same thing through the use of "network namespaces".
Or of course you could just use software routers (either the built in routing facilities in major operating systems or something from a router vendor) and run them inside VMs.
Unfortunately as pointed out in another answer these solution's don't scale well to an operation the size of AWS. There are only about 4000 usable VLAN IDs and most routers were designed to support a handful of virtual network, not tens to hundreds of thousands. Ethernet's tree-based design is also a major scaling problem.
That answer also linked to a video at https://www.youtube.com/watch?v=Zd5hsL-JNY4 which explains how they actually do it. To summarize the answer is that the customer traffic is carried in an encapsulated form between VM hosts. Each packet from a client VM is wrapped in a VPC header, then wrapped in an outer IP packet before being sent across the underlay network.
For hosts on the same subnet, the VM host for the source VM intercepts the arp requests from the customer VM and looks up the destination details in a mapping service based on the combination of IP address and customer. The VM host can then use the response from the mapping service to both synthesize an ARP request for the VM and to send encapsulated data packets to the VM host for the destination VM.
For hosts on different subnets the VM host intercepts the arp request for the default gateway in the mapping service, determines it is a virtual gateway and crafts an apprpriate arp response. When the actual data packets are sent the VM host looks up the destination IP in the mapping service to determine where to send the encapsulated packet.
For performance reasons the mapping service runs a local instance on each VM host, which caches all the information about the networks of the customer's that have VMs on that host.