I already have a certificate from AWS Certificate Manager (ACM) when only the 1 region was available (think the US-West-1 region?) and currently being used with Cloudfront to host a website for the Australian market.
Now that ACM is available in more regions, would using a certificate created from the Sydney region have any improvements in performance?
ACM now supports multiple regions, but that doesn't have any implications for certificates for use with CloudFront.
To use an ACM certificate with Amazon CloudFront, you must request or import the certificate in the US East (N. Virginia) region. ACM certificates in this region that are associated with a CloudFront distribution are distributed to all the geographic locations configured for that distribution.
https://docs.aws.amazon.com/acm/latest/userguide/acm-regions.html
The reason for this is that CloudFront, unlike most AWS services, where the regional implementation of the service is independent of all other regions, has all of its provisioning/administrative infrastructure based in us-east-1.
The operational infrastructure is globally distributed and independent, so the centralized management of CloudFront doesn't have performance implications. If you have performance issues, those should be investigated separately.
The announcement of new regions for ACM doesn't apply to CloudFront. It's applicable to the other service integrated with ACM, Elastic Load Balancer, which previously only supported ACM certificates in us-east-1 because that was the only region in which they were available, and ELB regions are fully independent of each other.
Follow-up: This answer was reviewed in May, 2018, two years after it was originally posted, and then again in the summer of 2020. It is still accurate, as written. Certificates for CloudFront (as well as for Edge-Optimized deployments in API Gateway, which have a somewhat hidden dependency on CloudFront) are always provisioned in the us-east-1 region of ACM. There is no compelling reason to expect this to change, as CloudFront's control plane runs in us-east-1.
Related
I made an application in an AWS region different than us-east-1. I already applied for and received an SSL certificate for a custom domain, and it is stored as ACM Certificate in a region differenet than us-east-1.
To my surprise, when I tried to use this certificate on CloudFront, I was met with this:
"Associate a certificate from AWS Certificate Manager. The certificate must be in the US East (N. Virginia) Region (us-east-1)."
A quick search informed me that:
"You can't export an ACM certificate from one AWS Region to another or from one AWS account to another. This is because the default AWS Key Management Service (AWS KMS) key used to encrypt the private key of the certificate is unique for each AWS Region and AWS account.
Resolution: You can create multiple ACM certificates with the same domain name across different AWS Regions and accounts. "
How do I solve this, can I just request a new ACM certificate for a new region (ie. us-east-1)? Will this impact my certificate that is already in use for the original region?
Yes, you need to provision the same certificate (for a given domain) in US-EAST-1 region and use it for your global CloudFront distribution. Your regional certificate (outside the global region) will not be impacted. Usually, regional certificates are attached to your ALB and Cloudfront distribution utilizes a certificate from North Virginia region (global region).
I am creating a Cloud Front distribution in AWS. I have a ELB created in Hong Kong region.
When I am selecting Origin Domain, My ELB in Hong Kong region is not coming in drop down. While, I tried with creating ELB in N.Virginia region and it is visible.
Is there any such restrictions imposed by AWS or I am doing something wrong?
I replicated the setup you described in my own AWS account and it happened there as well: The ELB did not show up in the Origin list. While I am not sure why this is the case, an easy workaround for you is to just manually enter the ELB's DNS name as the Origin. My test ELB had the DNS record test-1224452099.ap-east-1.elb.amazonaws.com, so I put http://test-1224452099.ap-east-1.elb.amazonaws.com as the Origin for my CloudFront Distribution. That worked. For production use, above URL should of course be HTTPS, not HTTP.
Please note: You might have to edit the rules of the ELB's security group if the ELB is not reachable from CloudFront. You can use a managed prefix list for this: https://aws.amazon.com/about-aws/whats-new/2022/02/amazon-cloudfront-managed-prefix-list/
Imagine if your CloudFront Origin is on your on-premise data center https://mydatacenter.example.com this should normally will not appear in the CF Origin list but it should work as long as the website is publicly accessible.
I am stuck on a possible implementation for a problem I am facing in AWS.
I have multiple websites that are hosted with S3 using CloudFront in us-east-1. If there is an outage in that region, I want to reroute traffic from those UIs to a website hosted with S3 using CloudFront in another region (just a basic error page, all UIs from us-east-1 need to be rerouted to the same one error page in the new region).
After doing research, I am seeing a lot of documentation for Route 53 DNS Failover handling. However, we don't use Route 53 for traffic routing, so I don't think these solutions apply for this particular problem. Does anyone have any advice on possible solutions?
Using CloudFront's Origin Groups feature, you can group the two S3 endpoints and configure the criteria for when CloudFront should failover to the secondary origin (e.g., 500-504 error). When you create your cache behavior, you'll use the Origin Group as your origin. Details: Optimizing high availability with CloudFront origin failover
The majority of my website traffic is from North America and the UK. Is it possible to "simply" use AWS Route 53 with GeoLocation routing instead of using a CDN? What I envision is deploying my app on an ELB in both North America and the UK and then have a GeoLocation routing policy in Route 53 which sends traffic to the appropriate ELB. The reasons I'd do this are to avoid the CloudFront CDN costs for a $600/month dedicated SSL... sort of a poor mans CDN.
I'd love to hear from others if this is possible, and effective.
I believe you will like one of the products that was recently added to the AWS catalog. With the AWS Global Accelerator you get a single IP address, and your traffic will be routed to the optimal region depending on user's location, but also on service health.
And of course you can always use the generic cloudfront domain for SSL, or a custom domain for SSL using SNI and that would be for free. You only need to pay $600 if you want a custom domain with a dedicated IP, so no SNI. Given the status of SNI support, it might be the case it's good enough for your user base.
As of late 2021, AWS Route 53's Geolocation Routing feature supports this use case...
Geolocation routing lets you choose the resources that serve your traffic based on the geographic location of your users, meaning the location that DNS queries originate from. For example, you might want all queries from Europe to be routed to an ELB load balancer in the Frankfurt region.
Recently AWS had a biggest outage with S3 on US-east-1. We would like to expand to multiple regions now deploying lambda and S3 data to other regions. I would like to retain one single url that can detect if the region has an outage and forward the call to the active region. If both regions are active, closest region will receive the request.
I tried with AWS Route53 and it did not help with https. Since Cloudfront cannot accept the same cname on more than one distribution.