I'm kinda sick of all the AWS posts on here, but I'm trying to be fair since some of them are really interesting.
This is one of those that's more of a "about damn time," features that'd I'd care about if I already didn't go with Digital Ocean/Linode instead just because of IPv6 support.
The reason there are all these posts in the last few days is because AWS's conference re:Invent is going right now in Las Vegas, and a lot of these announcements are therefore being made right now.
This is the post I've been waiting for 2+ years - we have a ton of projects that we would like to deploy on AWS, but EC2 and friends have never supported IPv6, which has blocked us from moving forward, and our customers are reluctant to deploy on anything other than the big 4 (IBM/Google/Azure/AWS).
I think "about damn time", but I definitely want these posts - I use AWS despite its flaws, and it's important to me to know what's going on.
As long as AWS is both widely used by existing users, and is a likely option for new users evaluating alternatives, these AWS posts are always relevant on HN.
We needed IPv6 support five years ago. IPv6 is so vital because without it, we'll see the cost of public IPs skyrocket. I'm surprised it hasn't considering two of the places I worked for in the past few years had trouble purchasing IPs for some of their larger data centre offerings.
It's sorta like the network neutrality argument, except you're talking about limits on who can offer services to everyone vs those with newer IPv6 devices and ISPs. You can end up with two different Internets.
What product are you building where you can avoid needing public IPv4 addresses considering that the vast majority of the people on the internet still use IPv4? It seems like you'll still need both for many years.
Yes, I agree with you. Which again makes me wonder why djsumdog considers full IPv6 support so critical. Except for very unusual businesses it doesn't seem to make sense.
Our entire application back end is written in IPv6 only. We don't have an IPv4 version of our product. Until IPv6 was offered, no way for us to host our application on AWS.
Good question - It's not the APIs that are the issue, it's the actual IPv6 addresses in the packets on the wire that we need. All of our remote devices (typically on the order of 5 million+ for larger customers) have IPv6 addresses. We can use tunnel routers to get the traffic over IPv4 networks to the destination, but the applications themselves are addressing the devices with IPv6 addresses - which means, at least on the network segments that our many applications servers are running on, we need to have IPv6 routing working.
Everything we've done assumes an IPv6 network - trying to squish large device networks into IPv4 is just a losing battle for a huge number of reasons (address mobility, address conflict, large number of downstream devices (20,000+) per network segment, etc...)
Couple different classes of customers - utilities are the existing (Electric/Gas/Water meters) and IoT (Sensors, Street Lights, Parking) are the up and coming.
Both of them lend themselves well to mesh networking application, and mesh networks, in which any one of the 5mm+ deployed devices might appear in any one of the 10,000+ network segments, and in which we just want to concatenate the MAC address and Network segment to get a network address (basically SLAAC) - really makes IPv6 a pretty good fit.
A few months ago Apple made it a requirement for all new iOS apps and app updates to support IPv6 only networking.
If the app backend is not also available from a network where IPv4 is completely blocked, the app is rejected.
At the same time, AWS does not let new accounts to create EC2 instances outside of VPC, and only provided IPv6 support in the non-VPC classic stack (only available to old AWS accounts that signed up years ago).
So for the last few months, AWS has been unusable as a backend for iOS apps unless you have an old classic AWS account.
The requirement is only to work in networks with NAT64. That means your app can not hardcode IPv4 addresses and not rely on IPv4 only APIs, it has to work if any of its backend services are only visible through an IPv6 address from a NAT64 gateway and it receives that address from a DNS64 service. The backend service itself does not have to have IPv6 connectivity.
A funny quip, but since it seems like you're missing the point: what's the business impact of the choice, or the existence/absence of IPv6 support in a hosting provider?
If I'm running a small startup that's available as a website, how does IPv6 support matter to me? (Assuming that I can otherwise get IPv4 addresses for hosting my site, which I can.)
Because there are many other factors in choosing a hosting provider (price, performance, features, security, scalability, etc). It seems a bit weird that all of these would be less important to someone than IPv6. Though I guess I can imagine that for some businesses it could be hugely important. Was just wondering what OPs business was that it became an overriding priority.
Rolling out an IPv4 only stack right now is debt. IPv6 has finally hit the point where there's no longer an if portion to the question, but rather a when. Every server rolled out in an IPv4 only setup, every service built, etc, is one more potentially service-interrupting area that will have to be changed when port your stack to IPv6. If you're young and small, starting as IPv6 native means that the next few years you'll have an advantage over your competitors because they'll be thinking migrations while you're thinking about growing your business.
That's reasonable, but I think you significantly underestimate how long it will take before these sorts of conversions will become necessary. IPv6 is 20 years old. These things take decades not years.
In addition, I think you overestimate the difficulty of conversion. Most backend servers run on 10.x.x.x networks and that doesn't need to change. You just need a proxy in front of them that can speak IPv6. Installing a new proxy does not sound like a hard job. It sounds trivial.
Great! Lots of people on Hacker News use AWS because places like Linode and DO don't actually have all the services and scale their work requires. Believe me, we agree that this announcement is several years overdue. I think most engineers who work in AWS would also agree. But when you get to their scale, it's hard to make big changes like this in a safe way. The fact that it rolled out in a brand-new region (us-east-2 only for now) is good evidence that they are being very very careful with this rollout.
And as mentioned, the reason there are so many AWS posts this week is because they save up all their announcements for the conference going on right now. I sorta wish they'd spread the stuff out more, myself, but these are mostly HN-front-page quality announcements. It's just a year's worth of work dumped all in two days.
>But when you get to their scale, it's hard to make big changes like this in a safe way
Which only makes it more baffling that AWS still doesn't support IPv6 everywhere.
IPv6 is 8 years older than AWS. AWS is a decade old. Given that the inevitability of IPv6 is long known and that it's well known that as a rule changes get more difficult the bigger you get, I would have expected Amazon to start IPv6 deployment much earlier, back when AWS was much smaller.
Pardon my ignorance, but why is this needed? I've seen dozens of "+1s" for ipv6 on both AWS and GCP, but no one says why really. Is there hardware out there on the public internet that cannot communicate over ipv4 already?
Most of it can't, actually. Rather, using the words in the question in their strict meaning, most of the hardware out there is not on the "public internet", it is behind NAT.
You can argue that behind NAT there is still IPv4 connectivity with public internet, but it is actually closer to proxying (i.e. having some device talk to internet on your behalf) than to routing (i.e. have some device pass your packets on).
Long story short, there is (for a long time already), no IPv4 public internet. There is IPv4 public interconnect between millions of isolated IPv4 islands. And a lot of hacks and shady engineering to make packets traverse from interconnect to islands and back.
You individually? There really isn't a reason to. *
However, as a whole, the lack of native IPv6 support in EC2 certainly held back the global deployment cycle. It's the chicken and the egg problem: Without support for servers that use IPv6, there is no reason for last mile providers to implement it in households. With this update, a huge swath of sites will get support, hopefully leading to quicker adoption for end users.
* for most applications. This is certainly trivializing a subset of applications where this could be useful.
The reasons are many. I'll name just a few:
* You cannot send UDP packets to your IPv4 customers.
* You cannot initiate TCP connections to your IPv4 customers.
* You cannot use any application-level protocol that carries information about source or destination IP address.
* IPSec more or less goes out the window
Of course you'll keep your firewall. NAT != Firewall
Your firewall may start with a simple "deny all incoming SYN packets" rule, but IPv6 gives you the option to open up holes in the firewall to any device or devices on your LAN (port forwarding only works once per port through a NAT).
The real benefits probably don't exist yet. There are entire categories of network software that have remained unknown and unexplored because it didn't work behind a NAT. There were several projects I wanted to write ~15 years ago that I never even started because it required a real internet connection, not a NAT "party line".
> Your firewall may start with a simple "deny all incoming SYN packets" rule, but IPv6 gives you the option to open up holes in the firewall to any device or devices on your LAN (port forwarding only works once per port through a NAT).
But see.. I can already do that with IPv4 and Nat. Oh I want to run a ftp server on my backend? Open up port 8000 on my firewall and forward to port 21 on my FTP server.
I find it weird I am making this argument, as I am normally progressive. I push Python3 over Python2, because it is the way of the future. Even though it causes me pain sometime. For some reason, I just do not see the (for me personally) reason to care about ipv6.
Clearly the more backbones that support it, the better. It at least gives us the OPTION to use it later. Not totally sure what good it will do still though ;)
> Oh I want to run a ftp server on my backend? Open up port 8000 on my firewall and forward to port 21 on my FTP server
funny you mention FTP where that is distinctly not true as the application level protocol encodes IP addresses and ports to either (depending on PASV mode) peer to open for the data transfer.
If your server is behind a NAT and the user is using passive mode, it'll tell the client to connect to some internal ip address, so unless the NAT router does deep packet inspection and alters your packet on the go, that won't fly.
Conversely, if you disable passive mode, a NATed client would have the same issue because in that case it would tell the server to connect to some internal IP on the client's side which too won't fly.
Same issue for all other protocols that have IP addresses in their payload. There are very few of them these days for precisely this reason, many early media streaming and VoIP protocols were doing this too.
Also somewhat related: Port forwarding from one public address only gives you the ability to forward to one specific server. What if you want to run two different HTTP servers on your backend? What if you want to run different SMTP servers on your backend.
Now you're again down to needing packet-contents inspection or you need multiple public IPs in the first place plus a more complicated NAT table. With v6, all you need is to open a few ports.
And these were the technical issues.
There's also a political issue: As v4 addresses get more and more scarce, so increases the control entities with addresses get to have over what services they do and to not allow on the network.
Do we want to live in a place where no new service gets to participate in the internet? Where the next Netflix can't launch because none of the providers want to have yet another service competing against their own content business?
In order for the internet to continue to grow, we need an abundance of addresses and the only way to get that is to have wide-spread v6 support. And in order to get there, every single bit counts: Every service that can offer v6 should. Every provider that can offer v6 should. Only this way we can avoid one big cause for a very much locked down internet in the hands of the providers and the old guard.
v6 plays a very important role for both technical and political reasons to the point where we really need to fight the "v4 works fine for me" attitude. Having a v4 address to run a service on is a privilege. Don't argue from a privileged position based on lazyness.
(pilif already covered the main arguments, so I'll keep this short)
> ftp server ... port 8000
Of course there are workarounds. This one requires specifying a non-standard port every time you want to use your server. That may be easy[1] now, but it becomes increasingly problematic the more times you create these workarounds.
The bigger issue is that hosts behind the NAT are not first-class citizens of the internet. They require an imprimatur[2] to publish. If you live in a privileged area that has a static v4 address, this isn't a huge problem. If you live in China behind 3+ layers of NAT, getting a port forwarded to your host isn't going to happen. As NAT becomes more complicated with more layers, even the insane hacks[3] we have to punch holes in NAT (which already require a 3rd party's permission (imprimatur)) start to fail. This will become an increasingly common problem as competition over v4 addresses increases[4].
> Not totally sure what good it will do still though ;)
It will enable the development of new network software that doesn't work over NAT. This type of benefit isn't immediately useful, so think of it as an investment.
It will let more people gain the benefit of being able to publish without needing the permission of a 3rd party. You may not find that important personally, but impartial media access is one of the most important properties of the internet. If we are not vigilant and robust in defense of every peer's right to publish, we will loose it. This isn't a theoretical concern, given how centralized the internet has become in the era of Facebook and Google.
[1] modulo the serious problems that FTP has with NAT that pilif already mentioned
[2] While I don't agree with everything in the essay (some things have changed since 2003), John Walker (co-founder of Autodesk) wrote a very insightful warning about the trend towards requiring an imprimatur to publish: https://www.fourmilab.ch/documents/digital-imprimatur/
I'm currently in a situation where I've needed to extend access to a wireless network - with two routers (as each has a single radio).
So I have a router that connects to a NATed subnet, which is plugged into another router which provides DHCP to a different private address space for my devices. Granted, in theory all these media hops could've been handled by (more) ethernet level bridging - but if I had simply had native routable ipv6 on my lan, routing through a couple of boxes would've been rather simple - as would exposing ssh or samba on my desktop to the lan or the Internet.
As it is, it's a terrible hack, that sort-of works...
In the vast majority of cases, you cannot use proxying/routing to reach an IPv6 address. If you don't have IPv6 yourself, then any attempt to communicate with another IPv6 address simply fails.
It's sort of like asking "Why should I connect to the Internet, if everyone I know already has a telephone?"
I don't know enough AWS to understand the announcement, but if your servers and your clients can speak IPv6 and you can skip al the NAT, you don't have to debug NAT problems.
We probably won't ever be rid of NAT. The likes of Cisco, who thrive on making things enterprisey and needlessly complicated will definitely be peddling IPv6 NAT soon, if they aren't already doing it.
You're probably right, but many telecoms have already deployed ipv6 without a bunch of layers of networking hell, and I'm hopeful that they'll just junk all the crazy ipv4 stuff without replicating it in ipv6. It'll be cheaper for them and nobody will notice the difference.
NAT gives the same amount of security as dropping all SYN packets at the firewall level. The latter just requires much fewer resources to do as it allows for completely stateless operation.
IPv6 NAT is generally discouraged and providers can gain huge benefits too from not doing NAT. NAT always implies state which needs to be stored somewhere. The moment you NAT, you very likely won't be able to do the routing in pure hardware any more, so throughput is an issue.
routing v6 directly is completely stateless. It can easily be done completely in hardware possibly not even requiring to store the packet anywhere, nor needing any knowledge of the protocols wrapped inside of the IP packet.
To do NAT, you need to know about TCP and UDP and about the various ports which means you need to look into the IP packet. To route v6, you just look at the IP packet.
More and more people are now getting IPv6-only connections (notably on mobile). To access IPv4-only websites, the ISP is using "carrier-grade NAT". Therefore, if your website is IPv4-only, users will go through a big translation cluster. The incentive for an ISP to keep it running well will become lower with time: the most "important" websites are accessible through IPv6. If you are IPv4-only, you will provide some of your users suboptimal service because the CGNAT box may slow down connections, drop connections or loose packets.
Along with the usual 'we are out of ipv4 space' - If you are in the IoT space you are dependent on IPv6. And if you are AWS you may be losing customers who are rolling out IoT infrastructure because of your lack of IPv6 support. http://www.computerworld.com/article/3071625/internet-of-thi...
It would be very bad form to wait until there was a prevalent set of users that couldn't access your service. It's almost the other way around, AWS – because it operates such a huge chunk of Internet sites – will bring the day where it's reasonable to ditch ipv4 much closer by expanding ipv6 support.
Is there a succinct developer/administrators guide to IPv6?
I recently discovered my home IP is ipv6 and have started to realize that it is more than just a larger address range. e.g. arp is replaced with ndp. While I haven't yet found a guide that has more depth than the very basics, but isn't a full on Cisco manual.
And you can get an awesome T-Shirt if you complete it. I wear mine with pride, mainly because in the process of doing it, I nagged our business ISP into properly supporting reverse delegations
I’m not an AWS user, so the “Virtual Private Cloud” caveat confuses me. If I just click an EC2 instance, will that be in a “Virtual Private Cloud” or not? Also, are these IPv6 addresses publically reachable or not?
If you're not an AWS user yet then any EC2 instance you create (if you ever decide to become an AWS user) will be in a Virtual Private Cloud, either one you create yourself or the default VPC associated with your account.
Only older accounts (from before december 2013) have the ability to create EC2 instances that aren't in a VPC.
They are public. When you create an AWS account, you will have a default VPC (this wasn't the case with the classic EC2), and when launching an instance, if you don't specify anything else, the instance you launch will be in the default VPC.
I went to one of the first IPv6 sessions at re:Invent this morning. The room was for maybe, 300-400 people? There were 40 or so people in it. So, yes, the interest is low.
That said, I think it's a great signal to the industry, and I'm excited to try to use IPv6!
Most production environments terminate on Cloudfront endpoints (or other CDNs) or ELBs/ALBs; not much need for IPv6 to individual instances (which can use IPv4 internally).
Could you explain? How does it help to use IPv6 internally if you're using IPv4 publicly?
One of the original motivations for IPv6 was that it would provide enough address space for every device in the world to have its own unique IP address. Then devices could communicate with each other directly, without worrying about intervening NATs. If you're using IPv4 publicly, then you've already lost that advantage.
Concerning private networks, IPv4 offers more than enough address space within its private ranges for your private network. The 10.0.0.0/8 block provides 16 million addresses, and there's also 172.16.0.0/12 and 192.168.0.0/16. There are certainly enough addresses in these ranges that running out is not a concern, so it does not seem that IPv6 would provide a benefit when applied specifically and only to private networks.
It frees you from expensive complexities arising from tunneling and private address space. You don't need the network engineering and service costs to bring your private 10.x overlay network to your various datacenters[1] behind different ISPs, you don't have to fight with addressing conflicts when talking to other people using rfc1918 space or debug situations where 1918 addresses are ambiguous, etc. It's cheaper, safer and simpler to integrate with other organizations because you only have to configure your firewall rule instead of trying to mash together incompatible rfc1918 internal networks and overlay technologies in addition to the fw. Your security posture is better and cheaper to maintain because your simpler network is easier to reason about.
[1] meaning your network locations, not your private datacenter (necessarily)
> IPv4 offers more than enough address space within its private ranges for your private network
While theoretically true from a raw numbers standpoint, it breaks down at Facebook's scale when you have many gigantic data centers all over the world and start thinking about how you assign the addresses and manage the network that uses them.
As the presentation says, there was lots of wastage due to racks being /24 and clusters being /n (where n < 24).
Assuming you want to provide IPv4 and IPv6 to the outside:
You can relatively easily map IPv4 addresses into IPv6 range: just pick a /96 prefix and append the 32 bit IPv6 address. This is a relatively easy translation, that does not require the machine doing the translation to keep state !!! (so you can send traffic to a random one and it can do the right thing, no need to have connections stick to one). It is thus quite easy to make an IPv6-only network deal with IPv4 clients. With decreasing IPv4 usage, your network naturally adapts since it only becomes easier.
The reverse is not easily possible for serving IPv6 clients from an IPv4 network: you can't map IPv6 1:1 to IPv4, so your gateways have to be more like traditional NAT and keep state tables around, which makes operation in general and load-balancing/fail-over in particular harder. The more and more IPv6 clients you have, the more resources you need for the translation. And at some point in the future, you are going to want to switch.
You could alternatively run your entire DC on IPv4 and IPv6 double-stack, but that adds a lot of unnecessary complexity. Your routers now have to keep routing tables for both around, behavior could differ for both, your applications (logging, fraud prevention, ...) have to understand both, ...
If you are in a position where you control everything you run (so you can make sure there aren't any stragglers that require IPv4 because their vendor doesn't care or something like that), the IPv6 model can be attractive. Do the switch and be done with it for the future, limit your dealings with two protocols to the very edge.
At my company, we used to use IPv6 internally and IPv4 publicly for future proofing and easier migration to a all IPv6 environment. Instead of changing the entire infrastructure we just had to change the gateway.
> The 10.0.0.0/8 block provides 16 million addresses
> and there's also 172.16.0.0/12 and 192.168.0.0/16.
> There are certainly enough addresses in these ranges
> that running out is not a concern
With the constraints of subnetting, it is a concern. I know a very large telco that ran out of private IPv4 addresses - and that specific issue was the reason for finally launching a proper IPv6 project.
One reason you would like to go full Ip6 internally may be if your network fit well in a case where you can have only 1 DNS server instead of maintaining 2: 1 for the external IPs plus 1 for the internal IPs. With IP6 you could get rid of the internal DNS server (Which would be simpler for small networks).
The biggest advantage I see (which is heavily coloured by the use cases I faced at Heroku on the Add-ons team) is being able to peer many VPCs without gymnastics to avoid IP range clashes and routing issues. I haven't looked at AWS' IVv6 announcement in enough detail to know if it addresses this head on, but I always looked forward to IPv6 as an avenue to making that kind of work much more straight forward.
Don't plan on inter-region peering ever shipping. Easy to do in network fabric at a region, not so easy to do across regions (constrained by fiber connectivity).
That's my thinking as well. Surely behind the edge is all implementation and should be hidden?
The only appreciable benefit i can see right now is that everything moves back to be a routable internet, no more NAT / nat scaling issues for EC2's sending large quantities of data directly to the public internet?
VPC ELBs and ALBs don't support ipv6 though. Presumably this is the first step to adding that support, although it's still not available even in the new ipv6 VPCs.
The more layers you have, the more time you need to convert all of them to IPv6 (from network to all the applications). IPv6 implementations of various things is always less complete than their IPv4 counterpart.
Notably, even low-level stuff may still be difficult to make with IPv6. For example, Linux supports IP equal-cost multipath routing for IPv6 since 2012. Quagga, a popular routing daemon, still doesn't support that. BIRD, another open-source routing daemon, just got partial support for it this year. If your network is relying on this, it's an additional burden to deploy IPv6.
Granted, that isn't necessarily a pre-requisite for going dual stack (aka: just attaching a v6 address to a machine), but it shows the fun problems you run into.
Might be a dumb question, but why would you want or need more than one IP address for an instance? It's not like more addresses will let you download/upload things faster. Maybe if you want to run multiple web servers on port 80 and give each one a different IP address, but how often do people do that, especially more than 8 times over?
Picture running something like Docker on a box, where each container gets its own IPv6 address—with services on their proper ports—instead of mashing a bunch of NATed ports together under the host's IP.
Or, moreover (and this is a bit of a pipe-dream, but it's something I've been hacking on to make possible) picture running something like an Erlang node on a box, where each Erlang process gets its own IPv6 address, fully Internet-routable. This effectively makes Erlang into an SDN vswitch for ephemeral, featherweight virtual machines (which would be oddly similar to AWS's just-announced "Lambda@Edge".)
Quantity changes the quality here. IPv6 address space being so large, we can afford to give everyone a virtually infinite number of addresses. Which in turn enables everything to be globally routable. I never cared about IPv6 much. Once I grasped it I am actually so so excited about it.
You'd more likely want them for outbound connections. On modern OSes, the IPv6 stack periodically calculates a new IP (see https://tools.ietf.org/html/rfc4941). Think of it as a kind of one-time-use address, so remote machines can't say "hey, I got a download request from this IP last week. I should try to hack it today!"
This honestly doesn't surprise me. Adding an infinite number of IPs is one way bot writers get around rate limits. I've done it before when I worked for a company that made a facebook/myspace/etc crawler.
Per IP rate limiting with IPv6 is a futile gesture against any attacker more sophisticated than a kid in his parent's basement. It doesn't take much effort to get a /48 while most ISPs are handing out /64s to their customers. This leaves rate limiters in a catch 22: Are all those requests coming from a given /48 a single attacker, or a bunch of Comcast users? It's impossible to tell without maintaining a table of what the "end user" allocation size is for a particular IP range, which would be a massive, never-ending task.
Out of curiosity, why does Amazon consider it their responsibility to prevent that? I'm personally glad that they do, but bots use resources, which is good for Amazon (money in their pocket), and as far as I know Amazon doesn't have anything it wants to protect from bots (at least, anything that would be heavily limited by IP).
In addition to the answers other people have given about not wanting AWS IP space blacklisted, people who are intending to do use services for nefarious purposes have a nasty habit of paying for them using stolen credit cards.
Well, one explanation might be the reputation of their IP ranges. Already, payment processors and some mail servers will give extra scrutiny to IP ranges belonging to AWS. If AWS is made attractive to that audience and damage is done to the reputation (in various systems) of those IP ranges, their offering becomes less compelling to all customer demographics.
From a rational self-interest standpoint, bots tend to get their IP addresses blocked by whoever they're targeting. Which means the Amazon IP address space gets on threat lists and block lists. The bot owners can just generate new instances with new IP addresses, and then some legitimate customer spins up an instance and gets their address, and wind up on blocked. The bots keep going until various services decide to just block all of Amazon's space, the same way they would for Tor exit nodes or other things associated with shady activity.
As a good netizen, you want to ensure that other providers don't blackhole your IP blocks (which they will if you allow abuse to be emitted from said IP blocks).
Infinite IP addresses aren't the same as infinite routable IP addresses. EC2 VPCs use private subnets, and instances created in VPCs don't have routable IP addresses unless you add them. It would be reasonable for AWS to allow infinite VPC subnet addresses to be attached to an instance, but only one or two public addresses.
I believe this doesn't mean there's IPv6 support for ELBs in a VPC yet. We unknowingly enabled dualstack configuration on Route 53 some time back and this led to users on devices which prioritised IPv6 over IPv4 to fail to connect.
The state of IPv6 remains sad and depressing. I just switched to centurylink fiber from comcast and I still don't have an IPv6 address. I have the option, but I have to pay for it, which seems totally backwards to me. Sure, I will pay for a static IPv4 address if I need it because I understand that they are few and far between by now. But you can't just give me one v6?
Basically I have a fiber connection in the US, which on it's own is pretty mindblowing, but no IPv6 address...
I have to wonder if Amazon started releasing all this product news to cover up the fact that one of their employees jumped off the company building in an apparent suicide attempt:
The AWS reinvent conference is going on, which is their annual developer conference. So probably just a coincidence. Each announcement has a stage announcement and planned sessions as well.
