AWS Generative AI Analyst Summit | Rob Kennedy & Anoop Dawani, AWS

Clips
More from AWS Generative AI Analyst Summit

Robert Kennedy

Vice President, Global Network Connectivity

AWS

Anoop Dawani

Director of EC2 Networking Product Management

AWS

play_circle_outline Data transfer out made free for customers to move data out of AWS at no cost.

play_circle_outline Lowering IT costs through larger free tiers and investments in network infrastructure.

play_circle_outline Maximizing AWS Benefits: Scalability, Resilience, and Cost Savings with Optimized Network Infrastructure

Info
Transcript

Rob Kennedy & Anoop Dawani, AWS

Robert Kennedy

Vice President, Global Network Connectivity AWS

Anoop Dawani

Director of EC2 Networking Product Management AWS

The discussion at AWS Studios focuses on networking, cloud computing resilience, and data transfer. Rob Kennedy, VP of Global Connectivity, and Anoop Dhawani, Director of EC-II Networking Product Management, emphasize the reliability and scalability of AWS infrastructure. They discuss the design of AWS as a scalable and reliable cloud computing environment, with a focus on network availability and independence. Services like Transit Gateway, PrivateLink, and NAT gateway allow customers to build secure architectures across multiple availability zones and regio... Read more

explore Keep Exploring

What was done to address the issue of data transfer being a barrier for customers to move out of AWS? add

What change did the company make last year in relation to data transfer out for their customers? add

What are the key principles and strategies behind AWS's network design and infrastructure reliability and availability? add

bolt Powered by CUBE AI

Rob Kennedy & Anoop Dawani, AWS

search

>> Hello, and welcome to theCUBE, live from the AWS Studios in Seattle. We're really unpacking what's going on, specifically around networking and cloud computing and some of the resilience and data transfer that's going on in here. I think I couldn't ask for two better people to come onboard with me to really unpack this. I got Rob Kennedy, who's the VP of Global Connectivity for AWS. And Anoop Dhawani, who's the director of EC-II Networking Product Management. Thanks for coming onboard, guys.

>> Yeah, thanks for having us.

>> Thanks for having us.

>> I think that, again, you guys have been making some great announcements in this space. Earlier this year you really talked about data transfer out to the internet, and really how it helped organizations that wanted to, if they were going to fully move out of AWS. What are you hearing from customers about this, and how do they understand DTO and the costs of that?

>> Well, honestly, we haven't heard much from customers in terms of moving out of AWS. Data transfer is a big blocker or barrier. In fact, from our perspective, we just really wanted to get rid of the misinformation that's out there that says there is a barrier. And so, earlier this year, we basically made it free for any customer to move all of their data out of AWS at zero cost.

>> Yeah. Again, there was a whole bunch of people who were announcing, "Hey, if you're going to leave, we'll make it free for you." And I think, again, it makes a lot of sense that, again, people want their data back, they can get it back. Which I think always was an AWS thing. It's your data, you own it kind of thing. Anoop, really, some of the recent news coverage around repatriation. What have you been seeing? Because people are saying, "Hey, it's due to cost," and things of that nature. What are you seeing in the ?

>> Based on even the data transfer out that we made it free, I don't think we have seen anybody moving out of the cloud. In fact, I see the trend in the opposite way. There are just too many examples. But for instance, there's a company called Fortis, they're a healthcare company. They operate in 50 countries, and they just very recently migrated their transit backbone network over to AWS using a service called AWS Cloud WAN. And by doing so, they retired all their on-premises hardware, simplified their network architecture. And in this process, realized 70% cost savings in their network transit service cost. These are some of the examples. Another great example is Capital One. I think in 2020 they migrated all their data centers to AWS. I think they became the first US bank to be all in the cloud, and they've been actually scaling pretty well and reaping benefit of cloud.

>> I think it's also important to highlight some real facts as well. Ever since we've released that free offering to move out, I can count the number of customers on a single hand that have actually executed against that.

>> That's pretty good. Again, it's good to have that option.

>> Yeah. And I think the primary reason that we hear from customers where they appreciate cloud environment, specifically AWS, is reliability and scalability that they get with our infrastructure. That's what keep them grow and actually scale their infrastructure on AWS.

>> Yeah. No, that totally makes sense. And I think, really some of the other things that AWS has always done is really been about lowering prices. Even though back in the days when I was here, again, it was always a function of how you could bring things down over time as you got to scale. What other things do you see that you're helping customers, from both of you, that really lower their IT costs?

>> Well, generally, if you think about data transfer out, last year we actually introduced a significantly larger free tier for customers. A tier that essentially allows over 94% of our customers to pay $0 every month for data transfer. Really, all customers gain the benefit of that. That's something that we've been able to institute because of all the investments that we continually make in our network over the years. That has gone down pretty well with customers.

>> And that's for them, just normal and normal.

>> Normal, doesn't matter where they're sending their data on the internet. They get 100 gigabytes free every single month, and that covers 94% of our customers.

>> Maybe they're bringing data somewhere else to do some other processing on it and bringing it back and doing-

>> Or they could have web facing applications to customers serving websites. Again, smaller companies who have websites out there on the internet and they want to put them on AWS. They can also use our CDN service called CloudFront, and they get a terabyte free every month for that service, which gives them low latency across the entire globe to users.

>> I think that, to me, is one of the things that people don't understand. Is that it's looking at how applications are actually architected. They're not all in one place typically, especially if they're open to the public or on the internet, or something of that nature. A customer-facing application to an end device or something like that. Let's come back to what you mentioned briefly there around scalability and reliability. And really, how you're designing it into the actual cloud infrastructure and what that critical choice is that you're making.

>> Yeah. I personally believe that we've designed and built AWS to be the most scalable and reliable cloud computing environment. And one of the key enabler of that is our network. We also do sweat a lot of small stuff, how to have everything so there's no single point of failures. And then we actually build in reliability into our networking services as well. My team is responsible for around 20+ AWS services in networking. And the software architecture that we have, the reliability and resilience is built into that architecture.

>> Let's stay with that for a second and understand. Because, to me, a lot of times people look at cloud computing and high availability and networking, and networking sometimes seems like the hardest part for them. How are you making that easy for customers? Because you're talking five different availability zones, some of the services stretch over those availability zones, sometimes the customers are building their own HA on top of that. And obviously network plays a different... How are you helping customers?

>> Right. Reliability and availability should be at multiple layers. First is the physical infrastructure. As I talked about, our easy design, by nature, everything is fully redundant .

>> I think it's important to this point out, AWS takes it from the physical ground all the way up, unlike many others. And that means we're purchasing the land, we're building the physical concrete, all of the power infrastructure. The cooling is our own technology. And that really allows us to do unique things in the data center, the physical environment just in those buildings itself. And then as Anoop was saying, all of our availability zones, they're geographically dispersed to ensure that some local event, whether it be some kind of natural disaster, a fire, some electrical substation were to go out. All of those things are protected against and independent with availability zones. That gives this foundation that then allows our software to be built and utilize that as well.

>> Yeah. The services that we offer, a lot of networking services that we offer are software defined networking services. Things like Transit Gateway, PrivateLink, NAT gateway. These are the products that customer used to build reliable architecture on top of us. And they're all built with two basic principles. One is called availability zone independence, or AZI that we call it. And another a static stability. Let me explain what these terms mean. Every service that runs on a region, they are availability zone independent, so AZI. What that means is that these services are actually running in each AZ independent of each other. And so that if something were to happen in one AZ, the service doesn't go down. For example, Transit Gateway is a great example. It's a regional router that we offer in a region that allow customers to connect their VPCs, those VPCs back to on-premises network through Direct Connect. It's a regional construct, but it runs its component or zone O. So that if anything were to happen in one of the AZ, the service still stays up. Another very important concept that actually our services are built with is called static stability. What that means is that even if some software issue happened, the system is designed to actually continue in the face of failure as well. Statistically, what we have seen is our control plane at our scale can fail more frequently than say data plane. So we design our system around that. And all these services, Transit Gateway, NAT gateway, PrivateLink, they are built with data planes so that once the data plane is programmed, it doesn't need a control plan, it continues to operate. And that is why customer actually get that reliability and availability on which they build their own infrastructure on top of it.

>> I think a good example, by the way, just as you think about a software service, a lot of times you're going to have to make some code changes to that software service. And what we mean by things like availability zone independence, is when you go make those software changes, each one of those software stacks are independent in each availability zone. So you're never going to change the software in multiple availability zones at the same time. Which then gives guarantees the customers who want to go and deploy high available architectures that they can be in a guaranteed spot that they're not going to see that impact across multiple AZs. And that goes as well for our regions as well, like our regions which are made up of multi-availability zones are completely independent from other regions as well. And so, again, customers can live in that good mindset that they've got that separation, which happens in all of our operations, happens in all of our software deployments globally.

>> Yeah. I think that's key. When we've heard of people having incidents where maybe they didn't try it in something like a Canaries zone or something like that and didn't have availability zones, and you have a rolling outage that takes down a particular service or something like that. But you brought up a good point here, which is it's not only just about the availability zones, it is about the regions. Because I may have used two availability zones in one region, and I may use another region and a third availability zone in a second region. How do you make that easy for customers from a networking perspective as well?

>> Well, first of all, just in the underlying infrastructure we built, again, everything is ground-up, owned by AWS. There is a private network that connects all of our locations within a region. And then connects all of those regions with all of the other regions around the globe. That is a private backbone that is owned and operated by AWS. From the fiber in the ground to the equipment that we run on top of that fiber, we're running our own network stack from top to bottom. Which really gives us control around things like cost availability, and so we can build a huge amount of durability into the end-to-end system. And then we make that connectivity super easy, especially with a whole bunch of network services that... Anoop?

>> Yeah. We often see our customers deploy their workloads across multiple availability zone or across multiple region. And we do have multiple products that customers use to actually connect these workloads. In a region, they might have thousands of VPCs, they use Transit Gateway for that. As I was talking about Fortis as one of the customers, where they run in 50 countries, so they are across multiple regions. They use things like AWS Cloud, where they can actually connect all these footprints with one single global network running on top of AWS backbone. If you want to access a SaaS service or AWS service and you don't want to go over internet, we have products like PrivateLink that offers you to have connectivity over our own private network. There are a lot of such products. As I mentioned, there are around 20+ products in our EC2 networking portfolio that customer find it useful to build a custom architecture of their own.

>> And you even have those PrivateLinks also work with some of the partners who are out there-

>> Absolutely....

>> community as well.

>> Yeah. We have over 200 PrivateLink support, over 200 AWS services. And many, many ISV partners who actually offer their services through PrivateLink.

>> Yeah. No, I think that is one of the really interesting things, because I think that opens up the ecosystem. And I think probably why you're not seeing a lot of DTO, and counting it on one hand kind of thing. But let's circle back to one of the big elephants that's been talked about, and probably thrown at you all the time. But the elephant in the room about egress charges, and how expensive egress is from an AWS perspective.

>> Yep. First of all, we don't talk about it as egress charges. We specifically call it data transfer out, for a good reason. When you say egress charges, a lot of people have the misconception that is, hey, we've only just got costs at the edge of our network where we're handing off to some other network or provider. But the reality is, that's not the majority of our cost. Our cost is built up from the time that a packet wants to go and leave an AWS availability zone, and it gets carried all over a global infrastructure to the right endpoint to go and burn it off too. And there's many ways you can build a network. You can build a network that is cheap, without a lot of reliability, doesn't have a lot of availability, doesn't have performance, doesn't scale very well. Or you can take a different tact. Which is, we understand that our customer's data is super important and needs to be protected at all times. And so we have built a global network that has huge amounts of availability in it, built into withstand multiple, overlapping, completely diverse failures. We take all of those failure models and we ensure that we can carry the peak traffic load at all times. We have automated forecasting systems that essentially tell us where we need to go and ensure that we're aggressive in terms of putting the capacity into the ground so customers can enjoy that elasticity as well. And all of that network is 100% secure. It's all encrypted with max encryption. Every single building that you leave that is an AWS building will basically have that kind of encryption on it, because you're leaving our physical security controls. And then we optimize the performance on that network as well. And we have some of the most sensitive customers out there, and they continue to push us to continue to improve that performance over time. Again, all of that takes investments. As I said, we own the hardware, we own the fiber, we own the operating system. There's a lot of investments that go in there, so there is some real substantial cost. But for that cost, you get an amazing service at the end of the day as well.

>> I think that, to me, is a great place to leave it. I think you guys really have gotten at some stuff that I think people are really interested in digging into. Because, again, it's not common to be talking about the elephants in the room and things like that. I appreciate you coming onboard and talking through that.

>> Cool. Yeah, I love to talk about this stuff. Thank you.

>> Well, I'm sure we will. I'm sure with re:Invent right around the corner, I'm sure we'll get to talk more. Yep. Thanks again.

>> Thank you.

>> Thank you.

>> And thank you for watching this episode of theCUBE, live from the AWS Studios here in Seattle. Stay tuned, we have more coming for you. We'll be right back.