[180245] in North American Network Operators' Group
Re: AWS Elastic IP architecture
daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri May 29 04:27:20 2015
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAL9jLaZPBGdJW8X+i2JP9jLop6iSToD48Bsk4zKkgfCgCLVKsw@mail.gmail.com>
Date: Fri, 29 May 2015 01:22:12 -0700
To: Christopher Morrow <morrowc.lists@gmail.com>
Cc: "luan.nguyen@dimensiondata.com" <luan.nguyen@dimensiondata.com>,
"nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
> On May 28, 2015, at 10:03 AM, Christopher Morrow =
<morrowc.lists@gmail.com> wrote:
>=20
> 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 =
encapsulation
>>> (like gre, ip-in-ip, lisp, mpls, vpls, etc) ...
>>> [...]
>>=20
>> I don't know how the public blocks get to the datacenter (e.g. =
whether they 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 change when you attach an Elastic IP to them.
>>=20
>=20
> 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.
It doesn=E2=80=99t sound like they have to encap/decap anything.
Sounds like the packet comes in, gets NAT=E2=80=99d and then gets routed =
to the 10/8 address by normal means.
Why do you assume some encap/decap process somewhere in this process?
>=20
>> 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
>=20
> i'd question scalability of that sort of thing... but sure, sounds
> like a reasonable model to think about.
They are known to be running multiple copies of RFC-1918 in disparate =
localities already. In terms of scale, modulo the nightmare that must =
make of their management network and the fragility of what happens when =
company A in datacenter A wants to talk to company A in datacenter B and =
they both have the same 10-NET addresses, the variety of things that are =
inherently broken by NAT or multi-layer NAT, and a few other relatively =
well-known problems, the biggest scalability problem I see in such a =
solution is the lack of available public IPv4 addresses to give to =
elastic IP utilization.
However, this is a scale problem shared by the entire IPv4 internet.
The solution is to add IPv6 capabilities to your hosts/software/etc.
Unfortunately, if you build your stuff on AWS, said solution is not =
possible and Amazon, despite repeated public prodding, has not announced =
any plans, intention, or date for making IPv6 available in a meaningful =
way to things hosted on their infrastructure.
Suggestion:
If you care about scale or about your application being able to function =
in the future (say more than the next couple of years), don=E2=80=99t =
build it on AWS=E2=80=A6 Build it somewhere that has IPv6 capabilities =
such as (in no particular order): Linode, Host Virtual[1], SoftLayer, =
etc.
Owen
[1] Full disclosure: I have no affiliation with any of the companies =
listed except Host Virtual (vr.org <http://vr.org/>). I have done some =
IPv4 and IPv6 consulting for them. I have no skin in the game promoting =
any of the above organizations, including Host Virtual. To the best of =
my knowledge, all of the organizations have ethical business practices =
and offer excellent customer service.
