When I try to setup a domain through serverless-domain-manager with sls create_domain, it fails with:
BadRequestException: The domain name you provided is already associated with an existing CloudFront distribution.
Remove the domain name from the existing CloudFront distribution or use a different domain name.
If you own this domain name and are not using it on an existing CloudFront distribution, please contact support. api.example.com was not created.
I tracked down the line where the library fails.
Note that my account does not have anything in CloudFront. This is what I see when I open it:
It's also interesting that in Certificate Manager, it says that the certificate is in use:
Under Associated Resources I can see an entry for cloudfront: arn:aws:cloudfront:: ...
Thanx to Matt's guidance I found what caused the phantom CloudFront distros. Within the AWS console, go to:
Amazon API Gateway > Custom Domain Names
Delete all the conflicting domains there and redo the deployment steps again.
When you create an API Gateway, it will create an underlying CloudFront distribution on your behalf. You may not see it in your AWS account, but it's there.
Also, domains used for CloudFront distributions must be globally unique. Which means that if someone else already has a CloudFront distribution for api.example.com, then you cannot use it as well.
So, you already said that you do not have an existing CloudFront distribution visible in your AWS account.
If you already have an API Gateway for api.example.com, then you cannot create a second one. If this is the case, you need to use a different domain, or delete the original one.
If you don't have an API Gateway for that domain, then someone else probably already has one. If this is the case, then you'll need to use a different domain.
Here's how I've encountered and solved this problem:
Created a serverless app and ran sls create_domain
Too late did I notice that my region was the wrong one in serverless.yml
Manually deleted the CloudFormation stack from AWS, plus the Route53 records.
Changed the region, tried to create_domain again, got the error - although I've deleted everything
Ran sls delete_domain - this threw an error as well, but apparently cleaned up some "hidden" AWS stuff
Ran sls create_domain again. Voila, worked.
The "phantom" cloudfront distro isn't visible because it's in an account owned by AWS itself and used for deploying distros used by Edge-optimized instances of API gateway.
As #Daniel mentioned in his answer above, delete any custom domain names associated with the certificate in the console, but if they aren't visible (if they were already deleted, for example), try deleting them using the AWS CLI, since it appears to do a better job of fully cleaning up the links to those AWS Cloudfront distros:
aws apigateway delete-domain-name --region "<INSERT REGION>" --domain-name "<INSERT DOMAIN NAME>"
As #CGreg encountered with the sls_delete_domain command, you may encounter errors. I was trying to delete an old certificate in ACM that was associated with one of these distros via a custom domain name which I'd already deleted. I ran the above command twice per custom domain name (in any region I thought I might have originally deployed to). The first time I got a "domain name not found" error and the second time I got an "operation timed out: max retries" error, but the association to the Cloudfront distribution was removed and I was able to delete the old cert 👍🏻
Not sure if just once would do it, but since I got different error responses something different must have been happening under the hood, so no harm trying it!
Related
I am trying to delete an AWS cert. In the ACM dashboard it states that is is still associated to a CloudFront distribution - therefore it will not let me delete it. The CloudFront distribution it states that it is associated with has been deleted for days and no longer exists.
I did a search and the only thing I have found so for is AWS telling me to delete a custom domain name for an API Gateway that might have been generated for this CF distro. I never set one up and if I look in the API gateway dashboard there are not even any API gateways there.
Any help on getting this cert deleted or disassociated with the non existent CF distribution?
I have a domain connected to AWS ec2(www.example.com) it works fine but when
I tried to create a subdomain(test.example.com) that point to the same ec2 as the parent domain I create an A record for the subdomain still gets 403 forbidden
Check your user permission at https://console.aws.amazon.com/iam/home#/users/<your-aws-username>. You must have one of the policies below attached to your account:
AmazonRoute53AutoNamingFullAccess
AmazonRoute53AutoNamingRegistrantAccess
AmazonRoute53DomainsFullAccess
AmazonRoute53FullAccess
If you don't have permission to attach one of these policies to your account, ask your administrator to do that.
I was facing this issue for a slightly different case but the reason of the problem was probably the same. After fixing my problem, i reproduced your case as well.
It may be because of the cloud front that you are using.
You may need to add all the URLs that you are going.
please check you have provided a value for CNAME in Cloud front distribution settings. (in your case you need to add two records there. One for main domain example.com and other for test.example.com).
Without this setting, cloud front distribution cannot be accessed via new "A record".
if you have HTTPS access then your certificate must cover the subdomain. and maybe that is why the cloud front needs this setting here( To check it against the certificate).
I have set up an S3 bucket to reroute all traffic to example.com to www.example.com with https according to this very poor AWS guide. It works for example.com and http://example.com.
But when I access https://example.com it hangs for a little while and then routes to a blank page. Why is it so difficult to redirect a URL I own to another one in AWS and how do I fix this?
Edit:
I am now configuring CloudFront distributions and trying to find one decent tutorial explaining how to perform this seemingly simple task.
Did you miss this line in the link you provided:
Note: The sites must use HTTP, because the redirect can't connect to Amazon S3 over HTTPS.
You are trying to do something that is expliciting called out as not being possible in the docs.
BTW: If you want to use https to service static s3 websites, using cloudfront if often the easiest and quickest way to do that.
https://aws.amazon.com/premiumsupport/knowledge-center/cloudfront-https-requests-s3/
So I finally figured this out and I am going to describe here what worked for me. E.J.'s answer above was a helpful pointer but wasn't specific enough to make this the absolutely trivial task I would hope this to be, even for a first-timer.
Here are the exact steps required, with some prior notes.
Two notes:
You HAVE to setup an SSL certificate with AWS to re-route after https. As an organisation AWS has not yet reached the place where automatic certificate management is... well... automatic. You have to use what I might call AWS "Extremely Manual" ACM.
You need an AWS S3 bucket (make it have the name of the domain your are routing FROM).
Steps:
Follow this guide to setup a S3 bucket that will route (without HTTPs) from example.com to www.example.com (or vice versa I guess)
Navigate to the absolute eye-sore that is Amazon CloudFront
Click everywhere until you find a button to "create distribution"
Set "Origin Domain Name" to the link for the bucket created in step 1. DO NOT use the one AWS recommends, you have to go to the bucket and copy the end-point manually, the one AWS fills-in automatically will not work. It should look like this: example.com.s3-website-eu-west-1.amazonaws.com but location and stuff will be different obviously. Not sure why AWS recommends the wrong end-point but that is the least of my concerns about this process.
This guide works for the rest of the CloudFront distribution creation but is not super specific and points to this mess at one important part. The other steps are okay but when creating an SSL certificate just click that "Request or Import a Certificate with ACM" button (you will have to refresh after creating a certificate because Ajax didn't exist when the AWS console was made 200 years ago)
And the most important step, take the link or whatever it is to your CloudFront distribution (which will look like this: d328r8fyg.cloudfront.net, this one is fake because apparently you're not supposed to share them), and make the A record for example.com created in step 1 point to that CF distro instead of pointing directly to your bucket.
And voila, only took about 3 hours to get a URL to redirect somewhere securely. Not sure why people expect us to make it to Mars when the largest company in the world can't point one url to another and Microsoft Image Editor still can't crop to a specific pixel dimension.
Anyway. I'm glad this is over.
I have tried several tutorials on how to set up https via CloudFront, but nothing is working. I am hosting from an S3 bucket and the app works fine via the http protocol, but I need it to be https.
Does anyone have a very thorough tutorial on how to make this work?
Some tutorials explain how to go about setting up a certificate, some explain how to use CloudFront to handle its distribution and I even found a CloudFront tutorial that explains how not using a link from the CloudFront setup forces the wrong region to be created for a certificate, so I even tried that.
I have not found anything that explains exactly what needs to be done for this very common setup, so I am hoping that someone here has some helpful resources.
I think the main issue I had when setting up a CloudFront distribution for an S3 static webhosting bucket was in the Orign Domain Name.
When you create a new distribution, under Origin Settings, the Origin Domain Name field works as a drop-down menu and lists your buckets. Except that picking a bucket from that list doesn't work for static webhosting. You need to specifically put the endpoint for the bucket there, for example:
mywebhostingbucket.com.s3-website-sa-east-1.amazonaws.com
And for custom domains, you must set up the CNAMEs under Distribution Settings, Alternate Domain Names (CNAMEs), and then make sure you have your custom SSL certificate in the us-east-1 region.
Then you can configure the alias record set for the CloudFront distribution.
Here is a complete answer for setting up a site with https.
I had everything in this document completed:
https://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html
And it worked to get the site live via http, but in order to add https, I needed to do the following:
I had requested a certificate for whatever.com, and tried several suggestions after that. But there were a couple of things missing.
To route traffic for the domain (whatever.com) to CloudFront distribution, you will need to clear the current value of the A record and fill in distribution domain name.
Several documents that I viewed said to point the whatever.com S3 bucket to the www.whatever.com S3 bucket, and use the second one to drive the site. Since CloudFront can serve multiple domain name, you may set CNAME of distribution with both, but you will need to set A record for both to distribution AND request an ACM certificate with both domain names (with and without the www). Also, I did ask this, so if you already have a certificate, you can't edit it to do this, which means you'll need to request a new one that has both whatever.com and www.whatever.com
After all of this, I still got "Access Denied" when I went to my site, so to fix this issue, I had to create a new origin in CloudFront with 'Origin Domain Name' set to the full address of the S3 bucket (without the http), and then set the Default (*) Behavior to the S3-Website-.....whatever.com bucket.
After all of this, my site was accessible via http AND https. I hope this helps anyone who experienced this challenge.
I just recently moved my domain name from a hosting provider to Amazon. I want to host my website using S3 buckets and I originally I tried to set up my buckets to be domain.com and www.domain.com but I think my previous hosting provider took these bucket names because I cannot create them.
So I am looking at a work around now ...
- created a new bucket with a unique name and put my website files in it
- I set up Cloud Front to pull the files from that bucket
- and lastly a Route 53 hosted zone with the CNAMES for domain.com and www.domain.com pointing to that Cloud Front.
Here is where my problem comes in. I cannot add www.domain.com to my CNAMEs in the Cloud Front. I get the following error:
com.amazonaws.services.cloudfront.model.CNAMEAlreadyExistsException: One or more of the CNAMEs you provided are already associated with a different resource. (Service: AmazonCloudFront; Status Code: 409; Error Code: CNAMEAlreadyExists; Request ID: 19a9a141-8b15-11e6-aa8f-87e12f4b3abf)
However, it does accept domain.com ... so when I visit domain.com I get the proper website, but when I visit www.domain.com I get the old website.
I think it is due to the fact that I can't add that CNAME in my Cloud Front. How can I fix this error?
Thank you
You cannot add an alternate domain name to a CloudFront distribution if the alternate domain name already exists in another CloudFront distribution, even if your AWS account owns the other distribution.
http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#alternate-domain-names-restrictions
This is the condition that would cause the error you're seeing. If you already have another CloudFront distribution configured with this, then clearly that needs to be removed and then this would work.
Otherwise, the old provider may still have your domain configured on one of their CloudFront distributions -- so you need to persuade them to remove it, or you'll need to have AWS support assist you. If the domain is already configured in CloudFront on another account, this can't be fixed by your actions alone.
AWS Support has a special process for handling exactly this situation: https://aws.amazon.com/premiumsupport/knowledge-center/resolve-cnamealreadyexists-error/
In case any of you guys have been playing with Zappa and/or AWS API Gateway before and CNAMEAlreadyExistsException occurred.
Just make sure with AWS CLI that domain you want to use isn't listed in AWS API Gateway anymore like this:
aws apigateway get-domain-names
In case you find it listed there:
aws apigateway delete-domain-name --domain-name <your-domain>
This fixed the issue for me. Piece!
BTW, I didn't find a way to list it or delete it through Web, just AWS API Gateway welcoming screens everywhere.
In my case I forgot I deployed an app using AWS Amplify in the past using the CNAMEs I wanted to use.
This is why I could not find the Cloudfront distribution on the Cloudfront console. Check to see if you have an AWS Amplify app using the desired names.