Does this plugin still exist? Not seeing it anywhere...

On this page:

• https://github.com/awsdocs/amazon-cloudfront-developer-guide/blob/master/doc_source/DownloadDistS3AndCustomOrigins.md

It seems S3 buckets configured as website endpoints are implied to still be defined as origins of type S3Origin, yet trying to create a distribution with such an origin will fail. Rather, a CustomOriginConfig must be used. I'm requesting more specific wording and guidance in the documentation to clarify the type of origin to use, and example origin configurations for each case (plain S3, S3 as website, and custom).

Setting up CloudFront to serve private content by using signed cookies can be a challenge, and our content doesn't currently include code samples for using signed cookies. If you've set up private content with CloudFront by using signed cookies, consider sharing your steps and code to help others who are working to get this set up.

Thank you very much, on behalf of all of your colleagues who want to use private cookies with CloudFront!

I've found that since JW player 8 that won't issue licenses for free member accounts, and forced user using JW Player 8 hosted on thier site.
Can you give us new guide for RTMP streaming?

https://github.com/awsdocs/amazon-cloudfront-developer-guide/blob/main/doc_source/private-content-creating-signed-url-canned-policy.md#L133

says:

Remove white space (including tabs and newline characters) from the hashed and signed string.

This sounds wrong: Removing white space from the binary representation makes no sense, it is not even properly defined (would that be an ASCII interpretation of the binary? Or UTF8)? Also, the perl sample code does not do it.

Hi
Following this article http://docs.aws.amazon.com/en_us/AmazonCloudFront/latest/DeveloperGuide/restrict-access-to-load-balancer.html
I realize that the custom header specified in the "Origin Custom Headers" section of the origin policy is transformed as the first letters of the words it is made of are capitalized. For example i specified a custom header named "elb-key" and at the origin it is received as "Elb-Key". It was a long troubleshooting to figure it out.
I suggest to update the UI to make it super clear what is the value used at runtime.
At least mention this clearly in the documentation.

New – HTTP/3 Support for Amazon CloudFront
https://aws.amazon.com/jp/blogs/aws/new-http-3-support-for-amazon-cloudfront/

https://github.com/awsdocs/amazon-cloudfront-developer-guide/blob/a21fd3218dcb37e721a81e498e438e4e7672b786/doc_source/distribution-web-values-specify.md#DownloadDistValuesSupportedHTTPVersions

Supported HTTP versions
Choose the HTTP versions that you want your distribution to support when viewers communicate with CloudFront. For viewers and CloudFront to use HTTP/2, viewers must support TLS 1.2 or later, and must support Server Name Identification (SNI).

In general, configuring CloudFront to communicate with viewers using HTTP/2 reduces latency. You can improve performance by optimizing for HTTP/2. For more information, do an internet search for "http/2 optimization."

Please add articles for HTTP/3 support for Amazon CloudFront.

examples:

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/AmazonCloudFront_DevGuide.pdf

Supported HTTP versions
Choose the HTTP versions that you want your distribution to support when viewers communicate with
CloudFront.
For viewers and CloudFront to use HTTP/2, viewers must support TLSv1.2 or later, and Server Name
Indication (SNI).
For viewers and CloudFront to use HTTP/3, viewers must support TLSv1.3 and Server Name Indication
(SNI). CloudFront supports HTTP/3 connection migration to allow the viewer to switch networks without
losing connection. For more information about connection migration, see Connection Migration at RFC
9000.

getting-started-secure-static-website-cloudformation-template's request diagram no longer up-to-date and should not include the reference to Lambda@Edge.

https://github.com/awsdocs/amazon-cloudfront-developer-guide/blob/main/doc_source/getting-started-secure-static-website-cloudformation-template.md?plain=1#L21

Page: Create a URL Signature Using Perl (https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CreateURLPerl.html)

Text:
To get the tool cfsign.pl, go to Amazon CloudFront Signed URLs Helper Tool (the hyperlink in this sentence is broken - https://aws.amazon.com/items/3052/?externalID=3052&categoryID=215)

Correct me if I have misunderstood something.

Hello,

How often is the content of this repo being published out to public?

For example I see that: TLS 2019 updates happened in e218f35

However, https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/secure-connections-supported-viewer-protocols-ciphers.html#secure-connections-supported-ciphers is somewhat outdated.

Reference: aws/aws-cdk#9738 (comment)

Thanks!

Why is there no mention of Python on this page? (doc_source/PrivateCFSignatureCodeAndExamples.md)
Why is there an explanation for signing URLs, but not cookies?
For python there is get_presigned_url but nothing for cookies.

PHP has a CookieSigner, why not Python?

If you've written a Lambda@Edge function to use with CloudFront that addresses a common pain point or use case, consider replying to this issue and sharing your steps. I'd like to include more practical, straightforward use case tutorials in the CloudFront docs, and your help would be much appreciated!

If you have a simple example of setting up CloudFront with your website using secure HTTPS access, consider replying to this issue and sharing your step-by-step example. I'd like to include more practical, straightforward use case tutorials in the CloudFront docs, and your help would be much appreciated!

Hello,

Under https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html#invalidation-specifying-objects, the docs say:

Whether you invalidate files by using the CloudFront console or the CloudFront API, the requirements and restrictions for specifying files are the same.

However, when it comes to specifying a leading slash, I believe this is not true.
On the console, leading slashes are optional. When attempting to make an API call, I encountered an error until I added a leading slash to all of the paths.

This may be something that's easier to fix on the API side than the docs, but I figured this would be the best place to get the ball rolling.

The page about 503 errors - here on Github - is not complete, and does not mention a relatively opaque error I see every so often.

The error reads...

<?xml version="1.0"?>
<ErrorResponse xmlns="http://cloudfront.amazonaws.com/doc/2020-05-31/">
<Error>
<Type>Receiver</Type>
<Code>ServiceUnavailable</Code>
<Message>CloudFront encountered an internal error. Please try again.</Message>
</Error>
<RequestId>
(myrequestid)
</RequestId>
</ErrorResponse>

There should be a section on what causes CloudFront encountered an internal error. Please try again. and what we, as developers, should do to fix this (if anything).

As a "basic" user, only spending around $9,000 per year on AWS, I don't have access to paid support, so ensuring these documents are up to date is critical.

Unfortunately, I can only report this documentation oversight, not help in documenting it.

Hey folks,

I'm trying to figure out how to set and persist cookies in a Lambda@Edge function. The documentation here indicates the example is setting cookies, but all I see is that it is reading cookies and seeing if they are set, and otherwise returning a random jpg. Is it possible to set a cookie within a Lambda@Edge function with CloudFront? Or am I barking up the wrong tree and need a different solution?

Thanks in advance.
Clark

It seem that there is no document about how to set metadata when use s3 as origin access.

I use cloudfront origin access presigned url for customers to upload files. I don't find too much documents for to special header to make the file in s3 have the metadata. For example I want the s3 file have the 'content-length' metedata. But add 'content-length' in header don't take effect. https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/forward-custom-headers.html say we can't even use ' X-Amz-*' so how can I set metadata using the cloudfront upload?

Greetings,

I was just having trouble invalidating and object that contained both spaces " " and a dash character. Originally parsed the file name to many files that did not exist so then I tried using the escaped URL ["%20", etc] and at first I didn't see the change so then I tried quotes which gave an error method. After checking again I saw the change too so I'm assuming the escaped URL worked.

I think an example showing how to handle spaces and/or special characters would be help at this page because it's linked from the AWS CloudFront Console:

On the help topic:
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html
https://github.com/awsdocs/amazon-cloudfront-developer-guide/blob/main/doc_source/Invalidation.md

And after going though this I thought an interface to select the objects (rather than type then) would be ideal. Granted I know that it would take a lot of work and is easier said than done but if something like that were made in the future I think it would be a nice addition to this feature in the console.

Thanks and keep up the good work!

AWS WAF quotas docs direct to CloudFront's documentation:

The maximum requests per second (RPS) allowed for AWS WAF on CloudFront is set by CloudFront and described in the CloudFront Developer Guide.

but not seeing that quota documented by CloudFront

I think we need at least 50 shards for the real-time log example below as each shard can ingest 1000 records per second:

For example, assume your distribution receives 50,000 requests per second, and that your real-time log records size is typically 500 bytes. This means that your real-time log configuration could generate 25,000,000 bytes (50,000 multiplied by 500), or 23.84 MB, per second. In this scenario you would need at least 24 shards. To add a buffer of about 20%, you would specify 29 shards.

The solution's description in the Getting Started guide doesn't reflect accurately what it does and do not match the solutions repository.
Specifically, there is no Lambda@edge in this solution and the diagram looks different.

I think it would be appropriate to mention that Security Headers can be set within CloudFormation as opposed using a CloudFront Function (see page: Add security headers to the response. I believe the less costly, easier implementation would be here: Using the managed response headers policies.

I think this feature was released recently.

It can be challenging to track down what the issues are when a Lambda@Edge function isn't working the way you want it to, especially if you're just getting started with using Lambda together with CloudFront. If you've successfully tracked down issues with Lambda@Edge and have a few tips or suggestions about best practices, consider replying to this issue and sharing your ideas. I'd like to include more specific troubleshooting guidance for Lambda@Edge in our docs, and your help would be much appreciated!

Are the runtime environments and versions up-to-date? Given the fact NodeJS8.10 is being deprecated , 12 was added and Python 3.8 is supported for "regular" lambda's this seems to not be aligned?

The documentation recommends to use whitespace from the policy, which the perl example code does not do.

What are the coresponding ISO3166-2 codes in CloudFront-Viewer-Country header for below special unkown cases?

Anonymous Proxy – The request originated from an anonymous proxy.
Satellite Provider – The request originated from a satellite provider that provides internet service to multiple countries. Users might be in countries with a high risk of fraud.
Europe (Unknown) – The request originated from an IP in a block that is used by multiple European countries. The country that the request originated from cannot be determined. CloudFront uses Europe (Unknown) as the default.
Asia/Pacific (Unknown) – The request originated from an IP in a block that is used by multiple countries in the Asia/Pacific region. The country that the request originated from cannot be determined. CloudFront uses Asia/Pacific (Unknown) as the default. If you display the Locations report by U.S. state, note that the report can include U.S. territories and U.S. Armed Forces regions.
If CloudFront can't determine a user's location, the location will appear as Unknown in viewer reports.

Hi @joshbean

The code provided doesn't work for PHP.

I have reviewed more than 10 times my s3 and CloudFront settings and spent almost 2days figuring out but no luck

Can you please review the code and update it?

Best Regards,
Syed

I was notified today that the CloudFront real-time logs are now available as CloudFormation resource (https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-cloudfront-realtimelogconfig.html), but I can’t seem to figure out how they actually can be used with a CF distribution. Is there any document that describes the actual usage with a distribution?

Hi, the page https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html details steps to generate keys in a .pem format for encryption. The sample in Java details code using .der files. It would be best for consistency to keep the same format of keys throughout the tutorial. Is there a Java sample describing how to decrypt field encrypted by Cloudfront using the .pem keys?