Common outbound IP, individual inbound IPs?

Besides SSH access across public internet, can you login to your AWS console and use SSM Session Manager and EC2 Instance Connect? SSM do not need to allow inbound access from public internet, and works for EC2 instance in private subnet.

With Session Manager plugin for the AWS CLI, you can start a SSH session and terminal session from your local desktop.

Hello.

How about using NLB as a load balancer?
With NLB, it is possible to fix the public IP address, so you do not need to register it on a whitelist even if EC2 scales.
https://repost.aws/knowledge-center/alb-static-ip

If you want to keep costs down, you can create another EC2 instance and use it as a reverse proxy server.
https://ngrok.com/blog/reverse-proxy-aws

For security reasons, it's better not to have the EC2s in public subnet, at least, not for SSH access. For situations like this, you can take advantage of AWS VPC Verified Access and it supports SSH and RDP.

https://aws.amazon.com/blogs/aws/aws-verified-access-now-supports-secure-access-to-resources-over-non-https-protocols/

Hi, You can solve this by decoupling inbound and outbound traffic paths.

Keep each Elastic Beanstalk instance in a public subnet so it retains its own public IP address for inbound access such as SSH. For outbound traffic, configure routing so that all external requests go through a NAT Gateway with a single Elastic IP instead of directly through the Internet Gateway.

In this setup, inbound connections continue to use the instance’s individual public IPs, while outbound connections are translated and sent through the NAT Gateway’s fixed Elastic IP. This allows you to whitelist one stable IP address with the third-party service, regardless of how many development environments or instances you create.

The key point is that outbound behavior is controlled by the route table, not by whether an instance has a public IP. By directing the default outbound route to a NAT Gateway, you centralize egress traffic without affecting inbound connectivity.

This approach is commonly used in AWS environments and scales cleanly as new development instances are added, significantly reducing operational overhead for IP whitelisting.