Amazon EKS (Elastic Kubernetes Service)AuthorCloudBrum editorial teamLast reviewed28 Oct 2026Reading time~12 minLevelBeginner to advanced

• A control plane you never patchAWS runs the Kubernetes API servers and etcd across three Availability Zones, replaces unhealthy control plane nodes and applies security fixes. You get a normal Kubernetes endpoint and talk to it with kubectl, Helm or any other client.
• Four ways to get worker nodesManaged node groups run EC2 instances that AWS patches and drains for you. Fargate runs each pod on its own small VM. Karpenter picks instance types as pods appear. Auto Mode goes one step further and has AWS run Karpenter, the load balancer controller and storage drivers for you.
• IAM for people and for podsAccess entries map IAM roles and users to Kubernetes permissions without editing a ConfigMap. EKS Pod Identity gives one service account an IAM role, so a pod can call S3 or DynamoDB without long-lived keys.
• Pods with real VPC addressesThe default VPC CNI plugin gives each pod an IP address from your subnets, so security groups, flow logs and routing work the way they do for EC2. The price is IP addresses: a busy cluster can drain a small subnet.
• Add-ons with versionsCoreDNS, kube-proxy, the VPC CNI, the EBS CSI driver and the Pod Identity agent are installed as EKS add-ons. EKS shows which version fits your cluster and can update them in place.
• Defined support windowsA Kubernetes minor version gets about 14 months of standard support and then 12 months of extended support. After standard support ends the control plane fee goes from $0.10 to $0.60 per cluster-hour, unless you upgrade first.
• Private clusters and encryptionTurn the public API endpoint off and reach the cluster from your VPC only. Add a KMS key for envelope encryption of Kubernetes secrets, and ship audit logs to CloudWatch.
• Runs beyond one RegionEKS Anywhere and hybrid nodes let you run Kubernetes on your own hardware while still managing it through the EKS API, which suits data that can’t leave a building.

Cluster

One EKS control plane plus the nodes registered to it. Most teams run a few clusters, not one per application.

Control plane

The Kubernetes API server, scheduler, controllers and etcd. AWS runs it in its own account and shows you only the endpoint and the logs.

Managed node group

An Auto Scaling group of EC2 instances that EKS creates and updates. You choose instance types, size limits and an AMI family.

Fargate profile

A rule that says which namespaces or labelled pods run on Fargate. Each pod gets its own isolated compute, with no nodes to patch.

Karpenter

An open-source autoscaler that watches for pods that can’t be scheduled and launches the cheapest instance that fits them. It replaces the Cluster Autoscaler on many clusters.

EKS Auto Mode

A cluster setting where AWS also runs the nodes, the load balancer controller, the block storage driver and node scaling. You pay a management fee per instance on top of EC2.

Access entry

A cluster record that connects an IAM principal to Kubernetes permissions. An access policy such as AmazonEKSViewPolicy supplies the rights.

EKS Pod Identity

Lets a Kubernetes service account assume an IAM role through an agent on the node. The role’s trust policy names pods.eks.amazonaws.com.

IRSA

The older way to do the same job, using an OIDC provider and a web identity token. It still works, and you’ll meet it in older clusters and on Fargate.

VPC CNI

The networking plugin that attaches VPC addresses to pods. Settings such as prefix delegation change how many pods fit on a node.

Add-on

A component managed through the EKS API, such as coredns, kube-proxy, vpc-cni or aws-ebs-csi-driver, with its own version.

Upgrade policy

A cluster setting, STANDARD or EXTENDED, that decides what happens when the version leaves standard support.

Cluster endpoint

The URL of the Kubernetes API. It can be public, private or both, and the public side can be limited to chosen CIDR ranges.

Pod Disruption Budget

A Kubernetes object that limits how many replicas can be down at once. Node upgrades and drains respect it, so write one for anything you can’t lose.

Create an EKS cluster with the AWS CLI

1. Pick the Region and the networkChoose a Region close to your users (Mumbai or Hyderabad for India). You need a VPC with subnets in at least two Availability Zones, and plenty of free addresses in them, because pods use them too.
2. Create the cluster roleEKS needs an IAM role that the service can assume, with the AmazonEKSClusterPolicy managed policy attached. Create it once and reuse it for every cluster.
3. Create the clusterRun aws eks create-cluster with the role, the subnets and the access mode API. Switch the public endpoint off if your build agents run inside the VPC, and add --upgrade-policy supportType=STANDARD if you never want extended-support pricing by surprise.
4. Wait until it’s activeCreation takes around ten minutes. aws eks wait cluster-active blocks until the control plane answers.
5. Add worker capacityCreate a managed node group with its own node role, two or three zones of subnets, and a size range. Start with a modest instance type and let the autoscaler or Karpenter do the rest.
6. Install the add-ons you needThe VPC CNI, CoreDNS and kube-proxy arrive with the cluster. Add eks-pod-identity-agent for pod permissions and aws-ebs-csi-driver if any workload needs a persistent volume.
7. Give people accessCreate access entries for the IAM roles your team uses, and attach an access policy at cluster or namespace scope. Skip the old aws-auth ConfigMap on new clusters.
8. Connect and deployaws eks update-kubeconfig writes the kubeconfig. Apply your namespace, deployment, service, autoscaler and disruption budget, then check that the pods are ready on more than one node.
9. Plan the first upgrade nowLook up the support end date of your version, put it in a calendar, and run Upgrade Insights before you change anything. Control plane first, add-ons next, nodes last.

• Set CPU and memory requests from observed usage. Requests decide scheduling and autoscaling, so guessing high wastes money and guessing low causes evictions.
• Use the Horizontal Pod Autoscaler for replicas and Karpenter or Auto Mode for nodes, and give new nodes time to join by keeping a little headroom.
• Spread replicas over zones with topology spread constraints, and add a Pod Disruption Budget so a drain never takes them all.
• Pick Graviton instance types for services whose images support arm64. They usually give more work per dollar.
• Keep readiness probes honest. A pod that reports ready too early gets traffic it can’t serve.
• Watch CoreDNS: a busy cluster can overload it. Scale it, enable node-local caching and avoid long search paths in application DNS names.
• Put heavy east-west traffic in one zone where you can, since cross-zone traffic adds latency and a per-GB charge.
• Use VPC CNI prefix delegation or larger instance types when pod density is the limit rather than CPU.

FinOps is the habit of managing cloud spend together with engineering. These are the FinOps checks that matter most for Amazon EKS.

• Remember the control plane fee of $0.10 per cluster-hour (about $73 a month). Fewer, larger, well-governed clusters cost less than one per team.
• Upgrade before standard support ends, because extended support costs $0.60 per cluster-hour for the same cluster.
• Let Karpenter consolidate nodes, and allow Spot capacity for stateless and batch workloads with a sensible interruption plan.
• Right-size requests with the Vertical Pod Autoscaler recommendations or your metrics. Oversized requests mean oversized nodes.
• Buy Savings Plans for the steady base load, and leave the spiky part on-demand or Spot.
• Share load balancers through one ingress or gateway instead of one per service.
• Add VPC endpoints for ECR and S3 if image pulls through NAT are large, since NAT gateways charge per GB processed.
• Cut log volume. Control plane audit logs and verbose application logs in CloudWatch can cost more than a small node group.
• Shut down development clusters at night or delete them after a branch is merged.
• Tag clusters, node groups and namespaces by team, and check Auto Mode’s per-instance fee against what Karpenter would cost you to run yourself.

• Keep the API endpoint private, or restrict the public endpoint to known CIDR ranges.
• Use access entries with narrow access policies instead of cluster-admin for people, and set the cluster’s authentication mode to API.
• Give every workload its own service account and IAM role through Pod Identity or IRSA, and don’t let pods fall back to the node role.
• Turn on envelope encryption of secrets with a KMS key you control, and keep real secrets in Secrets Manager or Parameter Store.
• Apply Pod Security Standards per namespace (restricted for most application namespaces), and run containers as non-root with a read-only root file system where you can.
• Add network policies, starting with default deny, and use security groups for pods where a workload needs its own firewall.
• Send control plane logs (api, audit, authenticator) to CloudWatch, and alert on unusual exec, role binding and secret reads.
• Scan images in Amazon ECR, pin tags or digests, and allow only your registry with an admission policy.
• Keep nodes patched by rolling the node group to the latest AMI release, or by using Bottlerocket or Auto Mode, which replace nodes regularly.
• Use GuardDuty EKS protection and AWS Config or Security Hub rules to catch drift and suspicious behaviour.

AWS CloudTrail records who created, changed or deleted clusters and node groups, EKS audit logs record what happens inside the Kubernetes API, AWS Config keeps the history and the rules above, and AWS Artifact holds compliance reports. The split of duties is the usual one for managed Kubernetes: AWS runs and patches the control plane, while you own node configuration, workload permissions, network policy, images and upgrades on time.

• Right-size requests and nodes. Idle capacity draws power all day.
• Consolidate with Karpenter or Auto Mode so lightly used nodes are removed.
• Prefer Graviton instances where your images support them. They deliver more work per watt.
• Run batch and test workloads when you need them, and delete the cluster afterwards.
• Share clusters and load balancers across teams instead of duplicating whole stacks.
• Keep traffic inside a zone and compress what you log, so less data moves and is stored.
• The AWS Customer Carbon Footprint Tool gives an account-level estimate. Check what it covers for container services before you quote a number.

Purchase options

What you actually pay for

• The control plane for every cluster, per hour, at the standard or extended rate
• EC2 instances or Fargate resources that run your pods
• Auto Mode’s per-instance fee if you use it
• Load balancers, NAT gateways and other VPC resources the cluster needs
• Storage, snapshots, logs and data transfer between zones, Regions and to the internet

A private three-replica web service called orders-api. The CLI tab builds the cluster with a managed node group, Pod Identity and an access entry, then applies the Kubernetes manifest (namespace, service account, deployment, service, autoscaler, disruption budget and network policy) with kubectl. Terraform builds the same cluster. The Python tab is the program inside the pod: it writes a receipt to S3 with the credentials Pod Identity hands out, with no keys anywhere. The C# tab runs from a laptop or a pipeline and waits for the rollout to finish. Replace the subnets, account number, bucket and Region with your own. A cluster bills from the moment it exists, so delete the test one when you’re done.

# Placeholders: replace the subnets, account and bucket with your own.
REGION=ap-south-1
CLUSTER=orders-prod
ACCOUNT=111122223333
SUBNETS=subnet-0aaa1111bbbb2222c,subnet-0ddd3333eeee4444f
BUCKET=orders-receipts-example

# 1. Roles: one for the control plane, one for the nodes, one that pods can assume.
aws iam create-role --role-name eks-orders-cluster --assume-role-policy-document '{
  "Version": "2012-10-17",
  "Statement": [{"Effect": "Allow", "Principal": {"Service": "eks.amazonaws.com"}, "Action": "sts:AssumeRole"}]}'
aws iam attach-role-policy --role-name eks-orders-cluster --policy-arn arn:aws:iam::aws:policy/AmazonEKSClusterPolicy

aws iam create-role --role-name eks-orders-nodes --assume-role-policy-document '{
  "Version": "2012-10-17",
  "Statement": [{"Effect": "Allow", "Principal": {"Service": "ec2.amazonaws.com"}, "Action": "sts:AssumeRole"}]}'
for P in AmazonEKSWorkerNodePolicy AmazonEKS_CNI_Policy AmazonEC2ContainerRegistryPullOnly; do
  aws iam attach-role-policy --role-name eks-orders-nodes --policy-arn arn:aws:iam::aws:policy/$P
done

aws iam create-role --role-name orders-api-pod --assume-role-policy-document '{
  "Version": "2012-10-17",
  "Statement": [{"Effect": "Allow", "Principal": {"Service": "pods.eks.amazonaws.com"}, "Action": ["sts:AssumeRole", "sts:TagSession"]}]}'
aws iam put-role-policy --role-name orders-api-pod --policy-name receipts-write --policy-document '{
  "Version": "2012-10-17",
  "Statement": [{"Effect": "Allow", "Action": "s3:PutObject", "Resource": "arn:aws:s3:::'$BUCKET'/receipts/*"}]}'

# 2. The cluster: access entries only (no aws-auth ConfigMap), private endpoint, audit logs, no accidental extended support.
aws eks create-cluster --name $CLUSTER --region $REGION \
  --role-arn arn:aws:iam::$ACCOUNT:role/eks-orders-cluster \
  --resources-vpc-config subnetIds=$SUBNETS,endpointPrivateAccess=true,endpointPublicAccess=false \
  --access-config authenticationMode=API,bootstrapClusterCreatorAdminPermissions=true \
  --upgrade-policy supportType=STANDARD \
  --deletion-protection \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator"],"enabled":true}]}'
aws eks wait cluster-active --name $CLUSTER --region $REGION

# 3. Nodes: three Graviton instances across the subnets, replaced one at a time during updates.
aws eks create-nodegroup --cluster-name $CLUSTER --region $REGION --nodegroup-name general \
  --node-role arn:aws:iam::$ACCOUNT:role/eks-orders-nodes --subnets ${SUBNETS//,/ } \
  --instance-types m7g.large --ami-type AL2023_ARM_64_STANDARD --capacity-type ON_DEMAND \
  --scaling-config minSize=2,maxSize=6,desiredSize=3 --update-config maxUnavailable=1
aws eks wait nodegroup-active --cluster-name $CLUSTER --nodegroup-name general --region $REGION

# 4. Add-ons and permissions: the Pod Identity agent, then the link between the service account and its role.
aws eks create-addon --cluster-name $CLUSTER --region $REGION --addon-name eks-pod-identity-agent
aws eks create-pod-identity-association --cluster-name $CLUSTER --region $REGION \
  --namespace orders --service-account orders-api --role-arn arn:aws:iam::$ACCOUNT:role/orders-api-pod

# 5. A read-only entry for the support team, limited to one namespace.
aws eks create-access-entry --cluster-name $CLUSTER --region $REGION \
  --principal-arn arn:aws:iam::$ACCOUNT:role/support-readonly --type STANDARD
aws eks associate-access-policy --cluster-name $CLUSTER --region $REGION \
  --principal-arn arn:aws:iam::$ACCOUNT:role/support-readonly \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
  --access-scope type=namespace,namespaces=orders

# 6. Deploy. Run this from inside the VPC, because the endpoint is private.
aws eks update-kubeconfig --name $CLUSTER --region $REGION
kubectl apply -f - <<'EOF'
apiVersion: v1
kind: Namespace
metadata:
  name: orders
  labels:
    pod-security.kubernetes.io/enforce: restricted
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: orders-api
  namespace: orders
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders-api
  namespace: orders
spec:
  replicas: 3
  selector:
    matchLabels: {app: orders-api}
  strategy:
    rollingUpdate: {maxSurge: 1, maxUnavailable: 0}
  template:
    metadata:
      labels: {app: orders-api}
    spec:
      serviceAccountName: orders-api
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels: {app: orders-api}
      securityContext:
        runAsNonRoot: true
        seccompProfile: {type: RuntimeDefault}
      containers:
        - name: api
          image: 111122223333.dkr.ecr.ap-south-1.amazonaws.com/orders-api:1.4.2
          ports:
            - containerPort: 8080
          env:
            - {name: RECEIPT_BUCKET, value: orders-receipts-example}
          resources:
            requests: {cpu: 250m, memory: 256Mi}
            limits: {memory: 512Mi}
          readinessProbe:
            httpGet: {path: /healthz, port: 8080}
            periodSeconds: 5
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities: {drop: ["ALL"]}
---
apiVersion: v1
kind: Service
metadata:
  name: orders-api
  namespace: orders
spec:
  selector: {app: orders-api}
  ports:
    - port: 80
      targetPort: 8080
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: orders-api
  namespace: orders
spec:
  scaleTargetRef: {apiVersion: apps/v1, kind: Deployment, name: orders-api}
  minReplicas: 3
  maxReplicas: 12
  metrics:
    - type: Resource
      resource:
        name: cpu
        target: {type: Utilization, averageUtilization: 70}
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: orders-api
  namespace: orders
spec:
  minAvailable: 2
  selector:
    matchLabels: {app: orders-api}
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: orders-api-ingress
  namespace: orders
spec:
  podSelector:
    matchLabels: {app: orders-api}
  policyTypes: [Ingress]
  ingress:
    - from:
        - namespaceSelector:
            matchLabels: {kubernetes.io/metadata.name: ingress}
      ports:
        - {port: 8080, protocol: TCP}
EOF
kubectl -n orders rollout status deployment/orders-api

# 7. Later: see what an upgrade would break, then move the control plane one minor version.
aws eks list-insights --cluster-name $CLUSTER --region $REGION
# aws eks update-cluster-version --name $CLUSTER --kubernetes-version <next minor> --region $REGION

# Placeholders: pass in your own subnet IDs and bucket name.
variable "subnet_ids" {
  type = list(string)
}

variable "receipt_bucket" {
  type    = string
  default = "orders-receipts-example"
}

data "aws_caller_identity" "me" {}

data "aws_iam_policy_document" "eks_trust" {
  statement {
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["eks.amazonaws.com"]
    }
  }
}

data "aws_iam_policy_document" "node_trust" {
  statement {
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["ec2.amazonaws.com"]
    }
  }
}

data "aws_iam_policy_document" "pod_trust" {
  statement {
    actions = ["sts:AssumeRole", "sts:TagSession"]
    principals {
      type        = "Service"
      identifiers = ["pods.eks.amazonaws.com"]
    }
  }
}

resource "aws_iam_role" "cluster" {
  name               = "eks-orders-cluster"
  assume_role_policy = data.aws_iam_policy_document.eks_trust.json
}

resource "aws_iam_role_policy_attachment" "cluster" {
  role       = aws_iam_role.cluster.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
}

resource "aws_iam_role" "nodes" {
  name               = "eks-orders-nodes"
  assume_role_policy = data.aws_iam_policy_document.node_trust.json
}

resource "aws_iam_role_policy_attachment" "nodes" {
  for_each = toset([
    "AmazonEKSWorkerNodePolicy",
    "AmazonEKS_CNI_Policy",
    "AmazonEC2ContainerRegistryPullOnly",
  ])
  role       = aws_iam_role.nodes.name
  policy_arn = "arn:aws:iam::aws:policy/${each.key}"
}

resource "aws_eks_cluster" "orders" {
  name                          = "orders-prod"
  role_arn                      = aws_iam_role.cluster.arn
  deletion_protection           = true
  enabled_cluster_log_types     = ["api", "audit", "authenticator"]

  vpc_config {
    subnet_ids              = var.subnet_ids
    endpoint_private_access = true
    endpoint_public_access  = false
  }

  access_config {
    authentication_mode                         = "API"
    bootstrap_cluster_creator_admin_permissions = true
  }

  upgrade_policy {
    support_type = "STANDARD"
  }

  depends_on = [aws_iam_role_policy_attachment.cluster]
}

resource "aws_eks_node_group" "general" {
  cluster_name    = aws_eks_cluster.orders.name
  node_group_name = "general"
  node_role_arn   = aws_iam_role.nodes.arn
  subnet_ids      = var.subnet_ids
  instance_types  = ["m7g.large"]
  ami_type        = "AL2023_ARM_64_STANDARD"

  scaling_config {
    min_size     = 2
    desired_size = 3
    max_size     = 6
  }

  update_config {
    max_unavailable = 1
  }

  depends_on = [aws_iam_role_policy_attachment.nodes]
}

resource "aws_eks_addon" "pod_identity" {
  cluster_name = aws_eks_cluster.orders.name
  addon_name   = "eks-pod-identity-agent"
  depends_on   = [aws_eks_node_group.general]
}

resource "aws_iam_role" "orders_pod" {
  name               = "orders-api-pod"
  assume_role_policy = data.aws_iam_policy_document.pod_trust.json
}

resource "aws_iam_role_policy" "orders_pod" {
  name = "receipts-write"
  role = aws_iam_role.orders_pod.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = "s3:PutObject"
      Resource = "arn:aws:s3:::${var.receipt_bucket}/receipts/*"
    }]
  })
}

resource "aws_eks_pod_identity_association" "orders" {
  cluster_name    = aws_eks_cluster.orders.name
  namespace       = "orders"
  service_account = "orders-api"
  role_arn        = aws_iam_role.orders_pod.arn
  depends_on      = [aws_eks_addon.pod_identity]
}

resource "aws_eks_access_entry" "support" {
  cluster_name  = aws_eks_cluster.orders.name
  principal_arn = "arn:aws:iam::${data.aws_caller_identity.me.account_id}:role/support-readonly"
  type          = "STANDARD"
}

resource "aws_eks_access_policy_association" "support" {
  cluster_name  = aws_eks_cluster.orders.name
  principal_arn = aws_eks_access_entry.support.principal_arn
  policy_arn    = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy"

  access_scope {
    type       = "namespace"
    namespaces = ["orders"]
  }
}

# Runs inside the orders-api pod. No keys anywhere: with an EKS Pod Identity association, the agent on the node
# serves temporary credentials, and boto3's default chain finds them (AWS_CONTAINER_CREDENTIALS_FULL_URI).
import json
import os
import uuid
from datetime import datetime, timezone

import boto3
from botocore.config import Config

BUCKET = os.environ["RECEIPT_BUCKET"]
s3 = boto3.client("s3", config=Config(retries={"max_attempts": 5, "mode": "standard"}))


def save_receipt(order_id, total):
    body = json.dumps({"order": order_id, "total": total, "at": datetime.now(timezone.utc).isoformat()})
    key = "receipts/%s/%s.json" % (datetime.now(timezone.utc).strftime("%Y/%m/%d"), order_id)
    s3.put_object(Bucket=BUCKET, Key=key, Body=body.encode(), ContentType="application/json",
                  ServerSideEncryption="AES256")
    return key


def who_am_i():
    # Handy in a pod that gets AccessDenied: this shows whether it's the pod role or the node role.
    return boto3.client("sts").get_caller_identity()["Arn"]


if __name__ == "__main__":
    print("running as", who_am_i())
    print("saved", save_receipt(str(uuid.uuid4()), 1249.50))

// dotnet add package KubernetesClient
// Waits for the orders-api rollout, then lists any pod that is not ready. The default config reads your
// kubeconfig (the exec plugin calls "aws eks get-token"), or the service account inside a pod.
using k8s;
using k8s.Models;

var client = new Kubernetes(KubernetesClientConfiguration.BuildDefaultConfig());
const string ns = "orders", name = "orders-api";
var give_up = DateTime.UtcNow.AddMinutes(5);

while (true)
{
    V1Deployment d = await client.AppsV1.ReadNamespacedDeploymentStatusAsync(name, ns);
    int want = d.Spec.Replicas ?? 1;
    bool done = d.Status.ObservedGeneration >= d.Metadata.Generation
                && (d.Status.UpdatedReplicas ?? 0) == want
                && (d.Status.AvailableReplicas ?? 0) == want
                && (d.Status.Replicas ?? 0) == want;
    Console.WriteLine($"{name}: {d.Status.AvailableReplicas ?? 0}/{want} available");
    if (done) break;

    if (DateTime.UtcNow > give_up)
    {
        V1PodList pods = await client.CoreV1.ListNamespacedPodAsync(ns, labelSelector: "app=" + name);
        foreach (var p in pods.Items.Where(p => p.Status.Phase != "Running"
                                                || (p.Status.ContainerStatuses ?? new List<V1ContainerStatus>()).Any(c => !c.Ready)))
        {
            var waiting = p.Status.ContainerStatuses?.FirstOrDefault()?.State?.Waiting?.Reason;
            Console.Error.WriteLine($"  {p.Metadata.Name}: {p.Status.Phase} {waiting}");
        }
        Console.Error.WriteLine("Rollout did not finish in 5 minutes. Run: kubectl -n orders describe deploy " + name);
        return 1;
    }
    await Task.Delay(TimeSpan.FromSeconds(5));
}
Console.WriteLine("Rollout complete.");
return 0;

Short walkthrough videos for this service are being prepared. They will appear here and load only when you press play. Until then, follow CloudBrum on YouTube for new videos.

If you only need to run a few containers without Kubernetes, look at Amazon ECS, AWS App Runner or the equivalents on the other clouds. For event-driven code with no servers use AWS Lambda. Databases for the applications on a cluster usually sit outside it, for example on Amazon RDS, and files go to Amazon S3.