Questions tagged with Amazon CloudFront
Content language: English
Sort by most recent
Make Cloudfront accessible and serve content from S3 Bucket.
1. Restrict direct access to S3 bucket.
2. Website should only be accessible from cloudfront url.
All via Lightsail, I created an Instance, attached a Static IP to it, created a Distribution, then set a Custom Domain on the Distribution, creating a Certificate. I attached that Certificate to the Distribution and all was well. This was being done in an experimental fashion. Deciding I wanted to use a different type of Instance, I nuked everything. No more Instance, no more Distribution, etc...
BUT, when I try to create everything all over again, the Instance is created just fine. The Static IP is created fine and attached as well. The Distribution setup is a breeze. Everything is perfect, except for the final steps, pertaining to the Certificate.
When I create the Certificate, the system acts as though it was still hanging around because the DNS entries for validation are exactly the same as before. As a result, the certificate seems to become validated almost instantly, quicker than before. Then, when I try to attach the Certificate to the Distribution, it throws the following error:
AttachCertificateToDistribution[us-east-1]
Alternative Domain Names [thefullyqualified.domainname.here] have one or more parameter that is already associated with a different resource.
InvalidInputException
In AWS Dashboard GUI for Lightsail, when picking a Certificate to attach to the Distribution, it says the Certificate is "Valid, not in use". But, still it throws this error.
So, I tried a different method where I made sure everything was detached and deleted via the AWS CLI. All seemed to be free and clear. Nothing hanging around that could be seen. I went through all of the normal steps that work via the AWS CLI to perform the same setup. Again, during the Certificate creation it seems to go much faster than usual, is instantly validated, and the validation CNAME record is the exact same as before. When I go to attach the Certificate via the AWS CLI, it gives this error:
An error occurred (InvalidInputException) when calling the AttachCertificateToDistribution operation: Alternative Domain Names [thefullyqualified.domainname.here] have one or more parameter that is already associated with a different resource.
I feel like either the Distribution (though getting deleted) is still hanging around and is still attached to the domain OR the Certificate is hanging around and is somehow referencing what it used to be attached to (which I believe would be the CloudFront Distribution, which goes back to my feeling that the Distribution itself is still hanging around even though it has been nuked via Lightsail.)
Any idea what I can do to get this to move forward without having to just pick another domain to use? I'm concerned that I'm going to end up in this boat one day with something that's fully in production and I'll be stuck. Is this just the risk of using Lightsail versus putting in the extra effort to setting up the EC2 instance and other configurations outside of Lightsail?
Is it possible to have a secure (https) site hosted on S3 without CloudFront? I am using AWS GovCloud, and CloudFront is not a service available to me, nor can I use the commercially available CloudFront. I need to find other methods that allow me to have an https site that can reach out to an authenticator. What services can I use to accomplish this? Do I use a VPN?
How do I enable a WAF rule for an website hosted in LightSail ?
asked 14 days ago
I have been trying to create a secure website with a domain name registered in route 53. I Requested a public certificate so that Amazon CloudFront distributions require HTTPS. I created 2 buckets in s3 and selected on Block all public access. I followed the instructions to create a cloudfront distribution in "Configuring Amazon Route 53 to route traffic to a CloudFront distribution". I created OAC and copied the policy to the bucket policy. I created an alias record that points to my CloudFront distribution.
Can't access the website.
If the Block all public access is set to on for a bucket used for a static website, can the website be accessed by routing traffic to a CloudFront distribution.
Hello,
I am practicing using SAM CLI to make and deploy Lambda functions as APIs. I am running into issues enabling CORS on the API gateway associated with my lambda function. I have tried both configuring CORS in my template.yaml file and going into the API gateway console and enabling CORS manually.
The lambda function is a simple hello world function that takes in 1 parameter which is a name and returns " {name} says hello world!". I have tested the api locally using a react app to invoke the api call and everything works fine. That is not the case for when its deployed to AWS.
Here is my template.yaml file:
```
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: >
apple-app Sample SAM Template for apple-app
# More info about Globals:
Globals:
Function:
Timeout: 3
MemorySize: 128
Resources:
HelloWorldFunction:
Type: AWS::Serverless::Function
Properties:
CodeUri: hello_world/
Handler: app.lambda_handler
Runtime: python3.9
Architectures:
- x86_64
Events:
HelloWorld:
Type: Api
Properties:
Path: /hello
Method: get
RestApiId: !Ref AWS::ApiGateway::RestApi
Cors:
AllowMethods: "'GET, POST'"
AllowHeaders: "'Content-Type,X-Amz-Date,Authorization,X-Api-Key,X-Amz-Security-Token'"
AllowOrigin: "'*'"
Outputs:
HelloWorldApi:
Description: "API Gateway endpoint URL for Prod stage for Hello World function"
Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/Prod/hello/"
HelloWorldFunction:
Description: "Hello World Lambda Function ARN"
Value: !GetAtt HelloWorldFunction.Arn
HelloWorldFunctionIamRole:
Description: "Implicit IAM Role created for Hello World function"
Value: !GetAtt HelloWorldFunctionRole.Arn
```
Am I configuring the implicit HelloWorld api correctly to enable CORS?
Since my configuration with the yaml file didn't work correctly. I tried manually enabling CORS by going into the API gateway console and clicking the button "Enable CORS and replace existing CORS headers". This is the response I get with an error:
✔ Add Access-Control-Allow-Headers, Access-Control-Allow-Methods, Access-Control-Allow-Origin Method Response Headers to OPTIONS method
✔ Add Access-Control-Allow-Headers, Access-Control-Allow-Methods, Access-Control-Allow-Origin Integration Response Header Mappings to OPTIONS method
✖ Add Access-Control-Allow-Origin Method Response Header to GET method
✖ Add Access-Control-Allow-Origin Integration Response Header Mapping to GET method
Your resource has been configured for CORS. If you see any errors in the resulting output above please check the error message and if necessary attempt to execute the failed step manually via the Method Editor.
! The Empty Model does not exist, and retry resource creation without it.
I am not sure what I'm doing wrong, so any help would be greatly appreciated.
Thank you.
This question is related to https://repost.aws/questions/QUGMi_eNmkTB-nVwLdze9eKA/what-are-the-benefits-of-using-amazon-cloud-front-together-with-amazon-api-gateway where REST API Gateway performance benefits were discussed when using along with CloudFront.
What about CloudFront distribution in front of **HTTP API Gateway**. Does it provide the same benefits in terms of performance? As far as I'm concerned this type of API Gateway uses Regional API endpoints. I wonder if I would benefit from a CloudFront distribution pointing to a HTTP API Gateway in a single region?
I use a third-party service to send emails to subscribers. During the email send process, they shorten links for tracking purposes. The issue is that these shortened redirect links point to the "edge server" URL instead of the original Cloudfront URL.
This is causing issues for us since it appears that these direct links cannot be invalidated. In other words, if I change the file on S3 (I also have Cloudfront caching disabled), the Cloudfront URL will show the new file immediately. However, these direct links to the "edge server" do not, they continue to show the old version.
I'm guessing the the email service runs a process to understand the URL that is being served before being shortened, and instead of using the original, it grabs the "edge server" link instead.
Any advice or thoughts? I need to be able to change these files (at times) after the email has been sent and am not able to.
I posted it earlier here, but didn't receive a response: https://stackoverflow.com/questions/75640175/how-to-understand-why-cloudfront-returns-301
I have a distribution in CloudFront pointing to a custom origin. It worked just fine for more than five years and just a few weeks ago started to return 301 for all requests. The origin works as before, SSL certificates are valid both at the CloudFront endpoint and at the origin. The configuration of the "behavior" I didn't change in CloudFront. What could be the problem and how can I understand where is it?
If it helps, here is the URL: https://djk1be5eatcae.cloudfront.net/?u=https://www.yegor256.com/index.html. The origin that it points to is relay.jare.io. Thus, the URL to be used to fetch the content is this: https://relay.jare.io/?u=https://www.yegor256.com/index.html (works for me). All information is public, no sensitive information is revealed.
Hi,
We have been trying to setup our cloud-front distribution to work with a backend origin. The distribution is setup fine but the alternate domain name attached to the distribution is not getting resolved. Here is the sequence of steps followed.
1. Create a cloud front distribution - Configure the backend origin, cache behaviors, etc.
2. Update the cloud front distribution - A custom SSL certificate (not from AWS) is imported into the ACM and attached to the distribution and the same has been used as the alternate domain name for the distribution i.e., the alternate domain name is "myapi-demo.example.com" and my SSL certificate has the SAN entry for the same
3. Create an ALIAS record under "example.com" hosted zone in R53
#3 is not working and tried the following options:
* Created a CNAME as some old articles say to use CNAME. Didn't work
* Created an ALIAS record. Didn't work
* Created a new hosted zone in R53 for "myapi-demo.example.com" and added ALIAS record. Didn't work.
* Created a new hosted zone in R53 for "myapi-demo.example.com" and tried creating a CNAME. Didn't work - failed with error "RRSet of type CNAME with DNS name myapi-demo.example.com. is not permitted at apex in zone "
Record name - "myapi-demo.example.com"
Record value - "d3hui35xh0ym6w.cloudfront.net"
Type - [CNAME] [ALIAS]
Dear Community,
I've got some problems setting up a CloudFront distribution.
It is supposed to deliver an .mp3 stream.
My external non AWS origin is accessible via its Ip and path 12.34.56.789:8001/mystream.mp3
of course I've set up an DNS record to have a domain as origin.
so now it is example.com:8001/mystream.mp3 which works fine without cloudfront.
Now cloudfront works fine to acess the server itself using example.com as the origin and set the port to 8001.
What doesn't work is setting the domain path as "/mystream.mp3"
The Browser is returning a "502 The request could not be satisfied."
Should I use root object instead or is there something I'm missing?
Thank you in advance
Iggy
I have created a Cloudfront distribution for an S3 static site with continuous deployment enabled. I have version 1 code in the S3 bucket which is the origin for the Cloudfront distribution. I have configured staging distribution to receive 10% of the traffic. I deployed version 2 code to the S3 bucket. I expect 10% of the requests to get version 2 and 90% to get version 1, but I get version 2 for all 100% of requests. Is my understanding correct? How can I test the traffic split?