NLBInternal
Internal Network Load Balancer (NLB) for the Rack. When enabled, creates a VPC-internal Layer 4 load balancer that Services can opt into via the nlb: field (scheme: internal) in convox.yml.
| Setting | Value |
|---|---|
| Default value | No |
| Allowed values | Yes, No |
Use Cases
- Cross-service TCP traffic between Apps inside the same VPC (peered VPCs, VPN clients)
- Dedicated internal endpoints for databases, caches, or back-end Services that should never be reachable from the public internet
- Stable DNS for an internal listener consumed by other AWS accounts or peered VPCs
Prerequisites
NLBInternal=Yes requires Internal=Yes. Set both in a single call:
$ convox rack params set Internal=Yes NLBInternal=Yes
Unlike the public NLB, the internal NLB does not consume any Elastic IPs. AWS assigns private IPs from the selected subnets.
Additional Information
When set to Yes, Convox provisions:
- An
AWS::ElasticLoadBalancingV2::LoadBalancerof typenetworkwithScheme: internal - A dedicated
NLBInternalSecuritysecurity group (exported as${Rack}:NLBInternalSecurityGroup) - Ingress rules derived from NLBInternalAllowCIDR (defaults to the Rack's VPCCIDR when empty) plus any per-port allow_cidr: entries declared by Services
Subnet placement depends on the Rack's Private parameter:
Private=Yes→ internal NLB lives in the Rack's private subnets (SubnetPrivate0/1/2)Private=No→ internal NLB lives in the Rack's public subnets withScheme=internal(matching the existingRouterInternalALB placement pattern)
Services opt in per-port using scheme: internal under the nlb: field in convox.yml. Each declared port becomes a dedicated Listener + TargetGroup on the shared internal NLB.
The internal NLB's DNS name is visible via convox rack once CloudFormation completes.
Related Rack parameters
- NLBInternalAllowCIDR: CIDR allowlist (defaults to VPC CIDR when empty)
- NLBInternalCrossZone: enable cross-zone load balancing on internal listeners
- NLBInternalPreserveClientIP: forward real client IP to target tasks
- NLBInternalDeletionProtection: block accidental internal NLB deletion
Disable
Before setting NLBInternal=No, remove any nlb: entries with scheme: internal from all deployed Apps and redeploy. The disable is refused with a list of blocking Apps otherwise. For a Service that declares only nlb: ports, see Removing ports from an NLB-only Service.
If NLBInternalDeletionProtection=Yes, NLBInternal=No is also rejected pre-flight; disable deletion protection first, wait for the update to complete, then toggle NLBInternal=No in a follow-up call.
On a Rack with a custom InstanceSecurityGroup, remove any ingress rule on that group that references the internal NLB security group before setting NLBInternal=No. EC2 does not delete a security group that another group's rule references, so the update would leave the internal NLB security group behind.
Known Limitations
Internal NLBs publish stable DNS names, which slightly lowers discovery cost for an in-VPC attacker pivoting between Apps, so rely on application-layer authentication, not network obscurity. Tighten reachability with NLBInternalAllowCIDR or per-port allow_cidr: if the default VPC-wide posture is broader than needed.
See Network Load Balancing for the shared limitations list (50-listener quota, concurrent-deploy caveats, downgrade procedure).
See Also
