‫So say you have a CloudFront distribution
‫and you wanna make it private
‫and you want to give access to people
‫to premium paid shared content all over the world.
‫But you want to be able to see and know who has access
‫to what on your CloudFront distribution.
‫For this, you can use a CloudFront signed URL
‫or a signed cookie and not tell the difference
‫of SAML and cookie at the very end of this slide.
‫So first, when we create a URL and a cookie,
‫you need to attach a policy
‫and you need to tell when does the URL or the cookie expire.
‫What IP ranges can access this data from?
‫So if you know the target IP of your clients,
‫then you should definitely use that.
‫And the trusted signers,
‫so which address accounts can create signed URLs
‫for your users.
‫Then you can ask me,
‫"How long should this URL be valid for?"
‫Well, if you're sharing a content, for example,
‫a movie, or music, you can make it very short,
‫a few minutes.
‫But if it's content that is private to the user
‫that they will access in a long period of time,
‫you can make that URL or that signed cookie last for years.
‫So what's the different between a URL and a cookie?
‫A signed URL gives access to individual files.
‫So you get one URL per file.
‫So if you have 100 files to show you'll get 100 URLs.
‫And if you have a signed cookie,
‫then you give access to multiple files
‫and the cookie can be reused.
‫So this time you have one signed cookie for many files.
‫So choose whatever you need based on the context.
‫Now, how does signed URL work as a diagram?
‫So we have our CloudFront distribution
‫and has a bunch of locations.
‫And for example,
‫we seen before that we can access our Amazon S3 bucket
‫through OAC origin access control for maximum security.
‫And so that means that the objects in our S3 buckets
‫cannot be accessed by anything else, but CloudFront.
‫But we still want to be able to give people access
‫to their objects through CloudFront.
‫So we have our clients, and our client is going
‫to authorize and authenticate to our application
‫and we have to code that application.
‫And our application will use the AWS SDK
‫to generate a signed URL directly from CloudFront.
‫It will return the signed URL to the clients
‫and then the clients will be able to use
‫that signed URL to get the data and the files
‫and the objects or whatever you need,
‫directly from CloudFront.
‫So this works for signed URL,
‫but this also works for signed cookie obviously.
‫But you may be asking yourself,
‫should I use a CloudFront signed URL
‫or an S3 pre-signed URL?
‫And they have a different purpose.
‫So CloudFront signed URL is to allow access to a path,
‫no matter the origin.
‫So signed URL works not just for S3 as an origin,
‫but HTTP, backend of whatever you want.
‫It's an account wide key-pair,
‫so only the root can manage it.
‫And you can filter by IP, path, date and expiration.
‫And you can leverage all the caching features out
‫of CloudFront.
‫So if you look at the diagram,
‫we have the clients using the signed URL
‫onto your CloudFront distribution
‫and then CloudFront distribution talking to your origin.
‫In this case, I put an EC2 instance.
‫Okay, so we have an idea for this.
‫Now for S3 pre-signed URL,
‫it issues a request as the person who pre-signed the URL.
‫So the idea is that if I signed the URL
‫with my own IAM principle
‫and I use my IAM keys to signing this,
‫then the person who has that URL has the same rights as me.
‫It has a limited lifetime.
‫And so the idea
‫is that now the client can access directly your S3 bucket
‫using that pre-signed URL.
‫So the idea is, if you want people to have access
‫to your CloudFront distribution and it's in front of S3.
‫You have to use a signed URL
‫because you cannot access your S3 bucket as you should
‫because there is a bucket policy restricting it to the OAI.
‫But if your users are using directly against S3
‫and you want to distribute a thousand S3 directly
‫without using CloudFront,
‫then pre-sign URL will be a great use case for it.
‫All right, that's is for this theoretical lecture.
‫I will see you in the next lecture.