Cloud Compute and Networking
Design virtual networks, subnets, security groups, load balancing, and scaling in a cloud environment.
- Certification
- CompTIA Cloud+
- Recommended study time
- 6h 35m
- Status
- Not started
Recommended study time
About 6h 35m in total, measured from the material on this page. At your session length of 45 minutes that is 9 sittings.
- Read the lesson24 min
About 3,141 words at a careful technical reading pace.
- Second pass with notes14 min
Re-read the harder parts and write your own notes.
- Recall from memory12 min
2 written recall questions.
- Practice decision12 min
One applied decision with feedback.
- Teach it back20 min
Write the topic in your own words.
- Real-world scenario15 min
Read the situation and justify your decision in writing.
- Hands-on practice3h 20m
Labs, commands and configuration until you can do it unaided.
- Spaced review1h 40m
4 short review sessions spread over the following weeks.
Learning objectives
- Design a virtual network with public and private subnets and controlled egress.
- Apply security groups and network ACLs following least privilege.
- Explain load balancing, auto scaling, and health check behaviour.
Start here
About 8 minutes of reading, in 10 short parts.
In the cloud, an entire network — addresses, subnets, firewalls, load balancers — is built with configuration instead of physical cables and switches. Designing it well means thinking about address space and access control deliberately, because a mistake here is invisible until traffic actually tries to flow through it.
Where you meet it: A newly deployed web application cannot be reached from the internet even though the server itself is running perfectly.
The lesson, part by part
Open one part at a time. Each part stands on its own, so you can stop and come back.
Building a network in the cloud is like designing the layout of a new office building entirely on paper before any walls exist. You decide how many floors there are and roughly how many rooms fit on each floor before deciding who goes where; that is your address space and subnets. Then you decide which doors are locked to whom — which rooms the public can walk into, which are staff-only, which require special clearance; that is your security groups and firewall rules.
Load balancing is like having a receptionist at the main entrance who directs each visitor to whichever available staff member can help them, rather than everyone trying to squeeze through one specific person's office door. And scaling is deciding that on a very busy day, more receptionists and more staff automatically come on shift, and on a quiet day, they go back to a smaller normal number, so you are not paying for a full building's staff around the clock when most of the time you do not need them.
Key ideas
If you remember nothing else from this topic, remember these.
- Cloud compute instances are provisioned from machine images and sized by virtual CPU, memory, and sometimes GPU allocation, chosen to match workload requirements rather than defaulting to the largest option.
- Auto-scaling adjusts the number of running instances based on demand, which requires the application to be designed statelessly or with shared state so any instance can serve any request.
- Virtual private clouds let a customer define isolated network address space, subnets, and routing within a provider's infrastructure, mirroring traditional network design in a virtualized form.
- Security groups and network access control lists both filter traffic but differ in scope: security groups are typically stateful and apply per instance, while network ACLs are stateless and apply per subnet.
- Load balancers distribute traffic across multiple instances for both performance and availability, and health checks determine whether an instance should keep receiving traffic.
- Cloud networking still relies on the same fundamentals as physical networking: subnetting, routing tables, and firewall rules, just expressed through a provider's console or API instead of physical switches.
Scaling a web application that failed under a traffic spike
A worked example, step by step.
A web application running on a single cloud compute instance became unresponsive during a marketing campaign traffic spike, and the fix must prevent recurrence.
- 01Review the incidentMonitoring shows CPU utilization on the single instance hit 100 percent and stayed there for the duration of the spike, with no other instance to absorb load.
- 02Design a scalable architectureA load balancer is placed in front of the application tier, and the application is confirmed to be stateless, storing session data in a shared cache rather than locally.
- 03Create an instance templateA machine image is built containing the application and its dependencies, so new instances can launch already configured and ready to serve traffic.
- 04Configure auto-scalingAn auto-scaling group is set to launch additional instances from the template when average CPU exceeds 60 percent, and to remove instances when demand drops.
- 05Configure health checksThe load balancer is set to poll a health endpoint on each instance and stop routing traffic to any instance that fails to respond correctly.
- 06Define network boundariesThe instances are placed in a private subnet with no direct public IP, reachable only through the load balancer, which sits in a public subnet.
- 07Restrict traffic with a security groupA security group on the application instances allows inbound traffic only from the load balancer's security group on the application port, blocking direct external access.
- 08OutcomeA simulated repeat of the traffic spike triggers auto-scaling within minutes, and the load balancer distributes requests across the new instances without any downtime.
Outcome: Moving from a single instance to a load-balanced, auto-scaling, network-segmented design eliminated the single point of failure that caused the original outage.
Cloud compute and networking reference
Worth keeping at hand while you work.
- Machine image
- A preconfigured template used to launch new compute instances consistently.
- Auto-scaling group
- A set of instances that automatically grows or shrinks based on defined demand metrics.
- Load balancer
- Distributes incoming traffic across multiple instances and can remove unhealthy ones from rotation.
- Health check
- A periodic test used to determine whether an instance should continue receiving traffic.
- Virtual private cloud (VPC)
- An isolated, customer-defined network space within a cloud provider's infrastructure.
- Subnet
- A segmented portion of a VPC's address space, typically designated public or private.
- Security group
- Stateful, instance-level traffic filtering; return traffic is automatically allowed.
- Network ACL
- Stateless, subnet-level traffic filtering; both inbound and outbound rules must be explicitly defined.
- Elastic/public IP
- A static public address that can be attached to an instance for direct external reachability.
- Private subnet
- A subnet with no direct route to the internet, typically reached only through a load balancer or NAT gateway.
- NAT gateway
- Allows instances in a private subnet to initiate outbound internet traffic without being directly reachable from outside.
- Route table
- Defines how traffic is directed between subnets, gateways, and the internet within a VPC.
Common misunderstandings
What most beginners get wrong here.
Auto-scaling alone solves a performance problem regardless of application design.
Auto-scaling requires the application to handle state in a shared way, since any new instance may serve any request, and a stateful application will break under scaling.
Security groups and network ACLs are interchangeable ways to do the same thing.
Security groups are stateful and apply at the instance level, while network ACLs are stateless and apply at the subnet level, requiring explicit rules in both directions.
Putting an instance in a private subnet makes it completely unreachable from the internet in every case.
A private subnet has no direct route to the internet, but instances can still be reached indirectly through a load balancer or allowed to initiate outbound traffic through a NAT gateway.
A single large instance is always a better choice than several smaller ones behind a load balancer.
A single instance is a single point of failure and cannot scale horizontally, while multiple smaller instances behind a load balancer provide both redundancy and elastic capacity.
Health checks are only useful for reporting status, not for actually changing traffic routing.
A failed health check actively removes an instance from the load balancer's rotation until it passes again, directly affecting where traffic goes.
Exam traps
How the question writers try to catch you out.
- Questions about traffic filtering scope expect you to distinguish stateful, instance-level security groups from stateless, subnet-level network ACLs.
- A scenario describing an application that breaks when scaled to multiple instances is testing recognition of a stateful design flaw, not an auto-scaling misconfiguration.
- Public versus private subnet questions expect knowledge that a private subnet still reaches the internet outbound only through a NAT gateway.
- Load balancer health check questions test that failing instances are actively removed from rotation, not merely flagged.
- VPC and subnet design questions often test that route tables, not just firewall rules, determine actual reachability between resources.
Check yourself
Answer in your head first, then reveal. This is not scored.
Why can auto-scaling make a stateful application worse instead of better?
What is the key difference between a security group and a network ACL?
How can an instance in a private subnet reach the internet for outbound updates?
What happens when an instance fails a load balancer health check?
Why is a single large compute instance considered a risky design for a production web application?
Quick reference
A condensed summary of the lesson above, for revision.
What It Is
A virtual network defines an address range divided into subnets, each associated with a route table. Public subnets route to an internet gateway; private subnets reach the internet through NAT or not at all. Security groups filter statefully per resource, while network ACLs filter statelessly per subnet. Load balancers distribute traffic across healthy targets, and auto scaling adjusts capacity to demand.
Why It Matters
Most cloud outages and exposures trace to routing, security group, or health check configuration. Understanding these objects lets you build environments that are both reachable and defensible.
How It Works
- Route tables determine which subnets can reach the internet and by what path.
- Security groups evaluate allow rules statefully; ACLs apply stateless allow and deny per subnet.
- Load balancers poll health checks and route only to passing targets.
Where You See It
- Cloud application platforms, hybrid connectivity, landing zone design, and migration architecture.
Key Terms
- VPC/VNet
- The isolated virtual network in which resources are placed.
- Security group
- A stateful per-resource firewall.
- NAT gateway
- Allows private subnet egress without inbound exposure.
- Health check
- Test determining whether a target receives traffic.
- Auto scaling group
- A managed set of instances scaled by policy.
Examples
- Databases belong in private subnets reachable only from application security groups.
- A failing health check removes an instance from the load balancer without deleting it.
Common Problems
- Overly open security groups
- Missing NAT for private egress
- Health checks too aggressive or too lenient
- Overlapping ranges with on-premises networks
How It Fails
- Instances flap in and out of service when health checks are stricter than startup time allows.
- A management port open to the internet is discovered and attacked within minutes.
- Overlapping CIDR ranges block hybrid connectivity entirely.
How to Troubleshoot
- Trace the path: route table, security group, ACL, then the application itself.
- Compare a working and failing resource's effective rules rather than reading intent.
- Check health check target, path, and timeout against real application behaviour.
Practical Knowledge
- Plan cloud address space against on-premises ranges before deploying anything.
- Reference security groups by group rather than by IP where the platform supports it.
Exam Coverage
- Virtual networking and subnets
- Cloud firewalling and access control
- Load balancing, scaling, and availability
Interview Questions
- Why do private subnets need a NAT gateway?
- How would you troubleshoot an instance that is healthy but receiving no traffic?
Watch and read
Verified official and reputable sources for this topic. Links open in a new tab.
Video training
Professor Messer video channel — general CompTIA training (no dedicated CompTIA Cloud+ course)
Professor Messer
WatchVideoFree
Lesson notes and bookmark
Notes and bookmarks for this lesson, saved with everything else you have marked.
No notes on this item yet.
Learning progress
0% across six evidence areas. Reading alone does not change progress.
Prerequisites
Next steps
- 01Draw a two-tier VPC design with public and private subnets across two zones.
- 02Write the minimum security group rules for a web and database tier.