I have an Elastic Beanstalk server behind an Application Load Balancer, all inside a VPC. The first call to the server after leaving it along for a while takes a very long time. It's almost as if the instance is being booted up right then! Instead of being already on...
This issue does not present locally, nor outside of a VPC, it only happens in the VPC on AWS so something in my configuration must be off.
The VPC has 3 public and 3 private subnets, in the same availability zones, and the public subnets all have auto-assign public IP on
I've assigned these to the network settings on my Elastic Beanstalk environment, assigning the public subnets to the public load balancer, and then the private subnets to the private instance.
I've set the auto scaling load balanced group with minimum of 3 instances, and confirmed they're running
Despite this, after leaving the site alone for a while... the first new call to the server consistently takes over one minute, and then works great. I assume I'm just missing something small but cannot figure out what it is...
Thanks in advance!
I am convinced this is not an application issue because, on first load the call takes over one minute, but on subsequent loads it's near instant, and this behavior is constant across days. Locally, I never have this issue. Outside a VPC, I never have this issue.
first/slow load (after leaving the app alone overnight)
second/fast load (refreshing right after the above)
UPDATE
AWS support suggested I deassociate the subnets from my route tables. I did that and now all subnets public and private are showing current routing table Main. Now though, instead of taking a long time all calls to my server are failing!
I tried attaching the internet gateway in that VPC to the routing table via edge association but I'm getting the error that
Route table contains unsupported route destination. The unsupported route destination is less specific than or non-overlapping with VPC local CIDR
There is one public subnet with overlapping CIDRs with the internet gateway (10.1.0.0/24 on the subnet and 10.1.0.0/24 on the gateway). I tried manually associating that to the Main routing table but still get the same error