AWS Office Hours: Amazon CloudFront - AWS Online Tech Talks

all right thank you very much we're very excited to have office hours with you today and again my name is Woodrow Arrington I'm a senior product manager on Amazon CloudFront been with the team for a number of years I'm also joined by a colleague of mine on the Amazon CloudFront team as well David Brown also a senior product manager on the cloud front team now today is office hours it's going to cover a number of topics not only on cloud front but one of our services called lambda edge now with cloud firm we're going to talk about the benefits that you can derive from using a content delivery network within your AWS architecture and we're also going to talk about use cases from which it can be deployed talk about the infrastructure and how is CloudFront built and what benefits does that type of infrastructure deliver when you're trying to deliver content to your viewers around the world now we'll also talk about how do you configure cloud front in a number of different options whether you might have static content or dynamic content video delivery or large file downloads whatever your use case might be there is a way that CloudFront can be incorporated into architecture and again delivering accelerated performance for your viewers and the experience that you are delivering with your application lastly we'll talk about the best practices that you can have again tailored to these different use cases and really when it comes down to the core of it all we want to make sure that your applications are secure as possible so with a little bit more additional deep dive into the security controls that you can configure within cloud front and really protect not only your content but also protect your origin infrastructure as well lastly we also talked about pricing and how to get started with CloudFront and transition into lambda edge and dive deeper into the use cases of which you can program your CDN delivery experience again to a greater control from which is explicitly tailored to your your use case so let's go ahead and get started so first and foremost cloud front can accelerate and deliver content for a wide range of applications it really can start with the whole site delivery whether you are supporting just get requests and you're delivering content to your viewers but we support all the other different HD HTTP verbs such as put and post requests as well where you're reading information into your origin now one really interesting thing if you're talking about the whole site delivery is that this really can marriage up a lot of different unique user experiences for example one recent thing that came across recently was seeing how Activision Blizzard uses cloud front to deliver a highly interactive and dynamic off-screen experience for some other Call of Duty gaming second hand or a second screen experiences using alexa and pali we also talked about api acceleration and how you can put cloud 4 into a proxy mode in which all information is just forwarded over optimized network path back to your origin and again we have user cases such as slack that has leverage cloud front for greater in line DDoS security protection on their api calls back to their service and we'll talk about that use case at the end as well now CloudFront can be used to deliver custom logic that's executed closer to your viewers and independently from your origin logic that you might be executing back on your your origin application server itself so with lambda edge you have a lot of tools available to you to trigger when that logic is executed and also make dynamic calls back to other sources on the internet to again customize and personalize that content request then static object delivery one of the core components for why a CDN was first made is to deliver static imagery CSS files or any other aspect of your webpage where it's highly cashable content and can be shared amongst multiple users now cloud fronting is also great when it comes to serving video content as well whether it's video on-demand or live video streaming and a perfect example of this is Amazon Prime video itself using cloud for both video on-demand content as well as live streaming events such as Thursday Night Football and then lastly we'll talk about just the large file downloads that you can configure as well whether these might be software updates or if you're doing patches or other type of game downloads in CloudFront is great when it comes to high high volume throughput to make sure that those downloads happen quickly and error-free so as you can see there is a whole host of different purposes for which CloudFront can be used and all of them can be used with the same rates and the same infrastructure of what we'll dive into a little bit deeper so first and foremost the Amazon CloudFront network is built on currently over a hundred and ninety one edge locations around the world and what's really cool about this network is that it is a living and breathing network and that it is always growing and every month we're launching new edge locations I know when I started with Amazon CloudFront we had just gotten to the point where we broke over a hundred applications and that was pretty excited and now we're getting close here to 200 and we've got some really exciting announcements coming along with that 200 pop launch announcement coming here soon so if we're looking at even what we've delivered today year-to-date we've launched over 73 edge locations and what this provides is just massive scalability and global reach so that wherever your users might be we can deliver that excellent performance and outstanding reliability as well so some recent additions to our network include Israel Bahrain Portugal and a fourth batch location in China which is a new network that we launched earlier this year now each one of these launches has delivered huge performance improvements for first byte latency and also throughput for example I've seen first byte latency reports coming back from Israel and Bahrain in terms of you know a 60 to 70 percent first by latency improvements which have been fantastic now sometimes one thing that might be overlooked in terms of applications and asus data security is the infrastructure from which it runs on and one of the things being a part of the Amazon or AWS network is that cloud front builds all of its edge locations to the same high standards that AWS has for its own regions and so with that robust security and that uniformity we meet or exceed requirements for a wide range of compliance regulations or standards such as PCI DSS HIPPA sock levels one two and three GDP our regulations and ISO regulations as well so what that means is that if those regulations are applicable to your industry or your use case you can have a peace of mind that CloudFront has already met those and so that your architecture is as a whole can be compliant and end now with this large network we also provide great protection against network and transport layer attacks as well and that really comes from the ability to disperse that traffic across each of our H locations and to shift it away to available capacity so that we can always continue to serve your legitimate traffic and protect your origin infrastructure and a lot of that comes from the inline DDoS protection we have with Amazon AWS shield and aw swath and we all will talk about some of those integrations that we have a little bit later in the presentation so some of the core benefits of a CDN again come from that network that's built and each of those edge locations built come with multiple links for transit and peering connections and so what that means is that we have mass amounts of connectivity now in addition to that we also have what's called the AWS private backbone network and each of our cloud fort locations are connected to that private private backbone network which allows us to have a optimized network path back to your origin wherever it might be and with most customers they already use AWS origins whether that might be easy - or s3 we have those paths all the way back to the oedipus regions again for lower latency and higher throughput now CloudFront automatically routes your viewers as they come to your website corporate will redirect them or route them to the location that is best for their experience and we do that with a number of different diffused web measurements and web agents to continue to measure the internet whether it may sure that again they're getting the best experience that you would expect for your own application and as I mentioned the DDoS protection is built in line and has scalability to make sure that your applications will always be available now if we look at cloud front and what it's built on there's a few foundational building blocks that we're going to review here about what cloud front is and first and foremost we talked about a distribution and this is really kind of a unique nomenclature to cloud Front itself the idea is that it's an area or a resource that configures information such as where's your origin and what kind of cache behaviors do you want to apply to your I advanced to slide too early it will leverage cache behaviors so that again you can customize your content delivery to tailor it to whether it's a dynamic content and where do you want to send that and how do you want to proxy that back to your origin or static content there might be different types of images that rotate a little bit faster than others and so again you can use cache behaviors to modify the behavior for how CloudFront will operate now let's jump into some of these best practices so first and foremost there's a lot of different methodologies for how you can use a content delivery network so this is just one idea one idea is that you want to cache as much as possible on your content delivery network and the idea here is that the more that your CDN can be put to work the less your origin has to do and so what you're doing here is you're maximizing your origin offload and so if we're looking at a typical web site again there's so many different elements that live on a single web page and each different piece of content really should be handled differently so whether it's private long live content such as a viewer name like in the bottom left that might only be relevant to a single viewer but it's not going to change other content such as private dynamic content like a shopping cart could represent something that's dynamically changing as you add things or remove things but again is unique to that one user or if you have shared static content such as images of one item but that gets requested by multiple viewers and it may or may not change and then you might have shared mutable content like the HTML of a website that might be requested by many viewers and actually by me might be updated periodically so ideally with whatever one of these type of contents that you have available on your web page again you want to handle them differently and create different cache policies now the other thing to consider here is it's not just cloud front that is caching your content your browser will be working in tandem with cloud front as a service and so really what you need to be mindful of here is how are each one working together and how long is the cache being held for the browser cache or cloud front and then how do you want to update that as well so listen let's dive into a little bit deeper here so I talked about those four different types of contents that I mentioned whether its private long live content or dynamic or whether it's shared dynamic content or something that's shared immutable again the idea here is that CloudFront will look at the cache control headers like cache control or expires that comes from your origin and it will use those settings on that your origin dictates and like me at you know the profile level now if they are not available CloudFront will go ahead and apply the default TTL the min or the max that you might have configured within CloudFront and so when you're looking at your browser as well if we're looking for example at the private long live content up there in the top right here you might want to say you don't want to cache any of this and so you don't want to cache on cloud front one way you can do this is you would set cloud front into a proxy mode where you'd forward all headers and then you'd also make sure that you set your TTL for the browsers for a long time as well now private dynamic content might be a slight - variation here where you don't want to cache this CloudFront or the browser as well and so in both scenarios do you would set a no store directive and just completely bypass and proxy that information back to the origin just to get whatever the latest is at that time and then shared static content you can set long TTLs for both browser and for CloudFront and if you want to version you can do that through a combination of using etags or if modified cents or change the URL self as well and then for a shared mutable content again here you might want to set a minimum cash TTL on CloudFront and then no cash directive on the browser and then the browser will always go check CloudFront and make sure that it has the latest version of the content before sending it back to the viewer experience again one thing you can do here is that you may want to update your content and so really the recommendation might be here is to try and use versioning and cache control policies to the best extent you possible now there are times where you might have to go in and do an invalidation and you want to go in and just forcibly just remove content and replace it with you know maybe an update that you would want your viewers to see in place and without invalidations they take just a few seconds and you know it's invalidate Adhan like 90% or more of the cloud front network within just a couple of seconds and those invalidations are ingested almost instantaneously so you have a lot of options in terms of how do you want to configure cloud front depending on the type of content you're serving now the other idea here is that you are going to be forwarding a lot of information back to your origin and by default CloudFront creates a caching key if that's what we refer to as how do we know what to cache the cache key itself is really going to be based on a combination of the path it's going to be a combination of the headers that are encoded or any of the headers that are in the query string as well and as you forward those back to your origin that's going to really help determine what is or is not cached within within CloudFront now the first advice that we really give to most people is to Ford as little as possible and really only forward that content or the information that is really meaningful to your origin or that you need to see that information now when you forward headers or query strings you want to also make sure you pay attention to the case and the order of which those appear because that can also affect the cache key and therefore your cache efficient efficiency so always make sure that you're keeping track of what it is you're trying to cache and what are you sending to your origin now sometimes you might want to vary these responses and so you can use the very header to inform the browser that it might vary and again go check the cloud from cache for those different types of versions that might be stored there now as I mentioned when you're when you're building that cache key you want to pay attention to the different variations that might come up here and so whenever possible you want to use things that are still standardized or consolidated a little bit more narrow but still give you the insight you need so for example some had some headers provided by CloudFront include the device type so instead of sending just the the full agent header you could use the information that's derived in cloud front and use that to communicate what's happening back to your origin so again the other aspect here is that when you're leveraging responsive web design you also want to make sure that you can reuse these elements within that same on-screen experience depending on whatever device it might be so that again you can use the same object to fill that user experience without having to just cache multiple iterations of it for every different type of viewing experience that you might see let's keep on moving forward when we look at what happens to the cache or a cloud front when it goes back to the origin requesting content there's different options you have available here by default cloud form will go ahead and do some type of negative caching or what that means is that we'll go ahead and cache the errors from your origin for a couple of minutes that default is five and can be configured but what this allows your origin to do is it allows your origin to get healthy again or stand back up if it were unavailable and during that time CloudFront will just go ahead and serve that air page that either is the default one provided by CloudFront or you can configure and customize your own custom air page for a better user experience just so that it's not as obvious that maybe your origin is running getting back up to a healthy state now I mentioned that security is one of those aspects that we can't emphasize enough and when we look at the security aspect that AWS takes it really comes based in the shared responsibility model and what that means the ADA base will protect the cloud and the services and tools that it provides to you as a user but then you as a user are responsible for whatever is put into the cloud or how its configured so by default again as mentioned CloudFront already goes ahead and has built-in DDoS protection for all known layer a network layer and transport layer DDoS attacks and then you can also add more.this protection through additional services such as shield advanced which we'll talk about a little bit later and we also mentioned that again the way the cloud front is built is inherently secure as well and it has the requirements and necessary to meet many of those certifications that handle sensitive information such as credit cards and PCI DSS compliance measures so in the following slides we're going to dive a little bit different into the different security controls that are powered by cloud front so first and foremost cloud fronts network is built with HTTP and HTTPS in mind and what that means is that it's a single platform and a single network that can deliver both types of content and that's not necessarily true with other market CDNs available where the two different protocols might be separated onto two different networks now with CloudFront you can redirect HTTP to HTTPS on the edge which is really good when it comes to layer 7 floods and protecting against those and you can control the TLS policy on cloud front and make sure that you have that right balance in terms of compelled compatibility between what the client is able to handle and what your origin expects and so you can really get in and dictate what is that minimum level of security that you're willing to to handle as the requests come back to your origin now we implement several advanced TLS advanced features such as OC OS CSP stapling to make sure that we offload the heavy lifting of checking certificate revocation status from the client and kind of shift that workloads to cloud front and then also perfect forward secrecy in which it's a key agreement protocol to make sure that any session keys will never be compromised even if that private key of the server might have been compromised in some way so what this again means that you're your viewer delivery experience is secured in a highly scalable way as well so when it comes to enabling HTTP communication on cloud front there are several ways that you can go ahead and do this first and foremost there's the default certificate with cloud front which is the star cloud for net certificate what this does is it goes ahead and provides the HTTP HTTP communication for any default CloudFront distribution and so this would be a use case where you don't necessarily care about the domain that's serving the content and you might be ok with the default domain name that CloudFront uses as part of its resource in this case might be D 1-2-3 CloudFront net now if that's not something you want and you want to use a custom URL to deliver your content there's two different ways that you can do this first and foremost you can use the sni cloud front ssl in which you would bring your own SSL certificate and you can also configure a certificate for free from Mazon certificate manager as well what this allows you to do is to configure the such as WWE example calm and then make sure that you can serve that certificate to your clients as long as they're able to read into that SMI header extension now if your client does not support the SMI extension we also offer dedicated IP custom SSL in which the IP address would be linked to your SSL certificate while it's in use and then your your clients can rely on that IP address to identify which certificate should be served though there are some additional costs when using that model now sometimes you want to restrict access to your content itself and there's different ways that you can do this whether you're using signed URLs or signed cookies the idea here is that you'd be using a combination of different keys configured in CloudFront which your origin application would use to sign a request coming in from a client and then that client would take that signed URL or that assigned cooking go request the content from CloudFront now CloudFront will then authenticate that that signature either using a canned policy that you might have used provided by CloudFront or you can use your own custom policy as well so you can then dictate whether that content should be served again whether it matches that that signature or if it's also within a certain time period for what you think that content should be valid so there's a lot of flexibility that you can bake into that logic and that you have available at your disposal another option you have that's a little bit more straightforward in its deployment is geo restriction and this might be an example where you simply have a very regionalised user base where you say I only have viewers in this one country or in its surrounding proximity and you might say I only want to whitelist those countries or you might say I want to blacklist certain countries that you say I have no business or no viewers or no desire to respond to the requests coming from that region and so you can quickly get in and create a whitelist or a blacklist to block the requests or accept the request according to those rules alright lastly another way that you can really protect or use CloudFront to enhance the security of your overall application is to really focus on the protection of the origin itself now we already talked about how CloudFront protects your origin by having that large network to distribute content or distribute requests that are incoming if they happen to be malicious but what you can also do is you can use custom headers to identify CloudFront to your origin so that your origin is only going to respond to requests coming from CloudFront and block anything else another way that this could be implemented is by using security groups to whitelist the cloud for IP ranges that would be known or expected on your origin application or a unique feature between CloudFront and s3 origins is what's called origin access identity and what uses a policy to again identify CloudFront as a specific resource of yours and have it known to s3 so again we'll say I'm only going to accept content requests you know coming from cloud front with this attached policy it's very simple to enable that and there are several blogs and CloudFormation template that can get you started on that as well now just wrapping up before I hand over to lambda edge when I talked about the security capabilities again when we're looking about what's built in and already included its the ADA base shield which provides that DDoS protection but you can also layer on additional optional services such as AWS RAF to do a lot of things like cross write scripting prevention and also work on SQL injection prevention as well and then shield advances available for customers as well who want additional DDoS protection and 24/7 access to our DDoS response team and then also want some economic protection in terms of making sure that the costs of scaling if it does happen are covered by AWS and not a financial threat vector to your operations as well so with that before I hand off the last thing I'd like to just touch on is when it comes to using cloud front and the pricing dimensions involved it really centers on two things it's going to be their request fees in terms of the number of a quests that are being made to cloud front infrastructure and then also for the data transfer coming out of cloud front to your viewers as well there are also some charges for data transfer going from cloud front to the origin but are provided at significantly reduced rates but one thing that's really most important to focus on here is that with Amazon Cloud front when you use it with an AWS origin the data transfer that is coming out of your it abuse origin such as easy - or s3 that data transfer is free of charge and it is not charged so when you're looking at the overall egress of your applications data you would only be paying for the data transfer out of cloud front and not for the data transfer out of the origin as well now just like many other AWS services cloud front comes with a a free tier available to go ahead and get started and then also for large volume use cases as well CloudFront also offers private pricing deal agreements as well to offer discounted rates for different time or volume commitments all right and what they I'm gonna go ahead and turn the time over to David to do a deeper dive into lamb dead edge at which point we'll then dive into a question and answer period at the end thank you information so lambda at edge it is a component of cloud Front it is really meant to serve as a means to take either application or server side logic and move it to the edge where it can be executed closer to your end user so there's oftentimes things where cloud friend can't do it natively but you'd like to be able to do or just simply you want to offload compute from your origin or your application and get it closer to your end-user and that's really what lambda edge is meant to do it is sort of the combination of AWS lambda which is a server list compute engine with cloud front so you could think of it as a server list compute with global scale and so let's talk a little bit about lambda and why we chose lambda as sort of the building blocks for lambda edge so lambda as I mentioned is AWS is serverless compute in the cloud it allows you to run code in response to events but the nice thing about lambda is that you don't have any overhead for managing the infrastructure dependencies scaling or even any of the operation you get to build and focus on what is most important for your business which generally as a developer is writing code I don't want to have to worry about servers I don't have to maintain them I just want to write code and lambda affords you that ability and so as we mentioned lambda runs in response to events that happen and so we'll take a little bit of a deep dive here we've got our function here and these functions can run really any sort of runtime whether it be node J S or Python all the way to things like c-sharp and go and those functions themselves can go off and execute any type of code that you want and and reach out to any other AWS service that may be existing so for example your lambda function might make a call to a dynamo DB table to update data or pull data into a function for useful it's executed and then on the other side of your function functions are triggered based off of events and those events can be anything it could be that your data has changed from one state to another maybe I've uploaded an object into s3 and I want to have a function run based on that it could be that I have an endpoint that's requesting data so when I hit that endpoint it executes a lambda function or even things like changes in resource state so maybe one of my load balancers becomes unhealthy and I can flag a lambda function to run to go out and help you know mitigate whatever problems there may be arising because of that and so one of those triggers that is available to you on lambda is CloudFront and so when you use cloud front as a trigger for a lambda function you're really getting lambda at edge so lambda edge again is combining the power of lambda that serverless compute engine with the global delivery of CloudFront so you are sort of taking a single bit of code and deploying it globally so that with a single click of a button you're really bringing that server list compute all the way to your users wherever they may be in the world and so that gives you much better performance and lower latency while still being able to leverage the power and scale of lambda and so what is really happening sort of behind the scenes with with lambda edge is when you deploy a function it actually takes that code and replicates it to locations and regions all throughout the world and so you write your code once and then when you deploy it gets propagated automatically to all of the edge locations within CloudFront and so there are a number of different triggers that are available to you as a user of cloud front as a trigger for your lambda edge functions the first one we'll talk about is a viewer request and so that is a viewer has made a request to Cloud front and you want some action to take place because of that request and so that may be something like manipulating the cache key so doing normalization of a user agent for example so that when the object goes through the caching engine you've got less copies of the same object the next one is origin request and so that is a request that will only be triggered if there's a cache miss meaning CloudFront doesn't have the object in cache and so these are really important ones to run you want some events to take place before it goes to your origin so for example maybe you have a lambda function that is dynamically selecting an origin based on the type of requests that came in you would do that at an origin request invocation stage we also have origin response so once your origin has responded with the content that's been asked for you can then manipulate that response back maybe you're adding in cache control headers before it hits the cache on the cloud front side so you can cache it for longer or shorter than what the origin is telling you to do and then the last one is a viewer response event so these are going to be at the very last point before we were set for cloud Fred sends the response back to the client you have the ability to manipulate that so this would be a good stage where maybe you'd want to add like the HSTs security header so that the next time somebody comes to your page you're forcing them to connect over HTTP to prevent you know unencrypted execution of your site so those are the four triggers that you have at your disposal you set these triggers up inside of your cloud front distribution inside the cache behaviors so you write your function and then you associate it with one of these four triggers from within your conference distribution so some of the use cases for lambda edge and there's almost an infinite number of them but they sort of fall into one of three categories the first one is sort of simple HTTP manipulation and these would be things like normalizing user agent headers to increase cache hit ratio adding security headers cache control headers you can even do simple things like a be testing with with single you know with with easy manipulation the next one is dynamic content generation and so this could be things like rewriting URLs or even redirecting to different URLs a lot of customers use lambda at edge just for those two functions alone you can also do some more complicated things like dynamically rendering pages so you may have static content served from an s3 bucket and some dynamic content that's being pulled from a DynamoDB table then you could use lambda tej to sort of combine those two together and render a page dynamically before sending it out to the client and then the last one is origin independence and that's really just being able to have URLs that are easy for the user to understand and to manipulate whereas on the back end you might be doing some complex logic you might have a different hierarchy structure on your origin or maybe you've got an older API that you want to wrap inside of a newer format where it's easier for users to consume that end point you can use lambda to edge to make those types of things as well so I'll quickly go through a couple of best practices with lambda edge the first one which might sound a little bit odd is like do you even need to use lambda edge in the first place lambda can solve all sorts of problems for you but it's not always the right choice simply because there are more native features or offerings available to you that you could leverage so a good example of that is you could use lambda edge to do security like to you know look at IP addresses and determine whether to allow or block them but you could just use AWS wife to do that same thing and it would generally be provided to you at a lower cost and it's oftentimes easier to do it using you know native features that are available through other AWS services or even cloud for Ann itself the cloud front also provides just a ton of features right so things like device identification there's analytics and then there's also access controls like signed URLs signed cookies like if what you're trying to do is available natively use it natively save yourself the headache of and cost of trying to run lambda edit also leverage responsive design whenever you can so you have one version of your site that can run across all devices that we are not trying to determine which version of the site to send the user to based on URL characteristics or device characteristics it's oftentimes easier if you just have a single format that runs across all devices and then lastly sometimes logic is better off if you run it on your origin so things like setting cache control headers that's often better done on your origin so just do it there rather than trying to leverage Lamba edge to do it the second one is only use lambda when you actually need it so do you need it to run on every single request or can it run when there's a cache miss an understanding when you win that behavior that needs to execute can drastically reduce your cost when using lambda edge and make it so that it only runs when it absolutely needs to run and then the other main point is use cloud front behaviors judicious and judiciously so that you're being as granular as you can to to allow users to execute functions only when they absolutely need to so be as granular and specific as you can don't be afraid to you know have lots of them and then obviously if you're not going to be using a lambda at edge function just just remove it like don't even don't even have it there then it won't execute the third one I'll mention is to choose the optimal memory configuration so within lambda you have the ability to set how much memory the function is actually going to use and subsequently that also increases the CPU available to use within that function and sometimes just by increasing the memory you can decrease the total amount of time that the function runs larger than the actual cost to offset that so what I mean by that is in this example here is by increasing the run the the memory available to the function from 128 Meg to 256 Meg I saw a 40% decrease in the actual function duration so how long the function actually executed but I only saw a 20% increase in my cost because of doubling the amount of memory and so you need to MIT you need to determine that trade-off is a 40% improvement in performance worth the 20% increase in cost and so sometimes playing with the right allocation of memory can have a big impact on not only performance but also your cost and so you need to factor that in when you're trying to determine the right size function to use lastly I'll just touch on a couple of security best practices the first one is is similar to AWS as a whole which is just adopt the principle of least privilege you have the ability to define a role for your lambda function where it can reach out to any AWS service that's available you want to limit that down so that your function is only accessing the resources inside of AWS that you absolutely need it to access don't give it access to everything and then also along with that you want to monitor and log your functions and set alarms based on those because if you aren't monitoring you don't know if you're under attack if there's a threat vector and so you want to have solid monitoring solid logging already set up in your function and also you want to know what is normal and what is not normal so if you don't know what normal traffic patterns look like you don't know if you're seeing a spike or whether that's just a normal traffic pattern because it's a Wednesday at 2:00 o'clock and that always spikes up so having that logging and monitoring there it goes a long way break up your functions to the smallest possible compute unit that you can you don't want to have big functions that do everything because that requires oftentimes access to systems where some parts of the functions might not need access to it so breaking it down into its smallest component keeps your attack vector smaller it keeps your code more secure and it also just gives you oftentimes a faster and more performant function encrypt data that one's kind of a no-brainer you use HTTPS whenever you can or use the AWS SDK if you're reaching out to other AWS services that's already encrypted for you automatically don't put passwords into your actual code itself use secret Security's storage for example don't put the log into your your database into your code store that in like secrets manager or kms and use that to pull in what do you execute the function and then people know lambda is application code only there's no access to the underlying infrastructure so attackers are going after exploits specifically at the application layer so just know that as you're at you're building out your function and try to keep some of those best practices in mind knowing that attackers are going to go after that and so things like the OAuth 10 like keep those types of threats in mind and whenever possible use wife because that will help protect a lot of those types of attacks and then lastly just delete functions when you're not using them no reason to have them lingering out there just just remove them completely so I think that's all that we had sorry I went through that really quickly no it's great let's you want to open it up to some questions yes we've got a number of questions coming through and we're just gonna answer this kind of just in a conversational manner so the first question that I saw come through was just asking about some of the more recent features that cloud front announced and first and fro so the one thing I want to do is you can always find information and news about aid abuse launches on the AWS blog there is a what's new thread that always just call us consolidates all of the threads about what's happening with each service so within that as well you can subscribe to clarin topics or look at the cloud front page itself and under our own what's new we have everything related to cloud front so it's a good resource for seeing what's new and happening in terms of new batch locations and new features the ones that come to mind at least on the cloud front side I'm looking at I am policies updated so now what you can do is let's say that you had multiple tenants within your organization or multiple teams and you're using a central AWS account now what you can do with cloud front is you can use am policies to restrict access to a specific distribution for a specific team and so you might have multiple distributions set up in your account in your AWS account so each team might have their own distribution and what you would not want to happen is for someone to inadvertently go in and mistakenly update the settings in someone else's distribution and and so what you can do here is each each account or each user coming in with an IM role and then they can only see or modify that one distribution another flavor of this is that we also do that tag based I am controls and so you can also tag multiple distributions or resources so you could say this set or this collection of distributions is relevant to that one team and then the others could be for a different team and so really what it does is just puts a lot of good checks and controls into managing your CloudFront resources we've got some other recent updates on legislate on the lamda edge aside a couple of notable updates in August or late July I guess I should say we announced support for Python 3.7 which which was one of the most widely requested features of lime dead edge so right now we support both no js' and Python so no I'm sorry eight ten and ten X and also Python 3.7 and then another feature that we recently rolled out is a consolidated dashboard for Lam dead edge functions so one of the the concerns with lambda is that because it runs globally logs and metrics get dumped into the region closest to where the function actually executes and that often means customers are sort of trying to determine and aggregate from all of those different regions which you know where the function was executed and and if there are errors it's a little bit harder to debug so we launched a consolidated dashboard inside the cloud front console that allows you to see regionally across all regions number of invocations errors throttling back that type of thing from from within one location so if you do have energy can then go into a specific region deep dive in and get information awesome there another question coming in here is talking about cloud front and integration with amplify and I guess really what we can do is with this question we can talk about all of the other better together stories or integrations where you talk about how is cloud front integrated with other eight of your services so you want to talk about amplify and and sure and then I can take some of the other ones we just kind of list them officer sure yeah so you can use cloud front with amplify and in fact if you're using the amplify console to deploy your single page app that is just inherently using cloud front as part of its deployment so as you deploy from amplify you're already taking advantage of cloud front and so there's nothing that you have to do explicitly you just sort of are doing it as part of using amplify you can deploy outside of the console and do it manually if you want but you would essentially be setting up the same way that you so that's an interesting thing when you also look at just having that resource automatically deployed on your behalf sometimes that is visible to the viewer and they can go in and that resource is made in their account and they can modify it and customize it according to whatever the use case might be other services actually have cloud front kind of underlying the service behind the scenes in a managed AWS and so some of these services where CloudFront is actually accelerating other services examples include api gateway and the edge optimized api a gateway the edge optimized endpoints so those come inherently with a CloudFront distribution already set up and configured and running and so you get those global endpoints where all the api's can come to get accelerated over that backbone a little bit faster rather than just hopping over the public Internet finding their way to whatever regional endpoint there might be and sometimes that might just be a single regional endpoint if they don't have a multi region like set up so sometimes you can kind of get you know that enhanced performance just by using CloudFront now another one that comes to mind is app sync applications as well and I know with that whether you're using the web sockets or or just standard HTTP protocols again cloud front is behind many elements of the set of the service to again accelerate those applications where you have a quick and easy way to launch an application and then automatically have cloud front a part of that story and then you know there's again the other integrations where maybe cloud front isn't an underlying resource but you still have integrations that make it easier or faster so things that I'm thinking of would be like the Amazon certificate manager no worry or media package with elemental media services as well so when you get cloud front you're actually getting a lot with other AWS services and I think the one thing that I would say is probably the biggest thing out there is also you get that free data transfer out of your origins so and that's any eight of your origin it's not just ec2 or s3 but any AWS origin free data transfer going to cloud front you'd only pay for the data transfer oh yeah and then starting to follow on that a lot of these services if you do have the option to set them up you can do so simply by just clicking them within AWS console so as you go to setup the origin if you're using something like s3 or even media package those are available to you directly to do click on and it sets it up for ya yeah there's a line we won't belabor the topic but you know additional integrations out there worth kognito as well you know for that authentication happening closer to the edge really what it does is just CloudFront can accelerate so many different types of applications it's really kind of fun to see all that different ways customers use this let's take a look at some other questions coming through here all right one of the questions was just asking about getting started in general this is a topic or an area where I love being part of the AWS community because you have a ton of people out there writing a lot of content and this happens both externally to AWS and also internally within edit voice and so if we look at the internal aspect of it we have solution architects who work in the field with our customers and one of the cool things is that as they report back different use cases or different examples that they've encountered in the field with live real experiences you know we've built solutions whether it's using lamb fat edge or coupling together different services like you know elemental media services what we do is we we try and document these and publish them on a blog that we set up just to vote over a year and a half ago and so if you go to the AWS blogs and you search for the networking and content delivery blog what's really cool is you can see a lot of these use cases especially around you know lambda edge and what happens here is it goes in and explains what the context is and my favorite part about this is the code snippets that are provided and so it's not just day this was a really cool story but it's actually a kind of a guided narrative to how do you can do it in your own application as well and so we have a lot of amazing blogs that can help you get started with that or if again you're just looking to get started with cloud front in just a very simple like static web page we have ten-minute tutorials to just run you through how do you do that with s3 or set up something with a like a WordPress site those blogs also have cloud formation templates which you can just click a button and have those deployed in your account and so it just sort of sets everything out for you yeah it's easy to get going yep awesome let's take a look here we got some more questions here a couple more minutes before we wrap up question is how is my content cached in the cloud front Network and is it served or across all quadrant locations so this is a setting called price class what that means is that depending on what kind of performance and cost you know trade-off or balance you want to to use you might choose different like Olmec sub networks within the cloud for network as a whole and so if you only have viewers in like North America or Europe you might choose what's our base price class 100 which only uses the edge locations in those regions what this means is that those regions are very low cost and users would come in and they as they request content it's pulled from the origin into all the different edge caches around the world that way you know subsequent requests can be served immediately from the edge so it's not necessarily pushed into everywhere but it's only pulled into the locations where you know it's actively being served yeah and then is held into the cache now one architectural aspect of this is CloudFront has a multi-tiered hierarchical you know caching the infrastructure and what that means is we have all of these edge nodes around the world and that's the hundred and like 80 or so and those are going to be the first line of caching that your viewers are going to experience now if the edge location itself does not have that content it doesn't always have to go back to the origins we have a mid tier cache and these are called regional edge caches and with there are 11 of these strategically placed in it abuse regions around the world we have more coming in the pipeline here in the next while but what these do is the edge locations will first check the regional edge cache that's most local to it and that's a much bigger - width and it will hold on to the content much much longer and again concede the caches of the edge now at each one of these points there's the collapse request collapse 40 and so I mean there's like content requests that are for kind of the same content they're not individually going to the origin they're being consolidated into a more efficient single request going back to your origin and so in terms of origins and when you are going through your your best practice as you mentioned a lot of customers have origins inside of a double yes is that an actual requirement to have no yeah so this is you know a great point that we should have covered it's more of just foundational basics but any any origin that is accessible over the public internet over HTTP you know it can be used by CloudFront now what we also added just about a year ago now is WebSockets support as well so we do support the WebSocket protocol to have those real-time experiences and it's been really cool to see how CloudFront is now accelerating like leaderboards or chat applications or online collaborations and so it really kind of takes that HTTP model and twist it into you know something that you holds on to those TCP connections for an extended period of time but yet still you know can accelerate those those frames as they go in between the client and the server over this optimized network path so people are seeing snappier faster more agile applications and viewers as well yeah definitely awesome got time for one more one one question let's see if there's something lambda debt related all right so yeah here's what go for it yeah so what are the best practices for using a lambda edge function within with the database located in a V PC so the short answer to that is lambda at edge cannot access resources inside a private subnet inside your V PC so if your database is located in a private subnet lambda edge would not be able to go and retrieve that information you would either have to move the database into a public subnet which you probably don't want to do or have some sort of load balancer or some sort of proxy in the public subnet that could then talk to your private subnet which lambda edge could then reach out to all right we're gonna want it to just say thank you for joining us for the office hours today and look forward to meeting people if they happen to come to reinvent and you know I tend our sessions there as well so thank you for joining us today yeah thank you

Channel: AWS Online Tech Talks

Views: 9,584

Keywords: Amazon CloudFront, CDN, Content Delivery Network, Web Development, Serverless, AWS, Webinar, Cloud Computing, Amazon Web Services

Id: cIZvZMZD8_o

Length: 57min 59sec (3479 seconds)

Published: Fri Oct 04 2019