I'm trying to set up a custom domain (say, myapi.com) for my API Gateway but am running into problems. The domain is currently registered on GoDaddy. So far, I've followed this tutorial and done the following:
Obtained a certificate for myapi.com and *.myapi.com from the AWS Certificate Manager.
Mapped the domain myapi.com (not *.myapi.com as I don't need it yet) to an API in the API Gateway.
Added a CNAME entry for the resulting "target domain name" in GoDaddy.
Here are the screenshots:
Now here's the problem: When I do ping myapi.com I get: No address associated with hostname. I'm not sure what's causing this, so would really appreciate some help. And while we're at it, are there any other steps I need to perform before this works as expected?
You cannot use a CNAME record at the apex or domain root with standard DNS services. I suggest you try using a hostname for your endpoint and using the CNAME there eg api.example.com.
Alternatively, you can move your DNS to Route 53. The Route 53 system does support aliases at the root domain level, using the Alias record type.
For more information on Alias records in Route 53 see https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html
Related
My client has a domain example.com hosted somewhere.
We need to create a subdomain cloudfront.example.com in my AWS cloud in order to make my Cloudfront Distribution accessible on that subdomain.
CF requires an SSL certificate to work with a custom domain.
I was only able to find a solution which leads to 4th level subdomains via creating an AWS Hosted Zone (3rd level domain) in my AWS account where I can then create another subdomain (4th level).
Is it possible to register a single record in my client's DNS table to point to my CF Distro?
Yes, you can use the client's DNS. What you need to do:
Use ACM to create an SSL certificate for cloudfront.example.com. You will see a necessary CNAME to confirm the SSL certificate
Add CNAME to your client's DNS that will validate the certificate
In CloudFront, define alternate domain name (CNAME) as cloudfront.example.com
In the client's DNS add a CNAME for cloudfront.example.com to point to your CloudFront distribution domain name (it's going to be some-hash.cloudfront.net)
I have a domain hosted through Route 53 called foo.com and all is good. I have both NS and SOA records created in Route 53:
foo.com. NS
ns-1609.awsdns-09.co.uk.
ns-431.awsdns-53.com.
ns-1071.awsdns-05.org.
ns-662.awsdns-18.net.
foo.com. SOA
ns-1609.awsdns-09.co.uk. awsdns-hostmaster.amazon.com.
We also segment our platforms by account. So, we have an AWS subaccount that supports our DEV environment (following the AWS document: https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-routing-traffic-for-subdomains.html). So, within our foo.com hosted zone, we also have an entry:
devapi.foo.com. NS
ns-3476.awsdns-09.co.uk.
ns-2341.awsdns-76.com.
ns-3245.awsdns-56.org.
ns-294.awsdns-67.net.
Within our AWS DEV account, we have a devapi.foo.com hosted zone with the exact same NS record:
devapi.foo.com. NS
ns-3476.awsdns-09.co.uk.
ns-2341.awsdns-76.com.
ns-3245.awsdns-56.org.
ns-294.awsdns-67.net.
along with a SOA record and an A record that points at the DEV API Gateway:
devapi.foo.com. A ALIAS f-8wdjr4hvgh.execute-api.us-east-2.amazonaws.com.
where f-8wdjr4hvgh.execute-api.us-east-2.amazonaws.com. is the domain name of the API Gateway.
I have a custom domain mapping for devapi.foo.com
Unfortunately, in all of this, devapi.foo.com is not pingable/routable. If you ping it, it returns an IP address but a Request timeout for icmp_seq* ...
If I use https://www.whatsmydns.net/#A/ for devapi.foo.com, I get green check marks but I believe that all that is telling me is that the domain name is resolvable.
Thoughts on what I am missing?
Followup: The issue was with the Custom Domain Mapping and Base Path.
I ran into a problem where I went to setup a record that mapped my custom sub-domain to my API Gateway. When I went to select the actual endpoint I got a red warning/error message saying "cannot retrieve endpoint suggestions"
The instructions for setting everything up are here:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-api-gateway.html
Before doing what I was trying to do, the prerequisites (stated on the linked page) were:
An API Gateway API that has a custom domain name, such as api.example.com, that matches the name of the Route 53 record that you want to create.
A registered domain name. You can use Amazon Route 53 as your domain registrar, or you can use a different registrar.
Route 53 as the DNS service for the domain. If you register your domain name by using Route 53, we automatically configure Route 53 as the DNS service for the domain.
I realized I had not done step #1. This needs to be done via the API Gateway interface, not the Route 53 interface. If you haven't done this for the domain yet (not the sub-domain, but the domain) you may need to do some work to setup a certificate for the domain. This involves placing what looks to be a sort of magic key entry in your domain registry (using Route 53 or whatever you used to register your domain) so that Amazon knows you own the domain.
Once this custom domain has been setup (again, in the API Gateway section, not Route 53), then I was able to create a record in Route 53 and my API Gateway endpoint was now detected for selection.
I have create a AWS elastic search domain in Virginia and got a Endpoint url.
Now I wanted to configure the Route53 behavior around it, so that a caller can use the same url, even though there is some change in elastic search or in case of a disaster recovery.
So,
Virginia Route 53 -- 1 Points to -- Virgina Elastic Search Domain URL
Oregon Route 53 -- 2 Points to -- Oregon Elastic Search Domain URL
Main Route 53 -- 3 Points to -- Route 53 1 or 2
I have already create these and also created and uploaded SSL certificate with correct SAN entries. But when I execute,
curl https://mainroute53/health
curl https://virginiaroute53/health
curl https://oregonroute53/health
I am getting this error,
curl: (51) Unable to communicate securely with peer: requested domain name does not match the server's certificate.
But when I am calling the Elastic Search URL directly its working. So I understand this is a issue with the way I am using the certificate. Any help appreciated.
Your Elastic Search endpoint will always return the Elastic Search SSL certificate.
So when you create a Route 53 "alias" for it, you may be connecting to it via your custom DNS entry, but Elastic Search will still use the Elastic Search SSL certificate.
Since the DNS endpoint you're using does not match the SSL certificate, you get that error.
You could use the --insecure curl flag to have it not check the SSL certificate, however, there are risks of doing that.
You can probably work around this by setting up a proxy server in front of the Elasticsearch domain, although it's kind of silly since there appears to also be an ELB inside the Elasticsearch domain. Ah well.
The domain Amazon ES creates for you includes the nodes in the Elasticsearch cluster and resources from several AWS services. When Amazon ES creates your domain, it launches instances into a service-controlled VPC. Those instances are fronted by Elastic Load Balancing (ELB), and the endpoint for the load balancer is published through Route 53. Requests to the domain pass through the ELB load balancer, which routes them to the domain’s EC2 instances.
https://aws.amazon.com/blogs/database/set-access-control-for-amazon-elasticsearch-service/
One way you can access Elasticsearch using your custom domain name is to use an API Gateway as an HTPP proxy. But then you have to deal with the authentication part since the Cognito cookies for ES will be pointing to the original domain (*.es.amazonaws.com).
In my experience this is doable and you should be able to use API Gateway (plus Custom Domain Names and Route 53) to achieve what you want (having a custom domain name over ES). It's just that it requires some Cognito knowledge and most likely, some coding (to handle the cookie problem).
You can use the http endpoint instead of the https one
i.e
curl **http**://mainroute53/health
This works around the fact that AWS does not allow providing custom domain certificate in its managed Elastic service
We had the same issue, wanted to be redirected to Kibana with a more friendlier DNS name and we used the solution with S3 bucket and the redirection as described here.
The steps:
Create a S3 bucket with any name.
In the bucket properties, enable “Static Website hosting”.
In the Static WebSite hosting properties, select the option to “Redirect Requests”.
In the target domain set the Kibana URL that is given from your elasticsearch domain: i.e. https://vpc-es-randomstring.us-east-1.es.amazonaws.com/_plugin/kibana/
Set Protocol to https
Then follow the steps from Step 5 on the guide above
I'm in the process of moving from another cloud provider. Currently I'm just testing in the default environment that has a url looking like this:
http://example-env-1.us-east-1.elasticbeanstalk.com
I'm trying to get SSL/HTTPS working for this address. I then plan using a CNAME to redirect to this address and eventually move the nameservers over completely.
However, after setting everything else up successfully I get to the point of adding the certificates and it just says "failed":
And even though I have my actual "example.com" ssl certificate successfully issued nothing shows up in the load balancer certificate selection dropdown (and yes I have refreshed):
How do I enable SSL using the Certificate Manager?
That's because you are trying to request a cert for the elasticbeanstalk.com domain. You will not be able to get a cert for that domain as you are not the owner of it :). Nor can you setup https for the default elastic beanstalk domains they give you.
You should use ACM to get a certificate for your custom domain, the one you plan on making a CNAME record for.
Example:
If you were to own say the domain amyneville.com. You could create a cert through ACM for that domain.
If you use your custom domain, you do NOT need a to get a cert for the elasticbeanstalk.com domain.
A couple more things:
You cannot create a CNAME record on a TLD (amyneville.com). You can create the CNAME record for www.amyneville.com. So if you want to use the CNAME approach you will have to create a non-www redirect to www..
But better then a CNAME would be to use an A record and point it to the elastic beanstalk resource that was setup. So the load balancer that was created for you, use it's A record.
Last but not least, you cannot apply the ACM cert through the elastic beanstalk console. Instead you will have to use the AWS CLI tools. Here's a link on how to do it: https://stackoverflow.com/a/35173500/1445460
I was looking for this myself and found this useful blog post from one of the Amazon team ...
https://medium.com/#arcdigital/enabling-ssl-via-aws-certificate-manager-on-elastic-beanstalk-b953571ef4f8#.frcj0rj4t
Whilst you can't use the console to select the certificate as stated in your question you can use the Elastic Beanstalk CLI to set the certificate to one you have created in Certificate Manager.
I have my domain name in godaddy's account. And I want to host that site on aws.
So for that I have created the EC2 instance and it is working fine with the public address they have given
http://ec2-23-20-10-132.compute-1.amazonaws.com/
I want to open the same thing with my domain name. How can I do that.
Need more context on this. Does Route 53 already have control of your domain name?
If your domain is in Route 53 and the NS (nameserver) values are using AWS name servers, then the process of routing your EC2 enviornment to your domain is quite easy.
In that case, all youll do is a create an A-level record set with the alias target of your raw EC2 url. Normally you set your A-level record set to be DOMAINNAME.com ...
After that, for posterity and canonical redirect purposes--you'd create a CNAME record for www.DOMAINNAME.com...this could point to your A-level record set of DOMAINNAME.com...
Hopes this helps!
Make sure your web server responds on domain.com
Point your DNS record (root records and/or www record) to the web server I.P