Exploring Public Service Hosting Options on EKS
Dinesh Sharma
Mentor | AWS Ambassador | Puluminary | AWS Community Builder | AWS Regional Practice Lead | IaC Ninja | Desi | PB13 | RJ19
Today, we're diving into the increasingly relevant world of Amazon EKS to uncover various strategies for hosting public services. At first glance, this might seem straightforward, but the rise of centralized network services accounts, or Network Hubs, has introduced new complexities. More organizations are adopting this architecture, bringing about a common dilemma: the hesitation to directly expose public services to the internet. This scenario often leaves organizations weighing their options, seeking the most effective method to make services publicly available on EKS without straightforward exposure from the workload account.
In this blog, we will explore the most efficient and secure ways to host public services on Amazon EKS, focusing on strategies that leverage both workload and network hub accounts. Our journey will dissect four distinct approaches:
?I hope by the end of this exploration, you'll have a clearer understanding of the potential pathways to host public services on Amazon EKS, including options that might not immediately come to mind. Let’s navigate the intricacies of each method to find the best fit for your organizational needs and security requirements.
Option 1: El-Classico - Public ALB inside the local workload account
Utilizing public subnets and an Application Load Balancer (ALB) is similar to the open-door policy of hosting services—inviting yet secure. This method relies on the presence of public subnets within your VPC, which may necessitate the creation of new ones if your setup is traditionally more private.
Key Details and Considerations:
Public Subnets Creation: Essential for those starting in a private-only landscape. This involves creation of public subnets inside the VPC. I personally prefer to create the subnet which are spanned across the 3 AZs. So, in short, if your workload VPC lacks public subnets, you'll need to establish them.
Internet Gateway (IGW) Attachment: To facilitate inbound traffic for public services, it's necessary to create an Internet Gateway (IGW) and attach it to the VPC.
Route Table Adjustments: Here lies the choreography of traffic flow. Ensuring your public subnets can route traffic to and from the IGW is crucial. Please make sure to create separate route table(s) for your public subnets with default route pointing towards the 0.0.0.0/0.
Application Load Balancer: When we talk about hosting public services, it's important to keep your EKS pods in the private subnets. However, the Application Load Balancer (ALB) responsible for hosting the public service should be placed in the new public subnets. Don't forget to configure the ALB controller annotation to be internet-facing.
Pros & Cons
Option 2: The Underdog - AWS Global Accelerator Meets Private ALB
Now that we've covered Option 1 aka main stream approach, let's shift our focus to explore alternative methods or the backbenchers of the class :). No offense to backbenchers – I was one myself back in my school days!
AWS Global Accelerator, known for enhancing global application availability and performance, can also serve as a front for private services. This solution doesn't necessitate any tweaks to the VPC architecture; the current setup will suffice. By linking the private ALB hosting the service with Global Accelerator, we can seamlessly expose the service to the public internet without tinkering with VPC, subnet, or route tables. This approach efficiently meets the immediate need to make the service accessible to the public internet.
Key Details and Considerations:
Integration with Private ALBs: To accommodate public traffic, a new private-facing ALB must be established within the same private subnets. The ALB controller annotation should be set to internal.
Although the ALB is configured as private, it's important to provision it within a public namespace or a namespace which is meant for services hosting the public traffic. This ensures a clear distinction between private and public services. You may wonder why a private ALB should be placed within a public namespace. The rationale behind this approach lies in the fact that the service delivered through the ALB and its intended audience are public. Despite the service being hosted privately, its consumers are from the public internet. Segregating traffic in this manner, based on its nature and target audience, ensures that internal and external traffic are appropriately handled.
Simplified Network Configuration: This method shines in its ability to bypass extensive VPC or subnet reconfiguration, offering a straightforward path to public accessibility without the infrastructural gymnastics.
Pros & Cons
Option 3: Sharing Network Hub VPC with the Workload Account
领英推荐
This method involves the utilization of AWS Resource Access Manager to share the network hub VPC with the workload VPCs. A new ingress controller will be deployed within the EKS cluster. This ingress controller will be configured to direct traffic to the public subnets that have been shared with the workload accounts via VPC sharing.
The solution includes a approach to set up and configure Virtual Private Cloud (VPC) sharing between a shared/network hub account and the workload account. This involves the deployment of an Amazon Elastic Kubernetes Service (EKS) cluster, which includes a managed node group operating within a shared subnet. Furthermore, the solution includes the deployment and configuration of the AWS Load Balancer Controller within the newly established shared subnets. This configuration is crucial for providing efficient network traffic management and ensuring optimal performance and scalability of applications running on the EKS cluster.
Key Details and Considerations:
ALB placement: To handle internet/public traffic, it's crucial to set up a new public-facing Application Load Balancer (ALB). This ALB serves as the gateway for services that require exposure to the public internet. It should be strategically placed within the public subnet inside the Networkhub account to ensure accessibility from external networks. Additionally, configuring the ALB controller annotation as internet-facing is essential to enable external access and route incoming requests effectively.
Pros & Cons
Option 4: Private ALB with NLB and Public ALB in NetworkHub
This option is what I call a symphony of load balancers. While we are discussing different ways to host public services, this is another method that can be used. Although it is a bit complex, every use case exists for a reason ??.
This strategy involves deploying a Network Load Balancer (NLB) with static private IP addresses in front of an Application Load Balancer (ALB) that serves the application requiring public accessibility. The NLB is configured within the workload account to leverage its static private IPs. A new public-facing ALB is created within the NetworkHub account, which is configured to target the static IP addresses of the NLB as its backend targets. This layered architecture allows for the public exposure of services hosted behind the ALB in the workload account, utilizing the NLB's static private IPs for stable connectivity and the public ALB for external access.
Key Details and Considerations:
Load Balancers: ALB Configuration within the Workload Account: To cater to internet/public traffic, a new private ALB needs to be configured within the public namespace of the EKS cluster. This ALB is strategically placed in a private subnet and serves as the gateway for services requiring public accessibility.
NLB Setup within the Workload Account: Similarly, a Network Load Balancer (NLB) should be provisioned to act as a front for the private ALB. This NLB facilitates the exposure of internet-facing functionalities and must be configured with static private IP addresses to ensure reliable targeting and accessibility.
Public ALB in the Network Hub Account: Within the network hub account, it's essential to establish a public-facing ALB. This ALB is configured to target the static private IP addresses allocated to the NLB in the workload account. This setup effectively bridges internet traffic to the services hosted behind the private ALB within the workload account.
Security Group Configurations for ALB & NLB: For the public ALB located in the network hub account, its associated security group can be configured to allow unrestricted internet access or can be tightly controlled to only permit connections from specific public IP addresses, based on the service's exposure requirements and target audience.
The security group associated with the private ALB must be configured to permit incoming traffic from the NLB’s security group. Additionally, the NLB’s security group needs to allow incoming connections from the CIDR ranges of the public subnets within the network hub account. This ensures secure communication between the ALB and NLB, maintaining the integrity of the network environment.
Pros & Cons
Cost Comparison
Kicking things off with Option 1 is like choosing the chill path—it's both the simplest and easiest on your wallet, with an estimation of $24.24. Think of it as grabbing a quick coffee on your way to work. Then there's Option 3, which is kind of like sharing that coffee—it doesn't cost you any more, but it does make things a bit more complicated since you're diving into VPC and subnet sharing shenanigans. Option 2 spices things up a bit, costing more at $57.24, but without the hassle of sharing your coffee. And finally, Option 4 is like ordering the deluxe coffee with all the fancy toppings. Sure, it's the most complex and expensive at $123.82, but it's also packed with all the bells and whistles you could want.
Please note: Cost estimation specifically focused on additional services such as ALB, NLB, and Global Accelerator to provide a cost estimation. Other components either do not incur additional costs or are shared across multiple approaches, such as traffic handling, EKS, NAT services, etc.
Cost estimation assumptions
Conclusion
Each option presents a unique path to achieving public visibility for services hosted on EKS, from the straightforward simplicity of public subnets to the intricate dance of load balancers. The choice hinges on your architectural preferences, security posture, and, of course, the level of engagement you desire with your public audience. Happy hosting, and may your services shine brightly in the public domain with all the security and efficiency you need. :)