I have a web application running on Elastic Beanstalk in load balanced environment however when I changed the configuration to a "single instance" environment the application returns a 408 Request Timeout with every https browser request to the server (custom domain).
The environment health in my AWS console shows everything is running okay so I am baffled by what could be causing the problem. When I change the configuration back to 'load balanced' everything works fine again.
When I change the configuration back to 'load balanced' everything works fine again.
Since you are using HTTPS with custom domain, when you switch to a single instance, the HTTPS functionality is lost. To make HTTPS work on a single instance, you need to obtained new SSL certificate (AWS ACM can't be used), and deploy it on your instance though re-configured Nginx:
How to Setup SSL(HTTPS) on Elastic Beanstalk Single Instance Environment
Related
I have a NodeJS API application running on a single instance (no load balancer) on AWS Elastic Beanstalk. Previously the app was on the old Amazon Linux environment which was deprecated, so this is now just freshly created in a brand new "Node.js 16 running on 64bit Amazon Linux 2/5.6.0" environment. I verified the new environment is up and running properly and now the domain is pointing to the new version. When using normal HTTP traffic the application responds normally.
The previous version had SSL enabled. The certificate purchased a year ago was just reissued for another year (from NameCheap - third-party CA). I generated the new cert/key per NameCheap's instructions. To configure EB for using SSL, I followed these instructions from Amazon exactly: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/https-singleinstance-nodejs.html And currently have the contents of the cert, the ca_bundle, and the private key in my .ebextensions/https-instance.config file (just to get it working... for production this would reference files on S3). I ran the contents through a YAML formatter to make sure the spacing was correct.
While my application responds OK without HTTPS, if I simply add the S I get ERR_CONNECTION_REFUSED. I've looked through all the logs available from Elastic Beanstalk and there are no errors.
How can I get more detail on why the traffic is not forwarding? How would I be able to determine if the problem is the certificate, or the key, or some other error in a config file, etc?
In my AWS environment I have 2 hosted zones:
aaa.nl
bbb.nl
I have an elastic beanstalk (NodeJS) application running. It works fine. I want this EB application to be available via the domain name:
my-app.bbb.nl
I followed this approach:
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-to-beanstalk-environment.html#routing-to-beanstalk-environment-create-alias-procedure
Configuring a new record is easy. I can select my EB application and the record is created successfully. And i see it listed in the record list of hosted zone bbb.nl (A Record)
Now I open up my browser and navigate to:
my-app.bbb.nl
To my great surprise, what I get to see in the browser is a different application that I have running at https://my-other-app.aaa.nl, but the url is https://app.bbb.nl (my-other-app is listed as an A record in hosted zone aaa.nl)
I did get some certificate warnings in my browser as well (in the browser I see that it has the ssl certificate of aaa.nl coming along),
I do have something else running correctly at https://bbb.nl
I have no idea how this is possible and how to debug this. Anyone any clues?
Use browser development tools to trace the request to my-app.bbb.nl
Look for redirection in response.
Check if my-other-app.aaa.nl isn't hardcoded into app itself.
I have my server application deployed in AWS with Beanstalk.
I'm using Beanstalk with Application Loadbalancer.
Beanstalk is very handy in autoconfiguring all for me and I like to use it, but,
for now, every Beanstalk instance contains NGNIX for proxy requests, but because I already have LoadBalancer that redirects requests to my server and responsible for SSL certificates, I don't see why I need NGNIX and I want to remove it from configuration (or at least not to use it between LoadBalancer and Application server).
Moreover, during my load testing and hight load, NGNIX causing me troubles (it takes a lot of CPU time, and crying about worker_connections)
But I can't find any option to use my beanstalk with load balancer without NGNIX
I've fixed my problem by configuring load balancer in my EBS. My application was listening on 5000 port (Java), and NGINX redirects from 80 to 5000, Load Balancer sends all requests to 80.
So I have following configuration by default
LB->80:NGNIX->5000:Java server
I've changed in LB Processes from 80 to 5000 so current configuration looks like following: LB->5000:Java server, so LB will redirect all requests directly to my service.
You can see configuration details in
documentation #processes paragraph
I'm a pretty new developer and deployed my first Django app via Elastic Beanstalk. I want to serve https requests and have configured my SSL certificate and have my load balancer set up correctly. When I go into EB > Configuration > Secure listener port and set it to 443 I'm getting the error upon saving:
LoadBalancerHTTPSPort: You have specified both the #deprecated(:default.aws:elb:loadbalancer:LoadBalancerHTTPSPort)
option as well as one in the new aws:elb:listener:443 namespace.
The :default.aws:elb:loadbalancer:LoadBalancerHTTPSPort option will be ignored.
Not sure what I'm missing because I'm still not able to serve https requests
I had the same problem with a NodeJS Elastic Beanstalk app. However, I was able to get around it by updating the Listener/Certificate settings via the AWS EC2 console (https://console.aws.amazon.com/ec2/), via the Load Balancers section (under LOAD BALANCING).
I was updating the certificate for a staging version of a cloned environment. This was the only way I could assign a different certificate to the staging environment.
See more at http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-create-https-ssl-load-balancer.html
When my Java application is deployed to Tomcat on Elastic-Beanastalk it takes a while (11 minutes) because it has to copy large data files from S3 and unzip them, but that is okay because this is all done in .ebextensions and the instance doesn't report itself ready until that is completed.
However, I have it configured for Autoscaling and it seems that when it decides it needs to start a new instance there is a period before the next instance has fully deployed that Elastic-Beanstalk will direct some application requests to this new server, of course because it is not ready it returns a 503 error.
But surely all calls should only go to the original instance until the second one is ready, has anyone else noticed this ?
Whether requests are directed to the new instance or not is decided by the Elastic Load Balancer (ELB). Your autoscaled instances are behind the ELB and ELB performs periodic health checks on your EC2 instances to decide whether traffic to your instances or not. By default the health check is TCP connect on port 80. So if ELB can establish a connection to port 80 on the Tomcat server, it will start sending traffic to the instance even before it is actually "ready".
The solution is to use a custom HTTP health check instead of the default TCP check. Set up your web app to return a 200 OK on a special path say '/health_ping'. Then configure the "Application Healthcheck URL" option to "/health_ping". You can do this using the following ebextension.
Create a file called .ebextensions/01-health-check.config in your app source with the following contents. Then deploy it to your environment.
option_settings:
- namespace: aws:elasticbeanstalk:application
option_name: Application Healthcheck URL
value: /health_ping
Read more about this option setting here.
You can also configure this in the web console or using the aws cli.