Cloud Networking Guide

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

A network is a boundary you can draw

Cloud networking here means one network you can name, a prefix you meant, and a path in that you can point at. The CIDR planner helps you sketch a prefix. The load balancer selector helps you choose a type. Neither tool creates a network in an account.

Use 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, or 2001:db8::/32 only in the note. A real prefix comes from the network desk. Do not type a documentation range into a production network because it appeared in this guide.

A route to the internet, a private network, and a connection back to a site you run are three designs. Pick one for the lab. The first hour does not peer you to a network you do not administer.

A load balancer is a later choice. Layer 4 and layer 7 answer different questions. Write which question you have. Do not create both to see which one gets traffic.

One prefix in the note, one source you can name

Sketch a lab prefix with the planner. Write it as documentation, then write the real prefix beside it if the network desk has already assigned one. If they have not, the lab stays on a prefix you reserved for labs, still not a documentation range pasted into the console.

Write the inbound rule you actually need. The source is a named prefix for the admins, or the load balancer's own range, not the whole internet. If a generator emits 0.0.0.0/0, delete that line before anyone applies it. Management access from the world is the mistake this page is here to prevent.

Choose a load balancer type only if the ticket already has a listener you can describe. Record the type and the port. Health checks are part of that sentence. A balancer with no healthy target is a name, not a service.

The identity guide owns who may change this network. A wide network permission is not a substitute for a drawing. The provider guide owns the commands that create the lab, after this drawing exists.

# Network note. Documentation ranges stay in the note.
# 192.0.2.0/24 is not a production prefix.
# example.com is not your zone.
# Delete any 0.0.0.0/0 rule before you apply a draft.
# One network. One inbound source you can name.

A change you can finish

This window produces the drawing. Creating the network is the provider lab, one network only.

Rollback is the previous route table or the lab network you can delete because nothing else uses it. Do not delete a shared network to undo a test.

Name the lab network and the region.
Sketch the prefix and mark documentation ranges as notes only.
Write the real prefix from the network desk, or stop until you have one.
Write one inbound rule with a named source.
Strike any 0.0.0.0/0 line.
Choose a load balancer type only if you can name the listener.
Hand creation to the provider guide.

Mistakes that outlive the command

cloud networking fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

Typing 192.0.2.0/24 into a production network.
Keeping 0.0.0.0/0 because the draft included it.
Opening management ports to the internet.
Peering to an account you do not administer.
Two load balancer types in one hour.
A balancer with no health check you can explain.
Changing a shared route table as a lab.
A security rule and a new subnet in one window.
Skipping the identity of who may edit the network.
Scanning addresses to see what answers.

Decisions to write down before the window

One decision for cloud networking: The network name and region are in the ticket. Documentation ranges were not applied. The real prefix is assigned, or the launch waits. The inbound source is a name you can say. 0.0.0.0/0 is not in the draft you will keep. Management access is not worldwide. One load balancer type, or none yet. No peering leaves the account you administer. The drawing exists before any create command. Identity owns who may change it. A second person can draw the path. And one network is this window.

The hour you stop

Write the account, the project or subscription, the region, and the clock time before you change anything for cloud networking. If this account is serving people and you do not have a way back, this hour is a plan. A plan you can read tomorrow is a success. A change you cannot undo is not.

Use a lab account, a lab project, or a lab subscription you administer. You do not point a CLI, a pipeline, or a browser tool at an account you do not run. The tools on this site run in the browser. They draft text. They do not log in, and they do not scan.

prompt-for-this is a reminder that a secret is missing. It is not an access key, a token, a password, or a kubeconfig you save. The real secret stays in the password store or the platform's secret store. If a file, a log, a ticket, or a pipeline still contains a live secret, stop and rotate it. Then delete the copy.

One change. A network, a virtual machine, a policy, and a pipeline do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous file, the previous plan, or the resource you can delete because it was only a lab.

A second person reads the scope aloud: which account, which region, which name. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.

Documentation addresses stay in the note. 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, and 2001:db8::/32 are not prefixes you type into a production network. example.com is not your zone. A generated file that opens 0.0.0.0/0 is a file you edit before it is applied. A source you can name is the rule you keep.

Do not apply a draft you have not read. A cost estimate, a policy, a manifest, and a Terraform plan are reading material. Apply, a resize of a live machine, and a delete of a bucket are later decisions with their own proof. Read the names. Then decide.

Keep the previous file. A generator draft is not the previous file. The previous file is what you put back if the new one is wrong. You practised the path back, including the serial console or a second admin, before you changed a network or a lockout setting.

If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied stack produces an account nobody can explain. Rebuild the lab from the copy you kept.

When the checks pass, the next account waits until someone else can repeat the proof from the notes. cloud networking is done for this window when the proof is written, not when a CLI printed a success line.

This page is a planning guide. It is not a vendor manual, not an official standard, not legal advice, and not an audit opinion. If an auditor must see the decision, they see the ticket and the evidence, not this paragraph.

Hand the finished note to the neighbouring guide that owns the next step, and leave this account alone until that guide has its own window.

Network checks before a create command

Confirm this before you call the change done: The prefix in the draft is the assigned prefix. A documentation range is labelled as a note. The inbound source is named. No 0.0.0.0/0 line remains. The region matches the instance note. The load balancer choice is one sentence or is absent. Nothing was created in this window. You did not scan a range. The account is yours to administer. A second admin path exists before you change a live route. The provider guide is next. The ticket has no secret. The hostname in the prompt matches the hostname in the ticket for cloud networking. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for cloud networking happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.

Companion: Network: Subnetting Explained Step by Step.