Cloud computing for network engineers: characteristics, service and deployment models, and connectivity
In short: Cloud computing means renting computing resources on demand over a network, paying for what you use. NIST defines five essential characteristics, three service models (IaaS, PaaS, SaaS) and four deployment models (public, private, community, hybrid). For network engineers the cloud adds virtual networks to design, new ways to connect sites, and a shared responsibility for security.
What makes something "cloud"
Many things are called cloud, but the widely used definition from the US National Institute of Standards and Technology (NIST SP 800-145) lists five essential characteristics:
- On-demand self-service: you create a server or network yourself through a portal or API, without raising a ticket with the provider.
- Broad network access: services are reached over the network from many kinds of device.
- Resource pooling: the provider shares large pools of hardware between many customers.
- Rapid elasticity: capacity grows and shrinks quickly, sometimes automatically.
- Measured service: use is metered and billed, like electricity.
A server room full of virtual machines is not a cloud just because it is virtualised; without self-service, elasticity and metering it is simply a virtualised data centre. For a beginner overview see What is cloud computing?.
Service models: how much you manage
- Infrastructure as a Service (IaaS): you rent virtual machines, storage and virtual networks. You design subnets, route tables, security groups and gateways yourself, so IaaS is where most network work happens.
- Platform as a Service (PaaS): the provider runs the operating system and runtime; you deploy code or databases. You still decide how the platform is reached: public endpoint or private connection.
- Software as a Service (SaaS): complete applications such as email or collaboration suites. Your job becomes making sure users reach them quickly and securely.
Whatever the model, security is shared. The provider secures the physical data centres and the platform; you always remain responsible for your data, identities and access settings.
Deployment models: who shares it
| Model | Who uses it | Network angle |
|---|---|---|
| Public | Many unrelated customers on a provider's platform | Reached over the internet or private interconnects |
| Private | One organisation, on its own or hosted hardware | Part of your own data centre network |
| Community | Organisations with shared needs, such as government bodies | Shared rules and connectivity between members |
| Hybrid | A mix of the above, connected and managed together | Needs reliable links, consistent addressing and policy |
Many organisations also use several public providers at once, which is called multi-cloud. The models are covered in more depth in Cloud deployment models.
What changes for the network engineer
- Virtual networks: providers give you a virtual private cloud (VPC) or virtual network with subnets and route tables. Plan the address ranges so they never overlap with offices or other clouds; overlaps are painful to fix later.
- Connectivity: options range from the public internet, through IPsec VPNs, to dedicated private circuits sold under names such as AWS Direct Connect, Azure ExpressRoute and Google Cloud Interconnect.
- Traffic patterns: when applications move to SaaS, sending all user traffic back through head office adds delay. Local internet breakout with SD-WAN or SASE often works better.
- Cost: data leaving a cloud (egress) is usually charged, so the design of where traffic flows has a direct cost.
- Automation: cloud networks are created through APIs, so tools such as Terraform become part of the network toolkit.
Real-world example: a college moves its student system
A fictional further-education college moved its student records system from an ageing on-site server to IaaS virtual machines in a public cloud, while email moved to a SaaS suite. The network team planned a 10.200.0.0/16 range for the cloud network that did not clash with campus subnets, built two IPsec tunnels from the campus firewalls to the provider's VPN gateway, and used BGP over the tunnels so traffic failed over automatically. Users reached the SaaS email directly through the campus internet link rather than through the tunnels. After the first term, monitoring showed the tunnels were busy enough at enrolment time that the college budgeted for a private interconnect the following year.
Practice
Which NIST characteristic is missing from a virtualised server room where staff must raise a ticket for each new VM?
In which service model does the customer design subnets, route tables and security groups?
Why must cloud address ranges be planned alongside office ranges?
Key takeaways
- NIST lists five characteristics: self-service, network access, pooling, elasticity, metering.
- Service models: IaaS, PaaS and SaaS shift more responsibility to the provider as you go up.
- Deployment models: public, private, community and hybrid; multi-cloud uses several providers.
- Network work in the cloud: virtual networks, non-overlapping addressing and connectivity choices.
- Security is always shared; you own your data, identities and access settings.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.