We have two VPCs one in US and the other in Europe. Each VPC has a load balancer in public subnets and we run our web application in private subnets. What we want is, if a user visits our website (makes a request to our host/domain) the request gets redirected to European VPC if the user is from Europe region and to US VPC if the user requests from US.
Route53 can help you with this
Route53 Geo Routing this allows DNS to return different values depending on the place that the DNS request was made from. See the "Geo Routing" section of this blog post for a good summary https://aws.amazon.com/blogs/aws/route-53-domain-reg-geo-route-price-drop/
You should also look at AWS CloudFront CDN. This can move static content to a global service that is based near your customer. So when a customer in for example Australia asks for static files (for example js or css) then these files are actually served from an endpoint in Australia. You don't have to set up any of the end points you just put the files in an S3 bucket
Related
So, I've created a website xxxxxxx.com (removing from post)
I registered it with Route 53.
Registered Domain - Established Hosted Zone
Established 2 Record Sets one of xxxxxxxx.com and one for www.xxxxxx.com
Record Set Details for one of the paths
But when I go to ping www.xxxxxxxx.com or xxxxxxxx.com - I don't get a response.
When I go to a DNS checker site - it fails all DNS servers.
I've been all over the place trying to get this to work, concerningly, it did work at one time, but then failed. I have deleted the hosted zone twice and rebuilt it. I have NOT touched the named servers.
S3:
setup 2 buckets, named appropriately. xxxxxxxx.com and www.xxxxxxxx.com
Both have two files on them. Block public is unchecked.
Static Web hosting is enabled.
Selected both files and set to Actions --> Make Public
Testing on their own with these addresses:
**edited - I had to remove the direct S3 Web hosting as once posted here they got hammered with hits.
I did try one other thing:
Route 53 --> Traffic Policies --> Create Traffic Policy -->
DNS Type a: IP address in IPv4 format to Endpoint Type S3 website endpoint Value xxxxxxxx.com.s3-website-us-east-2....
This does not appear to have rectified the situation, unfortunately. And they want to charge $10 a month to direct it with www. prefix - which doesn't make any kind of sense, so I didn't do that.
Any advice or help that can be rendered would be helpful! I've covered most of the ground with Amazon and videos setting up domain to S3 to no avail.
Something seems off with your DNS records: https://www.whatsmydns.net/#NS/fojsan.com
Domain registered 2 days ago, should have NS listed in all regions. Leave the S3 for the time being and focus here. If DNS record can not resolve , S3 will not work.
Make sure that DNS entry for NS (name Servers) is set to:
ns-1145.awsdns-15.org.
ns-1694.awsdns-19.co.uk.
ns-20.awsdns-02.com.
ns-576.awsdns-08.net.
It looks like it might have been removed and are expiring.
I have a multiple sites for various location like UK,BE,US etc... If i use the US site it need to be hit only US region server only. Like wise UK means UK server etc.. Is this possible to achieve using AWS server.
What I think you need is Geolocation routing. The AWS documentation for this is found here.
En excerpt from this page is:
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.
Can we use CloudFront with Geolocation policy or does CloudFront internally have this feature and can be used alone to satisfy? Or Route53 is a correct option while having the requirement to serve requests from the nearest geo-location for a global website to improve the customer experience.
Also, I am not clear whether we can use both CloudFront with Route53 together or not?
Thanks.
Both cloudfront and Route53 have different purpose.Route 53 is a DNS service whereas Cloudfront is CDN service to serve static (and dynamic) content.
You can use the cloudfront with Route 53 Geolocation Routing. But the location wise content delivery is already enabled in cloudfront, so geolocation policy wont help that much. If you are not using cloudfront and you want to distribute traffic based on user location, then you can use Route53 geolocation policy to route traffic to the nearest app server though ELB (elastic load balancer).For example, you might want all queries from Europe to be routed to an ELB load balancer in the Frankfurt region. So here you are deciding which server is going to serve the traffic from specific region. But in case of cloudfront, it caches the content at the nearest data center ( edge location), when the first request is hit. And next request from that region are automatically served through that edge location.
Cloudfront: It is a web service that speeds up distribution of your static and dynamic web content, such as .html, .css, .js, and image files, to your users. The content is cached at edge location (data center). In cloudfront you specify the distribution from where the content needs to be server.
Route 53: Its a DNS service which provide translation of your easily remember DNS name (like google.com) into more complex server name serving the actual content.
You can use cloudfront and Route53 together by creating alias record in route 53 which points to your cloudfront distribution.
Yes, You can use Route53 along with CloudFront for the best results with Alias records (When you purchase your domain with AWS only if you purchased it from outside AWS then you can directly configured/add your CloudFront details there as in this case adding Route53 will increase the number of ip visits. Read More here).
CloudFront will distribute your content over 100+ edge location which will decrease your response time with low latency and save your cost as well. It will deliver the content from the nearest location.
Route53 will manage your DNS things.
CloudFront is more than enough for the delivery of content from the nearest edge location. It will also help you to copy data to multiple edge locations as well.
It's like Content Delivery Network(CloudFront) + DNS(Route53).
Read this for good understanding.
When you create a web distribution, you specify where CloudFront sends requests for the files that it distributes to edge locations. CloudFront supports using Amazon S3 buckets and HTTP servers (for example, web servers) as origins.
Route53 is a DNS service and is an origin for data. The term Origin is a term for where the original data resides before it is cached in the CDN (CloudFront).
So currently we have two ec2 instances (lets say A and B) and a cloudfront.
If the user goes to www.appdomain.com/app the user should get routed to the cloudfront SPA page. However if the user goes www.appdomain.com the user should be routed to the EC2 instance A, and if user goes to www.appdomain.com/api be routed to EC2 instance B.
All of these applications must be on the same domain.
Now we found out how to set path rules using an application load balancer, but would like to know how to set it to cloudfront as well.
Update:
So in summary the question is how do we route /app to cloudfront / and /api to ec2.
All of these applications must be on the same domain.
In this scenario, every request for that domain must pass through CloudFront first.
Your DNS record will need to point to CloudFront (not the ALB) and CloudFront is then responsible for routing the request to the appropriate target -- to an EC2 instance via an ALB, to an S3 bucket, to wherever you need the requests to go -- and each of these things is called a content origin.
Once the origins are specified by their individual domain name (not your site's domain name, but a domain name specifically for the resource in question), you define CloudFront path patterns to select which origin is to receive the request for each pattern (e.g. /api*).
Once your DNS is changed to point to CloudFront, all requests go there first, and are handed off to the next service, unless CloudFront has a cached copy of the requested object -- in which case, CloudFront will serve it from its cache, and nothing will be sent to the origin.
You can't route from ALB to CloudFront, but you can route from CloudFront to ALB.
You can't subdivide a domain into multiple, different path-based content origins without using a reverse proxy that is able to match the paths and fetch the content on behalf of the requester -- HTTP and DNS don't support such functionality. CloudFront, in addition to providing the CDN service, is also a reverse proxy.
ALB, of course, is also a reverse proxy, but does not support as many different types of content origins as CloudFront does -- ALB only supports EC2 instances, servers in your data center (in which case, ALB must have a VPN path in order to reach them), and Lambda functions as content origins. CloudFront can use literally anything as a content origin as long as it speaks HTTP/HTTPS and is accessible via the Internet. (To choose a somewhat random example, CloudFront can even use a service from another vendor -- like a Google Cloud Storage bucket -- as a content origin, if that was something you needed to do, for whatever reason... because these are accessible via HTTP across the public Internet.)
I have hosted a static website on S3 with suitable bucket policy set. Viewing the "endpoint" in another tab works perfectly fine. After this I created a Hosted zone in route 53 to give it a desirable human readable address.
After creating the hosted zone, I have two records in my newly created hosted zone, One being of type NS and the other being of type SOA. So far so good. I go ahead to create a new record set.
I add the name as desired, enter type as 'A' - IPv4 Address tick yes for Alias, where in the drop down (Alias Target) i can see my previously created bucket endpoint.
I set the routing policy to be simple and Evaluate Health Target set to no. The record set is created successfully. However when i enter this name in another tab, I get the "Site can't be reached". I try and test the record set using the functionality provided by AWS. Here the response code i get is "NOERROR" which i assume is a positive response. Am I missing something here.
I have also referred to this video. Am I missing something. Also, I have not created the Hosted Zones myself.
A hosted zone is not the same as domain. You have to update the NS values for your domain registrar to point to the NS values as generated by Route53.
From the docs:
When you create a hosted zone, Amazon Route 53 automatically creates a
name server (NS) record and a start of authority (SOA) record for
the zone. The NS record identifies the four name servers that you give
to your registrar or your DNS service so that DNS queries are routed
to Amazon Route 53 name servers.
[...]
After you update the settings with your domain registrar to include
the Amazon Route 53 name servers, Amazon Route 53 responds to DNS
queries for the hosted zone even if you don't have a functioning
website.
NS transfer may take from 1 to 24 hours, depending on the registrar.
I faced the same issue. I bought domain thevegfoodies.com through AWS Route 53, created simple index.html page and uploaded to bucket thevegfoodies.com and set bucket for Static website hosting ,added public policy. created second bucket www.thevegfoodies.com and redirect to thevegfoodies.com, created aliases everything , read through documents everything. But nothing worked.
Until, i realized that my redirect bucket www.thevegfoodies.com was not set for public read access. I set it too Read bucket permissions for Everyone. (Note my primary bucket thevegfoodies.com already has public access.) and i could load my website using my domain name.
Now, I have read through AWS document again just to see if I missed this step of setting up public access for redirection bucket.
https://docs.aws.amazon.com/AmazonS3/latest/dev/website-hosting-custom-domain-walkthrough.html and all other steps to setup static website.
if you check Step 2.3: Configure Your Website Redirect, it is not mention that we need to set public access.
POINT- AWS Documentation is not clear. One need to have public access to redirect bucket too.