- Newest
- Most votes
- Most comments
Your best bet is to put the Beanstalk instances in private subnets and allow their internet access to egress through NAT gateways (with Elastic IPs) in public subnets. A NAT gateway with an associated EIP should not change and you can have the EIPs added to an allow list on the API side.
If this answer provided benefit, please mark the answer as accepted.
Hi,
Proposal in a different direction: create an additional resource (EC2 instance, Fargate container, container) with EIP fully under your control acting as a relay to internet API and have your ELB instances talk to this relay (located on same vpc) to query this API.
Going serverless rather than EC2 should minimize your additional costs (and provide proper scalability if needed)
This way you would get independent of ELB updates mechanisms.
I know it's not your question but just in case you're open to different options.
Best,
Didier
Thanks my friend, it worked! The solution was to create a private subnet with a NAT Gateway on a public subnet.
Relevant content
- asked 9 months ago
Dear friend, Thanks for the answer. I followed as you suggested and created two subnets with a NAT gateway in each one's routing table, but we were unable to upload the selected beanstalk instances, we received the error below:
The EC2 instances failed to communicate with AWS Elastic Beanstalk, either because of configuration problems with the VPC or a failed EC2 instance. Check your VPC configuration and try launching the environment again.
do you have any tips?
Thanks my friend, it worked!