Planning compute instances on NNumbers Cloud
Consider the following when planning a cloud computing instance deployment:
-
Creating a private network (VPC). See: Networks.
-
Creating a router from the public network to the private network. See: Routers.
-
If you need to keep a public IP (for DNS records, load balancing, horizontal scaling, failover, or switchover), you need to reserve floating IP(s). See: Floating IPs.
-
To connect a network inside a project to the company's internal network or another network outside the project — and for better internal management of instances without exposing services such as SSH directly on public networks — you can create a virtual private network through the VPN service. See: Site-to-site VPN.
-
To expose the services you need, create security groups with rules matching each service type. Every rule has a source in CIDR notation, and getting that source wrong is the most expensive mistake at this stage — see Rule sources: what CIDR means, below. See also: Security groups.
-
To build load balancing with stronger availability guarantees, create server groups. Server groups define affinity and anti-affinity rules. See: Load balancers.
-
For load balancing and better use of the public IPs you reserved, there is a Load Balancer service that distributes load across the instances you choose. See: Load balancers.
-
Optionally, you can make changes to the default image at boot through cloud-init — changing the default user name, updating and installing packages when the instance starts, and so on.
Rule sources: what CIDR means
Every security group rule has a source written in CIDR notation — an address followed by a slash and a number. That number is how many bits of the address are fixed, and it decides how many addresses the rule allows.
| Notation | How many IPv4 addresses | Meaning |
|---|---|---|
203.0.113.45/32 | 1 | Exactly that address |
203.0.113.0/24 | 256 | That range |
10.0.0.0/8 | 16,777,216 | The whole private 10.x.x.x range |
0.0.0.0/0 | all | Any address on the internet |
0.0.0.0/32 does not mean "any network". It is a single-address CIDR — and the address 0.0.0.0 belongs to no machine, so the rule allows nobody.
"Any network" is 0.0.0.0/0. In IPv6, the equivalent is ::/0.
SSH (port 22) must never be opened to 0.0.0.0/0
A port 22 open to the whole internet starts receiving automated authentication attempts within minutes. Prefer, in this order:
- Your public address as
/32— for one-off administrative access. - Site-to-site VPN — access over the company network, without exposing the port. See Site-to-site VPN.
- Bastion (jump host) — a single exposed instance, with the rest reachable only through it. See SSH access.
- Source security group — allow by security group rather than by address when the source is another instance in the same project.
Side by side
| Intent | Unsafe | Safe |
|---|---|---|
| Administer over SSH | TCP 22 from 0.0.0.0/0 | TCP 22 from 203.0.113.45/32 |
| Publish a website | — | TCP 443 from 0.0.0.0/0 (this is the intent) |
| Database reachable by the application | TCP 5432 from 0.0.0.0/0 | TCP 5432 from the application's security group |
| Diagnostics with ping | ICMP from 0.0.0.0/0 | ICMP from your administration range |
Public HTTP and HTTPS can use 0.0.0.0/0: that is exactly what a public site wants. The difference is that there the exposure is the intent, whereas with SSH it is an accident.
Finding your public address
Use a service you already trust and that states what it does. Two examples run by well-known providers:
curl https://checkip.amazonaws.com
curl https://api.ipify.org
If your company has a fixed internet egress, ask the network team for the range rather than looking up your own computer's address — a home address usually changes.
Inbound and outbound are different rules
- Inbound (ingress) — who can open a connection to the instance. This is where exposure risk lives.
- Outbound (egress) — where the instance can open connections to. The default is usually open; restricting it limits the damage a compromised instance can do.
Verifying the rule works
After creating the rule, confirm it from outside the instance:
# Should connect from the address you allowed
ssh user@203.0.113.10
# Should fail with a timeout from any other address
nc -vz -w 5 203.0.113.10 22
A Connection timed out from an address you did not allow is the expected result — it is the proof that the rule is restricting.
Revoking after use
A one-off access rule needs an end date. When the maintenance is done, remove the rule in the console (Network → Security Groups → Manage Rules → delete) and confirm access no longer works. A forgotten /32 rule becomes an open door for an address that, months later, may belong to someone else.
To reach Linux compute instance(s) on NNumbers Cloud you need:
-
To create a key pair for SSH access, or import an existing key. The key(s) you create or import are used when creating the instance(s).
-
Or to create a user and password at instance creation time through a cloud-init script (YAML format).
Next steps
Was this page helpful?
Report a problem on this pageDo not send passwords, keys, tokens, or customer data.