‫Let's explore some advance options
‫for CloudFront that can come up in the exam.
‫So let's talk about pricing and price classes.
‫So we know that CloudFront edge locations
‫are all around the world,
‫but because they're all around the world
‫the cost of data out per edge location will vary.
‫And so here is a table.
‫So as you can see based on the continent
‫or geographic region that the edge location is in
‫then you will have a different pricing.
‫So if you look at this table, (mumbles)numbers.
‫But if you look at Mexico, United States and Canada
‫the first 10 terabytes is
‫going to cost $0.08 per gigabytes.
‫But if you have the same education in India
‫is going to be about twice the cost
‫at $0.17 per gigabyte of data transferred and so on.
‫And the more data is transferred
‫out of CloudFront, the lower the cost.
‫So if you transfer
‫over five petabytes of data out of CloudFront
‫you're only going to pay $0.02 out of the United States.
‫So the idea is that's from the left side
‫to the right-hand side you have a higher cost
‫which brings us to the price classes.
‫So you have a choice you can make
‫and you can reduce the number of edge locations
‫around the world that is going
‫to be used for your car CloudFront distribution
‫in order to do cost reduction.
‫And there are three price classes available.
‫There is the price class all
‫which is giving you all regions
‫and obviously the best performance.
‫But it's going to cost you a little bit more money
‫because as you can see, for example
‫an edge location in India will cost more
‫than an education in the United States.
‫You can do the price class 200
‫which gives you most regions
‫but excludes the most expensive regions
‫and the press class 100
‫to only get the least expensive regions.
‫And this is summarized in this table.
‫Now the table is not really fun to look at.
‫So I made a little diagram here is the world
‫and we have a lot of edge locations around the world.
‫Now the price class 100 is going to give us
‫the America, the North America and Europe.
‫Then price class 200
‫is going to add some of these regions
‫and price class all is going to
‫have the entire world available for the edge locations.
‫So now let's talk about multiple origin
‫in the cloud fronts and then origin groups.
‫So for example, you may want to redirect
‫and route to different kinds of origins based
‫on the content type
‫or the path being passed to CloudFront.
‫For example, you have a path for images,
‫a path for the API and a path for everything else.
‫In which case in CloudFront
‫you can set different cache behaviors
‫with a path being determined.
‫And for example
‫if you have this /API/* path, okay
‫you can say that you need to have a response
‫from the origin being your Application Load Balancer.
‫But in case anything else is requested
‫maybe everything else is steady content,
‫then you should get that content out of your S3 buckets.
‫And so, as we can see
‫we have defined the multiple origins based
‫on the path being in Amazon CloudFront.
‫Now you can also set up origin groups
‫and this is a different use case.
‫This is to increase high availability
‫and do failover in case one origin has failed.
‫So an origin group consists
‫of one primary and one secondary origin.
‫And if the primary origin fails
‫then CloudFront will try to failover
‫to the second origin.
‫So let's take an example, say we have CloudFront
‫and we have an origin group made of two EC2 instances.
‫The first one is going to be our primary origin
‫and the second one is going to be our secondary origin.
‫So Amazon CloudFront will send a request
‫to the first EC2 instance.
‫And in case there is an error coming back
‫from the EC2 instance
‫then Amazon platform will retry
‫the same request on the origin B
‫and hopefully this one will respond
‫with an okay status code.
‫So there is a failover happening.
‫You can also use this with Amazon is free.
‫So in this example,
‫if we use S3 and CloudFront with origin groups,
‫we can get to region level
‫high availability and disaster recovery.
‫So let's have a look.
‫We have an origin group made of two S3 buckets.
‫The first one is going to be a primary origin
‫and the second one's going to be our secondary origin.
‫And if these S3 buckets are in different regions
‫then we can set up replication between these buckets.
‫So all the content of origin A
‫will be replicated into origin B.
‫Now, if Amazon CloudFront sends a request
‫and we get an error from the first S3 bucket
‫because maybe there is a region level outage,
‫then CloudFront will try the same request
‫onto another S3 buckets in another region
‫that will have all the data as the first one,
‫because of thanks to the replication.
‫And therefore this one should hopefully reply
‫with an okay status.
‫So it just gives you a great architecture to get
‫to regional level disaster recovery
‫for Amazon CloudFront and your S3 buckets.
‫Finally, let's talk about field-level encryption.
‫So this is to protect sensitive information
‫through the application stack.
‫And this adds an additional level of security
‫alongside using encryption in flight using HTTPS.
‫So the idea is that anytime
‫a sensitive information is sent by the user
‫the edge location is going to encrypt it
‫and they will be only be able to be decrypted
‫if someone has access to a private key.
‫And therefore,
‫this will be using asymmetric encryption.
‫So how does it work?
‫Well, in the POST requests being made
‫to Amazon CloudFront, then they will be a set
‫of fields that we want to be encrypted
‫up to 10 fields, for example, a credit card.
‫And they will specify
‫the public key to encrypt them with.
‫So let's go through an example.
‫We have a client taking over HTTPS to edge location
‫which will be forwarding it
‫to the CloudFront service using HTTPs again.
‫And then it will go all the way
‫to the origin using HTTPS
‫through Application Load Balancer
‫which will forward all the data using HTTPS
‫to your web server.
‫So everything is encrypted in flights
‫but we want to specify field-level encryption.
‫So say for example, that our user
‫is sending us some credit card information
‫and this is the one in orange right now.
‫We specify that we want to have it field level encryption
‫for the credit card information.
‫And therefore the edge location will encrypt
‫that field using a public key.
‫So now the data being passed from the edge location
‫to Amazon CloudFront to the origin
‫will have the credit card information
‫being encrypted thanks to the public key.
‫And so the information will be passed all along
‫until the web server.
‫And then the web server will have access to the private key
‫and we'll be able to decrypt that encrypted field
‫using the private key to decrypt
‫and get the credit card number.
‫As we can see all along the stack, none
‫of the CloudFront location
‫and Application Load Balancer will have
‫the opportunity to decrease that field.
‫Only the web server will need you have some custom
‫application logic to decrypt that field.
‫So that's it for this lecture.
‫I hope you liked it.
‫And I will see you in the next lecture.