Best Projects for New Cloud Engineers to Build

Cloud · Projects · Portfolio · 2026

Best Projects for New Cloud Engineers to Build

SECTION 01How to sequence projects

The temptation is to jump straight to the "impressive" project — a Kubernetes cluster or a Terraform-managed production stack. Don't. Projects you can't fully explain are worse than simpler projects you can. The right sequence:

• One concept per project. Project one teaches hosting. Project two teaches compute. Project three teaches DNS. If a project teaches five things at once, you'll learn none deeply.
• Every project ends with a live URL and a public repo. Not a screenshot in a PDF. A URL a recruiter can click and a repo they can read.
• Every project has a README explaining the design. Why this service, why this structure, what you'd change at scale. The README is half the portfolio.
• Every project gets destroyed at the end. Delete the resources when done — or document that you did. Leaving AWS billing silently running is a common newbie mistake and a real interview red flag.
• Every project is documented with architecture. A simple diagram (draw.io, Excalidraw) showing the services and their connections.

SECTION 02Foundation projects

Project 1 — Static site on S3 + CloudFront

• What it teaches: Object storage, static website hosting, CDN caching, HTTPS certificates, DNS routing.
• AWS services: S3, CloudFront, Route 53 (optional), ACM.
• Time: A weekend.
• Signal: You understand the cheapest, most common deployment pattern in the industry — hosting a static frontend globally.

Build a small site — your portfolio, a landing page, a documentation site. Upload to S3, serve through CloudFront, add a custom domain with HTTPS. Then update it with the AWS CLI or a small deployment script. This is how you learn the fundamentals of bucket policies, cache invalidation and certificate management.

Project 2 — EC2 web server with a real app

• What it teaches: Compute provisioning, security groups, SSH, package installation, systemd services.
• AWS services: EC2, VPC (default), Security Groups, Elastic IP.
• Time: 1–2 days.
• Signal: You can provision a server, secure it, install software and keep a service running — the foundation of cloud engineering.

Launch an EC2 instance with Amazon Linux, restrict SSH to your IP, install a small web app (Flask, Express or a static Nginx site), configure it as a systemd service, and access it via public IP. Then attach an Elastic IP and — critically — terminate the instance when done. Understanding what a security group does before touching anything else will save you months.

Project 3 — Domain + HTTPS in front of EC2

• What it teaches: DNS records, TLS certificates, HTTPS enforcement, load balancer basics.
• AWS services: Route 53, ACM, Application Load Balancer, EC2.
• Time: 1–2 days.
• Signal: You understand how HTTPS works at the cloud level — a surprisingly common interview topic.

Buy a cheap domain, point it at an Application Load Balancer, request a free certificate from ACM, terminate TLS at the ALB and forward HTTP to your EC2 instance. This is the smallest "real" production pattern — and it teaches you the exact shape of most production web architectures you'll see later.

SECTION 03Intermediate projects

Project 4 — Serverless API with Lambda + API Gateway

• What it teaches: Serverless computing, event-driven design, API Gateway, IAM roles for functions.
• AWS services: Lambda, API Gateway, DynamoDB (optional), IAM.
• Time: 3–5 days.
• Signal: You understand serverless — the alternative compute model that many modern products rely on.

Build a small REST API for a to-do list or a URL shortener. Routes hit a Lambda function, which reads and writes to DynamoDB (or a simple S3 JSON file for extra credit). Deploy with the Serverless Framework or AWS SAM. The learning here is IAM — permissions between services are where most beginners get stuck.

Project 5 — CI/CD pipeline from GitHub to AWS

• What it teaches: CI/CD, GitHub Actions, containerisation basics, automated deployment.
• Tooling: GitHub Actions, Docker, ECR (or S3 for static), EC2 or App Runner.
• Time: 3–5 days.
• Signal: You can automate what you built manually — the single biggest skill gap between "used the console" and "can work in a real team".

Take the EC2 project and automate the deployment. Containerise the app, push to ECR on every commit, and have GitHub Actions SSH into EC2 (or use SSM) to pull and restart the container. The pipeline should run tests, build the image, push, and deploy — all triggered by a git push. Include a rollback step.

Project 6 — Monitored application

• What it teaches: Observability, metrics, alerting, dashboards, cost visibility.
• AWS services: CloudWatch, CloudTrail, SNS, Budgets.
• Time: 3–4 days.
• Signal: You understand that running software is about operating it, not just deploying it. This is what separates the professionals.

Add CloudWatch dashboards for your EC2/Lambda project — CPU, latency, error rate, request count. Set up CloudWatch alarms that notify you via SNS when error rate exceeds a threshold. Enable CloudTrail to log API activity. Add a budget alert at $5 to avoid surprise bills. The deliverable is a dashboard you can show in an interview — and the ability to say "here's how I'd know if this went down".

SECTION 04Advanced projects

Project 7 — Container deployment on ECS Fargate

• What it teaches: Containers, ECS, Fargate, task definitions, service discovery, load balancing.
• AWS services: ECR, ECS, Fargate, ALB, VPC, CloudWatch Logs.
• Time: 1 week.
• Signal: You can run containerised workloads — the baseline for modern cloud employment.

Take a multi-service app (frontend + backend + database) and deploy it on ECS Fargate behind an ALB. Push images to ECR, define task definitions, set up two ECS services (frontend and backend), and connect them via Service Connect or an internal ALB. This is real production shape — the same pattern most mid-size companies use.

Project 8 — Multi-environment setup

• What it teaches: Environment separation, config management, deployment promotion.
• AWS services: Any — but scaled across dev/staging/prod.
• Time: 1 week.
• Signal: You understand that production is a discipline, not a service. Most candidates have never thought about this.

Duplicate your earlier deployment into three environments — dev, staging and prod. Each has its own VPC, database, secrets and CI/CD pipeline. Deploy to dev on every push to develop, staging on merge to main, and prod on manual approval. This is the smallest realistic production setup and the base every future project builds on.

Project 9 — Custom VPC with public + private subnets

• What it teaches: VPC design, subnetting, route tables, NAT gateways, security groups vs NACLs.
• AWS services: VPC, Subnets, Route Tables, Internet Gateway, NAT Gateway, Security Groups.
• Time: 1 week.
• Signal: You can design the network layer. This is the single most common "did you actually understand it?" interview topic.

Build a custom VPC (not the default) with two public and two private subnets across two availability zones. A bastion host or SSM Session Manager in public. Application servers in private — reachable only through the ALB, no public IPs. A NAT gateway for outbound. The deliverable is a diagram and the ability to explain why each piece exists. If you can draw this from memory, you're ready for the next tier.

SECTION 05Portfolio projects

Project 10 — Full stack managed by Terraform

• What it teaches: Infrastructure as code, state management, modules, plan/apply workflows.
• Tooling: Terraform, remote state (S3 + DynamoDB lock), any two or three of the above services.
• Time: 2 weeks.
• Signal: You can define infrastructure as code — the single most important skill for a mid-level cloud engineer.

Take your multi-environment project and re-implement it entirely in Terraform — VPC, subnets, security groups, ECS services, ALB, DNS, certificates, everything. Structure it with modules (networking, ECS, database) and separate variable files per environment. Store state in S3 with DynamoDB locking. The deliverable is a repo a reviewer can terraform apply in their own account and get a working stack. This is the portfolio project that most convincingly says "hire me".

Project 11 — Kubernetes deployment on EKS

• What it teaches: Kubernetes, EKS, Helm, ingress, autoscaling, service discovery.
• AWS services: EKS, ECR, ALB (via ingress controller), IAM roles for service accounts.
• Time: 2–3 weeks.
• Signal: You can run workloads on Kubernetes — required for many DevOps and platform roles.

Create an EKS cluster with the eksctl tool, deploy the same multi-service app as a set of Deployments and Services, add an ALB Ingress for routing, and configure HPA to autoscale on CPU. If you have time, package the app as Helm charts. Destroy the cluster when you finish — EKS costs money every hour, and that cost awareness is itself a skill.

Project 12 — Production-style platform

• What it teaches: System design, trade-off reasoning, documentation, and cross-service integration.
• Combines: VPC design + Terraform + CI/CD + ECS/EKS + monitoring + security.
• Time: 3–4 weeks.
• Signal: You can design and defend a real platform. The portfolio project for a junior cloud engineer.

Build a complete platform: a small e-commerce or SaaS app deployed across three environments, all defined in Terraform, deployed via GitHub Actions, running on ECS or EKS, behind an ALB with HTTPS, monitored with CloudWatch and alerts, secrets in AWS Secrets Manager, and a documented incident runbook. The README should contain the architecture diagram, cost breakdown (even approximate), what you'd improve with more time, and what you'd do differently next time. This is the project you'll walk through in interviews for a year.

# The Terraform skeleton for project 10
# modules/
#   networking/   → VPC, subnets, route tables, NAT
#   ecs/          → cluster, services, task definitions
#   database/     → RDS or DynamoDB
#   observability/→ CloudWatch dashboards, alarms

# envs/dev/main.tf
module "networking" {
  source   = "../../modules/networking"
  cidr     = "10.0.0.0/16"
  env      = "dev"
}

module "ecs" {
  source        = "../../modules/ecs"
  vpc_id        = module.networking.vpc_id
  subnet_ids    = module.networking.private_subnet_ids
  container_img = "${var.ecr_repo}:${var.image_tag}"
  env           = "dev"
}

SECTION 06What interviewers look for

When an interviewer asks about your projects, they're not counting services — they're testing whether you understand what you built. Here's what matters:

• Can you draw the architecture from memory? The single strongest signal. If you built it, you can draw it. If you copied a tutorial, you'll struggle.
• Can you explain why, not just what? "I used ECS because…" beats "I used ECS". Trade-off reasoning is the skill being hired.
• What broke, and how did you fix it? Real projects have debugging stories. The best candidates have 3–4 to tell.
• How would you scale it? What happens at 10x traffic, or across regions? Even a rough answer shows you're thinking beyond "it works".
• How do you know when it's broken? What metrics, what alerts, what logs. Monitoring is often skipped in portfolios and it's the biggest differentiator.
• How much does it cost? Even approximate numbers. Cost awareness is rare and highly valued in cloud roles.
• What would you do differently? Reflects maturity and self-awareness. Almost every good candidate has a list.

SECTION 07Test yourself — cloud projects

SECTION 08Frequently asked questions

SECTION 09Related reads