We're building a website editor - like Wix, Webflow etc. Users can create their websites, and choose to deploy them - and add their own custom domain to it.
For example -
An user created a website and wants it to be deployed to https://client1.com
The static files for that entire website is being stored in a subfolder of a bucket called all-sites. This bucket will have subfolders, each one corresponding to a different website.
For example, the bucket all-sites will have these sub-folders -
/client1-site
/client2-site
/client3-site
and each one of these folders will have their static website content/resources -
/client1.com
..index.html
..js/
....script.js
..img/
....img.png
How do I ask users to add A/CNAME records to their domain, that points exactly to these subfolders? Or what should my server's endpoint do to serve all these websites, while loading content for each website independently, also making sure the websites are being served over HTTPS?
Currently I have come up with a couple of approaches, but none of them are good -
Instead of saving files to s3, save it to my server's storage, and return files from the server - which is very easy but will have problems with SSL certificates.
Add a cloudfront distribution for that bucket, and serve sites - https://xyz.cloudfront.net/site-id/index.html etc. But how do I link that to a client's url?
Your CloudFront idea sounds best to me as you would gain some extra advantages, key among them enabling caching on different regions (which might not be advisable if using APIs though).
I guess at this point you would have to ask the customer to add a CNAME record pointing towards his corresponding CloudFront distribution domain name (typically something like XXXXXXXX.cloudfront.net). Hope that helps.
I am not good at DNS configuration. I did some research on this topic. but it seems am unable to find the best way to set up the multiple TXT records using the host as # in my domain DNS configuration. I was able to add aws TXT record but now I am trying to add Facebook and Google domain verification code in the TXT record in a host as #. I added it with DNS configuration but Facebook and Google are not verifying my domain.
I tried added with a meta tag and HTML file but nothing is works well. Is there any suggestion from you folks will appreciate it.
Cloudflare might be an easy way to do this, they support multiple TXT records in the root of the domain, or atleast, I haven't had any problems with it. There are also other alternatives like ClouDNS or deSec.
Almost any DNS provider should support multiple TXT records in #.
I have a Google Cloud Storage bucket mywebsite-static. Due to browser restrictions on max parallel HTTP connections, I would like to create multiple DNS records in such a way that I can access files within this bucket using static.mywebsite.com, static2.mywebsite.com, etc.
The docs recommend adding CNAME records, but the bucket name must match the CNAME. Keeping content in the one bucket saves synchronising/updating multiple buckets when the static content changes, and is also much cleaner than storing multiple copies of the same static content.
Is there any way to create multiple DNS records in order to reach a single storage bucket?
Not with GCS alone. However, using Google Cloud Load Balancing, you could set up a global forwarding rules which all map to a single backend GCS bucket. This will give you an IP address that you can map to as many DNS names as you like. https://cloud.google.com/compute/docs/load-balancing/http/global-forwarding-rules
The Load Balancer is a powerful tool and can also be used to swap out which GCS bucket you're serving from or let you serve some directories dynamically from GCE or other services.
The downsides are that may be overkill for your use case, configuring this is somewhat complicated, and global forwarding rules aren't cheap, but it will get the job done. It might be easier to look into other options to improve your site, such as CSS sprite sheets.
As some of the answers in that thread hint, if you are using HTTP 2.0 the parallel connection issue is not a problem. You can use HTTP 2.0 with GCS, so long as you are accessing it via HTTPS. This means either use https://storage.cloud.google.com/bucket/object, https://bucket.storage.cloud.google.com/object or GCLB+Backend bucket. HTTPS doesn't work with the CNAME as GCS won't have a certificate for that domain.
So i have a senario, where i have an application which can be assigned to any client's domain without doing anything on the application side. Client just adds the Cnames (the long url that is assigned to every Beanstalk app) of the Elastic Beanstalk URL.
So when client goes to www.example1.com they will see the website, similarly when another client goes to www.example2.com they will also see the same website. Now the issue is that i use clean url's without the www. In order to do that i have to Use A records, but Godaddy only let A records to be assigned to IP addresses but in the case of AWS beanstalk. I know you cant assign IP addresses to the Application url as the instances get deleted when scaled, so is there any other solution to this problem?
I have read somewhere that cloudflare can help but have no idea how to use it.
Well i know the question is not related to programming but i can see many similar questions asked over here, so i guess it should be OK.
As always, any help is appreciated. Thankyou :)
Use Route53 with ALIAS.
You can do something manually, but the changes won't be permanent. See here for the full list of options: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-options.html#command-options-general
Create a hosted zone "example1.com." in route53 and create an alias record "example1.com" pointing to the ELB of your environment in this hosted zone.
Now you can give the name servers for your route53 hosted zone to GoDaddy. Let me know if this setup does not work for you.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 3 years ago.
Improve this question
I'm trying to setup forwarding in Amazon Route53. My last DNS service (Nettica) allowed me to route requests to "aws.example.com" to "https://myaccount.signin.aws.amazon.com/console/".
Is this functionality supported by Route53?
How does Nettica achieve this? Does it insert a special A, CNAME, PTR, or TXT record(s)?
I was running into the exact same problem that Saurav described, but I really needed to find a solution that did not require anything other than Route 53 and S3. I created a how-to guide for my blog detailing what I did.
Here is what I came up with.
Objective
Using only the tools available in Amazon S3 and Amazon Route 53, create a URL Redirect that automatically forwards http://url-redirect-example.vivekmchawla.com to the AWS Console sign-in page aliased to "MyAccount", located at https://myaccount.signin.aws.amazon.com/console/ .
This guide will teach you set up URL forwarding to any URL, not just ones from Amazon. You will learn how to set up forwarding to specific folders (like "/console" in my example), and how to change the protocol of the redirect from HTTP to HTTPS (or vice versa).
Step One: Create Your S3 Bucket
Open the S3 management console and click "Create Bucket".
Step Two: Name Your S3 Bucket
Choose a Bucket Name. This step is really important! You must name the bucket EXACTLY the same as the URL you want to set up for forwarding. For this guide, I'll use the name "url-redirect-example.vivekmchawla.com".
Select whatever region works best for you. If you don't know, keep the default.
Don't worry about setting up logging. Just click the "Create" button when you're ready.
Step 3: Enable Static Website Hosting and Specify Routing Rules
In the properties window, open the settings for "Static Website Hosting".
Select the option to "Enable website hosting".
Enter a value for the "Index Document". This object (document) will never be served by S3, and you never have to upload it. Just use any name you want.
Open the settings for "Edit Redirection Rules".
Paste the following XML snippet in its entirety.
<RoutingRules>
<RoutingRule>
<Redirect>
<Protocol>https</Protocol>
<HostName>myaccount.signin.aws.amazon.com</HostName>
<ReplaceKeyPrefixWith>console/</ReplaceKeyPrefixWith>
<HttpRedirectCode>301</HttpRedirectCode>
</Redirect>
</RoutingRule>
</RoutingRules>
If you're curious about what the above XML is doing, visit the AWM Documentation for "Syntax for Specifying Routing Rules". A bonus technique (not covered here) is forwarding to specific pages at the destination host, for example http://redirect-destination.com/console/special-page.html. Read about the <ReplaceKeyWith> element if you need this functionality.
Step 4: Make Note of Your Redirect Bucket's "Endpoint"
Make note of the Static Website Hosting "endpoint" that Amazon automatically created for this bucket. You'll need this for later, so highlight the entire URL, then copy and paste it to notepad.
CAUTION! At this point you can actually click this link to check to see if your Redirection Rules were entered correctly, but be careful! Here's why...
Let's say you entered the wrong value inside the <Hostname> tags in your Redirection Rules. Maybe you accidentally typed myaccount.amazon.com, instead of myaccount.signin.aws.amazon.com. If you click the link to test the Endpoint URL, AWS will happily redirect your browser to the wrong address!
After noticing your mistake, you will probably edit the <Hostname> in your Redirection Rules to fix the error. Unfortunately, when you try to click the link again, you'll most likely end up being redirected back to the wrong address! Even though you fixed the <Hostname> entry, your browser is caching the previous (incorrect!) entry. This happens because we're using an HTTP 301 (permanent) redirect, which browsers like Chrome and Firefox will cache by default.
If you copy and paste the Endpoint URL to a different browser (or clear the cache in your current one), you'll get another chance to see if your updated <Hostname> entry is finally the correct one.
To be safe, if you want to test your Endpoint URL and Redirect Rules, you should open a private browsing session, like "Incognito Mode" in Chrome. Copy, paste, and test the Endpoint URL in Incognito Mode and anything cached will go away once you close the session.
Step 5: Open the Route53 Management Console and Go To the Record Sets for Your Hosted Zone (Domain Name)
Select the Hosted Zone (domain name) that you used when you created your bucket. Since I named my bucket "url-redirect-example.vivekmchawla.com", I'm going to select the vivekmchawla.com Hosted Zone.
Click on the "Go to Record Sets" button.
Step 6: Click the "Create Record Set" Button
Clicking "Create Record Set" will open up the Create Record Set window on the right side of the Route53 Management Console.
Step 7: Create a CNAME Record Set
In the Name field, enter the hostname portion of the URL that you used when naming your S3 bucket. The "hostname portion" of the URL is everything to the LEFT of your Hosted Zone's name. I named my S3 bucket "url-redirect-example.vivekmchawla.com", and my Hosted Zone is "vivekmchawla.com", so the hostname portion I need to enter is "url-redirect-example".
Select "CNAME - Canonical name" for the Type of this Record Set.
For the Value, paste in the Endpoint URL of the S3 bucket we created back in Step 3.
Click the "Create Record Set" button. Assuming there are no errors, you'll now be able to see a new CNAME record in your Hosted Zone's list of Record Sets.
Step 8: Test Your New URL Redirect
Open up a new browser tab and type in the URL that we just set up. For me, that's http://url-redirect-example.vivekmchawla.com. If everything worked right, you should be sent directly to an AWS sign-in page.
Because we used the myaccount.signin.aws.amazon.com alias as our redirect's destination URL, Amazon knows exactly which account we're trying to access, and takes us directly there. This can be very handy if you want to give a short, clean, branded AWS login link to employees or contractors.
Conclusions
I personally love the various AWS services, but if you've decided to migrate DNS management to Amazon Route 53, the lack of easy URL forwarding can be frustrating. I hope this guide helped make setting up URL forwarding for your Hosted Zones a bit easier.
If you'd like to learn more, please take a look at the following pages from the AWS Documentation site.
Example: Setting Up a Static Website Using a Custom Domain
Configure a Bucket for Website Hosting
Creating a Domain that Uses Route 53
Creating, Changing, and Deleting Resource Records
The AWS support pointed a simpler solution. It's basically the same idea proposed by #Vivek M. Chawla, with a more simple implementation.
AWS S3:
Create a Bucket named with your full domain, like aws.example.com
On the bucket properties, select Redirect all requests to another host name and enter your URL:
https://myaccount.signin.aws.amazon.com/console/
AWS Route53:
Create a record set type A. Change Alias to Yes. Click on Alias
Target field and select the S3 bucket you created in the previous
step.
Reference: How to redirect domains using Amazon Web Services
AWS official documentation: Is there a way to redirect a domain to another domain using Amazon Route 53?
I was able to use nginx to handle the 301 redirect to the aws signin page.
Go to your nginx conf folder (in my case it's /etc/nginx/sites-available in which I create a symlink to /etc/nginx/sites-enabled for the enabled conf files).
Then add a redirect path
server {
listen 80;
server_name aws.example.com;
return 301 https://myaccount.signin.aws.amazon.com/console;
}
If you are using nginx, you will most likely have additional server blocks (virtualhosts in apache terminology) to handle your zone apex (example.com) or however you have it setup. Make sure that you have one of them set to be your default server.
server {
listen 80 default_server;
server_name example.com;
# rest of config ...
}
In Route 53, add an A record for aws.example.com and set the value to the same IP used for your zone apex.
Update
While my original answer below is still valid and might be helpful to understand the cause for DNS based URL forwarding not being available via Amazon Route 53 out of the box, I highly recommend checking out Vivek M. Chawla's utterly smart indirect solution via the meanwhile introduced Amazon S3 Support for Website Redirects and achieving a self contained server less and thus free solution within AWS only like so.
Implementing an automated solution to generate such redirects is left as an exercise for the reader, but please pay tribute to Vivek's epic answer by publishing your solution ;)
Original Answer
Nettica must be running a custom redirection solution for this, here is the problem:
You could create a CNAME alias like aws.example.com for myaccount.signin.aws.amazon.com, however, DNS provides no official support for aliasing a subdirectory like console in this example.
It's a pity that AWS doesn't appear to simply do this by default when hitting https://myaccount.signin.aws.amazon.com/ (I just tried), because it would solve you problem right away and make a lot of sense in the first place; besides, it should be pretty easy to configure on their end.
For that reason a few DNS providers have apparently implemented a custom solution to allow redirects to subdirectories; I venture the guess that they are basically facilitating a CNAME alias for a domain of their own and are redirecting again from there to the final destination via an immediate HTTP 3xx Redirection.
So to achieve the same result, you'd need to have a HTTP service running performing these redirects, which is not the simple solution one would hope for of course. Maybe/Hopefully someone can come up with a smarter approach still though.
If you're still having issues with the simple approach, creating an empty bucket then Redirect all requests to another host name under Static web hosting in properties via the console. Ensure that you have set 2 A records in route53, one for final-destination.com and one for redirect-to.final-destination.com. The settings for each of these will be identical, but the name will be different so it matches the names that you set for your buckets / URLs.