DEV Community: Amapakabo, Joseph I.

Scaling Up: How I Deployed an Azure VM Scale Set with a Load Balancer and Apache2

Amapakabo, Joseph I. — Sat, 23 May 2026 09:48:07 +0000

A hands-on walkthrough of setting up an Azure Virtual Machine Scale Set (VMSS) from scratch — complete with a Load Balancer, autoscaling, custom Apache2 web pages, and NSG configuration. Each step is screenshotted.

TL;DR: In this post, I walk through how I set up a complete Azure VM Scale Set (VMSS) environment — resource group, virtual network, load balancer with a health probe and inbound rule, autoscaling configuration, Apache2 deployed via cloud-init custom data, and NSG rules to let traffic through. The end result? A live, load-balanced web page rotating across multiple VM instances. Let's go. ☁️

Why VMSS?

A single VM is fine for learning, but it's not how real production workloads run. The moment your app starts getting actual traffic, you need something that can scale out automatically and stay available even when an instance goes down.

That's exactly what Azure Virtual Machine Scale Sets (VMSS) solve. VMSS lets you run a group of identical VMs that scale in and out based on demand — and when paired with an Azure Load Balancer, traffic gets distributed evenly across all running instances.

This is the setup I put together, step by step.

Prerequisites

An active Microsoft Azure account
Basic familiarity with the Azure portal
A browser and some patience 😄

Step 1: Create a Resource Group

Everything starts here. The resource group is the logical container that holds every resource we're about to create — VNet, Load Balancer, VMSS, NSG, all of it.

Search for Resource Groups in the portal, click Create, and fill in your subscription, a name (azure-vmss), and region. I used South Africa North throughout.

Click Review + create, then Create.

Step 2: Create the Virtual Network (VNet)

Next up is the network that our scale set instances will live inside.

Search for Virtual Network, click Create, attach it to the azure-vmss resource group, name it vmss-vnet, and set the same region. Go through the tabs — leave Security defaults as-is, configure your address space, skip Tags — and click Create.

Step 3: Create the Load Balancer

This is the piece that sits in front of our VMs and distributes incoming traffic. Without it, VMSS doesn't have a single public entry point to route requests through.

Search for Load Balancers and select Create > Standard Load Balancer from the dropdown.

3a. Basics

Name it vmss-lb, set the type to Public, SKU to Standard, and tier to Regional. Make sure it's in the same resource group and region.

Click Next: Frontend IP configuration.

3b. Add a Frontend IP Configuration

The frontend IP is the public-facing address your load balancer listens on. Click + Add a frontend IP configuration.

Name it frontend-vmss1, leave IP version as IPv4, and click Create new under Public IP address to generate a new one. Save, then save again.

3c. Add a Backend Pool

The backend pool is the group of VMs the load balancer will distribute traffic to — our VMSS instances will register here automatically.

Click Next: Backend pools, then + Add a backend pool.

Name it backend-vmss1, select the vmss-vnet virtual network, set backend pool configuration to NIC, and save.

3d. Add an Inbound Load Balancing Rule

The load balancing rule tells the balancer how to distribute incoming traffic to the backend pool. Click Next: Inbound rules, then + Add a load balancing rule.

Set the rule name to vmsslb-rule1, select frontend-vmss1 as the frontend IP, backend-vmss1 as the backend pool, protocol TCP, and port 80.

For the Health probe, click Create new.

Name it vmsslb-health, set protocol to HTTP, port 80, path /, and interval 5 seconds. Save.

Save the rule, then save again to confirm all settings.

3e. Review + Create

With everything configured, navigate to Review + create. Confirm the validation passes and click Create.

Once deployment completes, click Go to resource to view your new load balancer. You'll also see a success notification in the top-right bell icon.

📌 Take note of your frontend IP address. You'll need it later to test the setup in your browser. Mine was 20.87.240.113.

Step 4: Create the VM Scale Set (VMSS)

With the networking and load balancer in place, it's time to create the scale set itself.

Search for Virtual Machine Scale Set in the portal and click Create.

4a. Basics

Fill in the details: subscription, resource group (azure-vmss), scale set name (myvmss1), region (South Africa North), and availability zones 1, 2, 3.

Set Orchestration mode to Flexible and Scaling mode to Autoscaling.

4b. Configure Autoscaling

Once you select Autoscaling, a Scaling configuration section appears. Click Configure to set up the autoscale policy.

You'll land on the Scaling configuration page showing the Default condition. Click the edit (pencil) icon to modify it.

In the Edit Condition panel, set the parameters like this:

Scale mode: Autoscaling
Default instance count: 2
Minimum: 2
Maximum: 5
Scale out when CPU > 80%

Scroll down to also set the Scale in rule and query duration:

Scale in when CPU < 20%
Query duration: 10 minutes

Save twice to apply and return.

4c. Select Disk Image, Size, and Admin Credentials

Scroll up to the image and size section. I used Ubuntu Pro 24.04 LTS - x64 Gen2 with size Standard B2as v2. Set your admin username (vmssengine) and password.

4d. Networking Tab

Click on Networking (or hit Next until you reach it). Confirm the virtual network and subnet are selected. Scroll down to the Load balancing section and select Azure load balancer, then pick vmss-lb as your load balancer and backend-vmss1 as the backend pool.

4e. Management Tab

In the Management tab, set Boot diagnostics to Disable — this prevents an unnecessary storage account from being auto-created. Leave everything else as default.

4f. Advanced Tab — The Cloud-Init Script

This is where the magic happens. The Advanced tab has a Custom data field that accepts a cloud-init script. Whatever you paste here runs automatically on every VM instance when it boots — no manual SSH required.

Scroll down to Custom data and cloud init and paste in the following script:

#!/bin/bash

# Update package index
sudo apt-get update -y

# Install Apache2
sudo apt-get install apache2 -y

# Enable Apache2 to start on boot
sudo systemctl enable apache2

# Start Apache2 service
sudo systemctl start apache2

# Get hostname
HOSTNAME=$(hostname)

# Create custom webpage
cat <<EOF | sudo tee /var/www/html/index.html
<!DOCTYPE html>
<html>
<head>
  <title>Azure VMSS Demo</title>
  <style>
    body {
      font-family: Arial, sans-serif;
      background-color: #f4f4f4;
      text-align: center;
      padding-top: 100px;
    }
    h1 { color: #0078D4; font-size: 50px; }
    p  { font-size: 24px; }
  </style>
</head>
<body>
  <h1>Hello from $HOSTNAME</h1>
  <p>Azure VM Scale Set Instance</p>
</body>
</html>
EOF

# Restart Apache2 to ensure changes are loaded
sudo systemctl restart apache2

💡 This script installs Apache2, grabs the VM's hostname, and writes it into a custom HTML page. This is how we'll later confirm which instance is serving each request.

4g. Review + Create

Click through Tags and head to Review + create. Confirm the summary looks right — Ubuntu Pro 24.04 LTS, Standard B2as v2, Autoscaling, South Africa North — and hit Create.

Step 5: Get the Load Balancer's Frontend IP

Once the VMSS deploys successfully, navigate to your vmss-lb load balancer → Settings → Frontend IP configuration. You'll see the public IP address that was assigned.

Copy that IP address and paste it into your browser.

If the page doesn't load — don't panic. It just means the Network Security Group (NSG) hasn't been configured to allow HTTP traffic yet. We'll fix that next.

Step 6: Fix the NSG — Allow HTTP Traffic

The VMSS creates a default NSG attached to the network interfaces of each instance, but HTTP (port 80) isn't open by default. We need to add an inbound rule.

Search for NSG (or Network security groups) in the portal search bar.

You should see the auto-generated NSG for your VMSS. Click on it.

In the NSG blade, under Settings, click Inbound security rules.

Click + Add to add a new rule.

Set the following parameters and click Add:

Source: Any
Service: HTTP
Destination port: 80
Protocol: TCP
Action: Allow
Priority: 100
Name: Allowport80

Step 7: Verify in the Browser — Load Balancing in Action! 🎉

Go back to your browser and refresh. This time, the custom Apache page should load — showing the hostname of whichever VM instance handled your request.

Refresh again. The load balancer routes the request to a different instance — and a different hostname appears!

That right there is load balancing working as intended. Two different VM instances, same IP, same Apache page — but different hostnames proving requests are being distributed across the scale set.

Snapshot: All Resources Created

Here's a final look at the azure-vmss resource group showing everything that was provisioned end-to-end.

What We Built — At a Glance

Resource	Name	Purpose
Resource Group	azure-vmss	Container for all resources
Virtual Network	vmss-vnet	Private network for VM instances
Load Balancer	vmss-lb	Distributes public traffic to backend VMs
Frontend IP	frontend-vmss1	Public entry point (20.87.240.113)
Backend Pool	backend-vmss1	Pool of VMSS instances receiving traffic
Health Probe	vmsslb-health	Monitors instance health via HTTP port 80
LB Rule	vmsslb-rule1	Routes port 80 traffic to backend pool
VM Scale Set	myvmss1	Auto-scaling group of Ubuntu VMs
NSG	basicNsgvnet-...	Controls inbound/outbound traffic to instances

Key Takeaways

Build the load balancer before the VMSS — the VMSS networking tab lets you attach directly to an existing load balancer during creation. Much cleaner than doing it after.
Cloud-init custom data is powerful. No SSH needed. The script runs at boot time on every instance — perfect for installing software across an entire scale set.
NSGs are the silent gatekeepers. Even with everything configured correctly, traffic won't flow until the NSG explicitly allows it. Always check here first if the browser isn't loading.
The hostname trick is a great sanity check. Embedding $(hostname) in the web page makes it immediately obvious when the load balancer is routing to different instances.
Autoscaling keeps costs in check. With min 2, max 5 instances and CPU thresholds at 80% (scale out) and 20% (scale in), the setup only spins up extra capacity when it actually needs it.

What's Next?

From here, you could:

Add HTTPS using an Azure Application Gateway or Let's Encrypt certificates
Set up Azure Monitor alerts and autoscale diagnostics
Deploy a real application instead of the static Apache page
Explore Azure Spot Instances within the scale set to cut compute costs significantly
Configure custom scaling schedules for predictable traffic patterns

This was one of the most satisfying setups I've done so far in my cloud engineering journey — watching the browser rotate between two different hostnames on refresh just hits different. 😄

If you followed along and ran into any issues, drop a comment. Happy to help.

Keep building. ☁️

#azure #cloudengineering #devops #vmss #loadbalancer #linux #apache #autoscaling #100daysofcloud #beginners

From Zero to Deployed: Setting Up an Azure VM with Apache2 (Step-by-Step)

Amapakabo, Joseph I. — Sat, 18 Apr 2026 07:01:40 +0000

A practical, beginner-friendly walkthrough of deploying an Azure Virtual Machine, configuring a Virtual Network, SSHing in, and hosting a live Apache2 web server — all from scratch.

TL;DR: In this post, I walk through how I deployed an Azure Virtual Machine from scratch — set up the subscription, resource group, virtual network, and finally spun up an Apache2 web server accessible via a public IP. If you're just getting into cloud engineering, this one's for you.

Why This Matters

Cloud infrastructure isn't just for big tech anymore. Whether you're building a side project, preparing for a cloud cert, or just trying to understand what "the cloud" actually means under the hood — knowing how to spin up a virtual machine and serve traffic from it is a fundamental skill.

This post documents my hands-on journey doing exactly that on Microsoft Azure. Every step is screenshotted, so you can follow along visually.

Let's get into it. 🚀

Prerequisites

Before we dive in, make sure you have:

An active Microsoft Azure account (free tier works fine to start)
Git Bash installed (or any terminal that supports SSH)
Basic comfort with the command line

Step 1: Create a Subscription

Everything on Azure lives under a subscription — think of it as your billing and organizational umbrella.

In the Azure portal, search for "Subscriptions" in the top search bar and click on it.
Click Create.
Type your subscription name in the highlighted field (I named mine My VM & Apache Setup).
Click Next and follow through each stage.

Once you've gone through all the tabs, you'll land on the Review + Create screen. Confirm the validation passes and hit Create.

💡 If you're on the Azure free tier, a default subscription is usually already set up for you. You can skip this step and move straight to Step 2.

Step 2: Create a Resource Group

A Resource Group is a logical container for all the Azure resources that belong to a project. It keeps things tidy and makes cleanup much easier when you're done.

From the left-hand menu of your subscription, select Resource Groups, then click Create.

Enter the required details — your subscription, a region, and a meaningful name for the group. I used MyVM1-setup and selected (Africa) South Africa North as my region.
Click Next through each section and finalize with Review + Create → Create.

Your Resource Group is now live and ready to house all the resources we'll be creating.

Step 3: Create a Virtual Network (VNet)

The Virtual Network is the private network your VM will operate inside. This is where you define your IP address ranges, subnets, and traffic boundaries. Think of it as building the roads before driving the car.

3a. Create the VNet — Basics Tab

Search for "Virtual Network" in the search bar and click on it.
Click Create, then select your subscription and resource group.
Give your VNet a name and proceed to the next tab.

3b. Security Settings

Leave the defaults in the Security section and click Next — no changes needed here for a basic setup.

3c. Address Space & Subnets

In the Address Space tab, you'll see a default subnet already configured. I deleted it and created my own to have full control over the IP range.

Click Next through Tags (skip if you don't need them), then select Create in the Review + Create tab.

3d. Navigate to Subnets After Deployment

Once the VNet deploys, you'll see the success screen. Click Go to resource.

Then, in the left-hand menu under Settings, click Subnets. Hit the + Subnet button at the top to add a new one.

3e. Add Your Subnet

In the Add a Subnet pane, enter your subnet name and configure the IP address range. I used vm1-subnet with a /24 range (10.0.1.0 - 10.0.1.255 — 256 addresses). Click Add when done.

Step 4: Create the Virtual Machine

Here's where the fun begins. 🎉

Search for "Virtual Machines" in the portal. You'll see the VM dashboard — currently empty.

Click Create and fill in all the necessary details — name, region, image (I used Ubuntu 24.04 LTS), size, and disk (I went with a 64 GB Standard SSD).
Critical step — Inbound Port Rules: Make sure these two ports are open:
- Port 22 — for SSH access
- Port 80 — for HTTP (public web access)

When you're satisfied with your configuration, click Review + Create → Create.

A prompt will immediately appear asking you to generate and download your SSH key pair. This is non-negotiable — Azure does not store the private key after this point. Download it, keep it safe.

Click Download private key and create resource, then Return to create a virtual machine. Wait a few minutes for the deployment to complete.

Step 5: SSH Into Your VM

With the VM up and running, it's time to connect to it. Open Git Bash and run the following:

# Navigate to your Downloads folder (where your .pem file is)
cd downloads

# Set the correct permissions on your key file (required for SSH)
chmod 400 vm1key.pem

# SSH into the VM using your key, username, and public IP
ssh -i vm1key.pem mrjoe@20.99.232.218

🔁 Replace vm1key.pem with your actual key filename and mrjoe@20.99.232.218 with your VM's username and public IP address. You'll find the public IP on your VM's overview page in the portal.

You'll be prompted to confirm the host fingerprint — type yes and hit Enter. If the key file and username are correct, you'll be welcomed right in.

Now update the OS to make sure everything is current:

sudo apt update

sudo apt upgrade -y

Then install Apache2:

sudo apt install apache2 -y

Apache2 starts automatically right after installation. No extra configuration needed. ✅

Step 6: Verify Apache in Your Browser — It Works! 🎉

Open any browser and navigate to your VM's public IP over HTTP:

http://20.99.232.218

If everything went smoothly, you'll be greeted by the Apache2 Ubuntu Default Page — the classic "It works!" screen that confirms your web server is live and publicly accessible.

What We Built

Let's quickly recap what was set up end-to-end:

Component	Purpose
Subscription	Billing and organizational container for all Azure resources
Resource Group	Logical grouping to manage and clean up project resources
Virtual Network + Subnet	Private network environment for the VM to operate in
Virtual Machine (Ubuntu 24.04 LTS)	The compute instance running our workload
Apache2	Web server serving HTTP traffic publicly on Port 80

Key Takeaways

Networking matters first. Setting up your VNet and subnets before the VM ensures your machine is dropped into the right network environment from day one.
Open only the ports you need. Port 22 for SSH and Port 80 for HTTP — nothing more. Security begins at the network layer.
Your .pem file is your key — literally. Azure will not store it for you. Lose it and you lose SSH access. Treat it like a password.
Apache2 just works. For a quick web server deployment on Ubuntu, it's hard to beat — install, done, live.

What's Next?

This is just the foundation. From here, you could:

Point a custom domain at your VM's public IP
Set up HTTPS with Let's Encrypt (free TLS/SSL)
Deploy a full web application instead of the default Apache page
Explore Azure Load Balancers to distribute traffic across multiple VMs
Lock down your VM further with Azure Network Security Groups (NSGs)

The cloud is a lot less intimidating once you've actually deployed something and watched it load in your browser. If you followed along and hit any snags, drop a comment below — happy to help.

Keep building. ☁️

#azure #cloudengineering #devops #linux #apache #virtualmachine #beginners #100daysofcloud

From Classroom to Cloud: Building My First Azure Resource Group ☁️

Amapakabo, Joseph I. — Thu, 19 Mar 2026 15:48:34 +0000

Cloud computing is often talked about in "big picture" terms, but as a student diving into the engineering side of things, I've realized it’s the small, foundational steps that really make the magic happen.

In my latest cloud computing assignment, I took a deep dive into the Microsoft Azure ecosystem. Here is a breakdown of what I’m learning and a step-by-step guide on how I set up my first cloud environment.

📱 The Cloud Apps I Use Daily (SaaS)
Before we look under the hood, it’s important to recognize how much we already rely on the cloud. Apps like Zoom, Google Meet, Facebook, X (Twitter), and YouTube are all perfect examples of Software as a Service (SaaS).

The beauty of SaaS is that I don't have to manage any infrastructure. I don't need to worry about server maintenance or database updates; I just use the service as-is.

🏗️ Thinking Like a Cloud Architect
When we move beyond just "using" apps and start "building" them, we have to think about infrastructure.

Why should a small Fintech startup choose the Cloud?
If a small fintech company asked for my advice, I’d tell them to skip the on-premise servers and go straight to the cloud for three main reasons:

Scalability: They only pay for what they need to launch. As users sign up, they can scale up instantly to maintain performance without having to buy new hardware.

Cost-Effectiveness: Starting on-premise means paying for physical space, security, cooling, and a large IT staff. In the cloud, those initial costs are reduced to nearly zero. You pay for what you use, keeping the budget lean.

Redundancy: In fintech, data loss is a disaster. Cloud providers allow you to deploy across multiple regions. If one data center has an issue, your data is replicated elsewhere, ensuring the service stays up and running no matter what.

🛠️ Tutorial: Creating an Azure Resource Group
In Azure, a Resource Group is a logical container. Think of it as a folder that holds all the related resources for a specific project—like your Virtual Machines, storage, and databases.

Here is the process I followed to get mine up and running:

Step 1: Accessing the Portal
I started by signing up and logging into my Azure Portal.

Step 2: Setting up a Subscription
To build anything, you need a subscription. I searched for "Subscriptions" in the top search bar to load the management page.

Step 3: Adding the Subscription
I clicked the + Add button and filled in the necessary billing and profile details.

Step 4: Finalizing the Plan
After reviewing the details and clicking Next, I hit Create.

Step 5: Verification
I checked my Notifications (the bell icon) to ensure the deployment was successful.

Step 6: Heading to Resource Groups
With the subscription active, it was time to create the container for my projects. I navigated to the Resource Groups section from the sidebar.

Step 7: Starting the Resource Group Process
I clicked Create to launch the setup wizard.

Step 8: Configuring the Group
I named my resource group Assignment-1 and chose the (US) East US region to keep my resources centralized.

Step 9: Success!
A quick check of the notifications confirmed that my Assignment-1 group was successfully created.

Step 10: The Result
Now, I have a clean workspace ready for my Virtual Machines and other cloud resources.

🏁 Conclusion
Getting started with Azure felt a bit intimidating at first, but once you understand the hierarchy (Subscription > Resource Group > Resources), it all starts to click. This is just the beginning of my cloud journey!

Are you just starting out with Azure or AWS? Let's connect in the comments and share tips!

cloudcomputing #azure #microsoftazure #devops #beginners #cloudengineering #fintech

Cloud Computing: The Good, The Bad & What You Actually Need to Know

Amapakabo, Joseph I. — Wed, 18 Mar 2026 08:56:10 +0000

No tech jargon. No confusing buzzwords. Just a plain, honest look at what the cloud actually is — and whether it's right for you.*

Wait, what even is "the cloud"?

You've probably heard someone say, "it's saved in the cloud" and nodded along without really knowing what that means. You're not alone.

💡 Think of it this way: Imagine you live in a rented apartment. You don't own the house, literally — you just meet the landlord or a realtor who takes you to inspect an apartment of your choice, among several fully built apartments, then pay at the end of the month, year as the case might be. Cloud computing works exactly like that, only instead of an apartment, it's computer power, storage, and software delivered to you over the internet.

In layman terms: instead of storing your photos, documents, or running software on your own computer or a hard drive sitting on your desk, those files and programs reside on someone else's powerful computer (called a server) — and you access them via the internet from anywhere.

You know Google Drive, Netflix, Gmail, Dropbox, Facebook or even WhatsApp. Every single one of these runs on the cloud. You use it every day, anywhere and anytime without realising it.

the picture above is what "the cloud" actually looks like behind the hood— massive buildings filled with servers (specially dedicated supercomputers) located in different regions across the globe.*

"The cloud is not some fluffy bubble in the sky. It's an actual physical building full of computers in a warehouse somewhere — and you're renting a tiny piece of it at will."

✅ Some Advantages of Cloud Computing

First, with the good stuff. There are some genuinely great reasons why businesses and everyday people have adopted the cloud the cloud for their daily computing needs.

Work from a coffee shop in Port Harcourt or a beach in the Bahamas— the cloud makes location irrelevant.*

💰 1. You spend less Money

Purchasing physical servers and hardware is a very cost intensive venture. With the cloud, you pay only for what you use — like a pay-as-you-go phone plan. No huge upfront costs. Small businesses especially benefit a lot from this.

🌍 2. Location is Irrelevant

Provided you are connected to the internet, you can easily access your files, tools, and apps from your phone, laptop, or any device, and work on the go — whether you're in Lagos, Lome, or Lekki.

📈 3. Easily Scales to suit your needs

Running a startup or a garage store today? Now growing into a big company? Scale up instantly. You can increase or decrease your usage without buying new hardware. Fun fact... done right, this can be done automatically.

🔄 4. Backups can be Automated

Remember the last time your computer crashed and you lost all your important stuff? Cloud to the rescue. Cloud services automatically back up your data so your files are safe even if your laptop breaks.

🤝 5. Collaborate Easily

Tools like Microsoft 365 lets multiple people connect and work on projects at the same time, from different locations around the world. Guess where these documents are housed, That's the cloud making teamwork seamless.

🔧 6. Less Maintenance for You

The company providing the cloud service handles all the technical upkeep — updates, security patches, hardware repairs. You just use it without worrying about the engine under the hood.

🌟 Real-World Example: When COVID-19 hit and everyone had to work from home, companies already on the cloud barely skipped a beat. Their teams just logged in from home. Companies relying on physical office servers had a much harder time.

❌ The Disadvantages of Cloud Computing

Now for the honest part. The cloud isn't perfect. Here are real problems you should know about before jumping in headfirst.

No internet? No cloud. That's the trade-off you need to think about.

📶 1. You Need Stable Internet

No internet, no access. If your connection is slow or keeps cutting out, working on the cloud becomes a nightmare. This is a real challenge in many parts of Africa where connectivity can be unreliable.

🔐 2. Security & Privacy Worries

When your data lives on someone else's computer, you have to trust them. Data breaches happen, and your sensitive information could be exposed. Not every cloud provider is equally trustworthy.

🏦 3. Costs Can Creep Up

While you save on hardware, monthly subscription fees add up. If you're not careful, you might find yourself paying for storage and services you're not even using.

⚙️ 4. Less Control Over Your Data

Your data is stored in a server you don't own, in a location you may not even know. If the provider changes their terms, gets hacked, or shuts down — your data is at their mercy.

🚫 5. Downtime Can Happen

Even the biggest cloud providers have had outages. When Amazon Web Services went down in 2021, it took Netflix, Disney+, and hundreds of other sites with it. You're dependent on their uptime.

📜 6. Compliance & Legal Issues

Depending on your industry or country, storing sensitive data on overseas servers can create legal complications. Some sectors (like healthcare) have strict rules about where data can live.

🏠 Think of it like renting vs. owning a house: Renting is flexible and cheaper upfront — but you don't control the house. The landlord can raise the rent, change the rules, or sell the property. Cloud computing is essentially renting your tech infrastructure.

📊 Quick Summary Table

Topic	✅ Advantage	❌ Disadvantage
Cost	No expensive hardware upfront	Monthly fees can add up
Access	Work from anywhere	Needs reliable internet
Backups	Automatic data backup	Still depends on provider
Security	Providers invest in security	Trusting a third party
Scalability	Grow or shrink instantly	Over-provisioning wastes money
Maintenance	Provider handles all updates	No control over timing of changes
Collaboration	Real-time team editing	—
Downtime	—	Outages affect your whole operation

🏁 Final Verdict

Should you use the cloud? For most people and most businesses — yes. The benefits outweigh the drawbacks, especially if you're building something modern. But go in with your eyes open. Understand what you're signing up for, pick reputable providers, and always have a backup plan.

The cloud is a tool — a powerful one — not a magic fix for everything.

Did this help you? Drop a comment below 👇 and share it with someone who's been confused about "the cloud." And if you're a developer, check out AWS, Google Cloud, and Microsoft Azure as starting points.