Learn Cloud Computing - Prerequisite Skills & Environment Setup

#Introduction

Welcome to the Learn Cloud Computing series! Over the next 21 episodes, you'll build an understanding of cloud computing from scratch: starting from why the cloud was born, all the way to production-grade architectures across the three largest cloud providers — AWS, GCP, and Azure — complete with networking, compute, storage, security, and FinOps.

Cloud computing isn't just "servers on the internet." The cloud is an operational model that changes how teams manage infrastructure: from buying hardware to renting compute power on demand, with managed security and reliability. But before you can build anything in the cloud, two things need to be in place first: skills and environment. Episode 0 is dedicated to preparing both.

#Prerequisite Skills: Basic Networking

The cloud is built on networking. Every cloud service — whether a virtual machine, database, or API — is ultimately a network service communicating over protocols. Without an understanding of networking, cloud errors will feel like guessing riddles.

#IP Addresses and Subnets

Every cloud resource has an address. An IP address (for example 203.0.113.10) identifies a machine on a network. A subnet divides a large network into smaller parts — by analogy, the IP is the house number and the subnet is the neighborhood boundary. When we discuss VPC later, you'll divide cloud networks into public and private subnets.

#Ports, DNS, and Routing

• Ports — the communication gateways on a machine. HTTP on port 80, HTTPS on 443, SSH on 22. Cloud firewalls decide which ports can be accessed from the internet.
• DNS — the internet's phone book that maps domain names like google.com to IP addresses.
• Routing — how data packets choose a path from one network to another.

Try it out directly from your terminal:

ip addr show
ping -c 4 1.1.1.1
dig +short google.com

• ip addr show — displays your IP addresses and network interfaces.
• ping — tests whether a host is reachable from your network.
• dig — performs a DNS query to find out a domain's IP.

#Linux CLI

Nearly all cloud workloads run on Linux — from ordinary web servers to Kubernetes. The main reason isn't a matter of taste: Linux is free, stable, modular, and fully supported by every cloud provider. That's why being comfortable in the Linux terminal is a non-negotiable skill.

At minimum, master the following core commands:

Core Linux commands

pwd
ls -la
cd /etc
cat /etc/os-release
grep -r "cloud" /etc

• pwd — displays the current directory.
• ls -la — lists directory contents in full, including hidden files.
• cd — changes directories.
• cat — displays file contents.
• grep — searches for patterns inside files or output.

Use --help or man to understand command options: ls --help. Every demo in this series uses the CLI, so get used to it from the start.

#Client-Server Architecture

The entire cloud computing ecosystem stands on one classic pattern: client-server. The client sends a request, the server processes it and responds. When you open the AWS dashboard, your browser is a client talking to AWS's API servers.

In the cloud, nearly all of your interactions are API calls — even when you use the dashboard, there's still an API behind it. The consequence: if you understand HTTP request formats (method, URL, header, body) and response status codes (200 OK, 403 Forbidden, 500 Internal Server Error), you already understand most of how the cloud works.

curl -I https://aws.amazon.com

The command curl -I https://aws.amazon.com sends an HTTP request and displays the response headers — tangible proof that every internet service is a client-server transaction.

#Cloud Accounts and Free Tier

Every cloud provider offers a free way in. Use the following three accounts to practice — they all provide a free tier to get started.

Think of a cloud account like renting an apartment with a security deposit: the credit card is the deposit, but as long as you use free services and stay within the limits, no charges are billed.

#Unified CLI: aws-cli, gcloud-cli, az-cli

The web dashboard is convenient, but you can't automate a dashboard. CLI (Command Line Interface) is the key to working reproducibly: the same configuration, run at any time, produces the same environment. This is the foundation of the Infrastructure as Code we'll cover much later.

Each provider has an official CLI. Install all three:

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /usr/share/keyrings/cloud.google.gpg
echo "deb [signed-by=/usr/share/keyrings/cloud.google.gpg] https://packages.cloud.google.com/apt cloud-sdk main" | sudo tee -a /etc/apt/sources.list.d/google-cloud-sdk.list
sudo apt-get update
sudo apt-get install -y google-cloud-cli
gcloud init

curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
az login

Once installed, verify everything:

aws --version
gcloud --version
az version

An aws-cli/2.x.x output from aws --version means the CLI is ready to use. gcloud init walks you through creating your first project, and az login opens a browser for Azure authentication.

#Configuring Credentials: aws configure

Every CLI command needs to know who you are (identity) and which account to use. The easiest way on AWS is aws configure, which stores credentials in ~/.aws/credentials:

aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: ap-southeast-1
Default output format [None]: json

Replace the values above with the access key and secret key you create from the IAM console. Region ap-southeast-1 (Singapore) is chosen because its latency is closest to Indonesia.

For GCP, additional authentication is done with gcloud auth application-default login, which creates credentials for the applications you write. On AWS, besides aws configure, make sure credentials are never shared to public repositories.

#Local Testing: LocalStack & Emulators

Practicing directly on a real cloud account is risky: a misconfiguration means unexpected bills, and forgotten resources can accumulate costs. The industry-standard solution: local emulation.

• LocalStack — an AWS API emulator that runs in Docker, supporting S3, Lambda, DynamoDB, SQS, and many more.
• GCP Emulators — gcloud beta emulators for Pub/Sub, Datastore, and Firestore.
• Azurite — a local storage emulator for Azure (Blob, Queue, Table).

docker run --rm -p 4566:4566 localstack/localstack

Code written against the AWS API can be run against LocalStack without significant modification — just point the endpoint to http://localhost:4566. This pattern is covered in depth in the LocalStack series, but it's important to know that learning the cloud doesn't always have to touch a real cloud.

#Conclusion

Episode 0 is the gateway to this series. Here's what you must take away:

• Master networking basics: IP, subnet, ports, DNS, and routing.
• Be fluent in core Linux commands and comfortable in the terminal.
• Understand the client-server pattern as the foundation of all cloud APIs.
• Create an AWS Free Tier, GCP Free Tier, and Azure Free Account.
• Install and configure aws, gcloud, and az; enable MFA.
• Know LocalStack and local emulators for practicing without cost.

In episode 1, we answer the most fundamental questions: how cloud computing was born, how it evolved from on-premise to the commercialization of AWS, GCP, and Azure, and what NIST's official definition of the cloud is. Welcome to the world of the cloud!