I have a external domain which I want to use for a static website on aws.
I found a couple of examples using S3 + CloudFront + Route 53
But is it possible to keep the name server of my domain and work with the external nameserver? (No Route 53?)
Yes, it is possible, Route53 isn't mandatory to use CloudFront and S3. You can have CNAME configured in your DNS provider. However, there is a RFC limitation on CNAME restriction for naked/apex domain(as you cannot have a CNAME record and another DNS record of a different type) so Route53 provides an alternate record called alias record, as long as your DNS provider provides this feature, you're good to go. e.g: CloudFlare provides CNAME flattening
https://support.cloudflare.com/hc/en-us/articles/200169056-Understand-and-configure-CNAME-Flattening
Amazon Route53 alias:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html
Related
I have a handful of domains registered for brand protection reasons that are currently managed in a rather manual registrar, but it currently handles redirection to the main domain.
I am moving DNS from this provider over to Route53 using Terraform. I'm setting up a redirector for the brand protection domains using S3, but running into a catch-22:
If I want a single S3 bucket to handle the redirects I need to put CloudFront in front of it, which means I need an SSL cert valid for the various domains, which means I need DNS to already be in Route53 for the validation.
If I want to avoid breaking the redirects during this migration, I can't move the DNS until the redirector is in place.
This means I think I have the following options:
Migrate the domains into Route53 first, then create the CloudFront distribution. Redirects will break until this is complete.
Create multiple S3 buckets for each domain, which won't cover wildcard domains (e.g. *.aliasdomain.com), but can at least do the apex and www for instance (and http only).
Manually create the necessary certificate and import it into Terraform.
Have I missed an obvious alternative? Ideally I would create a single redirector that would handle all http traffic to begin with, then sort out https later.
I'm confused about this for a while.
I have an API application hosted on ECS and an ALB with a target of this ECS.
I need to setup Cognito for ALB but the ALB needs to be SSL-ed.
I also how a primary domain registered on a different DNS (not R53).
The AWS documentation says that there are two ways to route traffic to a LB. With CNAME or Alias record set.
My questions are:
Do I need a primary domain on R53 to create an alias record set for ALB? Do I need a registered domain at all or will alias automatically create a free one (since AWS says that alias is free)?
Can I create a subdomain CNAME on R53 of a primary domain hosted on another DNS?
Will I be able to pass paths from my alias or cname to the ALB, example:
If I enter a path in my ALB amazon given DNS name like this: "{DNS-ALB-name}.amazon.com/api/path1 this will GET that from the API application.
but if I have an Alias or CNAME how can i pass {CNAME-domain}.com/api/apth1 or {alias-domain}.com/api/path1 to the ALB domain which will in the end pass that path to API. Or do I need some sort of revers proxy server?
Can I SSL an alias record set?
Can I integrated a primary domain from another DNS to AWS R53 ss it is as if R53 has that TLD?
you need to either migrate the domain to Route53 or delegate it
if I understand your questions correctly - yes
assuming that I understand your questions correctly: the path and domain names do are separate things, unless you redirect. in this case CNAME will simply point the request at the load balancer, so domain does not actually matter
SSL is added to a resource such as load balancer ot ec2 server, not DNS entry. Once you create an alias and point it at e.g. application load balancer, you will be able to add certificate to it. it integrates well with AWS Certificate Manager
that's called DNS delegation, and yes it is possible
I bought a domain (xyz.com) from some domain provider.
I pointed its nameserver to Cloudflare to host dns.
I created an S3 bucket with name (xyz.com) and hosted my static website on it.
I added a CNAME record on cloudflare to point to the static website url of bucket.
Everything is working fine till here. (xyz.com) opens the static website hosted on S3 bucket.
Now I want to create (api.xyz.com) for AWS API Gateway custom domain.
I want API Gateway to trigger Lambda so that it computes and return back the result.
For above I added another CNAME record in cloudflare so that AWS ACM is able to issue me a certificate for (api.xyz.com). After few minutes ACM was able to issue me a certificate.
Now I added the custom domain in API Gateway and selected the above ACM certificate.
When I make http GET call to my api chrome shows:
This site can’t be reached
api.xyz.com’s server IP address could not be found.
DNS_PROBE_FINISHED_NXDOMAIN
How to fix this?
I am a beginner and maybe I am using some terms wrong. Please Ignore
Create a CNAME record to your api gateway and make sure you hit it using https
I am developing a SaaS web application (https://mywebsite.example) which will be hosted in AWS and will have subdomains for individual customers like https://customer1.mywebsite.example , https://customer2.mywebsite.example.
As a second step I would like to introduce custom domain names and map it with the subdomains of mywebsite.com through cname records
https://customer1.example --> https://customer1.mywebsite.example
Here is what I have analysed till now.
Using Certificates in AWS loadbalancer for the custom domains as a SAN in the certificate. However the AWS Loadbalancer certificate limits are lesser than the number of customers I am expecting to add.
CloudFlare DNS setup for mywebsite.example and its subdomains, with ssl certificates configured in cloudflare. However Cloudflare allows thirdparty (custom domain) cname redirections only in the Enterprise Plan.
Are there any other alternative service or are there is an alternate way of achieving this use case?
it seems that this solution available in AWS EC2 marketplace should solve your problem
You can try, there is some trial available, called Kilo SSL
https://aws.amazon.com/marketplace/pp/prodview-nedlvgpke4hdk?sr=0-1&ref_=beagle&applicationId=AWSMPContessa
Also it is possible to map your customer's domains to your saas. Algorithm is:
you create EC2 instance. Allocate and associate public IP to it
create domain name which points to this instance. You will use this domain name as CNAME when pointing your own subdomains in your DNS provider (but there is limit of 50 certificates per week per one domain, so you can create only 50 domains like customer1.yourdomain.com ... customer50.yourdomain.com per week)
For customers who want to use their own domains (like app.customer1.com), you also provide them your CNAME and ask customer to set DNS record. After they will do it, you will be able to create certificate for their domain using this service.
Also this service allows to point different domains to different URLs. We started to use this in our SAAS application for URL shortening (we have several hundreds of customers who use their own domains. So we automatically able to create certificate for them, and everything is automated via API). Also we use the same machine to support SSL for all our company's domains.
available API methods: https://docs.kilossl.com/
I have a subdomain for my website named api.example.com and I want to have the following achieved:
have 1 CloudFront distribution for an S3 static website mapped to api.example.com
have the API Gateway custom domain name mapped to the same subdomain api.example.com
The steps I did to achieve this setup are:
Create an API Gateway custom domain api.example.com and set the base mappings for the APIs I want to expose as v1 (version 1 for now)
In Route 53 I created a CNAME record api.example.com pointing to the Edge optimized Target domain name of the API Gateway from Step 1
Note: at this point I get, as expected, the 200 response from https://api.example.com/v1
I created an S3 bucket and set it up for Static website hosting. All files uploaded successfully and working.
I created a new Cloudfront distribution with the origin in the S3 bucket. At this point, for this Cloudfront distribution, I can not set the CNAME record as api.example.com because it is already used by the first Custom Domain Name set in the API Gateway and AWS gives an CNAMEAlreadyExistsException - so I leave this field empty. Accessing the CloudFront distribution for the S3 bucket works as expected.
Under the CloudFront distribution generated for the S3 bucket I add another origin (the API Gateway custom domain name) and create the Bevahior rule to route the v1/* calls to API Gateway custom domain name.
At this point, things are not falling into place anymore:
- when accessing https://api.example.com I get the {"message": "Fobidden" } from the API Gateway distribution. However the URL https://api.example.com/v1 still returns the expected result.
Question: Is there anything which I missed to set so it will work for the URL https://api.example.com to return the content of the S3 static website?
Note: also, the fact that I have an empty CNAME field on the S3 bucket cloudfront distribution while I have a CNAME defined in Route53 using the same cloudfront distribution prompts me an warning message saying that this situation may expose me to a vulnerability.
For your usecase mentioned, you only need one Cloudfront distribution (which is mapped to api.example.com) where it should be able to forward the traffic to S3 and API Gateway (both added as origins to the same distribution) using different behavior configurations. You can configure the behaviors in a way that /v1/* traffic is routed to the API Gateway and other traffic to S3.
When setting up the origins and behaviors, there are few configurations you need to follow.
Make sure both S3 and API Gateway behaviors redirects HTTP to HTTPS.
When adding API Gateway origin set only to forward HTTPS traffic.
In API Gateway behavior, whitelist the headers for accept-* ones , authorization, origin, referrer and makesure you do not whitelist 'Host' header.
In both origins, don't add any paths.
For the API Gateway behavior configure the TTLs to 0 and allow all the methods (GET, POST & etc.)