🎂 What Launched Today - Tuesday, September 26
Presented by: Anie Jacob, Dina Kozlov, Phillip Jones
Originally aired on January 9 @ 10:30 PM - 11:00 PM EST
Welcome to Cloudflare Birthday Week 2023!
2023 marks Cloudflare’s 13th birthday! Each day this week we will announce new products and host fascinating discussions with guests including product experts, customers, and industry peers.
Tune in all week for more news, announcements, and thought-provoking discussions!
Read the blog posts:
- Amazon’s $2bn IPv4 tax — and how you can avoid paying it
- Sippy helps you avoid egress fees while incrementally migrating data from S3 to R2
Visit the Birthday Week Hub for every announcement and CFTV episode — check back all week for more!
English
Birthday Week
Transcript (Beta)
Hello, everyone, and welcome to Birthday Week.
My name is Dina Kozlov. I'm a product manager here at Cloudflare.
And today we have our Cloudflare TV segment that's all about Birthday Week and what launched today.
And on with me, I have two very special guests.
I'll let you guys introduce each other or yourselves. Hi, my name is Anie and I am also a product manager here at Cloudflare for IP addressing and egress.
And I'm Phillip.
And I'm also a product manager, and I work on R2 on the developer platform group here.
Perfect. And so today, like I said, we're continuing our celebration of Birthday Week.
Birthday Week is Cloudflare's Innovation Week. Cloudflare launched on September 27, 2010.
And this year we are turning 13 years old, actually tomorrow.
And so today one of the big themes was all about taking on big cloud.
And so one of the ways that we're going to be doing that is by calling out AWS for the egregious taxes and fees that they're putting on their customers.
So I'm going to start with the most recent tax that AWS has placed.
Anie, can you give us a recap?
Yeah, so this past July, AWS actually announced that they're going to be putting a tax on their IPv4 space, whether it's attached to a service or not.
So that means if you use AWS services, whether you have an IP address attached to a service, or if you just have it with your account, that means that you're going to be taxed for it starting February 1st of 2024.
Wow, that's crazy. And so I read that AWS has a lot of IPv4 addresses.
So just about how big is this tax? Yeah, so this is about a $2 billion tax, which is huge.
I mean, imagine before you just had your IPv4 addresses, you were able to use them with your services.
And now you're going to, I mean, across the globe, we're going to be paying $2 billion in taxes for this.
Right, that's crazy. And I know anytime that you set something up on AWS, first of all, you're testing things out and they instantly start charging you and that's impossible to find.
But also with I feel like every load balancer, every service, like you said, they instantly attach IPv4 addresses.
So I'm sure that's going to impact so many different developers and users out there and they're about to get a big bill for this.
So before we start talking about how Cloudflare is going to help those customers and developers out, can you give us a quick recap of IPv4 and the more recent protocol IPv6 and what all should we know about IP addresses in general?
Yeah, so an IP address in general is just something that your device is used to communicate over the Internet.
Every device needs it.
So whether you're using a service device, your phone, anything, you need an IP address.
So IPv6 and IPv4 comes in because these are two different versions of IP addresses.
So IPv4 is an older version and it is a 32-bit number. And there are about 4.3 billion addresses, which sounds a lot, but actually we have run out of them.
You can no longer get them through a public registry. You have to buy them privately.
Usually these addresses go for like $40 a pop. And even then you have to buy them in a prefix.
So you have to buy like 254 at a time. Whereas IPv6 has a ton more addresses.
It's 128 bits. So there are, I think it's like a decillion IPv6 addresses out there.
So exponentially more than IPv4, way bigger address space. So allows us to have way more addresses for way more devices and hopefully not run out.
Yeah, that sounds like so many. I didn't even know such number exists. But I guess what would be the motivating factor of moving to IPv6 other than the fact that it may be hard to get an IPv4 address?
Yeah. So that first factor where we have, there are just so many more IPv6 addresses is the first thing.
The second thing is it's a lot more scalable than IPv4.
There are a lot more also performance and security measures that we have with IPv6 that have been innovated since IPv4 has been put out and created.
Got it. Nice. And IPv6, I think it launched some number of years ago.
And over time, we have seen the adoption grow. But it still seems like IPv4 is the more popular protocol or standard that customers use.
Why is that? And what do you think is holding back the adoption of IPv6?
It can be so expensive for a company and individual to just update their back end infrastructure, their network to support a whole new protocol.
There is a lot of new security measures.
There's just a lot of, I guess you can say that people's networks are just used to IPv4.
So making that change to IPv6 can be very large, very expensive, take a lot of time and a lot of investment to do.
But I would say I think it's really worth it just for all the benefits of IPv6.
Yeah. And it's just the future. We're not going back to IPv6.
And so when it comes to Cloudflare, if you're using Cloudflare services, do you get IPv4 addresses?
Do you get IPv6? What else do you get?
Yeah, when you use Cloudflare services, you get both IPv4 and IPv6. We offer them both.
We've been using IPv6 since years and years and years ago. One of the first birthday week projects had to do with this exact thing that we're talking about today, helping customers be able to move to IPv6, which is incredible.
So we've been using it basically the entire time we've had Cloudflare.
And we have all, I mean, whether you're using IPv4, IPv6, I mean, you get the robust security networks that Cloudflare has to offer in general.
Yeah. No, that's great. I even know that like in the dashboard, if you go and you try to disable IPv6, it gives you like an old timey poem that's like, art thou sure, you want to disable this and like go to the golden days.
So back to the AWS tax, how are we helping customers avoid this?
And so what are we doing on the Cloudflare side? Yeah, the very interesting thing is like, like I said before, Cloudflare has been prepared for this.
We've actually had this functionality for years. Like I said, this was something that we introduced at one of the first birthday weeks.
It's IPv6 compatibility.
So basically what happens is if you have an AWS origin, but you only use IPv4, what we're going to do is you should go through Cloudflare in order to get an IPv6 address to your AWS origin.
And how that basically works is you come into Cloudflare with your IPv4 address, we convert it and then make it into an IPv6 address so that it can egress out of Cloudflare to AWS.
And you don't have to get taxed for it because AWS is only charging for those IPv4s.
They're not charging for IPv6.
Which is great. You basically get to get around this entire tax and still be able to fully use your service.
And this is also, I mean, it helps you as a customer be able to say like, hey, like, we want to switch to IPv6, but this is going to take us some time.
And in the meantime, we don't want to be paying Amazon all this money just to be able to continue to use our services.
This kind of helps customers say, hey, like, hey, like, I want to move to IPv6, but Cloudflare is going to give us a helping hand, which is great.
And so we're going to use IPv6 only to Amazon.
But let's say I have customers who are using legacy devices that don't yet support IPv6, would they still be able to access my application and domain through IPv4?
Yeah, so if your customers, let's say, like are coming through Cloudflare with an IPv4 eyeball, it works the same way.
You still come through Cloudflare, we convert that to an IPv6 and it goes to whatever origin it is, whether it's AWS or not.
So this works with AWS or it works with any other application that has an IPv6 address attached to it.
Nice. So this sounds really great.
If you're a customer that's watching this and you're interested, you want to know how do I get started?
How do I start getting Cloudflare credits? How can they get started?
Yeah, so what they should do, we have a great blog post out that has great directions.
But kind of a TLDR of that is you want to go ahead and change your AWS origin so that it is IPv6 instead of IPv4.
Then you go into your Cloudflare account and put that new origin in there with that new IPv6 address.
And then you're going to go into your networking tab and there should be a little box there that says IPv6 compatibility.
You're just going to click that on.
And those are the three different things you have to do and it should be on. And also if you want to opt in for a credit deal, which gives you $43 credit.
So instead of paying AWS $43, you're actually getting $43 from us.
You'll also have to go into our opt-in form that should be on Cloudflare.com.
So you should be having traffic running through that connection for the next six months.
Majority of it, 99% of it being to an AWS origin that's IPv6. And we should get you that credit sometime next year.
Nice. That sounds great. Anything else that you think our customers should know?
Yeah, I think just the last thing is Cloudflare has really been ahead with this.
I mean, we've been offering this for years.
And I think this is a great way if you've been saying, hey, I want to be able to move to IPv6, but I don't have the time.
There's a lot of stuff to do. I need help.
We are here to help you. Exactly. If you're looking for a sign or any motivation, this is it.
You're getting $43 back. Yeah. Which you can spend on WAF, security, whatever you want.
You can spend it on as a pro-biz, on our different R2 and workers products.
Yeah, it's a great credit. That's perfect. No better time than right now to switch to IPv6.
So thank you so much, Annie. Now I want to bring up the other notorious tax that Amazon is known for.
So it's no secret that AWS charges its customers for egress fees.
So Philip, before we dive into this, can you just explain what that means?
What is an egress fee? Why do AWS customers have to pay it?
Yeah, absolutely. And that's a great question because I feel like a lot of people that we talked to at first, they're not familiar with it until after they see it on their bill.
So it's good to know upfront. So what data transfer fees or egress fees, as they're also called, mean is essentially you're paying Amazon or a lot of cloud providers for every sort of byte of data that leaves their network.
And it's not only data that leaves their network, but oftentimes you're paying for cross-region egress or data transfer, even if you're going from one region to another within a cloud.
So that's essentially what it means. So if you're doing any kind of data transfer, either between compute instances, or let's say you're serving media or images to your users, that's data leaving the network as well, and you're paying for every byte of that.
So that's kind of what that is. Wow. So essentially, every time that someone makes a request to your application, if there's some media that you want to serve, you have to pay a tax on each one of those requests?
That's exactly right.
So it's typically a cost that's billed per gigabyte. So every gigabyte that's going out or a fraction thereof of a gigabyte, you're paying usually a high single digit in terms of cents.
So it could be $0.09, $0.07, something like that, every time that data is leaving.
And depending on the use case, we see this as quite a large percentage of overall spend that folks have with those cloud providers.
We've heard even in some cases, in excess of around 90% of their total storage costs relative.
So it's quite a huge deal. Wow, that's crazy. I can't imagine you set everything up, you think you paid for it all.
And then actually 90% of your bill is something that you did not even know you were going to be charged for.
Yeah. And it's kind of more than that, too, because it's not a good feeling if you're a developer or you're someone who's just launching a new product, and you're excited to see maybe it's gaining some traction.
But we've talked to folks where they're saying, oh, wow, we're getting a lot of new users, but in the back of their mind, they're not even excited because they know what that means in terms of the cost.
So it's not a good thing to be in that position. No, that's horrible.
You're supposed to be excited about scale, not actually, we need to get users off this platform.
And so I know Cloudflare recently launched R2, which is our alternative distributed object storage.
And so it has zero egress fees.
And so can you tell us just a bit more about R2? And what should our customers know about it?
And why should they use it? Right. I mean, it's pretty much what you said.
So it's Cloudflare's distributed object storage product. There's no data transfer.
So that's part of our model is not charging for that. And that sort of affords a lot of other benefits than just the cost perspective.
We see folks who are storing data on R2 who are able to leverage best in breed analytics tools, no matter what cloud folks are able to use it as the glue for their multi-cloud architectures just because the data is able to move freely, etc.
But yeah, I mean, it's our object storage. It's highly durable, highly available, has great performance as well.
And we're seeing many thousands of developers and other folks use it to power their applications.
Nice. And since R2 is relatively new, I'm guessing that means that most of our customers' data already lives somewhere else, especially if their applications are older than the product.
So if that's the case, what's the best way for those customers to start migrating over to Cloudflare?
That's a great question. And I suppose that's the reason I'm here is we have some new data migration products that we're offering.
So a few months ago, we sort of announced the general availability of a product that we have called SuperSlurper, which is a tool that allows folks to migrate data from cloud providers like S3, AWS S3, to R2 in one go.
So essentially, it allows you to easily say, this is my S3 bucket, this is my R2 bucket.
And in the background, we move it over in a quick, reliable way.
However, for use cases where you just kind of want to move all your data over, it's perfect.
But there are other use cases where you may want to start moving your data over slowly.
And I guess, why would you want to do that?
There's a few reasons. One of those reasons is that thing that we've been talking about called egress or data transfer fees.
So if you have a lot of data in Amazon S3, and you want to move it all over to R2, that data leaves the network, and there's a cost associated with that.
And then some of the other reasons just have to do with ease of use and making live migrations or migrations with minimal downtime.
Moving things all at once, you have to sort of consider how are you going to make the switchover.
And today, we announced something called SIPI, which is our incremental migration product, which addresses a couple of those pain points.
And I could talk just briefly about how. So specifically cost, right?
If you have a gigabyte of data, and you just move it just for the sake of migration, maybe it's going to cost you five, nine cents, something like that, and data transfer fees.
But if instead of migrating it sort of just to migrate it, instead, if you were, you know, as your users were requesting the data, maybe you have like an image as users requesting an image, you're going to be paying that data transfer to AWS, whether you know you're serving it directly to the user, whether it's moving, you're migrating, etc.
And so we're sort of leveraging that natural flow of your application.
And when your users are actually pulling data to simultaneously serve that to the user, and then also copy it to R2.
So, you know, we're sort of leveraging the fact that your users are already requesting things, your applications are already requesting things, and we're able to copy those over to R2, you know, all at the same time.
And what that means is no sort of additional migration specific egress fees.
And then once your data is actually moved over to R2, then you get the benefits we're talking about of, you know, zero egress from from then on.
So super excited to make that announcement today.
And super excited about kind of the pairing of those two migration tools as well, because you can, you know, sort of incrementally migrate some and then move over the rest, you know, if you see fit in the future.
No, exactly.
Also, I have to say I love the names. And so if customers want to start doing this today, how can they get started?
Yeah, so, you know, the, I think a good first resource to check out would be the blog post that we're excited about that that came out today.
And that blog post also links to our document links to our documentation if you want to learn more about how this works, or how to set it up.
So, you know, today was the announcement of SIPI going into open beta.
And right now, the way you enable it is via an API command and we have some example commands of, you know, how to how to set it up and more information on getting started.
Nice. Um, and so what is, I would love to just hear what is some of the feedback that you've gotten from customers that have migrated from using AWS to R2?
Yeah, I think in terms of the migration products, specifically, just, you know, what we've been hearing is just how fast and easy it is.
So, you know, when we're talking about super slurper and kind of migrating all the data at once, some of the things that we're hearing from folks is like, hey, like, I was expecting that migration to take, you know, many hours and it was done in a few minutes.
Right. So I think just surprising people on how fast it is. And then in terms of, you know, the incremental migration and that SIPI provides, I think it's really the, you know, ease of use of it, where it's something that not to not to kind of, you know, be a little too excited.
Yeah, but it's, it's almost magical in a sense, because in terms of ease of use, in a way, it kind of eliminates, you know, the fact that you need to think about migration at all, because it's something that's built right into your storage bucket on R2, you just turn it on.
And then from the moment you turn it on, you can essentially use, you know, use that bucket via S3 API, public URL, whatever, as if all the data is there.
So I think the real thing is ease of use, because, you know, you take an empty bucket, you just say, hey, this is the bucket it belongs to an S3.
And then you just start making requests.
And then you go to the dashboard, and you just see your data appearing there.
And you go to AWS, and you see your data transfer bill, you know, falling off a cliff, right?
And that's, that's really what, you know, we've been hearing and what we're excited about today for.
No, um, that's so incredible.
I'm sure so many different companies are excited to move their data to R2.
And then, you know, the next month, they're like, we have all this money. What are we going to do with it?
There's so much they can start investing in to continue building out their solution.
So it's going to be like Christmas for all of these customers.
And so I would love to know if you can share with us, is there a sneak peek of what's coming up next for R2 that our customers should be excited about?
Yeah, I think for SIPI and some of the migration things. First of all, I guess for SIPI specifically, you know, right now, I mentioned that it's enabled via an API.
And some of the things that we're looking forward to doing next is, you know, putting it in the dashboard, making it easier and more accessible for folks to go ahead and enable and start getting that benefits.
And then some of the other things we're looking forward to do on the SIPI front as well as provide analytics to folks.
So, you know, as your data is getting migrated, we want to tell you how much you're saving in egress, you know, how much of your data has been moved over already, things like that, and provide that in the dashboard too.
And then, you know, outside of data migration things, I think one of the exciting things that we're working on now is just providing, you know, lower cost, you know, methods of storage, lower cost ways of storage for folks who are storing kind of like long tail multimedia assets, things like that.
So that's something that we're excited and we're building towards.
No, that's great. And I love the analytics aspect.
I'm sure people are so excited to kind of like take that screenshot, take it to their boss and be like, this is why we're moving to R2.
Look how much we're getting back.
Yeah, absolutely. And so these were not our only announcements today.
We have a few other exciting ones. If you would like to learn more about them, I highly recommend that you read the blog post or watch the other Cloudflare TV segments.
But just to give a quick recap of everything that was launched today. So last birthday week we actually launched the Cloudflare Radar Outage Center.
What this does is it allows the community to stay updated on Internet disruptions, like outages and shutdowns that we are seeing all around the world.
And so what we are excited to do now is to add an alerting feed to Cloudflare Radar that's going to show both the country and network level outages as we detect them and make the data available via API so that anyone out there can automatically pull it.
But that's not all.
We're also going to be launching new notification functionality so that you can subscribe and stay updated on traffic anomalies that we're seeing, any confirmed Internet outages, route leaks or route hijacks.
And so Cloudflare's dashboards, within the Cloudflare dashboard there's where you can set up notifications for just like your domain, your origin, but that's also where now users are going to be able to set up notifications for one or more countries, or even autonomous systems, ASNs, and receive notifications whenever we see relevant events occur.
And so these notifications can be sent to you via email or webhook.
And so what we're really hoping is that by adding this transparency and surfacing all of this information, that we really are going to encourage network operators to do better if they're not doing well.
And we really hope that this is going to help shape the Internet to have less outages and less route leaks and make it more secure in the long run.
And then also if you'd like to learn more, we have a technical deep dive that we published today that goes into how we went about solving this problem and all of the challenges that came with it.
Another thing that we announced today is that starting November 15, we are going to be merging Cloudflare Images and Image Resizing into one product.
So all image resizing features are now going to be part of the Cloudflare Images product.
But not just now, we're also going to be launching a new pricing model for it.
And so that's really going to help you calculate more accurately and reliably what your monthly costs are for your images.
And so make sure to read our blog post around it and learn more about how we came about to these decisions, all of the changes that are coming, and how you may be impacted if you are using our images products.
But that's all that we have for today.
So tomorrow is Cloudflare's birthday. It's going to be a very exciting day.
I wish I could share all of the announcements right now, but I'm not going to spoil it.
And so please get ready. Thank you all for tuning in and stay updated.
And happy birthday week.