By using AWS re:Post, you agree to the Terms of Use
/Amazon CloudFront/

Questions tagged with Amazon CloudFront

Sort by most recent
  • 1
  • 90 / page

Browse through the questions and answers listed below or filter and sort to narrow down your results.

Non guessable CloudFront URL

I'm wondering if there's a way to make the S3 path unguessable. Let's suppose I have an S3 path like this: https://s3-bucket.com/{singer_id}/album/song/song.mp3, this file will be served through CloudFront, so the path will be: https://cloundfront-dist-id.com/{singer_id}/album/song/song.mp3?signature=... (I'm using signed URLs). My question is : it is possible to make the /{singer_id}/album/song/song.mp3 not guessable by hashing it using for example Lambda or Lambda@Edge function so the client will see a url like this https://cloundfront-dist-id.com/some_hash?signature= ? Thanks in advance. https://stackoverflow.com/questions/70885356/non-guessable-cloudfront-url I am also facing issue. Question may arise why need of hash because signed url are secure. For my side, I need such url with s3 path hidden. I am using same AWS bucket for retrieving image for internal use without signed url and sharing that file to others using signed url. Internal USe CDN without signed url after CNAMe https://data.example.com/{singer_id}/album/song/song.mp3 Signed url https://secured-data.example.com/{singer_id}/album/song/song.mp3?signature=. &Expires == Since both using same AWS bucket and if someone guesses in signed url then access content https://data.example.com/{singer_id}/album/song/song.mp3?signature=. &Expires . File opens . In this scenario, I want to hide {singer_id}/album/song/song.mp3 to some new value and file is displayed under new name
1
answers
0
votes
7
views
asked 10 days ago

AWS Cloudfront Signed URL still valid after expiry time

To generate AWS cloudfront signed url , I have enabled restrict viewer access --> Yes --> Trusted signer while creating distribution. from datetime import datetime,timedelta, timezone from cryptography.hazmat.backends import default_backend from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives import serialization from cryptography.hazmat.primitives.asymmetric import padding from botocore.signers import CloudFrontSigner import base64 CLOUDFRONT_KEY_BASE64 = "*******" def rsa_signer(message): private_key_string = base64.b64decode(CLOUDFRONT_KEY_BASE64) private_key_ascii = private_key_string.decode('ascii') private_key = serialization.load_pem_private_key( private_key_ascii.encode('UTF-8'), password=None, backend=default_backend() ) return private_key.sign(message, padding.PKCS1v15(), hashes.SHA1()) key_id = '*******' url = 'https://*****.cloudfront.net/hello.pdf' expire_date = datetime(2022, 4, 24,11,33) cloudfront_signer = CloudFrontSigner(key_id, rsa_signer) signed_url = cloudfront_signer.generate_presigned_url(url, date_less_than=expire_date) print(signed_url) The signed url is generated: https://****.cloudfront.net/hello.pdf?Expires=1650799980&Signature=******&Key-Pair-Id=***** This url works even after expiry time 2022-04-24 11:33:00 But when I generate URL of old date (2022-04-23), the url doesnot work. I checked with today date 2022-04-24 but older time 2022-04-24 07:33:00, url works even after expiry. How to invalidate the signed url after expiry time?
1
answers
0
votes
6
views
asked a month ago

AWS Lambda@Edge created using AWS CDK doesn't put Log to CloudWatch

I created a simple Lambda@Edge function like below. ``` 'use strict'; exports.handler = async function(event, context, callback) { const cf = event.Records[0].cf; console.log('Record: ', JSON.stringify(cf, null, 2)); console.log('Context: ', JSON.stringify(context, null, 2)); console.log('Request: ', JSON.stringify(cf.request, null, 2)); callback(null, cf.request); } ``` And I deployed it using AWS CDKv2 `experimental EdgeFunction like below ``` const edgeFunction = new cloudfront.experimental.EdgeFunction(this, 'EdgeFunction', { runtime: Runtime.NODEJS_14_X, handler: 'index.handler', code: Code.fromAsset(path.join(__dirname, '../../../../lambda/ssr2')), }); ``` and also I set it up as edge function for a Distribution ``` const distribution = new Distribution(this, 'Distribution', { defaultBehavior: { origin, cachePolicy: CachePolicy.CACHING_DISABLED, viewerProtocolPolicy: ViewerProtocolPolicy.REDIRECT_TO_HTTPS, edgeLambdas: [ { functionVersion: edgeFunction.currentVersion, eventType: LambdaEdgeEventType.VIEWER_REQUEST, } ] }, ``` But when I tried sending the request to the Distribution, the log didn't show up anything. I checked the permission, the role already has permission ``` Allow: logs:CreateLogGroup Allow: logs:CreateLogStream Allow: logs:PutLogEvents ``` I expect the function write logs to the CloudWatch. What did I miss? **UPDATE 1** Below is the role document, ``` { "sdkResponseMetadata": null, "sdkHttpMetadata": null, "partial": false, "permissionsBoundary": null, "policies": [ { "arn": "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole", "document": { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "*" } ] }, "id": "ANPAJNCQGXC425412345", "name": "AWSLambdaBasicExecutionRole", "type": "managed" } ], "resources": { "logs": { "service": { "icon": "data:image/svg+xml;base64,PHN2ZyB2aWV3Qm94PSIwIDAgNjQgNjQiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyI+CiAgPGcgdHJhbnNmb3JtPSJzY2FsZSguOCkiPgogICAgPGRlZnM+CiAgICAgIDxsaW5lYXJHcmFkaWVudCB4MT0iMCUiIHkxPSIxMDAlIiB4Mj0iMTAwJSIgeTI9IjAlIiBpZD0iYSI+CiAgICAgICAgPHN0b3Agc3RvcC1jb2xvcj0iI0IwMDg0RCIgb2Zmc2V0PSIwJSIvPgogICAgICAgIDxzdG9wIHN0b3AtY29sb3I9IiNGRjRGOEIiIG9mZnNldD0iMTAwJSIvPgogICAgICA8L2xpbmVhckdyYWRpZW50PgogICAgPC9kZWZzPgogICAgPGcgZmlsbD0ibm9uZSIgZmlsbC1ydWxlPSJldmVub2RkIj4KICAgICAgPHBhdGggZD0iTTAgMGg4MHY4MEgweiIgZmlsbD0idXJsKCNhKSIvPgogICAgICA8cGF0aCBkPSJNNTUuMDYgNDYuNzc3YzAtMy45MDktMy4yMDItNy4wOS03LjEzOC03LjA5LTMuOTM1IDAtNy4xMzYgMy4xODEtNy4xMzYgNy4wOSAwIDMuOTEgMy4yIDcuMDkgNy4xMzYgNy4wOXM3LjEzNy0zLjE4IDcuMTM3LTcuMDltMi4wMSAwYzAgNS4wMTEtNC4xMDMgOS4wODctOS4xNDcgOS4wODctNS4wNDMgMC05LjE0Ny00LjA3Ni05LjE0Ny05LjA4NyAwLTUuMDEgNC4xMDQtOS4wODYgOS4xNDctOS4wODYgNS4wNDQgMCA5LjE0OCA0LjA3NiA5LjE0OCA5LjA4Nm04LjQ0IDEzLjY5N0w1OC41IDU0LjIwM2ExMy4wMzMgMTMuMDMzIDAgMDEtMS45NDcgMi4xNmw2Ljk5OCA2LjI3YTEuNDc0IDEuNDc0IDAgMDAyLjA2Ni0uMTA3IDEuNDUzIDEuNDUzIDAgMDAtLjEwOC0yLjA1Mm0tMTcuNTg4LTIuODEyYzYuMDQzIDAgMTAuOTU4LTQuODgzIDEwLjk1OC0xMC44ODVzLTQuOTE1LTEwLjg4NC0xMC45NTgtMTAuODg0Yy02LjA0MSAwLTEwLjk1NyA0Ljg4Mi0xMC45NTcgMTAuODg0IDAgNi4wMDIgNC45MTYgMTAuODg1IDEwLjk1NyAxMC44ODVtMTkuMTkgNi4yQTMuNDgzIDMuNDgzIDAgMDE2NC41MjkgNjVhMy40NzUgMy40NzUgMCAwMS0yLjMyMi0uODgzTDU0LjkzMSA1Ny42YTEyLjkzNSAxMi45MzUgMCAwMS03LjAwOSAyLjA2Yy03LjE1IDAtMTIuOTY3LTUuNzc5LTEyLjk2Ny0xMi44ODIgMC03LjEwMiA1LjgxNy0xMi44ODEgMTIuOTY3LTEyLjg4MSA3LjE1MSAwIDEyLjk2OSA1Ljc3OSAxMi45NjkgMTIuODgxIDAgMi4wMzgtLjQ5MiAzLjk2LTEuMzQ0IDUuNjc0bDcuMzA5IDYuNTRhMy40NDQgMy40NDQgMCAwMS4yNTYgNC44NzJNMjEuMjggMjkuMzkzYzAgLjUxOS4wMzIgMS4wMzYuMDk0IDEuNTM2YS45OTQuOTk0IDAgMDEtLjgyMyAxLjEwNmMtMi40NzIuNjM0LTYuNTQgMi41NTMtNi41NCA4LjMxIDAgNC4zNDggMi40MTMgNi43NDggNC40MzkgNy45OTYuNjkxLjQzMyAxLjUxLjY2NCAyLjM3My42NzNsMTIuMTIyLjAxMS0uMDAyIDEuOTk3LTEyLjEzMS0uMDFjLTEuMjQ2LS4wMTQtMi40MjgtLjM1MS0zLjQyOC0uOTc3QzE1LjM3NyA0OC43OTcgMTIgNDUuODkgMTIgNDAuMzQ1YzAtNi42ODMgNC42LTkuMTUzIDcuMy0xMC4wMjYtLjAyLS4zMDctLjAzLS42MTctLjAzLS45MjYgMC01LjQ2IDMuNzI4LTExLjEyMyA4LjY3Mi0xMy4xNzEgNS43ODItMi40MDcgMTEuOTA4LTEuMjE0IDE2LjM4NCAzLjE4OSAxLjM4OCAxLjM2NCAyLjUyOSAzLjAyIDMuNDA0IDQuOTM3YTYuNTA5IDYuNTA5IDAgMDE0LjE1NC0xLjUwMmMzLjAwMiAwIDYuMzgyIDIuMjY0IDYuOTg0IDcuMjE1IDIuODEyLjY0NCA4Ljc1MyAyLjg5NCA4Ljc1MyAxMC4zNjIgMCAyLjk4MS0uOTQxIDUuNDQ0LTIuNzk4IDcuMzE5bC0xLjQzMy0xLjQwMWMxLjQ3My0xLjQ4OCAyLjIyLTMuNDc5IDIuMjItNS45MTggMC02LjUzMi01LjUwNC04LjE1Ny03Ljg3My04LjU1MWExLjAwMiAxLjAwMiAwIDAxLS44MjMtMS4xNTdjLS4zMjktNC4wNTUtMi43NTMtNS44NzItNS4wMy01Ljg3Mi0xLjQzNyAwLTIuNzg0LjY5NS0zLjY5NyAxLjkwN2ExLjAwNiAxLjAwNiAwIDAxLTEuNzUtLjI1OGMtLjgyMy0yLjI2Ni0yLjAxLTQuMTcxLTMuNTI1LTUuNjYxLTMuODgtMy44MTYtOS4xODQtNC44NS0xNC4xOTUtMi43NjYtNC4xNyAxLjcyNy03LjQzNyA2LjcwMi03LjQzNyAxMS4zMjgiIGZpbGw9IiNGRkYiLz4KICAgIDwvZz4KICA8L2c+Cjwvc3ZnPgo=", "name": "Amazon CloudWatch Logs" }, "statements": [ { "action": "logs:CreateLogGroup", "effect": "Allow", "resource": "*", "service": "logs", "source": { "index": "0", "policyName": "AWSLambdaBasicExecutionRole", "policyType": "managed" } }, { "action": "logs:CreateLogStream", "effect": "Allow", "resource": "*", "service": "logs", "source": { "index": "0", "policyName": "AWSLambdaBasicExecutionRole", "policyType": "managed" } }, { "action": "logs:PutLogEvents", "effect": "Allow", "resource": "*", "service": "logs", "source": { "index": "0", "policyName": "AWSLambdaBasicExecutionRole", "policyType": "managed" } } ] } }, "roleName": "MyProject-EdgeFunctionFnServiceRoleC7B72E4-1DV3AZXP558ZS", "trustedEntities": [ "lambda.amazonaws.com", "edgelambda.amazonaws.com" ] } ``` I just tried using the Test in the Lambda Panel. All the tests send logs to the CloudWatch. However when I send request to the CloudFront, it didn't send anything. **UPDATE 2** I just found out from StackOverflows that the log is being stored not centrally but distributed to regions. Something like below ``` /aws/lambda/us-east-1.MyProject-EdgeFunctionFn44308ADF-loJeFwXXzTOm ``` So instead of opening it from Lambda panel, I need to open it in the CloudFront panel. Somewhat I couldn't find it in any AWS documentations. **References** https://aws.amazon.com/id/blogs/networking-and-content-delivery/aggregating-lambdaedge-logs/ https://stackoverflow.com/questions/66949758/serverless-aws-lambdaedge-how-to-debug#:~:text=Go%20to%20CloudWatch%20and%20search,%2D%3E%20Lambda%40Edge%20Errors%20.
2
answers
0
votes
8
views
asked a month ago

Cloudfront not respecting Origin Path

I have a cloudfront distribution with two origins. The first is an S3 static-website bucket and the second is an ALB. I also configured an extra behavior (apart from the default) to forward all api requests to the ALB. **CNAME** - service.example.com **Behavior: ** * Path Pattern - `api/*` * Cache Policy - `CachingDisabled` * Origin Request Policy - `AllViewer` **Origin** * Origin Path - `/api/v1` The objective is to fetch `https://service.example.com/api/v1/something` when I try to access `https://service.example.com/api/something`. This doesn't work. If I access `service.example.com/api/anything` the URL does not even get rewritten to `service.example.com/api/v1/anything` Is there a CloudFront behavior I'm not aware of that's making me misconfigure this? Edit to add: I enabled ALB access logging and this is how all requests look: ``` https 2022-04-21T08:35:38.496934Z app/example-service/48c3493fa5414f88 65.49.20.66:45416 10.0.2.91:8000 0.001 0.002 0.000 404 404 39 178 "GET https://44.198.88.248:443/ HTTP/1.1" "-" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:us-east-1:ACCOUNTID:targetgroup/example-service/1d723b6babea76f0 "Root=1-6261175a-69c4fa13012685" "-" "arn:aws:acm:us-east-1:ACCOUNTID:certificate/1d74321b-[snip]-539" 0 2022-04-21T08:35:38.493000Z "forward" "-" "-" "10.0.2.91:8000" "404" "-" "-" ``` Referring to the syntax of this log line, it seems like `"GET https://44.198.88.248:443/ HTTP/1.1"` is the requested path. There is no path here even though I requested `/api/v1/something/else`.
2
answers
0
votes
14
views
asked a month ago

Does Amazon CloudFront support HTTP 1.0 requests without the Host header?

CloudFront fails for an HTTP 1.0 request without the `Host` header (optional for HTTP 1.0): ``` POST / HTTP/1.0 Content-Type: application/ocsp-request Content-Length: 75 HTTP/1.1 400 Bad Request Server: CloudFront Date: Wed, 16 Mar 2022 21:22:41 GMT Content-Type: text/html Content-Length: 915 Connection: close X-Cache: Error from cloudfront Via: 1.1 edd67566d372ed79fbaa7f9cc3d7815e.cloudfront.net (CloudFront) X-Amz-Cf-Pop: ICN51-C1 X-Amz-Cf-Id: KOUV_x5KqMc2f1CsGn1oXTrgaLFSSJn76dycoN97BqIdmgRYjySN3g== <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <TITLE>ERROR: The request could not be satisfied</TITLE> </HEAD><BODY> <H1>400 ERROR</H1> <H2>The request could not be satisfied.</H2> <HR noshade size="1px"> Bad request. We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner. <BR clear="all"> If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation. <BR clear="all"> <HR noshade size="1px"> <PRE> Generated by cloudfront (CloudFront) Request ID: KOUV_x5KqMc2f1CsGn1oXTrgaLFSSJn76dycoN97BqIdmgRYjySN3g== </PRE> <ADDRESS> </ADDRESS> </BODY></HTML> ``` Now, I'm aware that a CDN edge server using shared public IPs (the default when using CloudFront) wouldn't be capable of identifying the correct distribution if it isn't provided with the `Host` header, so I enabled dedicated IP address for my distribution (https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cnames-https-dedicated-ip-or-sni.html#cnames-https-dedicated-ip) hoping that it could help, but CloudFront still fails. Now, considering that (at least technically) using dedicated IP addresses would make CloudFront capable of identifying the correct distribution and send the requests to the expected origin even when the `Host` header is missing, is this something supported at all?. PS: I don’t even see the previous request through Standard logging, so I guess it is lost even before reaching my distribution. Same question asked in https://stackoverflow.com/questions/71505681/does-amazon-cloudfront-support-http-1-0-requests-without-the-host-header with a bounty.
2
answers
0
votes
4
views
asked 2 months ago

How to handle path-based routing for SPA when CloudFront has multiple behaviors?

We have an Angular SPA hosted on S3/CloudFront and we would like to use path-based routing. When a link like https://ourapplication.com/foo/bar is opened in a browser, we need the request to resolve to a 200 response containing the contents of `index.html`, so that the path part of the URL `/foo/bar` can be processed as a route by the Angular app running in the client. We got this working by adding "Custom Error Responses" to the CloudFront distribution - when the path `/foo/bar` is sent to the S3 origin, a 403 is generated. The custom error response maps this 403 to a 200 response with the contents of `index.html`. Perfect, apart from the fact that we also have another behavior on the CloudFront distribution that routes requests matching `/api/*` to API Gateway. Since the custom error response applies to the entire distribution, any API response returning 403 will also be mapped to index.html/200 - not what we want. Ideally we would have a per-behaviour or per-path custom error response. We tried to replicate something similar with redirection rules on the S3 bucket, but for various reasons this doesn't seem to be possible. Even if this could be made to work, it would always result in a redirect being sent back to the client instead of the `index.html` content being returned in the original request, so an extra round trip is required. We also considered Cloudfront/Lambda@Edge functions - we'd prefer not to use the latter for cost reasons. It's not clear how we would implement this with Cloudfront functions given that only Viewer Requests/Responses are supported there. [This SO post](https://stackoverflow.com/questions/54107781/how-to-setup-cloudfront-to-have-a-custom-error-page-per-origin) describes the same problem, and a possible solution based on Lambda@Edge Origin response handlers, which we'd rather not use for cost reasons. If we can't solve this, we'll probably fall back to hash-based routing but that has drawbacks for SEO, analytics etc. A path-based SPA with a same-origin API routed via a CloudFront behavior must be a fairly common scenario, so hopefully there's a better way or perhaps something on the CloudFront roadmap.
0
answers
1
votes
4
views
asked 2 months ago

Route53 not resolving custom domain for CloudFront

I have set up an S3 bucket to serve a website via https using CloudFront. Within that bucket, I have a folder for each environment and a set of version folders within the production folder: ``` my-bucket |-dev |-prod |-v1.0 |-v1.0.1 ...etc. ``` My initial (development) attempt worked fine using https://dev.mydomain.org, but when I decided to change the alternate domain name in the CloudFront distribution to the production name (i.e. https://mydomain.org and https://www.mydomain.org) and updated the Origin path, it stopped working. I am using Route53 to manage DNS and I haven't deleted the hosted zone. As far as I can tell, all the name server entries match like they're supposed to (makes sense, given I haven't touched the zone). I HAVE removed and recreated AAAA alias records that point to my CloudFront distribution with the two alternate domain names. Several times. No dice. I have also removed the alternate domain names from the distribution and re-added them. (I re-created the Route53 AAAA records after changing the distribution.) I can dig my domain without error. The Route53 test also comes back fine (for what it's worth). However, if I try to ping or curl, I get 'unknown host' errors. Visiting https://mydomain.org in a browser similarly returns a DNS_PROBE_FINISHED_NXDOMAIN response. In case it's relevant, I have this function attached to my distribution to re-route https://www.mydomain.org requests to https://mydomain.org: ``` function handler(event) { var request = event.request; var headers = request.headers; var host = request.headers.host.value; if (host.startsWith('www')) { var response = { statusCode: 301, statusDescription: 'Moved Permanently', headers: { location: { value: 'https://' + host.replace('www.', ''), }, }, }; return response; } return request; } ``` However, unlinking the function doesn't resolve the issue. (I have tested the function in the AWS console and it seems fine.) CloudFront itself seems to be OK. If I hit the CloudFront domain (e.g. d3abcdefghi123.cloudfront.net), I can see the site in all its glory. I have created a TLS/SSL certificate through ACM that covers both the apex and wildcard. I don't think there's a problem there. Something just refuses to resolve my custom domain to the CloudFront distribution. I know DNS changes can be slow - maybe I'm just too impatient? I don't want to create a new CloudFront distribution if I can help it - surely it's possible to update the Origin path and alternate domains? Given the site works fine through the default CloudFront domain, I don't *think* I need to invalidate it either. I'm out of ideas at this point, so suggestions would be most welcome. Regards, Flic
1
answers
0
votes
8
views
asked 2 months ago

How to fix "The following resource(s) failed to update: [Cloudfront]."

I'm getting this error > The following resource(s) failed to update: \[Cloudfront\]. when trying to redeploy my cloudformation stack. This is the template file: ```yaml AWSTemplateFormatVersion: "2010-09-09" Description: 'Cloudfront stack' Parameters: ViewerRequestFunctionVersionArn: Type: String Description: S3bucketStack Name that your want to import the DNSDomainName from. OringResponseFunctionVersionArn: Type: String Description: S3bucketStack Name that your want to import the DNSDomainName from. LambdaVideoPathEdgeVersionArn: Type: String Description: S3bucketStack Name that your want to import the DNSDomainName from. DNSDomainName: Type: String Description: S3bucketStack Name that your want to import the DNSDomainName from. MaxLength: 150 MinLength: 5 S3VideoDNSDomainName: Type: String Description: S3bucketStack Name that your want to import the DNSDomainName from. MaxLength: 150 MinLength: 5 IdParam: Type: String Description: S3bucketStack Name that your want to import the DNSDomainName from. MaxLength: 150 MinLength: 5 IdVideoOriginParam: Type: String Description: S3bucketStack Name that your want to import the DNSDomainName from. MaxLength: 150 MinLength: 5 OrigingAccessIdentityID: Type: String Description: S3bucketStack Name that your want to import the DNSDomainName from. MaxLength: 450 MinLength: 5 OrigingAccessIdentityVideoID: Type: String Description: S3bucketStack Name that your want to import the DNSDomainName from. MaxLength: 450 MinLength: 5 SSLCertificate: Type: String Description: SSLCertificate ARN . MaxLength: 150 MinLength: 5 Comment: Type: String Description: SSLCertificate ARN . MaxLength: 450 MinLength: 5 CommentOrigin: Type: String Description: SSLCertificate ARN . MaxLength: 450 MinLength: 5 AllowedMethodsParam: Type: CommaDelimitedList Description: Buket Name for website config( eg exemple.com). CachedMethodsParam: Type: CommaDelimitedList Description: Buket Name for website config( eg exemple.com). AliasesParam: Type: CommaDelimitedList Description: Buket Name for website config( eg exemple.com). defaultTTLParam: Type: Number Description: SSLCertificate ARN . Resources: CloudFrontDistribution: Type: AWS::CloudFront::Distribution Properties: DistributionConfig: Aliases: !Ref AliasesParam Comment: !Ref Comment CacheBehaviors: - AllowedMethods: !Ref AllowedMethodsParam CachedMethods: !Ref CachedMethodsParam Compress: false DefaultTTL: !Ref defaultTTLParam PathPattern: 'public/*' ForwardedValues: Headers: - Access-Control-Request-Headers - Access-Control-Request-Method - Origin QueryString: true MaxTTL: 31536000 MinTTL: 0 SmoothStreaming: false TargetOriginId: !Ref IdParam ViewerProtocolPolicy : "redirect-to-https" - AllowedMethods: !Ref AllowedMethodsParam CachedMethods: !Ref CachedMethodsParam Compress: false DefaultTTL: !Ref defaultTTLParam PathPattern: 'images/*' ForwardedValues: Headers: - Access-Control-Request-Headers - Access-Control-Request-Method - Origin QueryString: true QueryStringCacheKeys: - w - h - t - q - v LambdaFunctionAssociations: - EventType: 'viewer-request' LambdaFunctionARN: !Ref ViewerRequestFunctionVersionArn - EventType: 'origin-response' LambdaFunctionARN: !Ref OringResponseFunctionVersionArn MaxTTL: 31536000 MinTTL: 0 SmoothStreaming: false TargetOriginId: !Ref IdParam ViewerProtocolPolicy : "redirect-to-https" - AllowedMethods: !Ref AllowedMethodsParam CachedMethods: !Ref CachedMethodsParam Compress: false PathPattern: 'videos/thumbnails/*' DefaultTTL: !Ref defaultTTLParam ForwardedValues: QueryString: true QueryStringCacheKeys: - w - h - t - q - v LambdaFunctionAssociations: - EventType: 'viewer-request' LambdaFunctionARN: !Ref ViewerRequestFunctionVersionArn - EventType: 'origin-request' LambdaFunctionARN: !Ref LambdaVideoPathEdgeVersionArn - EventType: 'origin-response' LambdaFunctionARN: !Ref OringResponseFunctionVersionArn MaxTTL: 31536000 MinTTL: 0 SmoothStreaming: false TargetOriginId: !Ref IdParam ViewerProtocolPolicy : "redirect-to-https" - AllowedMethods: !Ref AllowedMethodsParam CachedMethods: !Ref CachedMethodsParam Compress: false PathPattern: 'videos/*' DefaultTTL: !Ref defaultTTLParam ForwardedValues: QueryString: true QueryStringCacheKeys: - codex LambdaFunctionAssociations: - EventType: 'viewer-request' LambdaFunctionARN: !Ref ViewerRequestFunctionVersionArn - EventType: 'origin-request' LambdaFunctionARN: !Ref LambdaVideoPathEdgeVersionArn - EventType: 'origin-response' LambdaFunctionARN: !Ref OringResponseFunctionVersionArn MaxTTL: 31536000 MinTTL: 0 SmoothStreaming: false TargetOriginId: !Ref IdVideoOriginParam ViewerProtocolPolicy : "redirect-to-https" - AllowedMethods: !Ref AllowedMethodsParam CachedMethods: !Ref CachedMethodsParam Compress: false PathPattern: 'gifs/*' DefaultTTL: !Ref defaultTTLParam LambdaFunctionAssociations: - EventType: 'viewer-request' LambdaFunctionARN: !Ref ViewerRequestFunctionVersionArn - EventType: 'origin-request' LambdaFunctionARN: !Ref LambdaVideoPathEdgeVersionArn MaxTTL: 31536000 MinTTL: 0 SmoothStreaming: false TargetOriginId: !Ref IdParam ViewerProtocolPolicy : "redirect-to-https" DefaultCacheBehavior: ForwardedValues: QueryString: false AllowedMethods: !Ref AllowedMethodsParam CachedMethods: !Ref CachedMethodsParam Compress: false DefaultTTL: !Ref defaultTTLParam MaxTTL: 31536000 MinTTL: 0 SmoothStreaming: false TargetOriginId: !Ref IdParam ViewerProtocolPolicy : "redirect-to-https" LambdaFunctionAssociations: - EventType: 'viewer-request' LambdaFunctionARN: !Ref ViewerRequestFunctionVersionArn DefaultRootObject: index.html Enabled: true HttpVersion: http2 IPV6Enabled: true Origins: - DomainName: !Ref DNSDomainName Id: !Ref IdParam S3OriginConfig: OriginAccessIdentity: !Sub "origin-access-identity/cloudfront/${OrigingAccessIdentityID}" - DomainName: !Ref S3VideoDNSDomainName Id: !Ref IdVideoOriginParam S3OriginConfig: OriginAccessIdentity: !Sub "origin-access-identity/cloudfront/${OrigingAccessIdentityVideoID}" ViewerCertificate: AcmCertificateArn: !Ref SSLCertificate MinimumProtocolVersion: "TLSv1.1_2016" SslSupportMethod: "sni-only" Tags: - Key: Application Value: Testing - Key: Distribution Value: Coudfront HTTPS Outputs: DomainName: Value: !GetAtt CloudFrontDistribution.DomainName Description: Cloudfront DomainName ``` I've reviewed the [cloudfront troubleshooting guide](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html) and the closest thing that I thought may be a cause was differences between the deployed resources and what the template specifies. So I reverted all the changes I'd made in the dashboard and tried redeploying, but the error persisted. What else can I try? Or is there more info I can provide to shed more light on the problem?
1
answers
0
votes
26
views
asked 2 months ago
  • 1
  • 90 / page