7. Cloud cost and security basics

Cloud providers charge for the resources you use — usually measured per hour, per GB, or per request. This is very different from buying a physical server, where you pay once and own it. On the cloud you rent resources, and the meter is always running.

The main cost categories you will encounter are:

Compute (CPU + RAM)

For a VPS (virtual machine), you pay for the time the server is running — even if no one is visiting your app. A small server might cost $5–$12 per month. If you scale up to a larger machine to handle traffic, the cost goes up accordingly.

Storage

Block storage (the disk attached to your VPS) is charged per GB per month. Object storage (like S3 or AletCloud Bucket) is cheaper per GB but you also pay for every request and for data transfer out of the cloud.

Bandwidth (data transfer)

Many providers charge for outbound traffic — data leaving their data centre toward your users. Inbound traffic (uploads to your server) is usually free. This matters a lot for apps that serve large files like images or videos.

Managed services

Managed databases, email services, and CDNs each have their own pricing model. A managed PostgreSQL database might cost $15–$25 per month for a small instance.

In Ethiopia, AletCloud bills entirely in Ethiopian Birr (ETB), which removes currency risk and makes budgeting predictable — a significant advantage for local businesses and developers.

Uncontrolled cloud spending is one of the most common problems for new cloud users. Here are the key strategies to estimate and control your costs.

Use the pricing calculator

Before you create any resource, use the provider's pricing calculator to estimate the monthly cost. Enter your expected CPU, RAM, storage, and bandwidth, and it will show you the projected bill. This only takes a few minutes and prevents surprises.

Set billing alerts

Almost every cloud provider lets you set a spending threshold. If your bill is heading toward a limit you set (for example 500 ETB), the system sends you an email or SMS warning. Configure this on day one — it is free and can save you from a large unexpected charge.

Right-size your resources

Start with the smallest plan that meets your needs. You can always scale up later when you have real traffic data. Starting with an over-powered server is a common and expensive mistake for beginners.

Shut down what you are not using

Test environments, development VMs, and staging servers should be stopped or deleted when you are not using them. A development server running 24/7 for a month can cost as much as a production server — even though it only handles occasional test traffic.

Understand free tiers

Many providers offer a free tier: a small amount of compute, storage, or requests every month at no charge. AletCloud, AWS, Google Cloud, and others all have free tiers. Read the limits carefully — when you exceed the free tier, charges begin immediately.

Monitor your bandwidth

If your app serves many images or large files, bandwidth can become your biggest cost. Use a CDN (Content Delivery Network) to cache content at edge locations close to your users — this reduces the amount of data that travels from your origin server, cutting both cost and latency.

Security in the cloud operates under what is called the shared responsibility model. The cloud provider is responsible for securing the underlying infrastructure — the physical data centres, the hypervisors, and the network hardware. You are responsible for securing everything you build on top of that infrastructure.

In practice this means:

The provider secures: physical buildings, hardware, power, cooling, and the virtualisation layer.

You secure: the operating system on your VPS, the software you install, your application code, the data you store, user accounts and passwords, API keys, and access control rules.

A common mistake is thinking 'the cloud is secure, so my app is safe.' The cloud infrastructure may be secure, but if your database is wide open to the internet with no password, or if your server has not had a security update in six months, attackers will find and exploit it.

Think of it like renting a shop space in a modern mall in Addis Ababa. The mall (the provider) secures the building, installs CCTV, and controls who enters through the main gate. But it is your job to install a strong lock on your shop door, secure your cash register, and train your staff not to share keys with strangers.

You do not need to be a security expert to protect a small cloud application. Applying these five practices covers the vast majority of common attack scenarios.

1. Use strong, unique passwords and SSH keys

Never use the default password on a VPS. Use an SSH key pair instead of password authentication for server login — it is far harder to attack. A 2048-bit or 4096-bit RSA key is unbreakable with current technology. Sara generated an SSH key on her laptop and added the public key to her server; now only her machine can log in.

2. Keep your software updated

The majority of successful attacks exploit known vulnerabilities — security flaws that the software vendor has already published a fix for. Run sudo apt update && sudo apt upgrade on your VPS regularly (at least monthly), and enable automatic security updates. On managed PaaS platforms, the provider handles OS and runtime patching for you.

3. Close unused network ports

A firewall controls which network ports accept connections. By default, close everything and only open the ports your app actually needs:

• Port 22 — SSH (server administration; restrict to your own IP if possible)

• Port 80 — HTTP (unencrypted web traffic; redirect to HTTPS)

• Port 443 — HTTPS (encrypted web traffic)

All other ports should be blocked by your firewall. Most cloud dashboards have a simple firewall or security group panel where you can set these rules in minutes.

4. Encrypt data in transit and at rest

All web traffic between your users and your server must go over HTTPS (TLS). Never serve your app over plain HTTP in production — passwords and personal data can be intercepted on unsecured networks like public Wi-Fi at Bole Airport. For stored data, enable disk encryption on your VPS if your provider supports it, and use encrypted database connections.

5. Apply the principle of least privilege

Every user account, API key, and service should have only the minimum permissions needed to do its job — nothing more. If Almaz's app only needs to read from a database, its database user should have SELECT permission only, not DROP or DELETE. If an attacker compromises that account, the damage is limited.