Skip to content

How to add ALBC-managed ingress in a separate AWS account without disrupting existing EKS ALBC in Account A?

0

I have an EKS cluster in Account A with ALB Controller already running and services exposed. I need to create a new NLB in Account B using ALBC, but I want to ensure there’s no disruption to the existing setup in Account A. What’s the recommended approach?

I am aware of this blog however my question is around existing ALBs in account A and no interruption to ALB/services running in account A.

https://aws.amazon.com/blogs/containers/expose-amazon-eks-pods-through-cross-account-load-balancer/

AWS

asked a year ago251 views

1 Answer
0
Accepted Answer

You cannot create an ALB target group in a different AWS account from where the ALB itself resides. This is a limitation of AWS's architecture. For your scenario where you have an EKS cluster in Account A with existing ALB Controller (ALBC) services and want to add a Network Load Balancer (NLB) in Account B, here are the recommended approaches:

  1. Use IP-based target groups: If your accounts are connected via Transit Gateway or have network connectivity, you can create an NLB in Account B with IP-based target groups that reference the private IP addresses of your pods/nodes in Account A. This approach requires:
  • Setting alb.ingress.kubernetes.io/target-type: ip in your ingress annotations
  • Ensuring proper network connectivity between accounts
  • Managing the IP addresses of your targets
  1. Use AWS PrivateLink: Create a VPC endpoint service in Account A that your resources in Account B can connect to. This provides a private connection between the accounts without exposing traffic to the public internet.

  2. Deploy a separate ALBC instance in Account B: Install a separate AWS Load Balancer Controller in Account B with its own IAM permissions. This controller would only manage resources in Account B and wouldn't interfere with the existing controller in Account A.

For any cross-account load balancer setup, you'll need to:

  • Ensure proper IAM permissions are in place
  • Configure appropriate network connectivity between accounts
  • Consider using annotations in your Kubernetes resources to specify which controller should manage which resources

To avoid disruption to existing services in Account A, make sure that:

  • You don't modify the existing ALBC configuration in Account A
  • Any new controller in Account B has its own service account and IAM role
  • You properly scope the permissions of any new controller to only manage resources in its respective account

This approach allows you to maintain your existing setup in Account A while extending your infrastructure to Account B.
Sources
ALB can have its target group in different account? | AWS re:Post
APIGateway and NLB cross account integration | AWS re:Post
Unpacking the Cluster Networking for Amazon EKS Hybrid Nodes | AWS re:Post

answered a year ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.