I have a use case where I would like all requests to start with a prefix like:
https://WHATEVER/pfx
For example https://WHATEVER/pfx/a and https://WHATEVER/pfx/b/c/d
But I wish to prevent https://WHATEVER/somewhere_else and similar requests that do not include the prefix (pfx). In preventing this, I'd like to simply redirect all such requests to https://WHATEVER/pfx (home page)
Is this possible with AWS ALB?
Thanks in advance!
A client of ours generally can get away with running just the one EC2 and also has an Aurora serverless MySQL 5.7 database running, however there are times when their load spikes up significantly. e.g. going from maybe 20 sessions to 200 sessions in a minute. This is because they sell tickets for events and tell people that tickets go on sale at x date so everyone tries to jump on at once.
At the moment the AWS Application load balancer is set to scale up when it hits 60% CPU utilisation across all the EC2 nodes in the fleet. I am not sure what triggers the Aurora serverless to scale up and down as yet. However what I was wondering is if there is any suggestions on how to better handle the increase in load. The spike in load can extend for around 30m or so but then tapers back to a normal level so we are just focusing on that short period of time when load really goes up.
At the moment they are configured to use c4.xlarge instances and in the Aurora rds it has a min capacity of 8 and max of 16
Our client would like to keep the bill down but would like to see better performances, is there any obvious suggestions.
I am using AWS to build a service. For this service I want to use ACM certificates. The backend is running on an EC2 instance with TLS enabled using a self-signed certificate. Since ACM certificates can't be exported I want to put a load balancer in front of the backend that will serve the valid certificate.
My Assumptions:
Even with this, I am still running into errors.
My current status:
The EC2 instance is reachable on port 443 and reports a self signed certificate (as expected). The EC2 instance is reachable on port 80 for health check purposes.
I've built an ALB with an https target group with my instance as the target. The ALB is reachable via browser and displays my valid certificate, but responds with a 502.
If instead I use an http target group and request the health check endpoint, I'll get a 200 back. For testing purposes I also use a very lax security group for the instance, as well as for the ALB.
So this is what I am seeing in the ALB logs (every line is pretty much the same apart from the time):
https 2020-06-05T09:39:26.715673Z app/testTLSAlb/660e809a22b5d7d2 10.95.21.6:65521 10.95.16.197:443 -1 -1 -1 502 - 240 293 "GET https://my.domain.com:443/adfs/.well-known/openid-configuration HTTP/1.1" "PostmanRuntime/7.25.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:eu-central-1:accountid:targetgroup/testhttpsTargetGroup/f1e8ce633e9ab069 "Root=1-5eda12ce-aabdb29ae55998867511a310" "my.domain.com" "arn:aws:acm:eu-central-1:accountid:certificate/d9a964b0-6d96-4eeb-b126-2b87f1350942" 0 2020-06-05T09:39:26.714000Z "forward" "-" "-" "10.95.16.197:443" "-"
The URL is reachable if I connect to the target directly. As you may have seen, this is an ADFS Server and that doesn't seem to support real logging.
I have captured a direct request and a request from the ALB with wireshark.
The direct request yields a response, the request from the ALB gets a TCP Reset after a TLS Client Hello:
As far as I could see, ciphers should be compatible (the successful request is using a cipher, that the ALB also offers). The only major differences are the TLS extensions that are sent (left is ALB, right is Postman). 
The missing SNI field seems to be the problem, since that is a requirement for ADFS (https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/overview/ad-fs-requirements)
I have an ALB, containing Rules that forward requests to my private EC2s, hosted on AWS, and when I make a new deployment, I have a script in Lambda that turns off my ASGs and turns them back on. During this period when the ASGs are down and I try to access the website, the ALB responds with default 503 error, and I wanted to override that with my custom error page which I have placed in a separate S3 bucket.
I've followed the instructions posted in the answers section here: AWS ELB "sorry, site is down" page
So here's what I did:
However, when I try to access my website when EC2s are down, I still get the same default 503 error page. (I think this comes from ALB, right?)
About steps 2) and 3), I've also tried using the S3 Origin, instead of Custom Origin, but it still didn't work.
By the way, when I access the xxx.cloudfront.net URL of the distribution, I get my custom error page with 200 OK response (is this correct?).
What am I doing wrong?
I have an ECS cluster with ELB. Last night I saw that a task was stuck in restarting loop. From the service Events log, it said:
"service xxxxx was unable to place a task because no container instance met all of its requirements. The closest matching container-instance xxxxxxxxxxxxxx is already using a port required by your task."
However, I have checked that all such tasks are dead and nothing should be using the port at that time. Updating the service does not help but creating new task definition and then update helps. Terminating the instance and allow ELB to relaunch it helps.
Any idea why the service cannot secure the port for the task?
