I have a Route 53 domain, which maps to a load-balancer, which maps to a NodeJS Express server (check it out here). But it is currently using HTTP, so I want to switch over to HTTPS. I also have an ACM SSL certificate ready to go.
I have tried adding a listener to the load-balancer...
However, when I entered the address in the browser, it times out.
So, I tried editing the security group corresponding to this load-balancer...
But it still times out.
Thanks for any help.
Extra references:
here is the video I have been watching
here is the AWS docs article I have been reading
P.S. Could it be a problem with the API itself i.e. do I have to add any extra configuration to the API?
Your current listener on HTTPS isn't working because you aren't pointing it at the same destination as the HTTP listener.
Set your HTTPS listener's Instance Protocol to HTTP and its port to the port
your API listens on - 31315.
I tried editing the security group corresponding to this load-balancer
This needs to be done as well. The load balancer's security group must allow 443, and the load balancer must be listening on 443. The only piece you look like you're missing is pointing the load balancer's listener to the correct destination port on the instance.
Could it be a problem with the API itself i.e. do I have to add any extra configuration to the API?
I wouldn't think so. The API probably doesn't care whether the load balancer listens for htts or not - the important thing is that the traffic is sent to the port the API is listening on.
I have a jfrog factory(port 8081) and jfrog docker( port 8082) running on an EC2 instance
with route53 I defined the url of the domain xxx.io and also two subdomains jrog.xxx.io and docker.xxx.io
with certificate manager I applied for a SSL certificate for the domain xxx.io who normaly is available as well for the subdomain if i dont make any mistakes .
What tools do I need to set up so that when a user enters the url jfrog.xxx.io it is redirected to the jfrog instance (port 8081) but the port of this instance must be mapped to 443 ?
You can use an application load balancer to achieve it.
The load balancer works with target groups and you will need 2 target groups for your load balancer. First target group will map the https (443) to your jfrog docker and the second target group will map https (443) to your jfrog factory.
The target group for jfrog factory will look like:
The target group for jfrog docker will look like below.
P.S: My instance is unhealthy because it has nothing in it, just a dummy instance.
Important things in the target group is the port mapping of your application and the target type. Then register your EC2 instance with the target groups.
Now in your load balancer, choose the tab Listeners and View/Edit rules for the listener of type HTTPS (443).
Then add new rules using a condition host header which will then redirect traffic to your target groups based on your subdomains (host header), it should look something like below. P.S I do not have SSL certificates, so I have used http itself, https should not be any different.
The finally you must make a DNS entry of type CNAME to map your domain (xxx.io) to the load balancer's DNS name.
This is where you will get the load balancer's DNS name:
I have an alb pointing to my ecs service registered to target-group-one. The DNS of the load balancer works fine and able to print the message from my simple apache webserver. However when I configure path based routing like in the image attached and the add the path to the the DNS url ......com/gci, I get the error message The requested URL was not found on this server.
What am I not missing or not doing right?
If your actual httpd server does not respond to /gci without ALB, then it will not work with ALB. The path rule that you configured only forwards the query to your target group (TG).
So if the rule matches www.example.com/gci, ALB will just forward the query to the associated TG. This means that your ECS service still must correctly respond to /gci path.
In other words, the forwarding rules of ALB do not re-write the paths.
I am using a Load Balancer with Elastic Beanstalk. I want to redirect any host that is different than domain.com to domain.com.
Is that possible to achieve with an AWS load balancer?
This is actually quite easy and fully supported by the AWS ALB.
What you're looking to do is to add a Host header based rule. The steps below should be followed:
Find your Application Load Balancer
For each listener select View/Edit Rules
Click the + symbol at the top of the console to add your rule, specify that the rule is a host header rule with a target of your target group.
Edit the default rule, remove the action and set to a redirect action (as show in the below screenshot).
By adding the host header rule with a target as the target group for you app, it will only connect to your hosts for the correct host name.
Otherwise have the default action be a redirect action to redirect to the domain you specify.
We are implementing a micro-services architecture in AWS. We have several EC2 instances which has the micro-services deployed on different ports. We also have an internet facing Application Load Balancer, which routes to different services based on the port.
eg:
xxxx-xx.xx.elb.amazonaws.com:8080/ go to microservice 1
xxxx-xx.xx.elb.amazonaws.com:8090/ go to microservice 2
We need to have a domain name instead of the ELB, the port should not be exposed through the domain name as well. Almost all the resources I found regarding route 53, use alias which does the following:
xx.xxxx.co.id -> xxxx-xx.xx.elb.amazonaws.com or
xx.xxxx.co.id -> 111.111.111.11 (static ip)
1) Do we need separate domains for each micro service?
2) How to use alias to point domains to a specific port of the ELB?
3) Is it possible to use this setup if the domains are from another provider other than AWS.
Important Update
Since this answer was originally written, Application Load Balancer introduced the capability for ALB to route requests to a specific target group based on the Host header of the incoming request.
The incoming host header can now be used to route requests to specific instances and ports.
Additionally, ALB introduced SNI support, allowing you to associate multiple TLS (SSL) certificates with a single balancer, and the correct certificate will be automatically selected based on the SNI presented by the client when TLS is negotiated. Multi-domain and wildcard certs from Amazon Certificate Manager also work with ALB.
Based on these factors, no separate ports or different listeners are needed -- simply assign hostnames and/or path prefixes for each service, and map those patterns to the appropriate target group of instances.
The original answer is no longer accurate, but is included below.
1.) Do we need separate domains for each micro service?
No, this won't help you. ALB does not interpret the hostname attached to the incoming request.
Separate hostnames in the same domain won't directly accomplish your objective, either.
2.) How to use alias to point domains to a specific port of the ELB?
Domains do not point to ports. Hostnames do not point to ports. DNS is only used for address resolution. This is true everywhere on the Internet.
3.) Is it possible to use this setup if the domains are from another provider other than AWS.
This is not a limitation of AWS. DNS simply does not work this way.
A service endpoint is unaware of the DNS records that point to it. The DNS entry itself is strictly used for discovering an IP address that can be used to access the endpoint. After that, the endpoint does not actually know anything about the DNS, and there is no way to tell the browser, via DNS, to use a different port.
For HTTP, the implicit port is 80. For HTTPS, it is 443. Unless a port is provided in the URL, these are the only usable ports.
However, in HTTP and HTTPS, each request is accompanied by a Host: header, sent by the web browser with each request. This is the hostname in the address bar.
To differentiate between requests for different hostnames arriving at a device (such as ELB/ALB), the device at the endpoint must interpret the incoming host header and route the request to an back-end system providing that service.
ALB does not currently support this capability.
ALB does, however, support choosing endpoints based on a path prefix. So microservices.example.com/api/foo could route to one set of services, while microservices.example.com/api/bar could route to another.
But ALB does not directly support routing by host header.
In my infrastructure, we use a combination of ELB or ALB, but the instances behind the load balancer are not the applications. Instead, they are instances that run HAProxy load balancer software, and route the requests to the backend.
A brief example of the important configuration elements looks like this:
frontend main
use_backend svc1 if { hdr(Host) -i foo.example.com }
use_backend svc2 if { hdr(Host) -i bar.example.com }
backend svc1
server foo-a 192.168.2.24:8080
server foo-b 192.168.12.18:8080
backend svc2
....
The ELB terminates the SSL and selects a proxy at random and the proxy checks the Host: header and selects a backend (a group of 1 or more instances) to which the request will be routed. It is a thin layer between the ELB and the application, which handles the request routing by examining the host header or any other characteristic of the request.
This is one solution, but is a somewhat advanced configuration, depending on your expertise.
If you are looking for an out-of-the-box, serverless, AWS-centric solution, then the answer is actually found in CloudFront. Yes, it's a CDN, but it has several other applications, including as a reverse proxy.
For each service, choose a hostname from your domain to assign to that service, foo.api.example.com or bar.api.example.com.
For each service, create a CloudFront distribution.
Configure the Alternate Domain Name of each distribution to use that service's assigned hostname.
Set the Origin Domain Name to the ELB hostname.
Set the Origin HTTP Port to the service's specific port on the ALB, e.g. 8090.
Configure the default Cache Behavior to forward any headers you need. If you don't need the caching capability of CloudFront, choose Forward All Headers. Also enable forwarding of Query Strings and Cookies if needed.
In Route 53, create foo.api.example.com as an Alias to that specific CloudFront distribution's hostname, e.g. dxxxexample.cloudfront.net.
Your problem is solved.
You see what I did there?
For each hostname you configure, a dedicated CloudFront distribution receives the request on the standard ports (80/443) and -- based on which distribution the host header matches -- CloudFront routes the requests to the same ELB/ALB hostname but a custom port number.
I think there is a possibility that he can build what he's describing. I was in the same boat for a while, here's some options for you to consider:
In R53 create a hosted zone - and point your domain at it.
Optional step: create ALIAS records. You can do this for each subdomain or
app. Leave the ALIAS field blank if using the root domain.
Create a record set using the SLA option, which is a service lookup for port
redirection. Try to point this to your LB port 80, alias the sub-domains.
Change your load balancer's listeners, to listen on port 80 - then redirect app traffic based on your apps port settings.
I havent used SLA, but this would definitely point you in that direction.