DevOpsMay 22, 202616 views0 comments

Deploy a Kubernetes Cluster on AWS in Under 20 Minutes with SeaGit

By SeaGit

#aws#kubernetes#cluster#terraform#iam

Spinning up a production-grade Kubernetes cluster on AWS usually means juggling VPCs, IAM roles, node groups, and a wall of Terraform. With SeaGit you can go from zero to a running EKS cluster in under 20 minutes — no prior Kubernetes expertise required. This walkthrough covers every step, the decisions that matter, the gotchas that bite first-timers, and how the whole thing stays reproducible under the hood.

What you'll need

A SeaGit account (the free tier works fine for this)
An AWS account with permission to create IAM roles
About 20 minutes and a coffee

You do not need the AWS CLI, eksctl, kubectl, or any Terraform installed locally. Everything below happens through the SeaGit dashboard, and the infrastructure is provisioned with infrastructure-as-code on the platform side.

Why EKS setup is normally painful

A "real" EKS cluster is never just the control plane. To run production workloads you also need a VPC with public and private subnets across at least two Availability Zones, NAT gateways for egress, IAM roles for the cluster and the nodes, an OIDC provider for workload identity (IRSA), an ingress controller, a load-balancer controller, DNS, and TLS. Wiring these by hand — or maintaining the Terraform that does — is where teams lose days. SeaGit encodes those decisions as sensible defaults you can override, so you get the same architecture without authoring it.

Step 1 — Connect your AWS provider (3 min)

In the SeaGit dashboard, go to Providers and click Connect AWS. SeaGit walks you through creating a scoped IAM role: you copy a generated trust policy into the AWS console, create the role, and paste the role ARN back. That's it — there are no long-lived access keys to store or rotate, because SeaGit assumes the role you created via STS.

Scope matters here. The role only needs permissions for the resources SeaGit provisions on your behalf (EKS, EC2/VPC, IAM for the cluster's own roles, ELB, Route 53 if you use managed DNS). Grant it at the account or organizational-unit level you're comfortable with; you can tighten it later without breaking existing clusters.

Gotcha: if the connection test fails, it's almost always the trust policy — make sure you pasted SeaGit's exact external ID and principal, not a hand-edited version.

Step 2 — Create a network (2 min)

Head to Networks and click New VPC. Pick a region and a CIDR range. The default 10.0.0.0/16 is fine for most teams and gives you room for tens of thousands of pods; only change it if it collides with an existing network you plan to peer with.

SeaGit provisions the VPC, public and private subnets spread across the region's Availability Zones, an internet gateway, and NAT gateways for private-subnet egress. Nodes run in the private subnets; load balancers live in the public ones. If you're cost-sensitive on a dev cluster, you can choose a single-NAT strategy — one NAT gateway instead of one per AZ — which trades a little resilience for a meaningful monthly saving.

Step 3 — Provision the cluster (10 min)

Open Clusters and click New Cluster:

Network — choose the VPC you just created
Kubernetes version — the latest stable release is pre-selected; unless you have a hard dependency, take it
Node group instance type — t3.medium is a good starting point for evaluation; move to m6i/c6i families for real workloads
Autoscaling — set min/max nodes (try 2–4). The cluster autoscaler adds and removes nodes as pods demand capacity

Hit Create. SeaGit provisions the EKS control plane, the managed node group, the OIDC provider for IRSA, and the core add-ons — NGINX ingress, the AWS Load Balancer Controller, and Argo CD — automatically. This is the longest step because AWS itself takes roughly 8–10 minutes to bring up a control plane. Grab that coffee.

Behind the scenes this is all declarative: the same cluster definition can be rebuilt identically, which is what makes it auditable and reproducible even though you never opened a .tf file.

Step 4 — Deploy your first app (3 min)

Once the cluster shows Ready, create an Environment (say, production), then add an Application. Point it at your container image, set the port your app listens on, and deploy. SeaGit assigns a DNS subdomain, requests a TLS certificate, wires up ingress, and rolls out your workload with zero-downtime defaults (rolling update, readiness gating).

Push a commit to a connected repository and the CI/CD pipeline builds the image and deploys an ephemeral preview environment on its own URL automatically — a real dark release that never touches your main deployment. (More on that in Preview & ephemeral environments.)

Common first-run issues

Cluster stuck in "Creating" past 20 minutes — usually an AWS service quota (VPCs, Elastic IPs, or NAT gateways per region). Check Service Quotas and request an increase. See the troubleshooting guide for the exact quotas.
Nodes never join — almost always the node IAM role or a subnet without a route to the control plane. SeaGit sets these up for you, but a hand-edited VPC can reintroduce the problem.
App reachable by IP but not by domain — DNS or certificate propagation; give external-dns and cert-manager a minute, then check the ownership TXT records. See DNS & domains.

What you actually get

You now have a real EKS cluster — autoscaling nodes, ingress, GitOps delivery via Argo CD, automatic DNS and TLS, and your first app live — in under 20 minutes. Everything is provisioned as infrastructure-as-code, so it's reproducible and auditable, but you never had to write or maintain a line of Terraform. And because the cluster runs in your own AWS account, you own the infrastructure and pay AWS directly with no platform markup.

Frequently asked questions

Do I need to know Kubernetes to use this?

No. The guided flow provisions the cluster, add-ons, and your first deployment for you. Engineers can drop down to node-group tuning, custom add-ons, and raw manifests when they need to, but the zero-config path is the safe path.

How much does the cluster cost?

You pay AWS directly for the EKS control plane (a flat hourly fee), the EC2 nodes you run, NAT gateways, and load balancers — there's no SeaGit markup on that infrastructure. SeaGit itself has a free plan; see pricing.

Can I deploy to my own AWS account instead of a vendor's platform?

Yes — that's the point. Clusters and workloads run in your AWS account (bring-your-own-cloud), so your data and infrastructure stay under your control. That's the core difference in SeaGit vs Heroku.

Does it work with Azure and GCP too?

Yes. The same flow provisions AKS on Azure and GKE on GCP. Connect the relevant provider under Providers.