When it comes to building an integration platform, you have two major approaches:

1. Using an open-source framework like Apache Camel to build and manage your own integrations.
2. Leveraging an Integration Platform as a Service (iPaaS) like MuleSoft, Boomi, or SnapLogic to handle integration as a managed service.

So, how do you decide which one is right for your business? Lets break it down.

Apache Camel: The Developers Choice

Apache Camel is a powerful open-source integration framework that enables developers to build custom integration solutions using Enterprise Integration Patterns (EIPs). It is widely used for on-premises, hybrid-cloud, and microservices-based architectures.

Pros:

• Flexibility & Control Highly customizable and developer-friendly.
• Lightweight & Efficient Can be embedded in Java applications (Spring Boot, Quarkus, etc.).
• Cost-Effective Open-source with no licensing fees.
• Strong Community & Ecosystem Large number of connectors and support for Kubernetes (Camel K).

Cons:

• Requires Development Effort Needs strong Java/Spring/Kotlin skills.
• Operational Complexity You must handle deployment, scaling, and security.
• No Built-in UI & Monitoring Requires additional tools (Prometheus, ELK, OpenTelemetry) for observability.

iPaaS (MuleSoft, Boomi, SnapLogic): The Business-Friendly Option

Integration Platform as a Service (iPaaS) solutions provide low-code/no-code capabilities with pre-built connectors, API management, and monitoring tools. These platforms are designed for cloud-based and hybrid integration use cases.

Pros:

• Rapid Development & Deployment Drag-and-drop UI with prebuilt connectors.
• Cloud-Native & Managed No infrastructure management needed.
• Built-in Security & Compliance Includes access control, encryption, and governance features.
• Monitoring & Analytics Out-of-the-box error handling, logging, and dashboards.

Cons:

• Expensive Licensing Subscription costs can be high for enterprises.
• Vendor Lock-in Moving away can be challenging.
• Limited Customization Some complex integrations require scripting (e.g., DataWeave in MuleSoft).

When to Choose What?

Choose Apache Camel if:

• You have a strong Java/Spring development team.
• You need custom integrations with high performance.
• You prefer an open-source, cost-effective solution.
• You require on-premises or hybrid-cloud integration.

Choose iPaaS (MuleSoft, Boomi, SnapLogic, etc.) if:

• You want quick deployment with low-code capabilities.
• You need a fully managed integration platform.
• Your team consists of business users & non-developers.
• You integrate common SaaS applications (Salesforce, Workday, SAP, etc.).

Final Thoughts

If you need full control and prefer open-source, Apache Camel is a great choice. But if you want faster time to market and dont mind the cost, an iPaaS solution like MuleSoft, Boomi, or SnapLogic can be a better option.

Introduction

vCluster is a lightweight, virtual Kubernetes cluster solution that allows running multiple Kubernetes clusters within a single Kubernetes host cluster. It is useful for multi-tenancy, development, and testing scenarios without the overhead of managing multiple EKS clusters.

In this guide, we will deploy vCluster on an AWS EKS cluster using Helm.

Prerequisites

Before proceeding, ensure you have the following:

• AWS CLI installed and configured with appropriate permissions.
• kubectl installed and configured to access your EKS cluster.
• Helm installed (v3 recommended).
• eksctl installed to manage EKS clusters.
• An existing AWS EKS cluster or create a new one.

Step 1: Create an EKS Cluster (If Needed)

If you don’t have an existing EKS cluster, create one using eksctl:

1

eksctl create cluster --name my-eks-cluster --region us-west-2 --nodegroup-name standard-workers --node-type t3.medium --nodes 2

Verify the cluster:

1

kubectl get nodes

Step 2: Install Helm

If Helm is not installed, you can install it using the following:

1

curl -fsSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Verify the installation:

1

helm version

Step 3: Add the vCluster Helm Repository

Add the loft Helm repository which contains the vCluster chart:

1
2

helm repo add loft-sh https://charts.loft.sh
helm repo update

Step 4: Deploy vCluster Using Helm

Create a namespace for vCluster:

1

kubectl create namespace vcluster

Deploy vCluster using Helm:

1

helm install my-vcluster loft-sh/vcluster -n vcluster

Verify the deployment:

1

kubectl get pods -n vcluster

You should see the vCluster pods running.

Step 5: Connect to vCluster

To interact with the vCluster, use the following command:

1

vcluster connect my-vcluster -n vcluster -- kubectl get nodes

This command sets up port forwarding and allows you to interact with the virtual cluster using kubectl.

Step 6: Deploy Workloads in vCluster

Once connected to vCluster, you can deploy workloads as you would on any Kubernetes cluster.

Example:

1

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

Verify the deployment:

1

kubectl get pods

Step 7: Deleting vCluster

To remove vCluster from your EKS cluster:

1
2

helm uninstall my-vcluster -n vcluster
kubectl delete namespace vcluster

If you created an EKS cluster specifically for this, you can delete it with:

1

eksctl delete cluster --name my-eks-cluster

Conclusion

In this guide, we deployed vCluster on AWS EKS using Helm, connected to the virtual cluster, and deployed workloads within it. vCluster provides a great way to create isolated environments for testing, development, and multi-tenancy within Kubernetes clusters efficiently.

Happy coding!

Local Network Packet Analysis Tool for API Inventory

In Taiwan’s business environment, many organizations have strict data security requirements and prefer to keep sensitive network data within their premises. This tool addresses these specific needs by providing a local solution for API inventory management API .

Key Features

100% Local Processing

All packet analysis happens on your local machine, ensuring that your network traffic never leaves your infrastructure.

No Cloud Upload

Unlike SaaS solutions, your PCAP files remain securely stored within your local environment. No external servers, no third-party data sharing.

API Inventory Discovery

Easily identify and catalog internal APIs running within your network, providing full visibility into API communications.

Compliance Friendly

This tool aligns with local data protection preferences and security policies in Taiwan, making it an ideal choice for enterprises handling sensitive data.

Approach & Implementation

Frontend: React-Based UI

The front end is built using React 19, leveraging modern UI frameworks for a smooth user experience. The key dependencies include:

1
2
3
4
5

{
  "react": "^19.0.0",
  "react-dom": "^19.0.0",
  "react-scripts": "5.0.1"
}

To improve performance, we are considering migrating to Vite instead of Create React App.

Backend: FastAPI-Powered API Processing

The backend is built using FastAPI, a high-performance Python framework that enables rapid development and efficient processing. Key advantages include:

• Asynchronous processing for handling large volumes of network traffic efficiently.
• Automatic OpenAPI documentation for seamless integration with API tools.
• Integrated Pydantic validation to ensure data accuracy and security.

Example FastAPI endpoint for processing PCAP files:

1
2
3
4
5
6
7
8
9
10

from fastapi import FastAPI, UploadFile, File
import scapy.all as scapy

app = FastAPI()

@app.post("/upload-pcap/")
async def upload_pcap(file: UploadFile = File(...)):
    content = await file.read()
    packets = scapy.rdpcap(content)
    return {"total_packets": len(packets)}

Packet Analysis & API Discovery

The tool processes PCAP files locally, extracting API-related metadata such as endpoints, methods, and response times. The backend uses Scapy (Python) or Tshark to analyze network traffic in real-time without exposing sensitive data externally.

Data Visualization

To provide insights into API traffic, the frontend includes interactive dashboards powered by Recharts or D3.js, allowing users to visualize:

• API request volume
• Response latency
• Error rates

GitHub Repository

The source code for this project is available on GitHub:
View on GitHub

Feel free to explore, contribute, or raise issues!

Stay tuned for more updates on this API security tool! If you’re interested in a demo or have feedback, feel free to reach out.

AWS Data Transfer Costs Breakdown

Understanding AWS data transfer costs is crucial for optimizing cloud expenses. AWS charges for outbound data transfer while inbound traffic is usually free. This blog post breaks down the key aspects of AWS data transfer pricing, helping you minimize unnecessary costs.

Data Transfer Cost Breakdown

1 ELB to EC2 Traffic

• Traffic between an Elastic Load Balancer (ELB) and EC2 instances within the same Availability Zone (AZ) is free.
• However, when ELB sends traffic to another AZ, AWS applies standard inter-AZ transfer charges.

2 Load Balancer (LB) Costs

• Application Load Balancers (ALB) charge based on LCUs.
• Network Load Balancers (NLB) charge based on NLCUs.
• Gateway Load Balancers (GLB) charge in GLCUs rather than per GB.

3 CloudFront Outbound Traffic

• AWS CloudFront offers free outbound traffic for the first 1TB per month.
• Additional usage costs range between $0.02 - $0.12 per GB, depending on the region and usage patterns.

4 General AWS Outbound Data Costs

• AWS charges $20 per TB for outbound traffic up to 10TB.
• Discounts apply for larger volumes.
• The first 100GB per month is free.

5 NAT Gateway Costs

• Using a Managed NAT Gateway incurs additional charges of $0.045 per GB on top of regular data transfer costs.
• This also applies to internal transfers (e.g., between S3, Kinesis, etc.).

6 Elastic/Public IPs and Internal Traffic Costs

• Using public or elastic IPs for internal AWS communication adds extra costs for both incoming and outgoing data.

7 Data Transfer Between AWS Regions

• AWS charges $0.02 per GB for data transfers between AWS regions.

8 Transit Gateway Charges

• Sending data via an AWS Transit Gateway incurs a fee of $0.02 per GB.

Optimizing AWS Data Transfer Costs

To reduce AWS data transfer expenses:

• Use VPC Peering instead of NAT Gateway when possible.
• Leverage AWS PrivateLink for inter-service communication.
• Minimize inter-AZ traffic by keeping workloads within the same AZ.
• Utilize CloudFronts free tier for global content delivery.
• Monitor data transfer patterns using AWS Cost Explorer.

Conclusion

AWS data transfer costs can add up quickly, especially for large-scale deployments. Understanding pricing models and following best practices can help optimize expenses and reduce unnecessary charges. Always keep an eye on networking costs as part of your AWS cost management strategy.

k
As organizations adopt Kubernetes for large-scale applications, multitenancy becomes a critical concern. This article explores different approaches to making a Kubernetes cluster multitenant while ensuring proper tenant isolation.

Why Multitenancy in Kubernetes?

Multitenancy allows multiple teams or applications to share a Kubernetes cluster while maintaining:

• Security: Preventing unauthorized access between tenants.
• Resource Efficiency: Maximizing infrastructure usage.
• Operational Simplicity: Managing fewer clusters while maintaining isolation.

Kubernetes does not provide built-in multitenancy features, so implementing isolation requires a combination of namespaces, RBAC, network policies, and resource constraints.

Types of Multitenancy Approaches

1. Logical Isolation (Soft Multitenancy)

Logical isolation is achieved within a shared cluster using namespaces, RBAC, and policies.

a) Namespace-Based Isolation

Each tenant gets a dedicated namespace, restricting workloads to that namespace.

1
2
3
4

apiVersion: v1
kind: Namespace
metadata:
  name: tenant1

• Use RBAC (Role-Based Access Control) to restrict access:

1
2
3
4
5
6
7
8
9

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: tenant1
  name: tenant1-role
rules:
  - apiGroups: [""]
    resources: ["pods", "services"]
    verbs: ["create", "delete", "get", "list", "watch"]

1
2
3
4
5
6
7
8
9
10
11
12
13

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: tenant1
  name: tenant1-binding
subjects:
  - kind: User
    name: tenant1-user
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: tenant1-role
  apiGroup: rbac.authorization.k8s.io

b) Network Isolation

By default, all pods in a cluster can communicate with each other. To isolate tenants:

• Use Network Policies to limit communication.
• Example: Deny all ingress and egress traffic.

1
2
3
4
5
6
7
8
9
10
11
12

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  namespace: tenant1
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress: []
  egress: []

c) Resource Quotas & Limits

Prevent tenants from consuming excessive resources.

1
2
3
4
5
6
7
8
9
10
11
12

apiVersion: v1
kind: ResourceQuota
metadata:
  namespace: tenant1
  name: tenant1-quota
spec:
  hard:
    pods: "10"
    requests.cpu: "4"
    requests.memory: "8Gi"
    limits.cpu: "8"
    limits.memory: "16Gi"

d) Pod Security Admission

• Enforce security rules (e.g., no privileged containers, running as non-root).
• Replace deprecated PodSecurityPolicy with Pod Security Admission in Kubernetes 1.23+.

2. Hard Isolation (Strong Multitenancy)

For stronger security, tenants should have dedicated infrastructure or virtual clusters.

a) Dedicated Node Pools (Taints & Tolerations)

• Assign specific nodes to tenants.
• Use taints & tolerations to ensure workloads are scheduled only on designated nodes.

1

kubectl taint nodes node1 tenant=tenant1:NoSchedule

1
2
3
4
5

tolerations:
  - key: "tenant"
    operator: "Equal"
    value: "tenant1"
    effect: "NoSchedule"

b) Virtual Clusters (vCluster)

Loft Labs’ vCluster allows running isolated virtual clusters inside a physical cluster.

1

vcluster create tenant1 --namespace tenant1

Each tenant gets:

• A separate Kubernetes API server.
• Full control over resources.
• Stronger isolation than namespace-based multitenancy.

c) Separate Kubernetes Clusters

For maximum security, each tenant can get its own Kubernetes cluster.

• Managed via Cluster API or Kubernetes Federation.
• Higher cost, but ensures strict tenant isolation.

3. Comparing Multitenancy Approaches

Recommendation:

• Use namespaces + RBAC for lightweight multitenancy.
• Use vClusters for stronger isolation while sharing infrastructure.
• Use dedicated clusters for maximum security.

4. Final Thoughts

Multitenancy in Kubernetes requires a combination of security, access control, and resource isolation. The right approach depends on your needs:

• Small teams: Namespace-based multitenancy is sufficient.
• Enterprise: Virtual clusters or node isolation offer better control.
• Highly regulated environments: Dedicated clusters ensure compliance.

By implementing the right strategy, Kubernetes can support multi-tenant workloads efficiently while maintaining security and performance.

Building a SaaS product in 2025 requires a modern, scalable, and efficient tech stack. With rapid advancements in AI, microservices, and serverless computing, selecting the right technologies is crucial to staying competitive. Heres a breakdown of the essential components you need to consider.

1. Frontend: High-Performance UI Frameworks

Modern SaaS applications demand fast, interactive, and responsive user interfaces. Consider the following frontend technologies:

• Next.js A React-based framework with built-in server-side rendering (SSR) and static site generation (SSG).
• SvelteKit A lightweight alternative offering a faster and simpler development experience.
• Tailwind CSS A utility-first CSS framework that enhances styling efficiency.
• tRPC Type-safe APIs for seamless communication between frontend and backend.

2. Backend: Serverless & Microservices Architecture

Scalability and performance are key to handling growing SaaS demands. Some popular choices include:

• Node.js (Fastify/NestJS) Highly scalable, event-driven architecture.
• Go (Fiber/Gin) Optimized for speed and low resource consumption.
• Django (Python) Ideal for rapid development with built-in security features.
• Serverless Framework Deploy microservices on AWS Lambda, Google Cloud Functions, or Azure Functions.
• gRPC Efficient, high-performance API communication.

3. Database: Scalable & Flexible Storage Solutions

Choosing the right database depends on your data structure and performance needs:

• PostgreSQL Feature-rich relational database with JSONB support.
• MongoDB NoSQL document database for flexible data modeling.
• Redis In-memory caching for high-speed performance.
• PlanetScale A MySQL-compatible, serverless database built on Vitess.

4. AI & Machine Learning: Intelligent Features & Insights

Integrating AI into SaaS applications enhances user experience and automation:

• OpenAI API Natural language processing for chatbots and content generation.
• TensorFlow/PyTorch Machine learning models for personalized recommendations.
• Hugging Face Pre-trained AI models for NLP, vision, and more.

5. DevOps & Deployment: Continuous Delivery & Monitoring

Automating deployment and monitoring ensures reliability:

• Docker & Kubernetes Containerized deployments for scalability.
• Terraform Infrastructure as Code (IaC) for cloud automation.
• Vercel & Netlify Seamless frontend deployment platforms.
• Datadog & Prometheus Real-time monitoring and logging.
• GitHub Actions CI/CD pipelines for automated testing and deployments.

6. Security & Authentication: Protecting User Data

Security is paramount in SaaS applications:

• OAuth 2.0 & OpenID Connect Secure authentication standards.
• Auth0 & Clerk Authentication-as-a-service solutions.
• OWASP ZAP & Snyk Automated security testing.
• Zero Trust Architecture Identity-based security model.

7. Communication & Monetization: Emails and Payments

Effective communication and seamless transactions are essential for a great SaaS experience:

• Emails: Use React Email to create interactive email templates and Resend for a streamlined email-sending experience.
• Payments: Stripe remains a top choice for its comprehensive API and rich ecosystem, though its increasing complexity may require careful integration.

8. Hosting & Domain Management: Reliable Infrastructure

A robust hosting and domain management setup ensures smooth operations:

• Hosting: Vercel (formerly Zeit) offers a hassle-free deployment experience, while Hetzner and DigitalOcean (with Coolify) provide excellent self-hosting alternatives.
• Domains: Cloudflare is the preferred choice for domain management due to its intuitive UI, robust DNS management, and security features.
• Testing & Development Tools: Ensure quality with React Testing Library, Cypress/Playwright for end-to-end testing, and ESLint, Prettier, and Storybook for development efficiency.

9. Additional Tools: When to Use Them

Not every tool is necessary for all projects, but these can be valuable depending on your needs:

• Astro Ideal for blazing-fast landing pages separate from your main app.
• Drizzle ORM A promising alternative to Prisma, worth considering for database interactions.
• React Query Useful when Server Components fall short for data-fetching needs.

Conclusion

The SaaS landscape in 2025 is driven by AI-powered automation, serverless computing, and microservices architecture. By leveraging the right tech stack, you can build scalable, efficient, and secure SaaS products that meet modern user expectations.

Creating architecture diagrams using code has become increasingly popular among developers and architects. This approach enhances consistency, reproducibility, and version control, aligning well with Infrastructure as Code (IaC) principles. Two prominent tools in this space are Mermaid and Architecture as Code (powered by Graphviz). Let’s compare these tools and understand their strengths and limitations.

What is Mermaid?

Mermaid is an open-source JavaScript-based diagramming tool that allows users to create diagrams using a simple, Markdown-like syntax. It supports various types of diagrams, including:

• Flowcharts
• Sequence diagrams
• Class diagrams
• State diagrams
• Entity-relationship diagrams (ERD)
• Gantt charts

Mermaid integrates well with documentation tools like Markdown and can be embedded directly in platforms such as GitHub, GitLab, and Notion. The simplicity of its syntax makes it easy to learn and use for rapid diagram creation.
he

Example of a Flowchart in Mermaid

1
2
3
4

flowchart TD;
  A[Start] --> B{Decision};
  B -->|Yes| C[Proceed];
  B -->|No| D[Exit];

What is Architecture as Code?

Architecture as Code is another approach that leverages Graphviz for generating architecture diagrams. Graphviz is a powerful open-source graph visualization tool that renders structural information into network graphs.

The key benefits of using Architecture as Code with Graphviz include:

• More precise control over diagram rendering
• Better layout optimization for complex diagrams
• Native support for directed graphs

Example of a Graphviz DOT File

1
2
3
4

digraph G {
  A -> B [label="Yes"];
  A -> C [label="No"];
}

Key Differences Between Mermaid and Architecture as Code

Which One Should You Choose?

• If you need quick and simple diagrams that integrate well with Markdown and documentation tools, Mermaid is a great choice.
• If you require highly detailed and customizable architecture diagrams with precise layout control, Architecture as Code (Graphviz) is the better option.

Both tools embrace the diagrams as code approach, allowing teams to store, version, and automate diagram generation within their workflows.

Introduction

Dify is an open-source LLM-powered application development platform that simplifies prototyping, deploying, and managing AI applications. It provides a visual workflow builder, prompt IDE, RAG capabilities, and agent tools that integrate with various AI models like GPT, Mistral, and Llama3.

This blog post will guide you through deploying Dify on Kubernetes using a Helm chart to manage configurations efficiently.

Prerequisites

Before you begin, ensure you have the following:

• A Kubernetes cluster (Minikube, Kind, EKS, AKS, GKE, etc.)
• kubectl installed and configured
• Helm installed (Install Helm)
• Persistent Volume (PV) support for storing data
• PostgreSQL & Redis deployed in your cluster (or external services)

Step 1: Clone the Dify Repository

1
2

git clone https://github.com/langgenius/dify.git
cd dify

Step 2: Deploy Dependencies

Dify requires PostgreSQL (for data storage) and Redis (for caching). You can deploy them using Helm:

Deploy PostgreSQL

1
2
3
4

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install dify-postgres bitnami/postgresql \
  --set auth.postgresPassword=yourpassword \
  --set primary.persistence.enabled=true

Deploy Redis

1
2
3

helm install dify-redis bitnami/redis \
  --set auth.enabled=false \
  --set master.persistence.enabled=true

Step 3: Deploy Dify using Helm

Create a Helm values file (values.yaml) for Dify:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

image:
  repository: langgenius/dify
  tag: latest
  pullPolicy: IfNotPresent

env:
  DATABASE_URL: "postgresql://postgres:yourpassword@dify-postgres.default.svc.cluster.local:5432/postgres"
  REDIS_URL: "redis://dify-redis-master.default.svc.cluster.local:6379"
  SECRET_KEY: "your-random-secret-key"
  BASE_URL: "http://localhost"

service:
  type: ClusterIP
  port: 80

ingress:
  enabled: true
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
  hosts:
    - host: dify.local
      paths:
        - path: /
          pathType: ImplementationSpecific

Now, deploy Dify:

1

helm install dify ./helm-chart -f values.yaml

Step 4: Verify Deployment

Check the deployed pods:

1

kubectl get pods

Expose the service (if not using Ingress):

1

kubectl port-forward svc/dify 8080:80

Access the Dify Web UI at http://localhost:8080 and complete the installation.

Conclusion

In this guide, we successfully deployed Dify on Kubernetes using Helm, along with its dependencies. This setup provides scalability, ease of management, and better security compared to standalone Docker deployments.

Feel free to explore Dify’s agent tools, RAG pipelines, and LLMOps features to build AI-powered applications effectively!

Happy Deploying!

AWS just made a seemingly small but disruptive change to Amazon S3default data integrity protections for new objects. On the surface, this is great: stronger checksums like crc64-nvme offer speed, security, and excellent SIMD support.

But there’s a catch.

AWS also changed the default settings in all its SDKs, breaking compatibility with nearly every S3-compatible service.

Whos Affected?

If you’re using any of these services, you’re likely to run into errors:

• Cloudflare R2 An error occurred (InternalError) when calling the PutObject operation
• Tigris Upgrading boto3 or the JavaScript S3 client? File uploads wont work.
• MinIO, Vast, Dell EC (pre-2025 versions) Same issuecompatibility broken.
• Trino Project Users reporting “Missing required header for this request: Content-MD5.”
• Apache Iceberg Recommending disabling the checksum requirement to avoid failures.

AWS Owns S3, Not Third-Party Vendors

This is a wake-up call for vendors building “S3-compatible” storage solutions. Many rely on AWS’s S3 SDKs, assuming API stability. But AWS can (and does) change the rules anytime.

This time, its checksums. Next time? It could be metadata handling, ACLs, or API versioning.

For anyone building on S3-compatible storage solutions, this proves a key point:
You dont control the S3 API. AWS does.

What Can You Do?

1. Disable the checksum requirement in your AWS SDK settings where possible.
2. Stick to specific SDK versions until your storage provider updates compatibility.
3. Push your vendor to support the new defaults or provide workarounds.
4. Consider alternative protocols Multi-cloud users may want to look beyond S3.

The Bigger Picture

AWS has made it clear that “S3-compatible” is a moving target. If you’re relying on it for long-term data management, now’s the time to rethink your strategy.

Introduction

By default, Amazon EKS provisions a Network Load Balancer (NLB) when creating a LoadBalancer type service using the AWS Load Balancer Controller. However, if you need to use a Classic Load Balancer (CLB) instead, you must disable the default NLB behavior.

In this guide, I’ll show you how to configure EKS to use Classic Load Balancers by default.

Problem: Why is NLB Used by Default?

Starting from AWS Load Balancer Controller v2.5, Kubernetes services of type LoadBalancer automatically use an NLB. This happens due to the service mutator webhook, which sets:

1
2

spec:
  loadBalancerClass: service.k8s.aws/nlb

By default, this webhook prevents the use of Classic Load Balancers (CLB). The solution? Disable the webhook!

How to Disable enableServiceMutatorWebhook

The AWS Load Balancer Controller allows you to disable the automatic NLB behavior by setting enableServiceMutatorWebhook=false.

If you installed the AWS Load Balancer Controller via Helm, run:

1
2
3

helm upgrade aws-load-balancer-controller eks/aws-load-balancer-controller \
  --namespace kube-system \
  --set enableServiceMutatorWebhook=false

Or if you are installing it for the first time:

1
2
3

helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  --namespace kube-system \
  --set enableServiceMutatorWebhook=false

This ensures that new services do not default to using an NLB.

Conclusion

By disabling the service mutator webhook in the AWS Load Balancer Controller, you can ensure that new Kubernetes services default to using Classic Load Balancers instead of NLBs.

If you need further automation, consider adding this configuration to your Helm charts or Infrastructure-as-Code (IaC) templates.