Kubernetes (often abbreviated as K8s) has become the de‑facto standard for orchestrating containerized applications. Modern web services need to be available around the clock, and developers expect to push new versions without downtime. Containerization makes that possible, and Kubernetes helps make sure those containers run where and when they should and have the resources they need. This tutorial walks through the key concepts of Kubernetes, shows how to deploy a simple application on Amazon EKS, and demonstrates how to scale both your application and the underlying infrastructure.<h3>1&nbsp;Understanding Kubernetes</h3><h4>1.1&nbsp;Cluster architecture</h4>A Kubernetes cluster consists of a control plane and a set of worker nodes that run containerized applications. The control plane hosts components such as the API server, scheduler, controller managers and etcd, which make global decisions for the cluster (for example, scheduling pods). Worker nodes run the pods—the smallest deployable units—that contain one or more containers. This separation lets you add or remove worker nodes without affecting the control plane, enabling high availability and fault tolerance.Key components include:<ul><li>kube‑apiserver – exposes the Kubernetes API. It scales horizontally by running multiple instances behind a load balancer.</li><li>etcd – the consistent, highly‑available key–value store for all cluster data.</li><li>kube‑scheduler – assigns newly created pods to nodes based on resource requirements, policy constraints and scheduling algorithms.</li><li>kube‑controller‑manager and cloud‑controller‑manager – run various controllers that handle tasks such as node lifecycles, jobs, endpoints and cloud provider interactions.</li><li>kubelet – an agent running on each worker node that ensures containers described in pod specifications are running and healthy.</li><li>kube‑proxy – a network proxy on each node that implements the Service abstraction and load‑balances traffic to pods.</li></ul><h4>1.2&nbsp;Workloads, pods and deployments</h4>A Deployment manages a set of pods for stateless applications. You describe your desired state (for example, the number of replicas and the container image) in a deployment object, and Kubernetes ensures that reality matches your declaration. Behind the scenes, deployments create and manage ReplicaSets, which in turn manage the individual pods. Deployments enable declarative updates and rollbacks and provide a simple way to scale up or down your application.The typical workflow for a deployment is:<ol><li>Define a deployment manifest specifying the container image, number of replicas and labels.</li><li>Apply the manifest with <code>kubectl apply -f &lt;file&gt;</code>.</li><li>Kubernetes creates a ReplicaSet and schedules pods on nodes.</li><li>You can scale or update the deployment declaratively (see section&nbsp;5).</li></ol><h4>1.3&nbsp;Services and load‑balancing</h4>Pods are mortal; they can be destroyed and recreated at any time. Services provide a stable network endpoint to access pods, load‑balancing traffic across all healthy instances. When you expose a deployment via a Service of type LoadBalancer, Kubernetes configures an external load balancer (on AWS this becomes an Elastic Load Balancer) and routes incoming traffic to your pods. This mechanism is essential when running multiple instances of an application.<h3>2&nbsp;Why Use Amazon EKS?</h3>Operating your own Kubernetes control plane on cloud virtual machines is certainly possible, but it requires ongoing maintenance, upgrades and high‑availability planning. Amazon Elastic Kubernetes Service (EKS) provides a managed control plane that takes care of these responsibilities for you. When you create an EKS cluster, AWS provisions and runs the Kubernetes control plane across multiple Availability&nbsp;Zones, applies security patches and upgrades, and manages critical components such as the API server and etcd. Because EKS integrates with AWS networking and security services—such as IAM, VPC networking and encryption—you can focus on building and deploying your workloads while AWS handles the underlying Kubernetes infrastructure. All that remains under your control are the worker nodes and the applications they run. This managed experience reduces operational overhead and enables you to adopt best practices with minimal effort.<h3>3&nbsp;Prerequisites and Tooling</h3>Before creating a cluster you need a few prerequisites:<ul><li>An AWS account with permissions to create EKS clusters and associated resources.</li><li><code>eksctl</code> – a command‑line tool for creating and managing EKS clusters. It automates the provisioning of the control plane and node groups.</li><li><code>kubectl</code> – the Kubernetes command‑line tool used to interact with your cluster for tasks such as applying manifests, inspecting resources and scaling workloads.</li><li>Docker – to build and package your application into container images. You’ll also need a container registry, such as Amazon Elastic Container Registry (ECR) or Docker Hub, to store your images.</li></ul>Install <code>eksctl</code> and <code>kubectl</code> using the instructions provided by AWS and Kubernetes, then verify the installation by running <code>eksctl version</code> and <code>kubectl version</code> on your local machine. A supported programming language runtime (for example, Python or Node.js) is needed to build your application.<h3>4&nbsp;Creating an EKS Cluster</h3><ol><li>Create the cluster – Use <code>eksctl</code> to create a cluster. The following command creates a cluster named <code>k8s-example</code> in the <code>eu-west-2</code> region:<pre><code class="language-bash">eksctl create cluster --name k8s-example --region eu-west-2</code></pre>This command provisions the Kubernetes control plane and an initial node group. Once provisioning completes, <code>eksctl</code> updates your <code>~/.kube/config</code> file so that <code>kubectl</code> can communicate with the new cluster.</li><li>Verify the cluster – After creation, confirm that the cluster is reachable by listing its resources:<pre><code class="language-bash">kubectl get nodes
kubectl get pods --all-namespaces
kubectl get namespaces</code></pre>These commands list nodes, pods and namespaces, verifying that the API server is responsive.</li><li>Configure AWS credentials – Ensure that your AWS CLI or SDK is configured with credentials that allow cluster creation and management. When you run <code>eksctl</code>, it automatically creates the necessary IAM roles for the control plane and node groups, but the underlying AWS account must have sufficient permissions.</li></ol><h3>5&nbsp;Building and Packaging Your Application</h3>To deploy an application on Kubernetes you first need to package it as a container image. For demonstration, assume a simple web service that listens on port&nbsp;3000. Create a <code>Dockerfile</code> in your project directory:<pre><code class="language-dockerfile">FROM node:20-alpine
WORKDIR /app
COPY . .
RUN npm install
EXPOSE 3000
CMD ["npm", "start"]</code></pre>Build and push the image:<pre><code class="language-bash">docker build -t &lt;your-dockerhub-username&gt;/myapp:1.0 .
docker push &lt;your-dockerhub-username&gt;/myapp:1.0</code></pre>If you’re using Amazon ECR, login using <code>aws ecr get-login-password</code>, create a repository and push the image there.<h3>6&nbsp;Defining Kubernetes Manifests</h3>Next, define a Deployment and a Service in a YAML file (for example <code>deployment-example.yaml</code>). The deployment ensures a specified number of pod replicas using your container image, and the service exposes the pods via a load balancer. A sample manifest looks like this:<pre><code class="language-yaml">apiVersion: apps/v1
kind: Deployment
metadata:
 name: myapp-deployment
 namespace: default
 labels:
 app: myapp
spec:
 replicas: 3
 selector:
 matchLabels:
 app: myapp
 template:
 metadata:
 labels:
 app: myapp
 spec:
 containers:
 - name: myapp-container
 image: &lt;your-dockerhub-username&gt;/myapp:1.0
 ports:
 - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
 name: myapp-service
 labels:
 app: myapp
spec:
 type: LoadBalancer
 ports:
 - port: 80
 targetPort: 3000
 selector:
 app: myapp</code></pre>In this example the Deployment runs 3 replicas, and the Service uses <code>type: LoadBalancer</code>. On AWS, this service type provisions an Elastic Load Balancer and routes traffic to your pods automatically. The <code>selector</code> field ensures that only pods with matching labels receive traffic.<h3>7&nbsp;Deploying the Application</h3>Apply your manifest to the cluster using <code>kubectl</code>:<pre><code class="language-bash">kubectl apply -f deployment-example.yaml</code></pre>Kubernetes creates the Deployment, ReplicaSet, pods and Service accordingly. Verify the status:<pre><code class="language-bash">kubectl get deployments
kubectl get pods
kubectl get svc</code></pre>When the Service shows an <code>EXTERNAL-IP</code>, open that IP in a browser to access your application. The load balancer distributes traffic across the pod replicas.<h3>8&nbsp;Scaling Your Application</h3><h4>8.1&nbsp;Manual scaling</h4>You can scale a deployment by changing the number of replicas. At creation time you can specify the <code>--replicas</code> flag with <code>kubectl create deployment</code>. Afterwards you can adjust the replica count declaratively by editing the manifest or imperatively using the <code>kubectl scale</code> command. For example, to scale to four replicas:<pre><code class="language-bash">kubectl scale deployments/myapp-deployment --replicas=4</code></pre>Scaling out a deployment ensures that new pods are created and scheduled on nodes with available resources. If you scale down, Kubernetes terminates excess pods while keeping the service available. Listing the deployment again shows updated <code>READY</code>, <code>UP‑TO‑DATE</code> and <code>AVAILABLE</code> columns.<h4>8.2&nbsp;Horizontal Pod Autoscaler (HPA)</h4>Manual scaling is useful for predictable workloads, but applications often experience fluctuating demand. The HorizontalPodAutoscaler resource automatically updates a Deployment or StatefulSet to match demand. Horizontal scaling means deploying more pods to handle increased load; vertical scaling (assigning more CPU or memory to existing pods) is a separate concept. The HPA controller runs in the control plane and periodically adjusts the desired scale based on metrics such as average CPU or memory utilization. When load decreases, it scales the deployment back down as long as the number of pods remains above the configured minimum.To use HPA you need the metrics server installed in your cluster. A simple HPA YAML might look like this:<pre><code class="language-yaml">apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
 name: myapp-hpa
spec:
 scaleTargetRef:
 apiVersion: apps/v1
 kind: Deployment
 name: myapp-deployment
 minReplicas: 2
 maxReplicas: 10
 metrics:
 - type: Resource
 resource:
 name: cpu
 target:
 type: Utilization
 averageUtilization: 50</code></pre>This configuration maintains between 2 and 10 replicas, targeting 50&nbsp;% average CPU utilization across the pods.<h4>8.3&nbsp;Scaling the underlying infrastructure</h4>Horizontal scaling of pods does not provision additional worker nodes. If your cluster lacks spare capacity, new pods remain in a <code>Pending</code> state. To scale the underlying compute resources automatically you need a Node autoscaler. The Kubernetes community sponsors two autoscalers: Cluster&nbsp;Autoscaler and Karpenter.Both autoscalers provision additional Nodes for unschedulable Pods and consolidate underutilized Nodes. Their differences lie in how they integrate with the cloud provider and how flexible they are:<ol><li>Cluster Autoscaler&nbsp;– adds or removes Nodes from pre‑configured Node groups. Node groups usually map to cloud‑provider scaling groups (for example Auto Scaling groups on AWS). A single Cluster Autoscaler instance can manage multiple Node groups and will add Nodes to the group that best fits the resource requests of pending Pods. When consolidating, it selects specific Nodes to remove, rather than simply shrinking the underlying group.</li><li>Karpenter&nbsp;– auto‑provisions Nodes based on NodePool (also called Provisioner) configurations defined by the cluster operator. Karpenter handles the entire node lifecycle: it provisions Nodes when pods cannot be scheduled, refreshes them when they reach a certain age and automatically upgrades them when new images are available. Karpenter works directly with individual cloud provider resources and does not rely on pre‑configured Node groups. It supports auto‑provisioning, meaning you specify only constraints and Karpenter chooses appropriate instance types.</li></ol>Cluster Autoscaler is part of the Kubernetes project and includes cloud provider integrations; Karpenter is published as a library that providers can integrate with. Karpenter currently has fewer provider integrations, but it offers faster scaling and more granular control. You can even run both autoscalers together: Cluster Autoscaler can handle steady‑state workloads, while Karpenter reacts quickly to sudden spikes. Combining a node‑level autoscaler with the Horizontal Pod Autoscaler ensures that your cluster scales pods and nodes in tandem.<h3>9&nbsp;Cleaning Up</h3>When you finish experimenting, delete the resources to avoid ongoing costs:<pre><code class="language-bash">kubectl delete -f deployment-example.yaml
eksctl delete cluster --name k8s-example --region eu-west-2</code></pre>Deleting the cluster removes all associated resources (node groups, VPCs and load balancers). Always verify that no additional AWS resources remain to prevent unexpected charges.<h3>10&nbsp;Conclusion</h3>In this tutorial you learned:<ul><li>The fundamental architecture of Kubernetes—including control plane components and worker nodes—and how deployments, pods and services work.</li><li>The advantages of Amazon EKS, which provides a managed control plane and integrates tightly with AWS networking and security services.</li><li>How to install the necessary tools (<code>eksctl</code> and <code>kubectl</code>), create an EKS cluster, package a simple application into a container image, define Kubernetes manifests and deploy the application on AWS.</li><li>How to scale your application manually with <code>kubectl scale</code>, automatically with a Horizontal Pod Autoscaler and scale your node pool using Cluster Autoscaler or Karpenter.</li></ul>Kubernetes and AWS EKS together provide a powerful, flexible platform for running containerized workloads in production. Starting from a basic deployment, you can layer on services, ingress controllers, continuous integration/continuous delivery (CI/CD) pipelines, observability tools and advanced autoscaling strategies. With a solid understanding of these fundamentals you’re ready to explore more advanced topics such as stateful workloads, service meshes and multi‑cluster deployments.

Getting Started with Kubernetes: Deploying and Scaling an Application on AWS

HashiCorp and AWS have officially rolled out Terraform AWS Provider 6.0, a major release that changes how we manage infrastructure across multiple regions. For years, Terraform users had to juggle multiple provider configurations and aliases to handle regional resources. With this release, that workflow gets streamlined — reducing duplication, improving performance, and simplifying infrastructure as code.<h2>Why This Release Matters</h2>The AWS provider is the glue that connects Terraform code to AWS services. Every resource you create — whether it’s a VPC, EC2 instance, or KMS key — flows through this provider.Until now, each provider block targeted only one AWS region, forcing practitioners to maintain duplicate provider definitions (<code>alias</code> blocks) for every region they needed. This approach worked but was cumbersome, especially for enterprises operating across 10, 20, or more regions.Provider 6.0 changes that. You can now define multiple regions directly at the resource level, using a <code>region</code> argument, all within a single provider configuration. No more cluttered aliases, no more redundant boilerplate.<h2>Key Enhancements in AWS Provider 6.0</h2>Here are the highlights that make this release important:<ul><li>Single provider block for multi-region Manage resources in different regions without loading multiple provider instances. This lowers memory usage and simplifies codebases.</li><li>Per-resource region parameter Every resource now supports an optional <code>region</code> argument (except global services like IAM, Route 53, and CloudFront).</li><li>Global resources remain global Services that don’t belong to a region continue to work as before — unaffected by the new model.</li><li>Improved performance Reduced provider duplication results in faster Terraform initialization and lower memory consumption.</li><li>Better resource imports Import commands now accept a region suffix (<code>@regionID</code>) to simplify bringing existing infrastructure under Terraform management.</li><li>Terraform plugin framework upgrade AWS API clients are mapped per region, making multi-region workflows more efficient and reliable.</li></ul><h2>Example: VPC Peering Across Regions</h2>Previously, you had to define two providers (one per region). Now, you can define both resources in a single configuration:<pre><code class="language-hcl">provider "aws" {
 region = "us-east-1"
}

resource "aws_vpc" "main" {
 cidr_block = "10.0.0.0/16"
}

resource "aws_vpc" "peer" {
 region = "us-west-2"
 cidr_block = "10.1.0.0/16"
}

resource "aws_vpc_peering_connection" "main" {
 vpc_id = aws_vpc.main.id
 peer_vpc_id = aws_vpc.peer.id
 peer_region = "us-west-2"
 auto_accept = false
}

resource "aws_vpc_peering_connection_accepter" "peer" {
 region = "us-west-2"
 vpc_peering_connection_id = aws_vpc_peering_connection.main.id
 auto_accept = true
}
</code></pre>Notice how both VPCs and the accepter resource simply use the <code>region</code> attribute, eliminating the need for a <code>provider "aws" { alias = "peer" }</code> block.<h2>Example: Multi-Region KMS Keys</h2>KMS multi-region keys are another great fit for this feature:<pre><code class="language-hcl">provider "aws" {
 region = "us-west-2"
}

resource "aws_kms_key" "primary" {
 region = "us-east-1"
 description = "Primary multi-region key"
 deletion_window_in_days = 30
 multi_region = true
}

resource "aws_kms_replica_key" "replica" {
 description = "Replica key"
 deletion_window_in_days = 7
 primary_key_arn = aws_kms_key.primary.arn
}
</code></pre><h2>Migrating to Version 6.0</h2>If your current setup uses provider aliases (<code>provider "aws" { alias = "peer" ... }</code>), here’s how to migrate:<ol><li>Upgrade provider Pin the provider to version 6.0 in your configuration:<pre><code class="language-hcl">terraform {
 required_providers {
 aws = {
 source = "hashicorp/aws"
 version = "~&gt; 6.0"
 }
 }
}
</code></pre></li><li>Refresh your state Run:<pre><code class="language-bash">terraform plan -refresh-only
terraform apply -refresh-only
</code></pre></li><li>Update configurations Replace provider aliases with the new <code>region</code> argument at the resource level.<pre><code class="language-hcl"># Old way
resource "aws_kms_key" "test" {
 provider = aws.peer
 description = "Multi-Region key"
 multi_region = true
}

# New way
resource "aws_kms_key" "test" {
 region = "us-west-2"
 description = "Multi-Region key"
 multi_region = true
}
</code></pre></li><li>Re-run <code>terraform init -migrate-state</code> to finalize migration.</li></ol><h2>Things to Keep in Mind</h2><ul><li>This release introduces breaking changes, so carefully test in a non-prod environment first.</li><li>Always pin provider versions in production to avoid surprises:<pre><code class="language-hcl">version = "~&gt; 6.0"
</code></pre></li><li>Multi-region support does not apply to global AWS services — these stay region-agnostic.</li><li>Check the <a target="_blank" rel="noopener noreferrer nofollow" href="https://registry.terraform.io/providers/hashicorp/aws/latest">Terraform Registry upgrade guide</a> for detailed migration notes.</li></ul><h2>Final Thoughts</h2>The Terraform AWS Provider 6.0 release is a big step forward for teams managing AWS infrastructure at scale. By collapsing multiple provider aliases into a single provider block, it makes configurations cleaner, faster, and easier to maintain — especially in multi-region deployments.For DevOps teams, this means less boilerplate, lower memory usage, and a smoother developer experience when working with Terraform and AWS.

AWS

Getting Started with Kubernetes: Deploying and Scaling an Application on AWS

Terraform AWS Provider 6.0: A New Era of Multi-Region Infrastructure Management