I currently have an API backend deployed as a pod inside EKS which I exposed it through using ELB via kubernetes service, and an AngularJS frontend hosted in S3 delivered through Cloudfront, which calls the API.
Is there any way that I could have frontend and backend as domain.com and domain.com/api respectively with the current setup?
The only other way I could think of is not using Cloudfront to host the AngularJS frontend, but instead dockerize it and deploy as a pod in the same cluster as the backend API but I am just wondering if there is a way that I could use Cloudfront (or any other services or ways) to do some kind path-based proxying to decide which end it should redirect.
Thanks in advance.
DNS records work with domains and subdomains but not paths. This means for /api to be interpreted and routed you need a proxy server or an ingress in Kubernetes case.
A simpler approach would be to use api.domain.com and domain.com then create separate A records pointing to your backend and CDN/S3 bucket, respectively.
If you swap the hosting of your AngularJS frontend from S3 to a Nginx container in EKS you can run your frontend and API behind an ingress controller. You can then target the load balancer created for the ingress from CloudFront with a single DNS record.
Note - You will need to configure the cache settings on your API otherwise CloudFront will cache the API output.
Related
I have a web project I am building for fun. It is react, express, mongodb
I currently have an aws domain we will call foo.com that my react app is linked to. I am using S3 and cloudfront to route foo.com as my react app sitting in S3.
I created an SSL cert for foo.com.
That all works
Now on an EC2 instance I have a Express.js app that I am using as a rest server. So my react app uses my elastic ip to call using REST on my EC2 instance.
Since I added SSL to my react app it now will not allow non SSL calls into my api so I am trying to fix that.
I setup an ELB and used my foo.com cert (Mistake?) pointing at my EC2 and opened port 80 and 443 via security group, all works. Except my cert is for foo.com. and my backend server is just setup to use elastic up. Or I guess now the load balancer URL. So I get an invalid certificate name error if I try to load the URL to my express app via the load balancer URL.
How do I use SSL to have my react app make http calls to my express backend. Do I create a new cert? The cert seems to want a DNS name like foo.com but my backend server is just an elastic ip.
Not really sure how to tie all this together I think I am 90% where I need to be.?
Need to get my react app on S3 with a cert and DNS name foo.com to talk to my rest server (express) on EC2 instance using just elastic IP? or Load Balancer URL? What do I do for a cert for that?
You need to add the cert to the load balancer, and point a domain at the load balancer. Something like api.foo.com. You do this by creating a CNAME record in your DNS provider, that points to the load balancer's DNS name. Then have your React app make calls to your API at that domain name. You can create the certs for free in AWS Certificate Manager that will attach to an ELB.
The cert you add to the load balancer will either need to be for api.foo.com or *.foo.com.
I have deployed my frontend in S3 bucket. backend is on EBS. bucket is secured with https but backend api's are not so frontend is not able to connect with the api's. i wanted to add HTTPS for the api's on EBS. i have generated Certificate for the domain name also. i have created a load balancer for the ec2 where my api's are deployed but still i'm not able to connect with it. i have set the Security groups groups also which routes the traffic from port 80 to 443. i don't know where i'm doing wrong or which step i'm missing.
Need help to know the full process and how this all mess is connected with each other.
Currently I am using aws ec2 instance to host my backend and frontend . Backend is in nodeJs and frontend is in angular. ALso using route 53 for routing . and bought domain from goDaddy.
I have used following steps for hosting.
for backend :
clone my backend files on ec2 instance.
run backend nodejs program using pm2(used to run nodejs in background)
used nginx as reverse proxy to point localhost to my sub domain.
for frontend:
cloned frontend production files on ec2 instance.
used nginx to point frontend file to my main domain.
Now nginx is little bit complex to handle for me. Is there any way to avoid nginx or to host though any other way ?
Thank you for your time.
If your frontend app uses angular, then presumably it's a 'Single Page App' that is only dynamic in the sense that it makes some kind HTTP calls to an (RESTful?) API provided by your nodeJS application.
If this is the case, then you can host the built version of the angular app in a public S3 bucket configured as a 'static' site, which will still be able to communicate with your backend via angular's HttpClient. You can use Route53 to point your bought domain at the bucket's index.html file, and also set up a CloudFront distribution if desired.
Your nodeJS app will continue to live on the EC2 instance, although you could consider either using Elastic Beanstalk to deploy the backend app for you, or at least setting up yourself a load-balancer and autoscaling group to give you fault tolerance and availability for the backend.
I am currently having two nginx servers and an AWS load balancer in front of them. The static content is served with nginx. Can I use nodejs for the application logic and routing. I dont want to use nginx as a reverse proxy.
You can create two target groups, one for each application.
Then use the AWS Application Load Balance to manage your requests.
In the Application Load Balance you must configure the listeners to forward the request to the correct target group.
Is it possible to configure dns settings in such way so web application is using www.domain.com and amazon aws api gateway uses www.domain.com/api?
Not using pure DNS, it would only let you point a subdomain to a destination, DNS doesn't see the path.
You can use something like nginx to proxy the path, or use api.domain.com for your API, which probably is better, as you don't need to proxy the requests at all.
You can configure AWS CloudFront as a proxy to map both API Gateway and Web Server (Or web application hosted in AWS S3) as origins. Then configure
www.domain.com to point to CloudFront.
This also improves the application performance, if you cache the static content, serving from the web application, by using the CloudFront CDN network of edge locations.
When mapping API Gateway do the following configuration for it to work.
Whitelist the headers and exclude Host header.
Set TTL values to zero.
Make the origin and behaviors for API Gateway https only.
To map www.domain.com/api to API Gateway, use the stage name as 'api' with CloudFront behavior mapping for /api/* .