Choosing Cloud Instance Types

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 family is a shape, not a trophy

An instance type is a bundle of processor, memory, and sometimes a disk or a GPU. The family selector helps you name the shape: general, compute-heavy, memory-heavy, or a specialised shape you can justify. The comparison tool lines up types you type. Neither tool launches a machine.

Start from the job. A small web lab is not a memory-heavy shape because the menu looked impressive. A database lab that the database guide already sized may be memory-heavy. This page does not invent that size. It records the family and the smallest type you will try.

Architecture is part of the choice. If you need a specific processor family, write it. If the image you have only exists for one architecture, that constraint wins. Do not discover it after the machine is up.

Burstable types spend credits. That is fine for a lab that is quiet most of the day. It is a bad surprise for a job that runs hot all afternoon. Write whether credits are acceptable. If you do not know, you are not ready for a burstable type in production.

One job, one family, one lab type

Write the job in one sentence: what the machine will do for one hour. Use the family selector with that sentence in mind. Record the family and the reason. A reason of 'it was the default' is a reason to look again.

Compare two types in the same family, a smaller one and the one you were tempted by. Keep the smaller one for the lab. The cost guide owns the estimate. You do not launch both.

Write the image constraint and the region. A type that does not exist in the region you named is not a choice. The networking guide owns the address. This page stops when the type name is written.

If the job needs a GPU, stop and use the AI infrastructure guide. A GPU is a cost and a data decision, not a checkbox on a general-purpose type.

# Instance note. Nothing here launches a machine.
# One job. One family. One lab type.
# Burstable credits are a written yes or no.
# A GPU belongs to the AI guide.
# The cost guide prices the type. This page only names it.

A change you can finish

This window writes the type. Launching it is the provider guide's lab, after the network and the cost note exist.

Rollback is choosing the other type you compared, before anything is launched. After launch, a resize is a new window.

Write the job in one sentence.
Choose a family and write the reason.
Compare a small type and the tempting type.
Keep the small type for the lab.
Write the architecture and the region.
Write whether burstable credits are acceptable.
Hand the launch to the provider guide.

Mistakes that outlive the command

instance selection 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.

Picking the largest type because it is first.
A GPU hidden inside a general choice.
Ignoring the image architecture.
A burstable type for a job that never idles, with no note.
Launching during the selection hour.
Two families for one undecided job.
A type from a region you do not use.
Skipping the cost estimate.
Resizing a live machine to 'try' the other type.
No sentence for why this family.

Decisions to write down before the window

One decision for instance selection: The job sentence is in the ticket. The family has a reason. The lab type is the smaller one. Architecture matches the image. The region has that type. Credits are accepted or refused in writing. A GPU was handed to the AI guide, or it is not needed. Nothing was launched in this window. The cost guide has the type name, or it is the next ticket. The network guide owns the address. A second person can say the job. And one type is enough.

The hour you stop

Write the account, the project or subscription, the region, and the clock time before you change anything for instance selection. 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. instance selection 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.

Instance checks before a launch ticket

Confirm this before you call the change done: The type name is written. The family reason is a sentence. The region is named. The image architecture is named. The lab size is the smaller comparison. Credits are a yes or a no. No machine was started. The cost note can use this type name. A GPU is not implied. The provider guide is the next page. The account is a lab account. The note does not contain a key. The hostname in the prompt matches the hostname in the ticket for instance selection. 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 instance selection 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.