Meet CloudyCups, a growing coffee startup that wanted to dip its toes into the cloud ☁️. Their mission? Launch a simple static website, set up a secure private/public network, and prepare a reusable EC2 deployment strategy.

As their cloud consultant (that’s me!), I guided them through a hands-on AWS setup. Here’s the story of how we went from zero resources → to a working, secure, and repeatable AWS environment.


🗂 Step 1: Hosting a Static Website on S3

We kicked things off with a simple S3 bucket website.

  • Created an S3 bucket named s3-54983537


  • Enabled ACLs and Versioning (future-proofing FTW ✨)

  • Configured public access and wrote a bucket policy 🛡️



  • Uploaded assets: index.html, hw.css, AWS_TE.pdf, and an image.


  • Changed the files visibility to public.


  • Flipped the magic switch → Static Website Hosting


💡 Aha moment: Seeing the Hello World! page live in a browser from an S3 link was CloudyCups’ first taste of serverless hosting.

We started with Amazon S3 → created a bucket, enabled ACLs, uploaded files, and turned on static website hosting. That gave us a quick, working Hello World! page 🎉.

💡 But here’s the catch: AWS now doesn’t recommend S3 static hosting for production websites. Instead, they guide you toward AWS Amplify Hosting — which gives you:

  • 🔒 Built-in HTTPS with free SSL certificates

  • 🚀 CI/CD pipelines from GitHub/GitLab/CodeCommit

  • 🌍 Global delivery via CloudFront automatically

  • 📊 Monitoring, rollbacks, and branch-based environments

⚡ Bonus Modern Step: Deploying with Amplify

To modernize CloudyCups’ static site, here’s what we did after finishing the S3 bucket deployment:

  1. Start a Manual Deployment and write app name then choose method as Amazon s3 and select s3 bucket on Browse s3 that we created.  

  2. Amplify built and deployed the site automatically 🏗️.

  3. Got a shiny Amplify domain with HTTPS enabled out-of-the-box ✨.


🌐 Step 2: Designing a Custom VPC

Next, we needed a secure playground for CloudyCups’ backend. Enter: VPC.

  • Created vpc-54983537 with CIDR 10.23.0.0/16


  • Added two subnets:

    • Public Subnet 54983537 → 10.23.0.0/24

    • Private Subnet 54983537 → 10.23.1.0/24


  • Enabled auto-assign public IPv4 for the public subnet by going to the Edit subnet settings on the actions menu after selecting the public subnet.

💡 Key takeaway: Public = internet-facing ☕ customers, Private = internal workloads 🍳 barista systems.

🔀 Step 3: Setting Up Routing & Gateways

Networking can be tricky — and we hit a small uh-oh moment here 🤯.

At first, both subnets shared the default route table (no internet access). That meant our instances were trapped! To fix it:

  • Created Internet Gateway (igw-54983537) and attached to the VPC


  • Created NAT Gateway (NAT-gw-54983537) in the public subnet with an Elastic IP

  • Edited Private-rt:
    • Added a route → 0.0.0.0/0 → pointed to NAT-gw-54983537.
    • This gave the private subnet secure outbound internet access.

  • Created a new route table → Public-rt-54983537.

    • Added a route → 0.0.0.0/0 → pointed to igw-54983537.
    • Associated it with the Public Subnet only in the Explicit subnet associations tile, by selecting Edit subnet associations.

💡 Aha moment: With this setup, the public subnet could serve traffic directly, while the private subnet could safely access the internet without being exposed.

💻 Step 4: Brewing Our First Web Server — EC2 with IIS

After setting up the VPC and routing, it was time to give CloudyCups its first web server. This was a critical moment: if we got this wrong, there’d be no place to host their app.

Here’s how we did it:

  1. Went into EC2 → Instances → Launch instance.

  2. Named it Win-starter-54983537.

  3. Selected the Microsoft Windows Server 2019 Base AMI (free tier eligible).

  4. Chose t2.micro (perfect for testing ☕).

  5. Created a new key pair: Win-54983537-keypair. (Saved carefully — without it, no login 🔑).


  6. Set networking:

    • VPC → vpc-54983537

    • Subnet → Public Subnet 54983537

    • Auto-assign Public IP → Enabled


  7. Created a Security Group Win-sg-54983537 with two rules:

    • RDP (default, for admin access)

    • HTTP (0.0.0.0/0) → “Allow HTTP for user data testing” 🌍

  8. Expanded Advanced details → User Data → added a script to install IIS automatically:

    <powershell> 
Install-WindowsFeature -name Web-Server -IncludeManagementTools  
</powershell>

    (This meant IIS would install as soon as the server booted — no manual work 💡).

  9. Launched the instance → waited until it hit Running and 2/2 checks passed ✅.

🔍 Testing the Setup

  • Copied the instance’s Public IPv4 from the console.

  • Pasted into the browser → boom 💥 the IIS Welcome Page appeared.

  • Uh-oh moment: At first, I mistakenly tried HTTPS and got nothing. Switching to HTTP fixed it immediately (because our SG only allowed port 80).

💡 Aha moment: With just a bit of automation (User Data + IIS), CloudyCups had their very first working web server serving content to the internet.

🖼 Step 5: Saving Our Recipe — Creating a Custom AMI

Once the first web server worked, I didn’t want to repeat those setup steps every time. So I turned it into a custom AMI — a reusable recipe.

  1. Selected Win-starter-54983537 in EC2.

  2. Actions → Image and templates → Create image.

  3. Named it Windows Web Server 2019, described as Windows Server 2019 with IIS installed.

  4. Waited until the AMI status changed to available ✅.

💡 Aha moment: Now CloudyCups had a blueprint web server ready to launch anytime, anywhere.

🔐 Step 6: Crafting a Web Security Group

To prepare for scale, I created a dedicated security group for web servers:

  • Name: Web-sg-54983537

  • Description: Allow public access to web servers in vpc-54983537

  • VPC: vpc-54983537

  • Inbound rule: HTTP (port 80) from Anywhere (IPv4) 🌍


💡 Aha moment: Instead of reusing the starter SG, CloudyCups now had a clean, dedicated SG for production-like web workloads.

📄 Step 7: Building a Launch Template

With the AMI and SG ready, I automated everything in a Launch Template:

  1. EC2 → Launch Templates → Create launch template.

  2. Name: web-template-54983537.

  3. Description: Windows 2019 web server running on a t2.micro instance.

  4. Image: selected the custom Windows Web Server 2019 AMI.


  5. Instance type: t2.micro.

  6. Key pair: Win-54983537-keypair.

  7. Security group: Web-sg-54983537.

  8. Advanced details: Metadata set to V1 and V2 (token optional).


  9. Created successfully ✅.

💡 Aha moment: Now CloudyCups could spin up identical IIS servers without re-clicking through 10+ wizard steps.

🚀 Step 8: Launching a New Instance from the Template

Time for the test.

  1. Selected web-template-54983537 → Actions → Launch instance from template.


  2. Used the Public Subnet 54983537.

  3. Added a tag: Name=Win-Web-54983537.

  4. Launched the instance.

  5. After checks passed → copied the Public IPv4.

  6. Opened in browser → IIS Welcome Page loaded instantly 🎉.

💡 Final aha moment: With a single template, CloudyCups now had repeatable, production-ready deployments.

✅ What We Built

By the end of the day, CloudyCups had:

  • 📦 An S3 website for static hosting

  • ☁️ A VPC with public + private subnets

  • 🔀 Routing via IGW & NAT Gateway

  • 💻 A running EC2 IIS web server

  • 🖼️ A custom AMI

  • 📄 A Launch Template for repeatable deployments

🚀 Next Steps for CloudyCups

The journey doesn’t stop here. If CloudyCups keeps brewing ☕ in the cloud, here’s where they could go next:

  • Add CloudFront CDN for global delivery 🌍

  • Secure with ACM SSL certs + AWS WAF 🔐

  • Move workloads to RDS (coffee order database) 🗄️

  • Automate deployments with CloudFormation ⚡

  • Set up CloudWatch alarms for proactive monitoring 📊

Final Remarks:

Whether you're brewing coffee or brewing cloud solutions, the principles remain the same: start with quality ingredients (solid AWS services), follow proven recipes (best practices), and always be ready to scale when demand grows. CloudyCups Coffee now has an infrastructure that can grow from serving a local neighborhood to serving customers worldwide—all thanks to the flexibility and power of AWS.

Remember: every expert cloud architect started with their first S3 bucket and EC2 instance. The key is to keep building, keep learning, and keep brewing. ☕☁️

Thank you for following along on this cloud journey. May your deployments always be successful and your coffee always be strong!