I have a WordPress blog that serves niche content on domain.com
On a different endpoint, domain.com/api/ I have a completely different Node.JS API that doesn't regard the WordPress but I want to serve it from the same domain.
It is worth mentioning that we proiritize performance and speed above all.
My thought was the following :
Set up 2 EC2 Instances, one for the WordPress and one for the API (Maybe make the API a Lambda instance ?).
Set up an Application Load Balancer that will know how to route requests with a rule depending on the URL.
Is it the right way to go ? Should I just use nginx as a reverse proxy and serve the Node.JS API on a local port ?
I also want to use Elastic Beanstalk to save myself the headache of configuring the Load Balancer and the Auto Scaling group.
P.S If anyone has any advice or good habits on how to build those (With S3 Bucket perhaps, over CloudFront, etc etc) it will be more than welcome.
Thanks !
Related
I wonder how to manage the routes of my architecture. To summarize, my architecture is composed of :
S3 static website exposed under CloudFront CDN
Elastic Beanstalk API (based on Docker container with Django Rest and Python)
I usually insert a new record to my hosted zone in my route 53 but my goal here is to have the equivalent of Nginx locations with proxy_pass. For example, I would have :
<my_dns_record>/api that target my Beanstalk API
<my_dns_record> that target my static website on my CloudFront
I thought about an API Gateway but I wonder if it's really the best way to structure the routing.
Does anyone have an idea how to achieve the desired behavior ?
Thank you in advance for your help.
If I understand correctly, you want to have multiple apps (your S3 static site, and your Elastic Beanstalk app) served under a single domain. Route53 doesn't have any special features to handle this, since it is just a DNS service, and what you are talking about is an HTTP path routing thing.
You also shouldn't use API Gateway for this, as you would be placing your entire website behind an API Gateway when it is really only appropriate to have your API behind an API Gateway.
I would just add the Elastic Beanstalk API under CloudFront as well, as a second origin, and configure CloudFront to send requests at the /api path to the Elastic Beanstalk origin.
Alternatively, forget about having everything under the same domain, and use a subdomain api.yourdomain.com for your API. Using subdomains for your different services instead of path routing is a lot more flexible.
I am running a custom PHP application, My application is using ALB and EC2. I am facing issues with a lot of fake requests which are similar to the WordPress site and loading my site and make it inactive. Is there a way that we can create Rules in WAF and attach it to load balancer to block that bad requests? Any other alternate way suggestions/solutions are also appreciated.
Fake requests look as below
https://example.com/xxx.php
https://example.com/wp-login.php
https://example.com/dsfh.php
My instance is a single instance, no load balancer.
I cannot seem to add a load balancer to my existing app instance.
Other recommendations regarding Elastic Load Balancer are obsolete - there seems to be no such service in AWS.
I do not need caching or edge delivery - my application is entirely transactional APIs, so probably don't need CloudFront.
I have a domain name and a name server (external to AWS). I have a certificate (generated in Certificate Manager).
How do I enable HTTPS for my Elastic Beanstalk Java application?
CloudFront is the easiest and cheapest way to add SSL termination, because AWS will handle it all for you through its integration with certificate manager.
If you add an ELB, you have to run it 24/7 and it will double the cost of a single instance server.
If you want to support SSL termination on the server itself, you're going to have to do that yourself (using your web container, such as apache, nginx, tomcat or whatever you're running). Its not easy to setup.
Even if you don't need caching, CloudFront is going to be worth it just for handling your certificate (which is as simple as selecting the certificate from a drop-down).
I ended up using CloudFront.
That created a problem that cookies were not being passed through.
I created a custom Caching Policy to allow the cookies, and in doing so, I also changed the caching TTLs to be very low. This served my purposes.
I have a website which I serve using express running in an EC2 instance. But this EC2 serves only the static content (html, js, css) and the dynamic part comes from API Gateway. Right now, these two have different IPs (and domains) which means that I have to deal with CORS problems accessing API Gateway from the web pages. If I could somehow serve the static content and dynamic one through the same address, that would be much better.
The way I see it, this can be done in two ways. I can serve both of them on the same host but different ports which I'm not sure if it's going to solve the same CORS problem or not. But another way which I'm sure it will not face the CORS problem is serving API Gateway under some specific sub-folder. Like http://example.com/api while the static content is served from any url except that.
Does anyone know how can I do this? Is CloudFront what I need? Or Elastic Load Balancer?
Yes, CloudFront is what you need for this scenario.
Application Load Balancer can also do path-based routing, but it doesn't support API Gateway as a target.
By default, CloudFront can route requests under a single domain to the correct choice from up to 25 destinations, using up to 25 path (matching) patterns (both of these limits can be increased by request, but it sounds like for now, you only need 2 of each, /api/* to the API, and the default * route to EC2). You can also leverage this setup to put some static content in an S3 bucket and take some load off of the servers in EC2.
For this configuration, you will want to configure your API Gateway deployment with a regional endpoint, not an edge optimized endpoint. This is because edge optimized endpoints already use part of the CloudFront infrastructure (a part to which you have no ability to configure), so using an edge-optimized endpoint behind your own CloudFront distribution sends each request and response through the CloudFront network twice, increasing latency.
Setup: Play Framework application deployed on Amazon EC2 instances via ECS, Elastic Load Balancer in front. I want to allow only HTTPS requests for the application.
I found several ways to use HTTPS with Play, but what are the pros and cons, or which one is best practice for a (dockerized) Play app?
Enable HTTPS directly within Play (with -Dhttps.port or https.port in config file).
Set up a front-end web server (e.g. Nginx) and let it handle the HTTP->HTTPS rewrite (example).
Implement a request filter in Play and redirect the requests within the application (as described here).
I'm not so keen to use the first version as I would have to manage the certificates separately on each instance, but I listed it for the sake of completeness.
One advantage I can think of for the third approach must be that the system architecture is simpler than in the second version and requires less configuration. Are there any disadvantages (e.g. performance) to using the third approach?
If you are using a load balancer then you should request a free SSL certificate from the Amazon Certificate Manager service and then attach that certificate to the load balancer.
To enable HTTP to HTTPS redirects you simply need to check the x-forwarded-proto header that the load balancer passes to the server. If it is http return a 301 with https. The article you linked covers this part.