Node groups (managed, self-managed, Fargate) in AWS - Deep Dive

Overview - Node groups (managed, self-managed, Fargate)

What is it?

Node groups are collections of servers that run your applications in a Kubernetes cluster on AWS. Managed node groups are handled by AWS to simplify updates and scaling. Self-managed node groups give you full control but require more work. Fargate lets you run containers without managing servers at all.

Why it matters

Without node groups, you would have to manually set up and maintain every server running your applications, which is slow and error-prone. Node groups automate this, making your applications more reliable and easier to manage. Fargate removes server management entirely, letting you focus only on your app code.

Where it fits

You should first understand basic Kubernetes concepts and AWS infrastructure. After learning node groups, you can explore advanced Kubernetes scaling, security, and cost optimization techniques.

Mental Model

Core Idea

Node groups are the sets of servers or serverless compute that run your Kubernetes workloads, managed at different levels by you or AWS.

Think of it like...

Think of node groups like different types of delivery drivers: managed node groups are like a delivery service that handles the drivers for you, self-managed node groups are like hiring and managing your own drivers, and Fargate is like ordering a drone delivery that needs no driver at all.

┌─────────────────────────────┐
│       Kubernetes Cluster     │
│                             │
│  ┌───────────────┐          │
│  │ Managed Nodes │          │
│  └───────────────┘          │
│                             │
│  ┌───────────────┐          │
│  │ Self-Managed  │          │
│  │    Nodes      │          │
│  └───────────────┘          │
│                             │
│  ┌───────────────┐          │
│  │   Fargate     │          │
│  │  (Serverless) │          │
│  └───────────────┘          │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

What is a Node in Kubernetes

Concept: Introduce the basic idea of a node as a server that runs containers in Kubernetes.

In Kubernetes, a node is a machine (physical or virtual) that runs your application containers. Each node has the software needed to run containers and communicate with the cluster. Nodes work together to run your app reliably.

Result

You understand that nodes are the building blocks where your app actually runs.

Knowing what a node is helps you see why managing nodes well is key to running apps smoothly.

2

Foundation

Node Groups Organize Nodes

Concept: Explain that nodes are grouped to manage them together.

Instead of handling each node alone, Kubernetes groups nodes into node groups. This lets you update, scale, or configure many nodes at once. Node groups make managing many servers easier and more consistent.

Result

You see node groups as collections that simplify managing many nodes.

Understanding node groups helps you grasp how large clusters stay organized and manageable.

3

Intermediate

Managed Node Groups by AWS

🤔Before reading on: do you think AWS manages updates automatically in managed node groups or do you have to do it manually? Commit to your answer.

Concept: AWS handles the lifecycle of nodes in managed node groups for you.

Managed node groups are sets of nodes where AWS takes care of provisioning, updating, and replacing nodes. You tell AWS how many nodes you want, and it handles the rest. This reduces your work and risk of mistakes.

Result

You can run nodes that AWS keeps healthy and updated automatically.

Knowing AWS manages these nodes lets you focus on your apps, not server upkeep.

4

Intermediate

Self-Managed Node Groups Explained

🤔Before reading on: do you think self-managed node groups require you to handle updates and scaling yourself? Commit to your answer.

Concept: You control all aspects of nodes in self-managed node groups.

Self-managed node groups are where you create and maintain the nodes yourself. You decide when to update, scale, or fix nodes. This gives you flexibility but requires more effort and knowledge.

Result

You have full control but must handle all node maintenance tasks.

Understanding this trade-off helps you choose the right approach for your needs.

5

Intermediate

AWS Fargate Runs Serverless Nodes

🤔Before reading on: do you think Fargate requires you to manage servers or does it run containers without servers? Commit to your answer.

Concept: Fargate runs containers without you managing any servers.

Fargate lets you run Kubernetes pods without provisioning or managing nodes. AWS runs your containers on demand, handling all server details. This simplifies operations but may have different cost and performance profiles.

Result

You can run containers without worrying about servers at all.

Knowing Fargate removes server management lets you focus purely on your app code.

6

Advanced

Choosing Node Group Types for Workloads

🤔Before reading on: do you think all workloads benefit equally from managed, self-managed, and Fargate node groups? Commit to your answer.

Concept: Different node group types suit different workload needs and constraints.

Managed node groups are great for standard workloads needing easy maintenance. Self-managed node groups fit when you need custom OS or special configurations. Fargate is ideal for bursty or unpredictable workloads needing fast scaling without server management.

Result

You can pick the best node group type based on workload characteristics.

Understanding workload needs guides efficient and cost-effective infrastructure choices.

7

Expert

Internal Mechanics of Node Group Lifecycle

🤔Before reading on: do you think managed node groups replace nodes one by one or all at once during updates? Commit to your answer.

Concept: Node groups use rolling updates and health checks to maintain availability during changes.

Managed node groups perform rolling updates by replacing nodes gradually, checking health before moving on. Self-managed groups require manual orchestration. Fargate abstracts this entirely. This ensures your app stays available during node changes.

Result

You understand how node groups keep apps running smoothly during updates.

Knowing the update process prevents downtime and helps troubleshoot node issues.

Under the Hood

Managed node groups use AWS APIs to create EC2 instances with Kubernetes software pre-installed. They monitor node health and replace unhealthy nodes automatically. Self-managed nodes require you to launch and configure EC2 instances, join them to the cluster, and handle updates manually. Fargate runs containers on AWS-managed infrastructure without exposing servers, using a serverless compute engine that schedules pods dynamically.

Why designed this way?

AWS designed managed node groups to reduce operational overhead and errors by automating node lifecycle. Self-managed groups exist for flexibility and legacy needs. Fargate was created to remove server management entirely, catering to developers wanting to focus only on containers. This layered approach balances control, simplicity, and innovation.

┌───────────────────────────────┐
│        AWS EKS Cluster         │
│                               │
│  ┌───────────────┐            │
│  │ Managed Node  │◄───────────┤
│  │   Group       │  AWS APIs  │
│  └───────────────┘            │
│                               │
│  ┌───────────────┐            │
│  │ Self-Managed  │◄───────────┤
│  │   Node Group  │  Manual    │
│  └───────────────┘  Control   │
│                               │
│  ┌───────────────┐            │
│  │   Fargate     │◄───────────┤
│  │ (Serverless)  │  AWS Runs  │
│  └───────────────┘  Containers│
└───────────────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do managed node groups require you to manually update nodes? Commit to yes or no.

Common Belief: Managed node groups still need you to manually update and patch nodes.

Reality: AWS automatically handles updates and health checks for managed node groups.

Why it matters: Believing this causes unnecessary manual work and missed benefits of automation.

Quick: Does Fargate run on your EC2 instances? Commit to yes or no.

Common Belief: Fargate runs containers on EC2 instances you manage.

Reality: Fargate runs containers on AWS-managed infrastructure without exposing or requiring EC2 instances.

Why it matters: Misunderstanding this leads to confusion about server management responsibilities.

Quick: Are self-managed node groups always better for customization? Commit to yes or no.

Common Belief: Self-managed node groups are always the best choice for custom setups.

Reality: While self-managed groups offer control, managed node groups now support many customizations, reducing the need for self-management.

Why it matters: Overusing self-managed groups increases operational burden unnecessarily.

Quick: Can you run all Kubernetes workloads on Fargate? Commit to yes or no.

Common Belief: Fargate supports running every type of Kubernetes workload.

Reality: Fargate supports most but not all workloads; some require node-level access or special configurations not available on Fargate.

Why it matters: Assuming full support can cause deployment failures or unexpected limitations.

Expert Zone

1

Managed node groups use a rolling update strategy with configurable maxUnavailable and maxSurge settings to balance availability and speed.

2

Self-managed node groups require careful handling of Kubernetes version compatibility and node labels to avoid cluster issues.

3

Fargate pricing is based on requested CPU and memory per pod, which can be more cost-effective for bursty workloads but expensive for steady high usage.

When NOT to use

Avoid self-managed node groups if you want to minimize operational overhead; prefer managed groups instead. Avoid Fargate for workloads needing persistent local storage, custom kernel modules, or privileged access. Use managed node groups for standard workloads needing stability and ease.

Production Patterns

Many production clusters use a mix: managed node groups for stable workloads, self-managed for specialized tasks, and Fargate for bursty or ephemeral jobs. Autoscaling policies often combine node group scaling with pod autoscaling for cost and performance balance.

Connections

Serverless Computing

Fargate is a form of serverless compute for containers.

Understanding Fargate as serverless helps grasp how infrastructure can be abstracted away, similar to serverless functions.

Load Balancing

Node groups work with load balancers to distribute traffic to pods running on nodes.

Knowing how node groups interact with load balancers clarifies how requests reach your app reliably.

Fleet Management in Logistics

Managing node groups is like managing a fleet of vehicles with different levels of automation and control.

Seeing node groups as fleets helps understand trade-offs between control, automation, and operational effort.

Common Pitfalls

#1 Trying to update managed node group nodes manually via SSH.

Wrong approach:

ssh into EC2 nodes and run updates manually.

Correct approach:

Use AWS EKS managed node group update commands or console to perform rolling updates.

Root cause:

Misunderstanding that managed node groups automate updates and manual changes can cause conflicts.

#2 Mixing Fargate and self-managed nodes without proper pod selectors.

Wrong approach:

Deploy pods without specifying node selectors or Fargate profiles, causing scheduling failures.

Correct approach:

Define Fargate profiles with proper selectors to ensure pods run on Fargate or nodes as intended.

Root cause:

Lack of understanding of how Kubernetes schedules pods to different node groups or Fargate.

#3 Using self-managed node groups without monitoring node health.

Wrong approach:

Launch EC2 instances and join cluster but do not set up health checks or auto-replacement.

Correct approach:

Implement monitoring and automation scripts or use managed node groups for automatic health management.

Root cause:

Underestimating the operational effort needed to maintain healthy nodes manually.

Key Takeaways

Node groups are collections of servers that run your Kubernetes workloads, managed at different levels by AWS or yourself.

Managed node groups automate node lifecycle tasks, reducing your operational burden and risk of errors.

Self-managed node groups give you full control but require manual updates, scaling, and health management.

Fargate runs containers serverlessly, removing the need to manage any servers, ideal for certain workload types.

Choosing the right node group type depends on your workload needs, control preferences, and operational capacity.

Practice

1. Which type of node group in AWS EKS automatically manages the worker nodes for you?

easy

A. On-premises node group

B. Managed node group

C. Fargate

D. Self-managed node group

Solution

1. Step 1: Understand node group types in EKS

   Managed node groups are designed to let AWS handle the worker nodes, including updates and scaling.

2. Step 2: Compare with other node groups

   Self-managed node groups require manual management of EC2 instances, and Fargate runs containers without servers.

3. Final Answer:

   Managed node group -> Option B

4. Quick Check:

   Managed node group = automatic worker node management [OK]

Hint: Managed node groups mean AWS manages nodes for you [OK]

Common Mistakes:

• Confusing self-managed with managed node groups
• Thinking Fargate manages EC2 instances
• Assuming on-premises node groups are managed by AWS

2. Which of the following is the correct way to specify a Fargate profile in AWS EKS configuration?

easy

A. Specify EC2 instance types under node group

B. Set up Auto Scaling group manually

C. Define selectors with namespaces and labels for Fargate profile

D. Create a launch configuration for EC2

Solution

1. Step 1: Recall Fargate profile setup

   Fargate profiles use selectors to match pods by namespace and labels to run on Fargate.

2. Step 2: Eliminate incorrect options

   EC2 instance types, Auto Scaling groups, and launch configurations relate to EC2, not Fargate.

3. Final Answer:

   Define selectors with namespaces and labels for Fargate profile -> Option C

4. Quick Check:

   Fargate profile uses selectors = Define selectors with namespaces and labels for Fargate profile [OK]

Hint: Fargate profiles use selectors, not EC2 settings [OK]

Common Mistakes:

• Trying to specify EC2 instance types for Fargate
• Confusing Auto Scaling with Fargate profiles
• Using launch configurations for Fargate

3. Given the following EKS setup, which node group type will run the pod?

apiVersion: v1
kind: Pod
metadata:
  name: myapp
  namespace: production
spec:
  containers:
  - name: app
    image: myapp:latest

Assuming a Fargate profile exists for namespace 'production' and a managed node group is also present.

medium

A. Managed node group

B. Self-managed node group

C. No node group will run the pod

D. Fargate

Solution

1. Step 1: Check pod namespace against Fargate profile

   The pod is in 'production' namespace, which matches the Fargate profile selector.

2. Step 2: Understand pod scheduling priority

   Pods matching Fargate profiles run on Fargate instead of node groups.

3. Final Answer:

   Fargate -> Option D

4. Quick Check:

   Pod in Fargate profile namespace runs on Fargate [OK]

Hint: Pod namespace matching Fargate profile means Fargate runs it [OK]

Common Mistakes:

• Assuming managed node group runs all pods
• Ignoring Fargate profile selectors
• Thinking self-managed node group runs pods by default

4. You created a self-managed node group but your pods are stuck in Pending state. What is a likely cause?

medium

A. EC2 instances in the node group are not registered with the cluster

B. Fargate profile is missing

C. Managed node group is not enabled

D. Pod namespace does not match Fargate profile

Solution

1. Step 1: Understand self-managed node group requirements

   Self-managed nodes must register with the cluster to run pods.

2. Step 2: Identify cause of Pending pods

   If EC2 instances are not registered, pods cannot schedule and remain Pending.

3. Final Answer:

   EC2 instances in the node group are not registered with the cluster -> Option A

4. Quick Check:

   Unregistered EC2 nodes cause Pending pods [OK]

Hint: Self-managed nodes must register to run pods [OK]

Common Mistakes:

• Assuming Fargate profile affects self-managed nodes
• Thinking managed node group must be enabled for self-managed nodes
• Ignoring node registration status

5. You want to run a highly scalable application without managing any servers. Which AWS EKS node group option should you choose and why?

hard

A. Fargate, because it runs containers without managing servers

B. Managed node group, because AWS handles node updates automatically

C. Self-managed node group, because you control EC2 instances directly

D. On-premises nodes, because they offer full control

Solution

1. Step 1: Identify requirement for no server management

   The question asks for running containers without managing servers.

2. Step 2: Compare node group options

   Self-managed and managed node groups require managing or at least maintaining EC2 instances. Fargate runs containers serverless.

3. Step 3: Confirm scalability and management

   Fargate automatically scales and removes server management burden.

4. Final Answer:

   Fargate, because it runs containers without managing servers -> Option A

5. Quick Check:

   No server management means Fargate [OK]

Hint: No servers to manage? Choose Fargate [OK]

Common Mistakes:

• Choosing self-managed for no server management
• Confusing managed node groups with serverless
• Selecting on-premises nodes for cloud scalability