可以说，这个问题在考试中和实际情况中很常见。比如：如何给那些缴费的会员显示相应的资源？或者如何给登陆用户展示相应的内容？
这里用到的一个核心技术，是CloudFront signed-URL和signed-cookie。
简单来说，我们假设需要访问的资源在S3上，也就是所谓的CloudFront Origin is S3。那么在启用配置Origin的时候，务必要限制S3 bucket的访问。从此以后，只能是CloudFront能够访问到S3的这个bucket，其他地方都不行。这个，就是所谓的OAI（Origin Access Identity）。
配置好后，那只有访问CloudFront生成的signed-URL，或者使用CloudFront生成的signed-cookie来访问的连接，才可以取到相应的资源。
那么问题一：此时的signed-URL或者signed-cookie什么时候生成？
根据场景，这个契机可以是在用户登陆的时候。当用户登陆之后，你产生这个signed-URL或者signed-cookie，返回给用户，然后用户跳转，使用这些完成访问。
画个图的话，大约是这个样子：
注意，这里Application使用了AWS SDK完成了signed-URL的生成。
好哒，那么问题二，这个Application是谁？
可以是任何能够使用AWS SDK完成请求的组件。比如：Lambda。
注意，这里的Lambda，是直接和CloudFront连接的Lambda，叫做Lambda@Edge。
别问我为什么有个@……仅从官网对其的slogan中，就可以感受到其功能的特殊性：
Lambda@Edge
Run your code closer to your users
看到了吧。Lambda@Edge是附着在CloudFront上的一个功能，非常靠近用户端。因此它完成的主要任务，就类似于完成用户认证啊、授权啊之类的。
其他它还可以做更多，比如修改HTTP Header之类的。让你更好地命中CloudFront Cache，或者命中想命中的SSL证书。
最后一个问题：signed-URL和signed-cookie哪个好？
视情况……视情况……
简单来说，signed-URL，只是一个URL。你需要对每一个URL都创建signed-URL才行。
而signed-cookies，你要带一个cookies，那么相应的URL都可以访问。
Use signed URLs in the following cases:
- You want to restrict access to individual files, for example, an installation download for your application.
- Your users are using a client (for example, a custom HTTP client) that doesn’t support cookies.
Use signed cookies in the following cases:
- You want to provide access to multiple restricted files, for example, all of the files for a video in HLS format or all of the files in the subscribers’ area of website.
- You don’t want to change your current URLs.
