I have a set of ASP.net core APIs running on AWS lambda. I have setup custom url paths that are mapped to these APIs. I also have the same set of APIs exposed in EC2 and at deploy time I deploy to both automatically.
The reason I do this is because the EC2 version is fast for light load scenarios with no cold start issues. However as load increases I'd like my requests to be directed to the API Gateway/Lambda APIs. Basically I'd be using Lambda to add resiliency and take the strain of heavy load without sacrificing performance in light load scenarios due to cold start peformance. I have an ELB sitting in front of my EC2 APIs and I thought that maybe I could use the load balancer to redirect traffic to API gateway based on some custom health monitoring.
My question would be is this possible or even a reasonable approach? Is there perhaps a better way where I have API Gateway forward to EC2 or Lambda instead?
Any guidance appreciated.
Thanks
Related
I have a cluster of private EC2 instances serving http requests behind a public ALB. https termination happens on the ALB, with authentication on the EC2 instances. I want to move authentication to the ALB, ideally via mTLS. But ALB does not support mTLS. From some initial reading, it sounds like API Gateway can replace load balancing/firewall functions of the ALB in this design, while also supporting mTLS? Is that correct?
If so, I wonder what would be the best way to implement sticky sessions, which seem not supported by API Gateway, but needed by my app. I guess client request could initially target an API served by any instance, but then subsequent requests would target API unique to the instance that replied?
Are there other drawbacks to API Gateway, other than higher cost at high volume? Is there a better approach to this problem?
My initial assumptions were incorrect. API Gateway is not an alternative to ALB except in some specialized circumstances. So, the solution for me is to put an API Gateway in front of a private ALB, e.g., as described in AWS example
https://aws.amazon.com/premiumsupport/knowledge-center/api-gateway-alb-integration/
If I have an architecture in AWS with many different microservices, each in their own AWS ECS cluster and an AWS application load balancer in front of each one, would I still need consul or linkerd?
Conversely, if I don't use an AWS application load balancer, would I be required to use something like consul or linkerd to handle the load balancing as the ECS clusters scale up/down?
I'm trying to understand whether these all are complementary services or whether they are competing services.
Meshes are really designed to mediate communications within the cluster. Linkerd could secure communications across this kind of multicluster, but to be candid I find myself wondering if you'd be better served with all the microservices in the same cluster? That would let you use an API gateway and service mesh to secure everything and provide better reliability and observability, and save you money on LBs.
(Full disclosure: I have ties to Linkerd and to Emissary-ingress, so I'm a touch biased. :) )
I have a web app running on my Amazon EC2 instance. How can I integrate a Web Application Firewall with my EC2?
I have tried setting up the WAF, but it can only be associated with either a CloudFront distribution or an Elastic Load Balancer. Do I need to setup a CloudFront distribution and point it at my EC2 instance?
I ended up setting up an elastic load balancer pointing to my single instance and then adding the web application firewall pointing to the load balancer. It works pretty well and doesn't cost too much more per month from AWS.
The two approaches you can connect AWS WAF to your EC2 instance through,
AWS CloudFront
Application Load Balancer (ALB)
Each approach has its own pros and cons. If your application servers more of content that can be cached, then having AWS CloudFront along with WAF. If your application cluster needs to scale but most of it is dynamic content then going for ALB is more reasonable.
Note: There is an added fixed cost for ALB (In addition to the variable cost which is not significant though) for each month while CloudFront cost is variable and consumption driven.
It is also possible to have both CloudFront and ALB together where you can add the WAF to CloudFront only.
This is how you use AWS WAF, it only works in these two scenarios. For an EC2 application it is best to configure an ALB in front of it (even if you have only one instance).
BTW: You might get away with only using the Application Loadbalancer (ALB) from AWS, this is doing more content validity checks than classic AWS ELB is doing.
You need to set up at least Application layer Loadbalancer to use AWS WAF.
side note: AWS WAF has a lot of restriction. For request count based blocking you will end up having LAMBDA scripts to COUNT and update the AWS WAF ruleset. Also, they don't provide WAF logs as of my Knowledge. Try looking at cloud WAF solutions like SOPHOS.
I have two custom hardware servers running a service for me, need to set up a load balancer. Till I can get my service provider to provide one for me, can I set up AWS ELB to load balance requests to my servers? Is there some other option? PS: Costs are an issue, so looking for cheaper alternatives
We’re trying to create a setup of multiple APIs via the Amazon AWS Elastic Beanstalk (AEB) component. The reason we have chosen AEB is because it provides seamless deployment and scaling for the applications we deploy, without the need to manually create Load Balancers (LB) and scaling rules. We would very much like to keep it this way as we are planning on launching a (large) number of applications and APIs.
However, we’re facing a number of challenges with AEB.
First and foremost, some of the API’s need to communicate internally, and low latency is a core requirement for us. In order to utilize internal network communication in AEB we have been “forced” to:
Allocate a VPC in Amazon
Deploy each application to this VPC - each behind their own internal LB
Now, when using the Elastic beanstalk URLs the APIs are able to resolve the internal IP of the LB of another API and thus the latency is eliminated and all is good - the APIs can communicate with one another.
However, this spawns another issue for us:
Some of these “internally” allocated APIs (remember, they’re behind an internal LB in a VPC) must also be accessible from the internet.
We still haven’t found a way to make the internal LBs internet accessible (while keeping their ability to also act as internal LB), so any help on this matter is greatly appreciated.
Each application should be on a subnet within VPC
Update ACL and ELB Security Group to let external access
AWS Elastic Load Balancing Inside of a Virtual Private Cloud
Also, this question on SO contains relevant information: Amazon ELB in VPC