Questions tagged with Amazon CloudFront
Content language: English
Sort by most recent
Hello,
I'm not a web developer. I created my AWS EB WebApp as Classic Load balancer. I'm now setting up Cloudfront distribution for CDN with a custom domain that I bought from AWS Route 53. My cloudfront is working, but it's not responding for POST request. When I read about it online, I think my aws eb webapp should be migrated to Application Load Balancer. Could you help please? - Haile
Hello All,
I've been trying to setup a Multi-region access point for S3.
The basic problem is that I have users in Asia that I'm trying to get better performance for.
The simple part. I've created two buckets, I've put an html file in each of them with a simple name of us-east-1 and ap-south-1.
Initially those were private access only but for the purpose of getting anything working they are now public.
They are setup in an mrap which for now is not replicating.
I setup a cloudfront distribution and pointed it at the mrap but only ever get errors.
https://corridor-ap-south-1.s3.ap-south-1.amazonaws.com/test/region-test/region.html - ap-south-1 html
https://corridor-cdn.s3.amazonaws.com/test/region-test/region.html - us-east-1 html
mrap alias: mbzcc59bo9dy4.mrap
mrap access point? https://mbzcc59bo9dy4.mrap.accesspoint.s3-global.amazonaws.com/test/region-test/region.html
The errors are: The authorization mechanism you have provided is not supported. Please use Signature Version 4.
I hope I'm wrong, but is there a ridiculously stupid world where I have to put a signature on my object request?
This seems like it would be a complete waste of money to setup a lambda to do this for all my object requests.
Dear Support and Community,
I use the following code to get a cloudfront distributed audiostream on my website.
Without cookie authorization everything works fine. When I use the code on my wordpress website the cookies get set as expected but cloudfront still rejects access with a 403 error. Do you see any mistakes I could have made?
BR Iggy
```
<?php
/**
* Plugin Name: CloudFront Auth Plugin 0.5
* Description: Ein Plugin zur Implementierung der CloudFront-Cookie-Authentifizierung.
* Version: 0.5
* Author: us
* License: GPL2
*/
function createSignedCookie($streamHostUrl, $resourceKey, $timeout){
error_log('function createSignedCookie gestartet');
$keyPairId = "APKA5**********HZVB"; // Key Pair
$expires = time() + $timeout; // Expire Time
$url = $streamHostUrl . '/' . $resourceKey; // Service URL -> The path for that the cookies shall be valid
$ip=$_SERVER["REMOTE_ADDR"] . "\/24"; // IP
$json = '{"Statement":[{"Resource":"'.$url.'","Condition":{"DateLessThan":{"AWS:EpochTime":'.$expires.'}}}]}';
$private_key_path = __DIR__ . '/private_key.pem';
$fp = fopen($private_key_path, 'r');
if (!$fp) {
return;
}
$priv_key=fread($fp, 8192);
fclose($fp);
$key = openssl_get_privatekey($priv_key);
if(!$key){
return;
}
if(!openssl_sign($json, $signed_policy, $key, OPENSSL_ALGO_SHA1)){
error_log('Failed to sign policy: ' . openssl_error_string());
return;
}
$base64_signed_policy = base64_encode($signed_policy);
$policy = strtr(base64_encode($json), '+=/', '-_~'); //Canned Policy
$signature = str_replace(array('+','=','/'), array('-','_','~'), $base64_signed_policy);
$signedCookie = array(
"CloudFront-Key-Pair-Id" => $keyPairId,
"CloudFront-Policy" => $policy,
"CloudFront-Signature" => $signature
);
return $signedCookie;
}
function TriggerSignedCookies(){
$signedCookieCustomPolicy = createSignedCookie('cookietest.ourwebsite.com', 'music.mp3', 300);
foreach ($signedCookieCustomPolicy as $name => $value) {
setcookie($name, $value, 0, "/", "ourwebsite.com", true, true);
}
}
function SetCloudFrontCookies() {
global $post;
if (is_a($post, 'WP_Post') && has_shortcode($post->post_content, 'SetCookies')) {
TriggerSignedCookies();
}
}
function ShortcodeHandler() {
// Gibt einen leeren String zurück, um zu verhindern, dass "1" auf der Website angezeigt wird.
return '';
}
function ShortcodeInit() {
add_shortcode('SetCookies', 'ShortcodeHandler');
}
add_action('init', 'ShortcodeInit', 0);
add_action('send_headers', 'SetCloudFrontCookies', 0);
?>
```
Hi,
S3 has static website enabled and configured through cloud front using OAI.
When s3 is public accessible , the cloudfront url is working , once S3 Public access is disabled , even website is not being accessed by cloudfront url and getting access denied.
I want to implement Audit logs for our API, for compliance needs. Every request that a customer performs to the API should be logged.
It must be hermetic, we can’t lose any log.
The API high level architecture:
Cloudfront -> API GW -> LB
I thought about Cloudfront standard logs, but the documentation says that it may not be hermetic, so it’s not relevant for my use case.
API GW access logs seems to be my direction for now, but setting the log template is pretty challenging. I couldn’t get the perfect template with all relevant data:
* Instead of the request payload, I get “-” (by using $input.body)
* Useragent is “Amazon CloudFront” instead the actual useragent (makes sense due to the fact that Cloudfront forwards the request)
* Many more fields are empty
*
2 comments:
*The log template documentation that I based on -
[https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-mapping-template-reference.html#context-variable-reference?cmpid=docs_apigateway_console]()
*I added to the Cloudfront distribution the “AllViewerExceptHostHeader” origin request policy, it didn’t help, looks like API GW still gets the requests with missing metadata from Cloudfront
[https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/using-managed-origin-request-policies.html#managed-origin-request-policy-all-viewer-except-host-header]()
The question is: is this the right direction for implementing API audit log? If not, would you recommend a third party product? I’m trying to avoid developing it in-house.
Thanks,
Yedidya
Hello,
I've followed [these instructions ](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.SimpleDistribution.html) to create a publicly accessible S3 bucket, with Cloudfront connected to it. I can access all S3 objects in my browser, but the Cloudfront URL always returns "Access Denied".
I'm confused because my S3 bucket is publicly available, and I'm able to access the bucket objects. What could be causing this error?
Cloudfront automatically added these bucket policy rules, but now my IAM user + production IAM role can't access the bucket to perform head object operation. How do I modify this to allow for object access for my server?
I also already tried using principle. It didn't work. The IAM user has full access to S3
```
{
"Version": "2008-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": "Server access",
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:GetObject",
"s3:ListBucket",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::bucket-name",
"arn:aws:s3:::bucket-name/*"
],
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:iam::1234567890:user/dev"
}
}
},
{
"Sid": "AllowCloudFrontServicePrincipal",
"Effect": "Allow",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::bucket-name/*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::1234567890:distribution/asdf"
}
}
}
]
}
```
[![enter image description here][1]][1]
[1]: https://i.stack.imgur.com/ox5E7.png
What might cause an "Access Denied" error when creating a cloudfront s3 Origin using cloudformation?
I have a bucket in account A. This bucket is configured to block all public access, and to allow GetObject to requests from cloudfront with "aws:ResourceOrgID" matching my orgId.
In Account B (inside my organisation) I can create an OriginAccessControl, and using this and the console, i can manually add the url bucketname.s3.region.amazonaws.com as an s3 origin, and using this OriginAccessControl, I can access the files from cloudformation.
(I have also verified that this is not possible form an account outside my org, I believe my bucket policy is ok)
Trying to configure the exact same origin using cloudformation leads to the following error:
Resource handler returned message: "Access denied for operation 'Access Denied. (Service: CloudFront, Status Code: 403, Request ID: ....
I assume, that cloudformation is either trying to verify that the bucket is accessbile in the background, or is trying to change the bucket permissions.
Unfortunately changing the bucket policy action to * for resources BucketName, BUcketname/* doesnt help.
What could cloudformation be doing that the console doesnt which causes this failure?
I've deployed a Nextjs v12 app on Amplify but I got error 503 on nextjs API routes:
ISSUE
The Lambda function associated with the Cloudfront distribution is invalid or doesn't have the required permissions. 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.
If you provide content to customers through Cloudfront, you can find steps to troubleshoot and help prevent this error by reviewing the Cloudfront documentation.
MY TRIES
I tried to add permissions for lambda functions to the Amplify role but it doesn't work. Also can't find a policy specific to lambda@edge.
I can see on the linked Cloufront the lambda@edge.
I found different documentation on this issue but the only solution proposed was to downgrade Nextjs to v11, something I wan to avoid.
No issues logged in the Amplify deploy:
2023-03-21T18:42:58 [INFO]: Deployed the following resources to your account:
2023-03-21T18:42:58 [INFO]: - CloudFront Domain ID: xxx
2023-03-21T18:42:58 [INFO]: - SSR Lambda@Edge: xxx
2023-03-21T18:42:58 [INFO]: - API Lambda@Edge: xxx
2023-03-21T18:42:58 [INFO]: - Image Optimization Lambda@Edge: xxx
2023-03-21T18:42:58 [INFO]: - S3 Bucket: xxx
2023-03-21T18:42:59 [INFO]: Deployment complete
SPECS
I'm using Amplify 'web dynamic', Nextjs v12, prisma (I do 'npx prisma generate' in the build phase).
Hello, I'm trying to create a distribution on Cloudfront and S3 and use a domain outside of AWS, with route 53 I can use my domain without problems, but my question is whether it would be possible to use my domain without using Route 53. on the site that hosts my domain, since I don't have ns, it's like something is missing. I can manage to configure the cname from the certificate generated in ACM, the txt and the alias that points to the cloudFront, but I could not configure the ns. So, is Route 53 fundamental in this process?
so i have a fargate proxy service for which public ip is disabled , i have configure load balancers, nat and internet gateway for the service because the servie was in private subnet , so i did all the configurations ,now i am trying to access the service using cloud front distribution wiht behaviour as token - loadbalancer origin , the service is working fine sometimes and sometimes giving me 504 cloud front error as this
"504 ERROR
The request could not be satisfied.
CloudFront attempted to establish a connection with the origin, but either the attempt failed or the origin closed the connection. 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.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.
Generated by cloudfront (CloudFront)
Request ID: RCHf8wHj1tiIdHY1XGCIjAYl2PClTVwR4F3k5hzUbiTsEsfbb0-Oug=="
i have configured the security group of the load balancer to allow all the traffic from internet and same with the secuirty group of my fargate service , for testing purpose , i have also configured a nat gateway , sothat the service can access the internet because it forward the service to another service on the internet and i have also configured an internet gateway so that the service on the internet can talk to the fargate service.
how should i resolve this error , can this be a cloud front specific error and if so how should i resolve it ???.
also in the fargate service logs i am not able to see any issue neither in the load balancer logs ,as well it is showing that the traffic is being forwarded.
I am serving images from S3 and want to migrate to CloudFront.
The S3 bucket is ACL-enabled. Some files are made public (ACL: public-read) and some are private, so they can be accessed like (where public files don't require signature):
* public -> https://xxx.s3.ap-northeast-1.amazonaws.com/public.jpg
* private -> https://xxx.s3.ap-northeast-1.amazonaws.com/private.jpg?AWSAccessKeyId=…&Signature=…&Expires=…
But when I set up CloudFront for this S3 bucket:
1. If I don't restrict viewer access (in Behavior setting), both public and private files can be accessed without signature.
2. If I restrict viewer access using the key pair, then both types require signature in the URLs.
Is it possible to set up this as S3 does, which means, requires signature based on the ACL of the objects in S3?