You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Feature Request]: Separate SubnetIds for Login Node NLB and EC2 Instances #7462
Currently, LoginNodes → Pools → Networking → SubnetIds is used for both the Network Load Balancer placement and the login node EC2 instance placement. This prevents implementing the standard AWS architecture pattern of an internet-facing NLB in a public subnet forwarding traffic to EC2 instances in private subnets.
Expected Behavior
Allow specifying separate subnets for the NLB and the login node instances, for example:
LoginNodes:
Pools:
- Name: cfd-loginCount: 1InstanceType: t3.largeNetworking:
LoadBalancerSubnetIds:
- subnet-public-xxx # NLB placed here (internet-facing)SubnetIds:
- subnet-private-xxx # EC2 instances placed here (no public IP)
This would enable the architecture:
Internet → Public NLB (public subnet) → Login Node EC2 (private subnet)
Current Behavior
SubnetIds controls both the NLB and instance placement:
Private subnet → NLB becomes internal, instances are in private subnet
Public subnet → NLB is internet-facing, but instances are also placed in the public subnet
There is no way to decouple these, resulting in either:
Instances unnecessarily exposed in public subnets, or
An internal-only NLB requiring a bastion/VPN for access
Use Case
This is a standard AWS networking pattern used widely across ELB-backed services (ECS, EKS, EC2 Auto Scaling). The AWS prescriptive guidance on load balancer subnets documents this as a recommended architecture:
NLB in public subnets (receives internet traffic)
Target instances in private subnets (no direct internet exposure)
NAT Gateway in public subnet for outbound-only internet access from instances
For HPC clusters that need to provide SSH access to external users (collaborators, researchers) while keeping login nodes hardened in private subnets, this separation is essential for security best practices.
Proposed Solution
Add an optional LoadBalancerSubnetIds (or ElasticLoadBalancerSubnetIds) parameter under LoginNodes → Pools → Networking:
changed the title [-]Feature: Separate SubnetIds for Login Node NLB and EC2 Instances[/-][+][Feature Request]: Separate SubnetIds for Login Node NLB and EC2 Instances[/+]on Jun 30, 2026
Activity
[-]Feature: Separate SubnetIds for Login Node NLB and EC2 Instances[/-][+][Feature Request]: Separate SubnetIds for Login Node NLB and EC2 Instances[/+]hgreebe commentedon Jul 1, 2026
I have added this to our backlog