AWS re:Invent 2017: Case Study: The internals of Amazon.com's architecture that allo (CTD305)

good afternoon welcome thanks for taking time out of your very busy family schedule at this time of year and no doubt your business schedules as well and to join us here at reinvent I really appreciate it so who wants to know how Amazon uses AWS that's next door how does the Amazon think about using the cloud today what did we think about the cloud when we started what did we learn and what can you learn from what we've done and the mistakes that we've made today I hope to clear up some myths about how Amazon is architected share about what we actually architect and while Amazon uses nearly every AWS product in some way today and we're almost a hundred percent in ec2 our journey in the cloud has really only just begun and so I'm going to share today some of the details of some of the AWS products that we use to serve our website today and most importantly things that you can take away from that to use in your business immediately after the presentation are you an enterprise customer in the room looking for information on how to migrate are you a partner looking for opportunities to actually help those enterprises move hopefully you'll be able to use some of the things that I talked about today to take back to your business and use right away hello my name is Gavin I lead an organization in our consumer division at Amazon that's responsible for transitioning the consumer businesses technology into AWS let's think for a moment about the priorities for an ism I'm hoping that our priorities match your priorities because our customers in many ways are likely to be your customers also and as I was putting this slide together and a couple days ago I was reminded about a Jeff Bezos quote that I heard a long time ago in the future no customer will ever expect or want a higher price in the future no customer will ever say I want this website to take longer in the future no customer will ever say I want this website to be unavailable unless of course there's a breach in which case I'd rather the site be down than disclosing my personal data and I'm sure you'd prefer the same to these statements define our priorities for architecture at Amazon and when it comes to our move to the cloud and to AWS it's exactly the same when we consider what AWS provides us and you we believe that it helps in each and every one of these areas now I've been at Amazon more years than I care to remember I've been in Amazon 11 years now and so I know many of the leaders in AWS personally who build the products on which we depend and I can tell you now that these priorities are their priorities as well so how much does Amazon need to migrate now I'm not showing you these numbers to boast about how big Amazon is Amazon's huge by some sources in the internet we have a lot of traffic every day to our website this number here is a some public source that the measures traffic across the Internet and this is just for Amazon and so reportedly we have 40 billion requests to our website every day directionally correct at least we run a business in 13 different countries I consumer business we have customers from every country in the world that buy books and apparently there's some other stuff on the website these days we ship the brown boxes to you that arrive at your doorstep all around the world there are hundreds of thousands of remote web services that sit behind the Amazon websites and to to illustrate the size is really only to demonstrate that if Amazon can move to AWS technologies without interruption to its service then this should be easy for all of those of you in the room which I'm guessing is many of you that don't have websites or applications that are nearly as complex there should be chicken feed for you if Amazon can do it so despite some myths that you may have heard Amazon has not always been on AWS Amazon to 20 year old business the cloud not nearly as old we started out where I'm guessing some of you in the room are today on-premise fleets databases frameworks and it's been a long journey to migrate from all of those things for us I was actually around in 2008 when Amazon very first moved its first application onto ec2 which happened to be the amazon.com website and we're still taking that journey today we've moved from owning the networking the routers the racks air-conditioning worrying about third-party vendor software legacy in-house technologies it's been a journey to move from the problems that we know and it'll be a journey for you to move from the problems that you know to these new challenges and new opportunities that we all face in AWS today with somewhere in the middle of this diagram we still have a very small number of things in our on Prem systems we still have a lot of proprietary legacy technology and we have a bunch of stuff that's in the cloud some of it lifted and shifted into ec2 some of it purely native using lambdas and containers SQS simple email service all of those things so it I'm curious show of hands in the room to understand a little bit more about where you are in your cloud journey how many of you purely on Prem couple ok how many of you somewhere in the middle in some hybrid most of you ok anyone lucky enough to be born native in the cloud ok good it sounds great to be born native in the cloud but as you've heard during the course of reinvent today at the last couple days AWS is innovating at a massive clip and just because you're all in on the cloud doesn't mean that you can sit back and call it job done for Amazon it's also true in some respects our journey in the cloud is still at day one and that's a really exciting place to be I'm excited about what we've seen at Amazon and the opportunities that moving to the cloud gives us being here at reinvent and experiencing how all of you are embracing the cloud and what opportunities you've been able to unlock gives me even more confidence that this is the right journey for Amazon and for everybody else so I'm gonna filter for a moment the journey that Amazon is on I'm gonna ignore some of the spaghetti of the hundreds of thousands of remote services and tens of thousands of applications on our website I'm gonna focus on a few key stories that highlight our migration that highlight our er Kotecha that highlight some of our elimination of undifferentiated technology at the same time following our guiding principles in some ways Amazon is just a novel application that sits on top of AWS primitives today we're really going to focus on those pieces of a migration that are most important to our customers things that we've learned that should apply to everyone here at things like adopting CloudFront reduced latency for most of our customers enabling route 53 enabled our business to migrate to the cloud seamlessly without any downtime and gave us lots of options to roll back using cloud front simplified the management of our secure connections to customers really enabling us to make our whole website secure by default and to do it incrementally using lambda at the edge reduces our costs by letting us move business logic out of our back-end technology and reducing the amount of traffic that our existing website stacks have to service using the website Application Firewall the woth inside of CloudFront wasn't hard to use and it also saves us a huge amount of capacity needed in the backend because we're able to stop unwanted traffic actually ever reaching our applications and everyone could take advantage of the denial of service capability that's provided in shield staffed by the very same people that Amazon uses to protect its website hopefully today you'll see the amazon.com x' architectural design and how we use AWS is something that you should absolutely consider using yourself let's take a look a little bit more of the details as with all projects at Amazon we start from the customer and work backwards you may have heard of our working backwards program or process pretty much everything we do and certainly every one of my whiteboard presentations or PowerPoint slides typically starts with the customer and works backwards so our customer devices start by talking to route 53 how do I get to Amazon well route 53 uses a bunch of weighted rules so that it then tells customers which have a multiple CDNs we actually want to send them through and yes Amazon doesn't just use CloudFront we actually have a multi vendor strategy for our CDN things and some of them are actually in the room watching us today to hold me accountable for making sure that I include them and our CD ends the route 53 can also send traffic directly to our origin but the CD ends are configured to then sand traffic customer traffic through to our origins our origins live on ec2 inside a V PC but really they're just a reverse proxy just might be a little bit of a understatement but our reverse proxy allows us to do advanced traffic routing and request manipulation before and after our web server fleets take over our web server fleets typically these days live in a situ in their own VPC in the original days when we moved our website from our home pram they had a lot of we had a lot of stuff than not in the cloud but now as we're in the cloud we're able to route different traffic to different parts of cloud technologist so applications that live in containers we can route individually and separately from applications that live on ec2 instances or in lambdas the important part here will this architecture allowed us to do migrations incrementally so we were able to leave our gateway pages in our own Prem data centers while moving our product detail pages into the cloud why would you want to do this well for us at least it was about an incremental migration Amazon is tens of thousands of applications owned by thousands of different development teams and we wanted to be able to move each one incrementally and independently from each other we're also a very data-driven company and we innovate incrementally as much as we innovate in a revolutionary way and so we were able to evaluate each and every one of our migration steps and ensure that each one of them improve the customer experience each time tools like at our origin proxy allowed us to do that very well but with the launch of the application load bouncer you can do the same thing using routes in in alb now let me dive into the architecture and I'll show you some of how each part works we'll start with around 53 to make sure that our customers can get to the right place now route 53 is really just self-service DNS management service with a bunch of control plane api's it's got a weighted routing policy that allows the Amazon to direct traffic to different places talked a bit about that before you should think about doing this if you're in the process of migrating to the cloud for some or all of your workloads think about having the ability to dial up and dial down your traffic with weighted cnames to your new applications what if your new version of your new website doesn't work the way you want wouldn't it be nice to be able to roll it back in just a single minute amazon's learned that the best way for us to do that and the fastest and safest way for us to do that is to actually use the route 53 configuration api's let's look at what dub-dub-dub done amazon.com really is any of you with a laptop open right now you can go do an nslookup and you'll get something that looks very similar to this hosted by route 53 dub-dub-dub done amazon.com it's actually just a seening canonical name points to dub dub dub CD n dot amazon.com and then see the end on amazon.com in this particular example is just a weighted C name for our CloudFront distribution but this might also list some other CDN vendor or it may list our origin it depends on the weighting the route 53 does for any given request so if you do this enough times now in the room you'll probably see a good mix of all three of those and finally behind our CloudFront distribution there's an IP address that gets given back to the client and that's where the device actually ends up going that's where cloud front starts processing the traffic and then decides whether or not to send it on to our origin it's easier to see in a picture so user types in the website address around 53 does it's magic and decides which of our origins or CD ends to send that traffic home team if you want to try this you can set it up in around 53 just by creating a record set in your origin then you set weights on each cname create a weighted routing policy to the origin and see the end that way you can just mix and match as and when you see fit why is that important well many times you want to do your own application experiments sometimes the CDN vendors or your origin may be doing some maintenance and they want you to switch off for a while being able to switch really quickly and really easily super important at least to us this is how Amazon switched from serving all of its traffic from its origin to using multiple CDN providers and allowed us to do a major migration with really really tight control and no code changes now this is great because now you can actually measure the impact of your migration on your customers as you dial up each of these changes so what does this really look like well here's a screenshot of our AWS console for CDN or amazon.com first you can see that there's a seeming second we just set some common TTLs time to lives so that when we make changes to our records there's some predictable behavior across the internet as different providers update their DNS records third we just put in our platform distribution in this case or any one of our other CDN endpoints or our origin then we just select a weighted routing policy and then we enter the weights that we want in our case we've got multiple entries here and we like to think of these weightings as a percentage so 95 here for us represents 95 percent of our traffic is gonna get routed through our plow front distribution in this example now don't worry if you're one of those 5% of customers who's trying to visit our website right now you're not gonna get black hold you're just gonna get sent through to one of the other CDN providers now I'm a builder at heart and I know this sort of functionality and flexibility could be built in other ways I could've architected a whole bunch of different stuff to do myself but honestly it's not differentiated for me I'd rather have someone I'd rather be able to do something else to help customers get to Amazon faster so let's go improve latency wouldn't you like to improve latency for every one of your users without changing a line of code no one really okay maybe I can finish early and we're all good here's how Amazon was able to do this without changing a line of code maybe no surprise but for Amazon the latency experienced and observed by our customers can be the difference between a conversion and an abandoned it's extremely important to us that our customers experience the absolute fastest possible website CloudFront distributed pop locations and indeed other CDN vendors reduces specifically the time it takes to connect a TCP connection directly to a client it reduces the physical round-trip time the physical distance that the connection has to travel from a customer's device and between our servers behind CloudFront we then use routing rules and so we can measure the impact of changing those data centers availability zones whatever we want to do behind them importantly CloudFront reuses the connection between its servers and house so it doesn't have to re-establish them for every connection that the customer makes they terminate TLS or SSL for us at the edge super super important given the multiple handshakes that TLS has it's critical that that doesn't have to traverse very large distances and lastly cloud front supports HTTP two at the very place where it matters most to our customers sure there's some other optimizations that are really interesting that HTTP 2 can give us but the connection pooling and the connection reuse is super super interesting and it really is easy to implement at the front end and it gives the most benefit to customer connection speeds reduces latency and in many cases saves battery life especially on mobile devices now each one of these advantages that I just talked about for cloud front or indeed any other CDN vendor could have been resolved elsewhere in other code and believe me I've watched over the years Amazon spend huge amounts of engineering time trying to make our applications faster but in this particular case making these improvements really for us is undifferentiated work it's work that our customers don't love Amazon for its customers it's work that customers expect to have already been done customers would prefer us and we'd prefer to be building them new echo devices lowering prices shipping more books inboxes we'd much rather not have to do thousands and thousands of HTTP - migrations that's why Amazon is really all-in on a lot of these cloud technologies let's look at some data but we're looking at him it's the average latency of Amazon's website as seen by customers every page on Amazon is instrumented we don't rely on third-party metrics or analytics we actually have our website instrumented for every single page request that you as a customer will make the green line here represents the average latency across our website of traffic that flows directly to our origin the blue line represents traffic that goes through CloudFront and it's a very similar line that we see when we use other CDN vendors also what you can see here clearly is exactly what our customers see not only did we see a substantial drop in latency by adopting CloudFront but we saw a much more consistent experience across every geographic region that we deployed this for all of the websites that we own bought it and Amazon's got thousands of different websites that it uses it's not just the Amazon retail branded websites that have adopted this but some of our more complicated web sites that we have for sellers and then does actually saw even more impressive latency winds as a result the average latency when four websites in North America was somewhere in the region of 200 milliseconds how often do you get a site wide improvement on latency of 200 milliseconds without writing a line of code not very often I would bet the biggest latency wins that we observed were actually in areas of the world where there's significant mobile penetration but terrible network performance countries like India for example these particular deployments of plow front and http2 had way bigger impacts to our customer experience in those regions SSL termination connection reuse substantial components of the improvements that we saw hit but now that we can see that the performance of our website is much more predictable for our customers importantly we're now able to see the improvements that we make or the effect of the improvements that we make through actual code changes that we make in our application before we couldn't always be sure whether we were improving latency because there was just too much noise on the internet for us to see the improvements so how do we do that let's look at our cloud front configuration for a moment after creating our CloudFront distribution in the AWS console again of course which I didn't put here because it's just as simple as creating a new distribution and posting pasting the C name of your origin we can then go start configuring it and as we showed before different paths on Amazon get routed with different behaviour in some cases we were out traffic for different URLs - completely different origins on the internet for example here we send all of our /dp star traffic that's all of the requests that go to our product pages we call them detail pages all of those get sent to a particular place a different origin different from the rest of the site and we force it to be HTTP so even if a customer comes to us over a non-secure connection we use CloudFront to insist that a renegotiates that as a secure connection as we migrate it to HTTPS out of interest it was really important to us to be able to set those forced connections to different parts of our web sites on a different cadence like I said before we have different teams that are building the product pages different teams that are building a gateway page and it was really important that we were able to decouple them and it turns out that that was a really critical move for us because some of these applications didn't play well with a secure only connection if we'd have had to have moved all in one go the whole site all at once we would have had an intractable problem coordinating across tens of thousands of developers thousands of different products thousands of different applications and this routing configuration and this forced connection on those different paths allowed us to do that incrementally and now the website's completely secure it took us probably somewhere in the region of nine months to do that but incrementally our customers were getting a better experience as we move through that project we could have achieved that in a different way but again that's undifferentiated work and I'd much rather be doing something different for example making my websites more available and making them more secure for our customers so now I'd like to share a few things about what the Amazon consumer business has learned over the last few years with respect to security and defense how many of you don't worry about whether or not your website's up and getting overwhelmed with traffic from the internet good Amazon takes pride in our reputation as one of the most trusted brands in the global e-commerce industry part of that trust comes from having a website that up and having a website that's fast we think about denial of service more about availability than we do about security it's a bit of both but for us mostly it's about availability robotic traffic and DDoS attackers can hurt both of availability and speed if you let them and we all need defensive solutions to make sure that we can protect ourselves against them our philosophy around this is simple we will always prioritize humans over robots when we're in a situation of limited resources we're in the cloud I hear you all scream but the cloud is infinite sure the cloud is infinite when your Amazon is a little less infinite than for other companies but for us actually that the problem is even if the cloud was infinite we would have to pay for the resources that we use to protect that website against all of these people things that want visitors and so we take specific decisions about how much we're willing to spend to serve the traffic that comes in and sometimes that means that we have to prioritize and we will always prioritize for a human to be able to come to our website and shop and have a great experience don't we well for a robot but it's a business decision at that point it's not a technology decision so over the years we've learned how to defend our websites and our applications from attacks like DDoS is like you've probably all heard of Mariah and WordPress pingbacks and other things like that we have a layered approach and as proud of it as we are it's really expensive to operate so if you're a professional looking to defend your site from unwanted traffic which apparently is all of you you should know that we found AWS to be a super cost-effective solution to scale our defenses and then we want to protect our customer data and so like this is not an option for us not doing this is absolutely not an option and it shouldn't be not an option for you either so I'll use an example to make my point clear here as it may not surprise you to hear Amazon doesn't use WordPress on its website kind of imagine building anyway hmm as many of you know WordPress is popular and it has this really cool feature in it if you want to figure out how to improve your SEO or get some better visibility it's got this cool feature that's called ping back but we don't need ping banks on our website we don't really care about them we have our own telemetry for dealing with SEO we have different tools the instrument our insight into our customers but ping banks can be used by nefarious actors to ddos legitimate websites in a ping back attack the attacker will send bogus traffic to a legitimate WordPress website and those sites do exactly what they're configured to do they send notification ping banks to the target which they think is the person that made the request in the first place and they sell that target that'll new links been posted to the site and you should go do something with it but remember Amazon doesn't want these so every request that we get from a ping back is a request that we don't want that we don't want to have to pay to service so let's go back to our architecture and figure out what would be the best place for us to stop those requests from coming into our origin and into our service to do this we simply inject a filtering rule into the website Application Firewall the laughs prior to the traffic being sent to our origin we do this filtration in CloudFront unsurprisingly so let's go have a look at the rule most legitimate WordPress websites won't have altered the request signature that you can see here this is a cut and paste from the request header of a wordpress pingback in that you can clearly identify the ping bank by the WordPress user agent and the word ping Bank so our laugh filter is very simple and the rule that we've created here is cut and pasted from our a filter for WordPress pingback attacks and we simply have a matching criteria that uses just a simple string comparison looking for the user agent beginning with WordPress and the user agent containing the word ping back and if those two things are true we simply drop the traffic we monitor what's getting filtered out by looking at our cloud watch metrics sounding like your salesman here now sorry about that so let's take a look at our metric why is this important to us here's a graph of October 15th 2017 not that long ago this is requests to amazon.com not all of the requests clearly we don't get no requests for most of the time but at that particular time on October 15th we had roughly sixty two thousand requests that were blocked in one hour actually as we dug into this after the fact we realized that those 62,000 requests happened over the course of only two minutes they went from nothing to 62,000 to nothing thank quickly now most spiky attacks like that will completely overwhelm most smaller websites and in fact 62,000 requests even at Amazon scale still a sizable chunk of traffic I'd certainly much rather not have to have a bunch of servers stuck around doing nothing but waiting for the possibility that this is going to happen so as I said before Amazon's defenses have layered and we've discovered that this is really the cheapest option to reject the traffic for us so what do you do if your site is under attack let's assume that you didn't have this rule configured for your website although by all means go copy this today and go add this to your cloud front configuration or your wife configuration and go protect your website from unnecessary pingbacks today but if you don't have that today and you're getting something weird that's going on who can help you figure out what that is I would assert that you would benefit from using the exact same people that we do Amazon's learned that there is simply no substitute for experts in secure the end DDoS defense and even though my team has built an amazing array of denial of service protections it's not our core competency and so from time to time we need some help and when we need help we pick up the phone to the AWS shield guys and they get on the line and they help us out and the exact same people that work for all of you and they can do the same thing for all of you but what if you don't actually want to reject the traffic what if it's legitimate what if it's a robot that actually needs to get a response before he goes away there are plenty of those well it would still be nice if you didn't have to serve that traffic with the full experience of your website it'd still be nice not to have to provision a bunch of ec2 instances to be sat there ready to do stuff we've learned that lambda at the edge which is built into our CD ends and distributed to our points of presence can be used to respond to traffic directly for Amazon we use lambda at the edge to politely respond to certain traffic that we don't want to see at our origin contrast that with the previous example where we chose to just drop all of our website WordPress traffic with lambda at the edge we can actually respond much more intelligently and much more cheaply than going to our back-end web servers here's a lambda script that we created again this is cut and pasted from our AWS console it's no js' really really simple what we do here is we take a look at the request header we match some contents of the request header to a database of blacklisted referrer URLs that I'm not gonna tell you what they are today you can go figure out which ones you don't want to come visit your website and then after we've done that we craft a response we set a response error we set a response body and we're done how do you do this for your website well if you were fast enough and I saw many of you doing this you copied the code that I just put up there that's fine you can use it I'd much rather us be a safer place collectively across the internet than not to be open and share this but you can go to your AWS console paste that code into a new lambda copy the a RN for that version and then go to your cloud phone configuration and in your cloud front configuration you can now go on a new event type just paste that AR n for your lambda function and you're golden we use an event type of your request so each time someone or something goes and visits our website and hits that CloudFront distribution that lambda will fire and we'll evaluate the response header the request header and we'll determine if we need to send the polite response back to them before letting them go away one of the things however that I should caution you on is we learn very quickly there are some scaling limits to using things like lambda at the edge and not every website will fit within those scaling limits the important thing to know though is for the most part those limits can be changed and most importantly raised so if you're thinking about serving all of your website through a lambda edge go work with your AWS account manager go work with your AWS support contacts and make sure that the limits that you have are actually appropriate for what you're using it's very easy with the default limits to overwhelm the thresholds that you've got set and have your customer traffic throttled well that's all well and good for availability but what about protecting customer data should your denial of service actually result in the compromised security breaches aren't just about the impact to your company in many cases there's bigger collateral damage - perhaps entire industries just think of some of the recent incidents in the press for example so how can you improve your resilience to a data compromised another of the security and defense features you'll find in CloudFront has its roots in solving a problem for the amazon consumer business any of you familiar with PCI audits they saw something and they saw a good reason like we don't want our customers data and our customers critical payment instruments to be compromised and as engineers and as builders we also don't want to spend thousands and thousands of hours talking with regulatory auditors going through each line of code to prove that we don't allow that data to be compromised at Amazon that gets pretty tricky I like to joke that Amazon really is just a Federation of startup companies we have some governing principles and checks and balances like all good corporations do but what it means is we have lots of pieces of software built by many different types of teams that are all only loosely and joined with each other and as you can imagine the complexity and the volume of the software that was subjected to audit back in the day was starting to get lengthy and cumbersome so we decided why not just encrypt all of our sensitive data all about customers sensitive data more importantly we started off with credit cards we then moved out to bank accounts and social security numbers and and now we do this for lots and lots of that customer data and we did that at our origin proxy so there are application servers wouldn't actually have to ever see a credit card reduces the number of pieces of software that ever need to see it and importantly it reduces the number of people that build that software that can ever see that - Sam Frank decided it's a great feature we should add that we called it cocoon we like to think about wrapping this data wrap into a little cocoon so that nobody else could see it CloudFront call it field level encryption and we use it an important part of our website those of you that are Amazon customers I'm not gonna ask you isn't it like an embarrassing you might recognize this page secure little furry example of my dog my dog's called Josie this one's called Jessen Amazon created a checkout page experience called a single page checkout it's really simple for customers to use it builds on our years of experience of having lots and lots of steps in our checkout pipeline but the single page checkout puts all of those steps just onto a single screen payment instruments shipping product review delivery dates shipping speed all sorts it's really simple we've done lots of experiments and we know from our data that customers love it but on this page there's lots and lots of code running all of that code is served from all sorts of different services this page alone probably calls about 20 or 30 different remote services notwithstanding the code that actually is in each of these widgets at Amazon usually each of those services has its own team and so probably somewhere in the order of 60 people are involved in orchestrating this page together when you add in networking monitoring hosting testing all of those teams that actually go to getting this code into production there's probably about 250 people that were involved and creating this page anyone feel comfortable giving their credit card today to 250 strangers no no me neither in our case only the credit card entry widget actually needs that number and so why should we make it available to all of those different teams so if you use simple public key encryption and you put the private key into your credit card storage system so that it's the only thing that can ever unencrypted the data that's the system that's going to send the customer credit card to the bank turns out that you actually have to unencrypt that in order to send it to the bank with the bank's key and you give CloudFront a public key and you tell it which request parameters to watch for typically that's a encrypt this field then all of those widgets and all of those other people even though their codes running on the same web server can never actually see anything other than the token those other pieces of code can't do anything with that token other than pass the token on so we now have effectively eliminated the risk of any bug showing anyone on the website a full credit card or passing it anywhere around the company it reduces the amount of software substantially that we have to worry about auditing and more importantly it reduces substantially the number of people that have access to credit card numbers for us this is the best way of enabling our front-end engineers to innovate on amazing customer experiences without ever having to worry about regulatory compliance this data protection for Amazon something that we take extremely seriously and I'm sure you do too and I'm very happy that I was able to be a part of the team that helped CloudFront actually add this feature to their product but while we're on the subject of credit cards and spending money some of you may know that our leadership principles include the concept of frugality sometimes you see at events like this it's hard to imagine that Amazon is is frugal with things actually it's really important to us that we're able to spend money on the right things so that we can keep our prices to customers low and with the tools that AWS gives us they're great for managing single applications they're great for managing a small number of simple things but when you run up the scale of Amazon it turns out you have many many thousands of things that you have to worry about and we have a lot of complexity in how we manage that fortunately AWS provides us with a great SDK the less us build tools that make sense for us we have a lot of configuration Amazon's got thousands of websites 13 different countries a hundred thousand services each of those sites typically has some difference in their configuration but for the most of it it's really important that we keep things consistent the way we improve our availability posture typically is by making sure that things are consistent we find good practices and we want to make sure that everyone observes those good practices so how do we do it well earlier I mentioned I was really excited about route 53 having or being a DNS server but with configuration api's his why I was excited it enabled us to build software tools to apply our changes and prevent mistakes and maintain consistency really really easily as just a single enterprise customer I am forced to realize that we have a bunch of different ways that we manage our company that are different from how AWS manage their business that are different from how you manage your businesses it's really important that we're able to build our own tool on top of that ultimately corporate governance whether it's illegal or compliance thing or whether it's just about operating under your own best practices it's a personal choice it's a business choice about how you choose to do that and it's not a product that you can just simply buy from AWS because it's personalized to you and so it's a shared responsibility and AWS SDK enables you to put that together Netflix for example are really well known for building their own compliance and governance tools on top of AWS and many of the tools that they've built for themselves and now available open source for all of you to use one of the tools that we built that's related to cloud from is a simple command line script that enables us to very quickly switch CDN weights super-important that we're able to do this in the event of an outage we can automate this so we can respond to an alarm and fire this off but this particular example is simply setting our CDM weights to a different distribution than they were before let's have a look at the code for that if your cameras have good enough resolution you can probably actually see that but this is all of the code that actually runs that CLI first we simply include the AWS SDK in our code second we build an object that contains all of the changes that we want to make third here's where we do our corporate governance thing we have a best practice where we want to ensure that the weights are split evenly in percentages and so we just make sure that what the operator typed into the CLI actually matches our best practice so we just check in here for adding up to 100% and then finally we actually commit that code to the AWS API and it responds back to us with the results of the changes that it paid now naturally in order to run this program the user needs the right credentials and the right passwords so you can't go run this on amazon.com today and change our CDN weights thankfully but you can certainly use this to change your own configuration for your own CDN and all build tools that are very very similar to this to control how you use other AWS resources today for us this is a very differentiated piece of technology and this is something that I'm happy for us to do and I'm happy that I don't have to give this to AWS because I want to manage the Amazon business or I want to enable the Amazon business to manage itself in the way it sees fit not the way somebody else chooses to tell us that it should be fit so that was just a whistle-stop tour through some of our stories of using AWS today and some of the things that we learned in our journey to AWS and hopefully some things that you learned from us that you can take back to your business tomorrow you can get lean see improvements by using CloudFront and other CDN providers you can reduce the cost of your DDoS insurance policy by using waffe and the large number of cloud front pops to reject unwanted traffic you can enforce best practices reduce operator error improve your availability you can improve your security by encrypting data and you can call the same experts that we do when you need help when your site's down and you can use things like compute at the edge to respond to request traffic in different ways I'm sorry that I can't talk about that all of the different things that Amazon does with AWS but hopefully today you learned something that's useful and I'm very happy to take any questions that anybody has [Applause]

Channel: Amazon Web Services

Views: 4,144

Keywords: AWS re:Invent 2017, Amazon, Jewell, Content Delivery, CTD305, AI, CloudFront, Lex, Route 53, AWS Shield, AWS WAF, Security

Id: dFVFLTYFgaA

Length: 53min 33sec (3213 seconds)

Published: Fri Dec 01 2017