Every cloud application depends on two designs that are usually drawn by different people: the network that carries traffic to and between systems, and the cloud architecture that runs the workloads themselves. When those two designs are made together, applications are fast, resilient and affordable. When they are made separately, the gaps show up as latency nobody can explain, outages that take out “redundant” systems, and data transfer bills nobody budgeted for.
Network architects and cloud architects are the people responsible for those designs. Their work is mostly invisible when it goes well. This article explains what each role does, where their responsibilities meet, and the specific decisions at that boundary that business and IT leaders should make sure someone owns.
Two roles, one path for every request
A network architect designs how traffic moves: between offices, data centers, remote workers and cloud providers. The toolkit includes wide-area networking and SD-WAN, internet and private circuits, firewalls, DNS, IP address planning, and increasingly secure access service edge (SASE) platforms, a model Gartner described in 2019 that combines networking and security services delivered from the cloud.
A cloud architect designs how workloads run on AWS, Microsoft Azure or Google Cloud: which services to use, how to scale them, how to spread them across availability zones and regions, how identities and accounts are organized, and how the whole thing is defined in code so it can be rebuilt consistently.
Every user request crosses both designs. A customer loading a web page travels over the internet, through DNS, into a cloud virtual network, through a load balancer, to an application, and often back out to a database or a third-party API. A problem at any hop looks the same to the customer: the page is slow or broken. That is why the two roles need a shared picture of the full path.
The decisions that sit on the boundary
Most of the trouble in hybrid and cloud environments comes from a handful of decisions that neither role fully owns by default.
IP address planning. Cloud virtual networks need address ranges that do not overlap with offices, data centers or other clouds. Overlaps are easy to create in a hurry and painful to fix later, because connecting two networks with the same ranges requires workarounds that add complexity and failure points.
How on-premises sites connect to the cloud. Options range from site-to-site VPN over the internet to dedicated private connections such as AWS Direct Connect, Azure ExpressRoute and Google Cloud Interconnect. Private links give more predictable performance but cost more and take weeks to provision. The right answer depends on how much traffic flows, how sensitive it is, and how much downtime the business can tolerate if one link fails.
Where traffic is inspected. Routing all traffic back through a central firewall is simple to govern but adds latency and creates a choke point. Inspecting traffic in the cloud or at a SASE edge is faster for remote users but requires consistent policy across several places.
Data transfer costs. Cloud providers generally charge for data leaving their networks and, in many cases, for traffic between zones and regions. An architecture that looks elegant on a whiteboard can generate large recurring bills if it moves data back and forth unnecessarily. In early 2024 the largest providers began waiving transfer fees for customers moving their data out entirely, but everyday egress still costs money and belongs in the design review.
DNS and name resolution. Hybrid environments often have several DNS systems that must resolve each other’s names. Misconfigured DNS is one of the most common causes of “the network is down” tickets, and it frequently falls between teams.
Resilience is a shared design problem
Cloud providers make it easy to deploy across multiple availability zones, and many teams stop there. But resilience also depends on things outside the application: the network paths into the cloud, the DNS provider, the identity provider, and the specific regional services the application relies on.
The October 20, 2025 disruption in AWS’s US-EAST-1 region is a useful reminder. According to AWS’s own post-event summary, a problem in the automated DNS management for the DynamoDB service left its regional endpoint unresolvable, and the effects cascaded to other services that depended on it. Organizations whose applications were spread across availability zones in that one region were still affected. Designing for that kind of event means deciding, deliberately, which systems need to survive a regional failure and paying for the network and cloud architecture that makes it possible.
Resilience is also where the trade-offs are sharpest. Multi-region designs cost more, add data replication complexity and make testing harder. Not every workload needs one. The value of an architect is in making that trade-off explicit, with a recovery time and recovery point objective the business has agreed to, rather than discovering the answer during an outage.
How to get network and cloud architecture working together
Whether the roles are held by two people, one person, or an outside partner, these practices keep the designs aligned:
- Keep one diagram of the end-to-end path. From user to application to data and back, including DNS, identity and third-party services. Update it whenever either design changes.
- Agree on an IP address plan before building. Reserve ranges for each cloud, region and site, and record them in a single source of truth.
- Set recovery objectives per workload. Decide how long each system can be down and how much data it can lose, then design connectivity and cloud deployment to match.
- Define networking in code too. Cloud networks, firewall rules and routing should live in the same infrastructure-as-code repositories as the workloads, with the same review process.
- Review data transfer costs monthly. Look for unexpected cross-region or internet egress; it usually points to an architectural shortcut.
- Test failure, not just function. Periodically fail over a connection, a zone or a DNS dependency in a controlled way and measure what actually happens.
Security runs through both designs
The traditional model protected a network perimeter and trusted everything inside it. Cloud adoption, remote work and SaaS have dissolved that perimeter. Zero Trust architecture replaces it with a rule that every connection is verified based on identity, device and context, wherever it comes from. Implementing that rule touches both roles: the network architect segments traffic and deploys the access layer, while the cloud architect enforces identity-based permissions and private connectivity to services. Neither can deliver Zero Trust alone.
The same convergence is happening at the edge, where 5G, IoT devices and local computing push workloads closer to users. We explored that shift in architecting intelligent connectivity with 5G and IoT and edge and ambient computing.
Frequently asked questions
Do small businesses need both a network architect and a cloud architect?
Rarely as two full-time hires. Many small and mid-sized businesses need architecture skills at key moments, such as a cloud migration, a new office, or a resilience review, rather than every day. What they do need is for both perspectives to be present when those decisions are made.
Is SD-WAN still relevant if most applications are in the cloud?
Yes, and often more so. SD-WAN lets branch offices send cloud and SaaS traffic directly to the internet with policy control, instead of backhauling it to a central data center. Many organizations now buy it as part of a SASE platform that also includes security services.
How do we know if our architecture has gaps?
Common warning signs include unexplained latency, frequent DNS-related incidents, surprise data transfer charges, overlapping IP ranges, and no one being able to say what happens if a region or connection fails. An architecture review that traces the full request path usually surfaces these quickly.
Build infrastructure that holds up
Delana Technologies helps businesses design and review hybrid and cloud architectures, from connectivity and resilience planning to Zero Trust access and compliance. See our cloud modernization services and cybersecurity and compliance services, call 239.414.5126 or contact us.
Sources: AWS post-event summary of the Amazon DynamoDB service disruption in the Northern Virginia (US-EAST-1) region (October 2025); Gartner, “The Future of Network Security Is in the Cloud” (2019); AWS, Google Cloud and Microsoft announcements on waiving data transfer fees for customers leaving their platforms (2024); AWS Direct Connect, Azure ExpressRoute and Google Cloud Interconnect documentation.