Every cloud application depends on connectivity.
Applications need to reach databases, users need to reach applications, workloads need to communicate with other services, and cloud environments may need to connect with enterprise data centers or other clouds.
The easiest way to understand cloud networking is to start with the complete traffic journey.
From Identity to Connectivity
In Identity and Access Management Across Multi-Cloud, MyRetail established who—or what—is allowed to act within its cloud environments.
Networking introduces the next foundational question:
How do those resources communicate?
A workload may have the correct identity and permissions, but it still needs a network path to reach another service.
Identity and networking therefore solve different but complementary problems:
IAM → Who can act?
Networking → Where and how can traffic flow?
Introduction
Networking is the communication foundation of cloud computing.
Whenever one resource needs to communicate with another, networking determines how traffic travels between them.
This includes communication between:
- Users and applications.
- Applications and databases.
- Cloud services.
- Different application tiers.
- Cloud environments.
- Enterprise data centers.
- Internet destinations.
Networking was introduced as one of the foundational capabilities in Cloud Building Blocks.
Now we are opening that building block and examining what is inside it.
Where Are We in the Cloud Architecture?
A cloud application is not just compute running somewhere in a provider’s infrastructure.
It normally depends on several foundational capabilities working together:
Compute
runs the workload.
Storage
holds data.
IAM
controls identity and permissions.
Networking
connects the components.
For networking specifically, we can think about the architecture in six basic building blocks:
- Virtual Network — creates the network boundary.
- Subnet — divides that network into smaller segments.
- IP Address — identifies a network interface or endpoint.
- Route — determines where traffic should go.
- Gateway — connects the network to another network or destination.
- Network Security Boundary — controls which traffic is permitted.
These concepts exist across AWS, Microsoft Azure, Google Cloud, Oracle Cloud Infrastructure (OCI), and IBM Cloud, even though product names and implementations differ.
Before exploring them individually, MyRetail gives us a practical reason to understand how they work together.
MyRetail Business Challenge
MyRetail can now provision cloud resources through the governed processes introduced in Resource Provisioning Across Multi-Cloud.
Its IAM foundation also provides a way to control which humans, workloads, automation systems, and AI agents are allowed to perform actions.
But those resources now need to communicate.
MyRetail therefore needs more than connectivity.
It needs intentional connectivity.
The objective is to provide each workload with the network paths it requires while avoiding unnecessary exposure.
That network foundation will later work together with the protections introduced in Cloud Security Fundamentals.
Understanding the Building Blocks of Cloud Networking
Cloud networking contains several related concepts.
Instead of learning them as isolated terms, first understand where each component sits in the traffic path.
A useful mental model is:
Network → Subnet → IP Address → Route → Gateway → Destination
Each component answers a different networking question.
The architecture is easier to understand visually before examining each building block.
Virtual Networks — The Network Boundary
The first concept is the virtual network.
A virtual network creates a logically isolated networking environment where cloud resources can communicate.
Think of it as the outer network boundary that contains other networking components.
Inside that boundary, architects can define:
- IP address ranges.
- Subnets.
- Routes.
- Gateways.
- Security controls.
- Connectivity to other networks.
Different providers use different terminology.
For example, AWS commonly uses Virtual Private Cloud (VPC), while Microsoft Azure uses Virtual Network (VNet). Other providers have their own implementations.
Where Does the Virtual Network Fit?
Think about the hierarchy as:
Cloud Environment
↓
Virtual Network
↓
Subnets
↓
Workloads
The virtual network provides the broad communication boundary.
The subnet gives that network more structure.
Subnets — Dividing the Network
A single virtual network can contain many workloads.
Placing everything into one large network segment would make the environment harder to organize, secure, and scale.
A subnet divides the larger network into smaller logical segments.
For example, MyRetail might eventually organize an application into:
Web Subnet
→ Front-end workloads
Application Subnet
→ Business services
Database Subnet
→ Data services
The purpose is not simply to create more network objects.
Subnets help architects create clear workload boundaries and predictable traffic patterns.
Where Does a Subnet Fit?
The structure now becomes:
Virtual Network
↓
Subnet
↓
Workload
A virtual network can contain multiple subnets, and each subnet contains an address range from the larger network design.
This segmentation will become increasingly important when we reach Cloud Security Fundamentals, because network placement and security controls often work together.
IP Addresses — Identifying Network Endpoints
Once workloads are placed inside networks and subnets, they need a way to participate in network communication.
That is where IP addresses enter the architecture.
An IP address identifies a network interface or endpoint so traffic can be sent toward it.
For this foundation lesson, the important distinction is:
Private IP
Used primarily for communication inside private network environments.
Public IP
Used when a resource needs direct addressing through public network connectivity.
Not every cloud resource requires a public IP address.
In enterprise architectures, many application and database workloads remain privately addressed and are reached through controlled network paths.
Where Does the IP Address Fit?
Our mental model now becomes:
Virtual Network
↓
Subnet
↓
Workload
↓
IP Address
The network creates the boundary.
The subnet defines placement.
The IP address identifies the network endpoint.
But knowing the destination address is not enough.
The network still needs to determine:
Which path should the traffic take?
That is the role of routing
Routing — Deciding Where Traffic Goes
So far, we have built the first half of the networking mental model:
Virtual Network → Subnet → Workload → IP Address
The workload now has a network location and an address. The next question is:
How does the network decide where traffic should go?
That is the role of routing.
A route describes the path traffic should follow to reach a destination. Cloud platforms evaluate routing information and direct traffic toward the appropriate next hop.
Before looking at individual routing concepts, it helps to see where routing sits in the complete traffic journey.
Understanding Routes
A route can be understood through two basic pieces of information:
Destination
Where is the traffic trying to go?
Next Hop
Where should the network send that traffic next?
For example, traffic destined for another subnet inside the same virtual network may remain within that network.
Traffic destined for an external network may need to pass through a gateway or another connectivity service.
This gives us the next structural relationship:
IP Address → identifies the destination
Route → determines the path
Gateway → connects the path to another network
Gateways — Connecting Network Boundaries
Routes determine where traffic should go, but some destinations exist outside the current network boundary.
A gateway provides a connection point between networks.
Think of the relationship as:
Route = Where should traffic go?
Gateway = How does it reach the other network?
A gateway may help connect a cloud network to:
- The internet.
- An enterprise data center.
- Another virtual network.
- Another cloud environment.
The exact gateway types and names vary between cloud providers. We will consolidate those differences later rather than interrupting the core networking model with provider terminology.
Where Does a Gateway Fit?
Our mental model has now expanded to:
Workload
↓
IP Address
↓
Route
↓
Gateway
↓
Destination Network
This same model becomes important later when MyRetail connects its cloud environments to enterprise locations and eventually builds a broader Multi-Cloud Architecture.
Public vs Private Connectivity
Not every workload should communicate with the outside world in the same way.
Cloud architectures therefore distinguish between private connectivity and public connectivity.
Before discussing specific technologies, understand the two communication models.
Public Connectivity
Public connectivity allows traffic to use publicly reachable network paths.
Typical examples include:
- Customers reaching an internet-facing application.
- Public APIs.
- Public web services.
A public path does not mean every request should be allowed.
Network controls and the identity principles introduced in Identity and Access Management Across Multi-Cloud still determine whether the interaction is permitted.
Private Connectivity
Private connectivity keeps communication within controlled network paths rather than exposing the destination directly through the public internet.
This is commonly useful for:
- Application-to-database communication.
- Internal enterprise applications.
- Management services.
- Data center connectivity.
- Service-to-service communication.
For MyRetail, an internet-facing storefront might accept customer traffic publicly while its application and database tiers remain privately addressed.
This leads to an important architecture principle:
Expose only what needs to be reachable. Keep internal communication private where practical.
Outbound Connectivity and NAT
A private workload can still need access to external services.
For example, an application may need to:
- Download a software update.
- Reach an external API.
- Contact a package repository.
- Send telemetry to an approved destination.
But MyRetail may not want that workload to accept unsolicited inbound internet connections.
This introduces another networking pattern: outbound connectivity.
Where Are We?
There are two different communication requirements:
Inbound
Something outside initiates communication toward the workload.
Outbound
The workload initiates communication toward another destination.
A private workload may require outbound internet access without becoming directly reachable from the internet.
Network Address Translation, commonly called NAT, is one mechanism cloud architectures use to support this pattern.
NAT can therefore support a common enterprise pattern:
Private Workload
→ Controlled Outbound Path
→ External Destination
without requiring:
Internet
→ Direct Public Reachability to Workload
The exact implementation varies by cloud provider.
At this stage, understanding the traffic pattern matters more than memorizing NAT products.
DNS — Finding Services by Name
IP addresses allow networks to identify endpoints, but people and applications usually prefer names.
Instead of remembering an address such as:
10.0.2.25
an application may connect to something like:
database.internal
The Domain Name System (DNS) translates names into network addresses.
Where Does DNS Fit?
DNS solves a different problem from routing.
DNS
What address belongs to this name?
Routing
How do I reach that address?
That distinction is important.
A successful DNS lookup does not guarantee that network connectivity exists.
Likewise, a valid network path is not useful if the application cannot resolve the destination name it expects.
Simple Mental Model
Application
↓
Service Name
↓
DNS
↓
IP Address
↓
Routing
↓
Destination
DNS therefore becomes part of the broader communication chain.
Later, when we reach Cloud Compute and Cloud Databases, service discovery and application connectivity will make this relationship even more practical.
Putting the Traffic Flow Together
We have now introduced several networking components.
Rather than treating them as independent terms, bring them back into one end-to-end communication flow.
Suppose a MyRetail application needs to reach another service.
The process can be understood as:
1. Application identifies a destination
↓
2. DNS resolves the name when required
↓
3. Destination IP becomes known
↓
4. Routing determines the path
↓
5. A gateway or connectivity service is used when crossing network boundaries
↓
6. Network controls determine whether traffic is permitted
↓
7. Traffic reaches the destination
This is the networking mental model that matters most.
Why This Mental Model Matters
When cloud connectivity fails, engineers can work through the same sequence:
Can the destination name be resolved?
→ Is the correct IP address being used?
→ Does a valid route exist?
→ Is the required gateway or network connection available?
→ Do network controls permit the traffic?
This provides a much more useful foundation than memorizing individual networking products.
It also prepares the reader for Cloud Security Fundamentals, where network traffic controls become part of the broader security architecture, and for later Cloud Automation and Infrastructure as Code lessons, where these network components can be provisioned consistently through code.
The networking picture has now expanded from:
Network → Subnet → IP
to:
Name → IP → Route → Gateway → Network Control → Destination
We also understand two important traffic patterns:
Public vs Private Connectivity
and
Inbound vs Outbound Connectivity
The next step is no longer learning individual network objects.
It is learning how architects organize these building blocks into enterprise network designs.
Network Segmentation — Organizing Cloud Networks into Trust Zones
So far, we have learned how traffic moves:
Network → Subnet → IP → Route → Gateway → Destination
Enterprise network design adds another question:
Should every workload be able to communicate with every other workload?
Usually, the answer is no.
A cloud network may contain web applications, application services, databases, management systems, shared services, and development workloads. These resources have different connectivity requirements.
Network segmentation divides the environment into logical network zones so workloads can be organized and traffic between those zones can be controlled.
Where Are We in the Architecture?
Think of segmentation as another layer of structure:
Virtual Network
↓ contains
Network Zones / Subnets
↓ contain
Workloads
↓ communicate through
Controlled Traffic Paths
A simple three-tier application might therefore use:
- Web Zone — receives application traffic.
- Application Zone — runs business logic.
- Data Zone — hosts databases and data services.
- Management Zone — supports administrative operations.
The objective is not to create as many subnets as possible.
It is to create meaningful boundaries that reflect workload responsibilities and communication requirements.
Why Segmentation Matters
Segmentation creates structure.
For example, a customer may need to reach MyRetail’s web application, but that does not mean the customer should have a direct network path to the database.
A more intentional path is:
Customer
→ Web Tier
→ Application Tier
→ Database Tier
Each transition becomes a point where connectivity can be controlled.
This complements the identity boundaries established in Identity and Access Management Across Multi-Cloud. IAM controls who or what can act, while network segmentation helps control where communication can occur.
Network Security Boundaries — Controlling Traffic Between Zones
Creating subnets and network zones provides structure, but segmentation alone does not decide which traffic should be allowed.
Cloud networks also use network security controls to permit or block communication.
At this foundation level, think about these controls as answering one question:
Should this traffic be allowed to cross this boundary?
Where Do Network Security Controls Fit?
The traffic flow becomes:
Source
→ Route
→ Network Security Check
→ Allow or Block
→ Destination
Network security decisions can consider information such as:
- Source.
- Destination.
- Protocol.
- Port.
- Direction of traffic.
The exact implementation differs across cloud platforms, so detailed provider terminology belongs in the consolidated Multi-Cloud Perspective rather than here.
A useful enterprise principle is:
Allow required communication. Avoid unnecessary network paths.
For MyRetail, that might mean the application tier can reach the database on the required service path, while the public internet cannot reach the database directly.
A private subnet by itself does not provide the entire security model.
Network controls work together with identity controls from Identity and Access Management Across Multi-Cloud and the broader protections that will be introduced in Cloud Security Fundamentals.
Load Balancing — Distributing Traffic Across Workloads
Network architecture is not only about creating paths and boundaries.
Enterprise applications also need to handle changing traffic volumes and avoid depending on a single workload instance.
This introduces load balancing.
Where Does Load Balancing Fit?
Imagine MyRetail has three application instances:
Application 1
Application 2
Application 3
Users should not need to know which instance is available.
Instead:
Users
↓
Load Balancer
↓
Multiple Application Instances
The load balancer provides a common entry point and distributes traffic across available workloads.
Load balancing supports both scalability and availability.
As demand grows, more application instances can participate in serving requests. If an instance becomes unavailable, traffic can be directed toward healthy instances instead.
This relationship will become more meaningful in Cloud Compute lesson, where we explore how compute workloads are deployed and scaled.
For now, remember:
Network path brings traffic to the application.
Load balancing distributes that traffic across application capacity.
Availability Zones and Regions — Designing Beyond One Location
Multiple workload instances improve availability, but another question remains:
What happens if the infrastructure location hosting those instances has a problem?
Cloud providers organize infrastructure into geographic and failure-isolation structures such as regions and availability zones, although exact terminology and implementation vary.
Where Are We?
Think about the hierarchy conceptually:
Cloud Provider
↓
Region
↓
Availability / Failure-Isolation Zones
↓
Networks + Workloads
A region represents a broad geographic deployment location.
Availability zones or equivalent constructs provide additional infrastructure separation within a region.
Networking connects workloads across those boundaries according to the provider’s architecture.
For MyRetail, this means network architecture cannot assume that every application component will live in one physical infrastructure location.
Network paths, load balancing, workload placement, and failure boundaries need to work together.
We will examine resilience more deeply later. At this stage, the networking lesson only needs one principle:
Do not make critical application connectivity dependent on a single infrastructure location when the workload requires higher availability.
Hub-and-Spoke — Organizing Enterprise Connectivity
As an enterprise creates more cloud networks, connecting everything directly to everything else becomes difficult to govern.
Imagine MyRetail eventually has separate networks for:
- Production.
- Development.
- Shared services.
- Data platforms.
- Security services.
- Different business units.
Creating independent connectivity between every network can lead to a growing web of connections.
A common architecture pattern is hub-and-spoke.
Where Does Hub-and-Spoke Fit?
Instead of:
Network A ↔ Network B ↔ Network C ↔ Network D
with many independent connections, introduce a central connectivity layer:
Spoke
↘
HUB
↗
Spoke
The hub provides shared connectivity.
The spokes contain workloads or application environments.
Why Enterprises Use Centralized Connectivity
Hub-and-spoke can provide a logical place for shared capabilities such as:
- Routing.
- Network inspection.
- DNS.
- Enterprise connectivity.
- Shared network services.
Application environments can remain separated as spokes while consuming common connectivity services through the hub.
This becomes increasingly valuable as cloud estates grow.
However, hub-and-spoke is an architecture pattern, not a universal requirement. Smaller environments may not need the additional complexity.
The architecture should match the scale, governance requirements, and communication patterns of the enterprise.
MyRetail’s Network Architecture Is Taking Shape
MyRetail’s network is now more than a collection of subnets.
The architecture is beginning to form a deliberate structure:
Customer
↓
Load Balancer
↓
Web Zone
↓
Application Zone
↓
Data Zone
while:
Management and Shared Services
use controlled connectivity paths.
As the environment grows, a centralized hub can connect application networks with shared services and enterprise locations.
This architecture also creates a foundation for the workloads introduced later in Cloud Compute, the data services explored in Cloud Storage and database lessons, and the automated provisioning patterns that will eventually be implemented through Infrastructure as Code.
The next question is bigger:
How does MyRetail connect its enterprise data center to cloud—and eventually connect multiple cloud providers together?
Hybrid Cloud Networking — Extending the Enterprise Network into Cloud
MyRetail’s applications may run in cloud environments, but the enterprise does not instantly stop using its existing data centers, corporate networks, branch locations, or private systems.
This creates the next networking requirement:
How does an enterprise securely connect its existing network to the cloud?
This is hybrid cloud networking.
Where Are We in the Architecture?
Until now, most of our traffic stayed inside or around a cloud network:
Users → Cloud Network → Application
Hybrid networking extends that boundary:
Enterprise Network
↕
Connectivity
↕
Cloud Network
The connection between them can use different approaches depending on requirements for cost, performance, reliability, security, and scale.
Two foundational models are:
- VPN connectivity — encrypted connectivity commonly transported across public network infrastructure.
- Dedicated private connectivity — dedicated or provider-connected network paths between enterprise locations and cloud environments.
Understand these models first before learning individual provider products.
VPN vs Dedicated Private Connectivity
Both approaches connect networks, but they solve different enterprise requirements.
Where Do These Options Fit?
Start with the requirement:
Enterprise Network
↓
Needs Cloud Connectivity
↓
Choose an appropriate connection:
VPN or Dedicated Private Connectivity
The decision depends on the workload rather than one option always being better.
For MyRetail, VPN connectivity might provide an appropriate starting point for some environments.
As traffic volume and business dependency increase, dedicated connectivity may become appropriate for critical workloads.
Enterprises can also use both approaches—for example, dedicated connectivity as a primary path with VPN supporting resilience requirements.
The architecture should be driven by the business requirement.
Cloud-to-Cloud Connectivity
Hybrid networking connects:
Enterprise → Cloud
A multi-cloud environment introduces another relationship:
Cloud → Cloud
MyRetail may eventually operate workloads across AWS, Microsoft Azure, Google Cloud, Oracle Cloud Infrastructure (OCI), and IBM Cloud.
Those environments should not be treated as though they automatically form one network.
Each cloud has its own:
- Network boundaries.
- IP addressing.
- Routing.
- Connectivity services.
- Security controls.
Connecting them requires intentional architecture.
Connected Does Not Mean Flat
One of the easiest mistakes in multi-cloud networking is assuming that connecting environments means every network should communicate freely.
That is rarely a desirable enterprise model.
A better principle is:
Connect environments intentionally while preserving meaningful network and security boundaries.
For example, MyRetail’s application in one cloud may need to consume a particular data or shared service hosted elsewhere.
That does not mean every subnet in both clouds requires unrestricted connectivity.
The same segmentation principles introduced earlier still apply at multi-cloud scale.
Multi-Cloud Network Design Principles
The products change between providers, but the architectural questions remain consistent.
Before choosing a networking service, architects should ask:
1. What Needs to Communicate?
Start with the application dependency.
Do not begin by connecting entire environments.
Ask:
Source → Destination → Required Communication
This reduces unnecessary network paths.
2. Where Are the Network Boundaries?
Identify:
- Cloud networks.
- Application environments.
- Enterprise networks.
- Shared services.
- Security zones.
This makes the architecture easier to govern.
3. How Will IP Addressing Be Planned?
Networks that need to communicate should have an intentional addressing strategy.
Overlapping IP ranges can make connectivity considerably more difficult.
Address planning therefore becomes increasingly important as the environment grows from:
One Network
to
Many Networks
to
Hybrid
to
Multi-Cloud.
Detailed IP-address management belongs in deeper networking material, but the foundational principle is simple:
Plan address space before connectivity becomes complex.
4. Where Should Routing Be Controlled?
As networks multiply, routing should not evolve through random one-off connections.
Enterprises typically establish connectivity patterns and governance around how networks exchange traffic.
This is where the hub-and-spoke architecture introduced earlier becomes useful.
5. Which Traffic Should Be Allowed?
Connectivity does not override security.
Multi-cloud networking should continue applying:
Required Path → Explicit Control → Approved Communication
Networking Across Major Cloud Providers
Now that the architecture is clear, provider terminology becomes easier to understand.
AWS, Microsoft Azure, Google Cloud, Oracle Cloud Infrastructure (OCI), and IBM Cloud all provide capabilities for:
- Virtual networks.
- Subnets.
- Routing.
- Internet connectivity.
- Private connectivity.
- Load balancing.
- Hybrid networking.
The service names differ.
The architectural responsibilities are similar.
The table is not intended to teach five separate networking platforms.
Instead, use it to recognize the pattern:
AWS VPC
Azure VNet
Google Cloud VPC
OCI VCN
IBM Cloud VPC
all address the same high-level architectural requirement:
Create a logical cloud network where workloads can communicate through defined addressing, routing, connectivity, and security boundaries.
Think Capability First, Product Second
This capability-first approach is one of the most important skills in the MyCloudWiki learning journey.
Instead of memorizing:
VPC = AWS
or
VNet = Azure
learn:
I need a virtual network boundary. What capability does this provider offer?
The same method applies to:
Routing
NAT
Load Balancing
Private Connectivity
and later to Cloud Compute, Cloud Storage, databases, observability, automation, and other cloud capabilities.
This is how engineers begin moving from provider-specific knowledge toward multi-cloud architecture thinking.
MyRetail’s Multi-Cloud Networking Direction
MyRetail does not need to connect every cloud to every other cloud immediately.
Its network should evolve with business requirements.
A reasonable progression is:
Stage 1
Enterprise Data Center
↕
Primary Cloud Environment
Stage 2
Enterprise Connectivity
↕
Multiple Cloud Networks
Stage 3
Shared Connectivity and Governance
↕
Selected Cross-Cloud Services
The goal is not:
Connect everything because multi-cloud exists.
The goal is:
Provide the minimum connectivity required by the business architecture.
That same principle appeared earlier in Resource Provisioning Across Multi-Cloud lesson: enterprise cloud design should create governed capabilities rather than uncontrolled resource growth.
Networking follows the same philosophy.
Engineer & Architect Perspective
Cloud networking becomes an enterprise capability when implementation and architecture work together.
Engineers make connectivity operational. Architects determine how that connectivity should be structured, governed, secured, scaled, and extended across the enterprise.
The networking lesson has progressed from individual components to enterprise connectivity:
Network Components
→ Traffic Flow
→ Network Segmentation
→ Hybrid Connectivity
→ Multi-Cloud Networking
At this point, responsibilities begin to separate naturally.
Cloud Engineers focus on implementing and operating the network.
Cloud Architects focus on designing the network model and its boundaries.
Both work toward the same outcome:
Reliable, controlled, and scalable connectivity.
Well-Architected Perspective
Networking affects every major quality attribute of a cloud workload.
A poorly designed network can create security exposure, application outages, unnecessary latency, operational complexity, and avoidable cost.
Think about networking through five architectural concerns:
Security
Reliability
Operational Excellence
Performance Efficiency
Cost Optimization
Networking influences all five.
Applying the Five Perspectives
Security starts with limiting unnecessary exposure. Public endpoints, private networks, segmentation, network controls, and IAM should work together rather than independently.
Reliability considers what happens when a connectivity path, workload, or infrastructure location becomes unavailable. Critical workloads should avoid unnecessary single points of dependency.
Operational Excellence requires networks that engineers can understand, monitor, troubleshoot, and reproduce. Later, Infrastructure as Code and Cloud Automation will make standardized network deployment even more important.
Performance Efficiency considers workload placement, latency, traffic paths, and connectivity choices. The shortest architectural diagram is not necessarily the best-performing real-world path.
Cost Optimization matters because network traffic is not always free. Cross-region, internet, private connectivity, and cross-cloud data movement can all influence architecture cost.
Networking is therefore not merely a connectivity concern.
It is an architecture concern.
AI & Agentic AI Perspective
AI changes how enterprises can operate networks, but it does not remove the need for network architecture.
AI systems can help engineers understand configurations, investigate connectivity problems, analyze telemetry, recommend changes, and automate approved network operations.
Agentic AI goes one step further.
An agent may be able to take action.
Where Does AI Fit?
There are three useful levels to distinguish:
AI Assistance
→ explains or recommends.
AI Automation
→ performs a predefined network task.
AI Agent
→ reasons about a goal and uses approved tools to perform bounded actions.
The more authority the system receives, the more important identity, permissions, network boundaries, approvals, and auditability become.
AI-Assisted Networking
At the assistance level, AI can help an engineer ask questions such as:
Why can this application not reach the database?
An AI-assisted tool could analyze relevant network information and help identify possibilities such as:
- Missing route.
- Incorrect destination.
- DNS resolution problem.
- Network rule blocking traffic.
- Unavailable connectivity path.
The engineer remains responsible for evaluating the recommendation.
Agentic Network Operations
An AI agent may eventually do more than provide an explanation.
For example:
Observe
→ detect a connectivity issue.
Reason
→ determine the likely network cause.
Plan
→ propose a remediation.
Act
→ perform an approved change.
Verify
→ confirm connectivity.
But the agent should not automatically receive unrestricted network-administrator permissions.
The identity model established in Identity and Access Management Across Multi-Cloud still applies:
Agent Identity
→ Least-Privilege Permission
→ Approved Tools
→ Policy
→ Bounded Action
→ Audit
This becomes particularly important when network operations are combined with Cloud Automation and later self-service capabilities in Platform Engineering.
Architect’s Notebook
Enterprise networking becomes difficult when networks are created individually without a common architecture.
A senior architect therefore looks beyond individual VPCs, VNets, subnets, routes, or gateways and asks whether the overall connectivity model remains understandable and governable.
The Architect’s Notebook captures the most important design observations from this lesson in one place.
The technical architecture is now complete.
The lesson has progressed from:
Network
→ Subnet
→ IP
→ Route
→ Gateway
into:
Segmentation
→ Load Balancing
→ Hybrid Connectivity
→ Multi-Cloud Networking
and finally into:
Architecture
→ Operations
→ Well-Architected Decisions
→ AI-Assisted Networking
→ Agentic Operations
MyRetail Business Solution & Progress
MyRetail started this lesson with a practical problem.
Its cloud resources could be provisioned, and Identity and Access Management Across Multi-Cloud established who—or what—was allowed to act. But applications, databases, users, shared services, and enterprise systems still needed predictable communication paths.
Cloud networking now gives MyRetail that connectivity foundation.
What MyRetail Has Established
MyRetail can now design its network around several simple principles:
- Create structured virtual networks and subnets.
- Keep application tiers logically segmented.
- Use routing to create predictable traffic paths.
- Limit unnecessary public exposure.
- Use load balancing for distributed application traffic.
- Connect enterprise environments through controlled hybrid connectivity.
- Extend connectivity to multiple clouds only when business requirements justify it.
- Keep network boundaries understandable as the environment grows.
The result is not a finished enterprise network.
It is a network architecture foundation that later lessons can build upon.
MyRetail has now progressed through another important architecture transition:
Resource Provisioning
→ How are cloud resources created?
Identity & Access
→ Who—or what—is allowed to act?
Cloud Networking
→ How do those resources communicate?
The next foundational capabilities can now be layered onto this architecture rather than designed in isolation.
