IaaS in practice: hosting a community app on AWS

Ever wondered what people actually mean when they say "we deployed it to the cloud"? Let's find out together. We'll use Amazon EC2 to explore Infrastructure as a Service (IaaS): you'll rent a server by the hour, host a small community app on it, and see which jobs the provider handles and which ones are still on you.
This one is for students and junior developers. If so far you've only run projects on your laptop or a shared host, you'll come away with a clear picture of what changes when you rent raw infrastructure.
A bit about me, for context: I'm a science student in Bamenda, and I built Bamenda Navigator, a map app for finding local places (40+ spots across 16 categories) with React, TypeScript, OpenStreetMap and Supabase. Supabase handled the backend for me, which is the managed, PaaS-style end of the spectrum. IaaS sits one level lower, where you run the server yourself.
I've also had a taste of the networking side. In a Cisco Packet Tracer assignment I connected two campus LANs with a router, static routing and SSH, so remote access and thinking about who can reach what weren't new to me when I started reading about EC2.
So why bother with IaaS?
Think about the last project you finished. Where did it run? A laptop goes dark the moment the battery dies. Shared hosting won't let you install what you need. Buying your own server means paying upfront, plus power, cooling and someone to fix it at 2 a.m. IaaS takes the hardware headache away but leaves the software in your hands, which is why it's usually the first cloud model developers try.
So what is IaaS, really?
Picture the cloud as a stack of layers, with IaaS as the bottom one. The provider owns the data centres, the physical servers, the disks and the cables. You simply rent slices of it over the internet: virtual machines, virtual disks and virtual networks. You pick the size, the operating system and where in the world it lives, and you only pay for what you use.
Here's the part worth remembering: responsibility is split. The provider looks after everything up to the hypervisor, the software that carves one physical server into many virtual ones. From the operating system upward, it's all you. Have a look at who handles what in each model:
Layer
On-premises
IaaS
PaaS
SaaS
Application and data
You
You
You
Provider
Runtime and middleware
You
You
Provider
Provider
Operating system
You
You
Provider
Provider
Virtualization, servers, storage, network
You
Provider
Provider
Provider
Data centre (power, cooling, buildings)
You
Provider
Provider
Provider
Want some real names to hang these on? Amazon EC2, Google Compute Engine and Azure Virtual Machines are IaaS. Heroku and Google App Engine are PaaS. Gmail and Google Docs are SaaS. Which of these have you already used?
Our case study: a community place-finder on EC2
Let's make this concrete. Imagine you're part of a student team in Bamenda building a web app that helps residents find clinics, markets and transport stops. It's a Node.js API with a small database, and at first only a few hundred people will use it. What do you need? A public address, a server that stays on, and room to grow.
EC2 (Elastic Compute Cloud) is a great fit here, and here's why:
• You're in control. Pick the operating system, install whatever you like and open only the ports you choose.
• Size on demand. Start small, then move up to a bigger instance later by stopping it and changing its type.
• A location on the continent. AWS has a region in Cape Town (af-south-1), which puts your servers in Africa. That can help for local users, but test it: compare response times from your own network against a European region before you commit. New regions open over time, so check the list too.
The IaaS pieces we'll use
EC2 is just one service, but a real deployment needs a few IaaS pieces working as a team. Here's the cast:
Building block
What it is
Role in our app
EC2 instance
A virtual machine with a chosen CPU and memory size
Runs Nginx and the Node.js API
AMI
A machine image: the operating system template
Ubuntu Server as the starting point
EBS volume
A virtual disk attached to the instance
Holds the OS, app code and database files
VPC and subnet
Your private virtual network inside AWS
Isolates the app from other customers
Security group
A stateful virtual firewall around the instance
Allows web traffic and admin SSH only
Key pair
A public/private key used to log in over SSH
Replaces passwords for server access
Elastic IP
A fixed public IPv4 address
Keeps the app address stable after restarts
EBS snapshot
A point-in-time backup of a volume
Lets the team restore after a mistake
Now let's see how they fit together. A visitor's browser reaches your Elastic IP. The security group lets in only ports 80 and 443. Nginx on the instance passes each request to your Node.js app, and any data lands on the EBS volume. Simple, and every piece has a clear job.
Let's build it: from zero to a running app
Roll up your sleeves, because we're doing this in the AWS console. Menu names move around now and then, so treat these steps as a map rather than a script.

1. Pick your region. In the console, switch to Africa (Cape Town) or whichever region works best for your users.
2. Launch an instance. Open EC2 and click Launch instance. Name it place-finder, choose an Ubuntu Server LTS image and pick a small type such as t3.micro. Before you click through, check your free plan: accounts opened since July 2025 start on a credit-based plan (up to $200 in credits, lasting at most 6 months), while older accounts keep the previous free tier.
3. Create a key pair. Download the .pem file and guard it carefully. AWS won't hand it to you a second time.
4. Set up the firewall. In the security group, allow SSH (port 22) from your own IP only, and HTTP (80) and HTTPS (443) from anywhere. Resist the urge to open SSH to the whole internet!
5. Connect. Swap in your instance's public IP and run: chmod 400 place-finder.pem ssh -i place-finder.pem ubuntu@YOUR_PUBLIC_IP
6. Install what you need. sudo apt update && sudo apt upgrade -y sudo apt install -y nginx nodejs npm
7. Bring your app over. Copy your project to the server (a git clone works nicely), install its dependencies and start it on port 3000. For anything beyond a quick test, run it under systemd or a process manager so it restarts itself after a crash or a reboot.
8. Let Nginx guard the front door. Drop this server block into /etc/nginx/sites-available/default, then run sudo nginx -t && sudo systemctl reload nginx: server { listen 80; server_name _; location / { proxy_pass http://127.0.0.1:3000; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; } }
9. Give it a permanent address. Allocate an Elastic IP and attach it to your instance, so the address survives stops and starts.
10. Build a safety net. Take an EBS snapshot before every big change, and try restoring from one at least once. A backup you've never tested is just a hope. Now open the Elastic IP in your browser. Did the app load? Congratulations, you've just run a real IaaS deployment! Who looks after what? Security and costs Here's a question worth asking before you launch anything: if something goes wrong, whose job is it to fix it? AWS answers with the shared responsibility model. AWS secures the cloud itself (the buildings, the hardware and the hypervisor), while you secure whatever you put inside it. On EC2, your to-do list looks like this: • Keep the operating system and packages up to date. • Open only the security group rules your app really needs. • Protect your key pair and switch off password logins over SSH. • Back up your data, and test the restore. • Encrypt sensitive data and rotate your secrets. Money deserves the same care. Compute is billed while an instance runs, but a stopped instance still costs you for its EBS volume, snapshots and any IP address you hold. AWS also bills for public IPv4 addresses, even idle Elastic IPs. So how do you dodge a nasty surprise? • Set a billing budget with an email alert in AWS Budgets on day one. • Terminate test instances and delete unused volumes, snapshots and Elastic IPs. • Start with the smallest instance that handles your load, and upsize only when monitoring tells you to. IaaS: the good, the bad and the alternatives

Advantages
Drawbacks
Cost
Pay for use, no hardware purchase
Bills can grow if resources are left running
Control
Full access to OS, software and network
You must patch, secure and monitor everything
Scale
Resize or add servers in minutes
Scaling beyond one server needs design work
Reliability
Multiple zones and regions available
One instance is still a single point of failure
Skills
Teaches real operations practice
Steeper learning curve than PaaS
So, is IaaS always the answer? Not quite. If your team just wants to ship code and has no appetite for managing servers, a PaaS like Heroku or App Engine takes the operating system chores off your plate. IaaS shines when you need custom software or specific network rules, or when you simply want to learn how deployments really work.
Wrapping up
IaaS hands you the raw building materials of computing, and EC2 shows the idea clearly: rent a virtual machine, a disk and a network, then build and secure everything on top. Our place-finder app went from nothing to a public, stable deployment with one instance, one firewall, one fixed IP and one backup routine.
Ready to go further? Here are a few next steps to try:
• Add HTTPS with a free certificate from Let's Encrypt.
• Move the database to a managed service, your first step into PaaS.
• Put the app behind a load balancer with two instances in different availability zones.
• Automate the whole setup with an infrastructure-as-code tool such as Terraform.