[180221] in North American Network Operators' Group
Re: AWS Elastic IP architecture
daemon@ATHENA.MIT.EDU (Christopher Morrow)
Thu May 28 13:03:32 2015
X-Original-To: nanog@nanog.org
In-Reply-To: <BN1PR03MB18683A4792CA6B7B15D25A0B9CA0@BN1PR03MB186.namprd03.prod.outlook.com>
Date: Thu, 28 May 2015 13:03:30 -0400
From: Christopher Morrow <morrowc.lists@gmail.com>
To: Michael Helmeste <elf@ubertel.net>
Cc: "luan.nguyen@dimensiondata.com" <luan.nguyen@dimensiondata.com>,
"nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
On Thu, May 28, 2015 at 11:59 AM, Michael Helmeste <elf@ubertel.net> wrote:
>> -----Original Message-----
>> From: NANOG [mailto:nanog-bounces@nanog.org] On Behalf Of Christopher
>> Morrow
>> Subject: Re: AWS Elastic IP architecture
>> [...]
>> i sort of doesn't matter right? it is PROBABLY some form of encapsulatio=
n
>> (like gre, ip-in-ip, lisp, mpls, vpls, etc) ...
>> [...]
>
> I don't know how the public blocks get to the datacenter (e.g. whether th=
ey are using MPLS) but after that I think it is pretty straightforward. All=
of the VMs have only one IPv4 address assigned out of 10/8. This doesn't c=
hange when you attach an Elastic IP to them.
>
right, so they encap somwhere after between 'tubez' and 'vm'. and
likely have a simple 'swap the ip header' function somewhere before
the vm as well.
> All that is happening is that they have some NAT device somewhere (maybe =
even just a redundant pair of VMs?) that has a block of public IPs assigned=
to it and they
i'd question scalability of that sort of thing... but sure, sounds
like a reasonable model to think about.
