Analyze Requirements for Cloud Network Design

0:01In this skill, we examine how business and technical requirements influence cloud network design decisions. Understanding workload communication patterns, performance expectations, and security needs ensures the resulting architecture is scalable, resilient, and aligned with organizational objectives. In this lesson, we will examine how business-driven requirements influence cloud network architecture decisions before implementation begins.

0:36Understanding the organizational objectives such as availability targets, regulatory obligations, and cost limitations allow cloud architects to design network topologies that align with business needs while still supporting operational and compliance requirements. Business requirements represent organizational objectives that must be supported by the network architecture. These requirements often originate from leadership, legal, or operational stakeholders and guide how workloads should be deployed within the cloud environment.

1:17Availability requirements, such as uptime service level agreements, determine how workloads must be distributed across availability zones or regions to support fault tolerance and service continuity. Regulatory frameworks may require isolation between sensitive and non-sensitive systems. Network segmentation may be required to enforce trust boundaries and prevent unauthorized access to regulated workloads.

1:52And of course, there's always budget limitations. Financial constraints may influence the choice between private connectivity services and VPN-based integration models when designing hybrid connectivity solutions. Legal requirements may mandate that customer data remain within specific geographic boundaries, which may influence where workloads are deployed and replicated.

2:22Next, let's examine how availability requirements influence deployment and redundancy strategies. So the first thing we want to discuss is recovery time objective, or RTO. This defines the maximum acceptable duration of service disruption following a failure or outage. Next, we have the recovery point objective, or the RPO. This determines the acceptable amount of data loss measured in time between recovery points.

2:59Just as an example, let's say we run our backups every night. The next day, somebody has a problem at 4.45 p.m., and they have to get all of their information restored from the backup the night before. That essentially means that everything they've done that day up until 4.45 is going to be lost when we roll it back to the previous backup. So for a lot of environments, that's not acceptable, and they'll actually do rolling backups throughout the day.

3:33But that's what we're referring to here. Next, we also have SLAs, or service level agreements. These define minimum availability requirements that cloud architectures must meet through redundancy and failover mechanisms. Another way to say this is simply uptime. Out of a certain amount of time, usually measured per year, what is our uptime? And you'll hear measurements here such as five nines, maybe you'll hear four nines, and this is basically what percentage the network is going to be up.

4:12So for example, five nines would be 99.999% uptime. And just to save you a little math, that comes out to about five minutes per year that we're allowed to have unscheduled downtime. Something else to keep in mind is regional redundancy may be required to maintain application availability in the event of a regional cloud outage.

4:42We also want to provide fault domain isolation. Distributing workloads across fault domains, such as availability zones, helps prevent localized infrastructure failures from impacting the entire application environment. If you're not really familiar with the term fault domain, we will be discussing this more throughout the rest of the course. But the general idea is this is an area of the network in which a fault will only affect that particular section.

5:16So essentially it's a way of referring to a single part of the network where a failure can take down that entire part of the network. So needless to say, we want our fault domains to be as small as possible. Now we're always going to have fault domains, but we want to try to minimize that and of course isolate any failures there to that fault domain only. In addition to availability targets, compliance requirements often dictate how cloud network segmentation must be implemented.

5:50So we really have to consider compliance and regulatory requirements. For example, if we take credit cards, we have the Payment Card Industry Data Security Standard or PCI DSS. This requires the protection of cardholder data and often mandates network segmentation to isolate payment processing systems. Here in the United States, we have something called HIPAA or the Health Insurance Portability and Accountability Act.

6:22This is specifically for the medical industry and it requires safeguards to protect health information, which may include again isolating health care data systems within dedicated network segments. In other parts of the world, we have the GDPR or the General Data Protection Regulation. This can restrict how personal data is stored, processed, or transferred across geographical boundaries.

6:52Oftentimes, there'll be data classification requirements. Organizational data classification policies often determine how workloads are grouped and segmented based on sensitivity. Segmentation requirements may be implemented to prevent unauthorized access or lateral movement between regulated and non-regulated workloads. Now, of course, beyond these regulatory obligations, cost considerations can also influence connectivity and redundancy design.

7:27Budget is almost always one of the top concerns in most corporations. So one of the big considerations here is going to be private connectivity cost considerations. In other words, having a dedicated circuit connecting two of your remote locations. This is going to be quite costly. Private connectivity services such as dedicated cloud interconnects may provide performance benefits and privacy benefits, but again, this is going to dramatically increase operational costs.

8:00Alternatively, we may choose to do a VPN deployment. Site-to-site VPN connections may provide cost-effective hybrid connectivity compared to private connectivity solutions. In most cases, our VPNs are simply going to use the internet access that we already have and we're already paying for. Something else to keep an eye on when it comes to budget and cost would be regional resource pricing. Cloud providers often charge different rates depending on the deployment region, which may influence workload placement decisions.

8:37We also need to watch for traffic egress charges. Inner region and outbound traffic may incur additional costs that impact centralized inspection or replication strategies. We also have to consider operational complexity tradeoffs. Highly redundant architectures may improve availability, but they can also increase management overhead and operational expenses. In addition to budget and cost restraints, legal requirements related to data storage may further influence regional selection and connectivity design.

9:15We have to be concerned with where our data is going to be stored. The first part of this may come down to geographic data storage mandates. Some regulations require that data remain within national or regional boundaries. Data sovereignty laws may also restrict how data can be stored or transmitted across international borders. We also want to be concerned with workload placement. Applications may need to be deployed within specific cloud regions to comply with residency mandates.

9:51There can also be cross-border data transfer limitations. Replication or backup strategies may be limited by legal restrictions on the data transfers. And of course, we always have to watch out for different jurisdictions. They can impose varying legal obligations that must be supported by the network architecture. These business requirements ultimately influence architectural design outcomes.

10:21So first, it's going to affect our topology selection. Requirement analysis may influence whether hub-and-spoke or transit networking models are going to be deployed. It's also going to influence our connectivity model. Hybrid connectivity options may include VPN or private interconnect solutions. We also need to be concerned with segmentation boundaries. Compliance obligations may determine subnet or virtual network segmentation.

10:53We also have to be concerned with disaster recovery placement. Availability requirements influence regional recovery strategies. And again, this may also come down to geographical location of where we're actually allowed to place a high-availability site. And of course, we also need to be concerned with where we're going to place the workloads. They must be deployed in regions that support the necessary compliance, performance, and cost objectives.

11:23By evaluating business requirements early in the cloud network design process, architects can align technical architecture decisions with organizational objectives. Availability targets, compliance obligations, cost constraints, and data residency mandates collectively influence our topology selection, segmentation strategy, and connectivity models.

0:01In this lesson, we will examine how technical requirements influence cloud network architecture decisions. These requirements describe how workloads must communicate within and across environments, including hybrid connectivity to on-premise systems, latency-sensitive application components, and centralized shared services such as authentication or monitoring platforms.

0:32Hybrid cloud deployments often require connectivity between on-premises or on-prem data centers and cloud-hosted workloads using VPN or private connectivity services. Enterprise applications may rely on on-prem databases or identity providers that must communicate with cloud workloads. Some applications require low-latency communication, which may influence regional deployment and routing strategies.

1:09In addition, organizations may deploy workloads across multiple regions to improve availability or reduce latency for geographically distributed users. And we also have to consider centralized services such as authentication, logging, or monitoring platforms, which may require network access across multiple environments. These technical requirements directly influence how workloads communicate across environments.

1:43So first, let's consider site-to-site VPN connectivity. Site-to-site VPN connections provide encrypted connectivity between on-prem networks and cloud virtual networks. We also may need to support client-based remote access. Remote administrators or users may require secure access to cloud workloads through client-based VPN solutions.

2:13Now again, depending on the needs, we may also want to consider private connectivity services. These services, such as dedicated interconnects, provide low-latency communication between on-prem environments and the cloud. We also, however, are going to need reachability regardless of what type of connectivity we use, so we also probably want some form of dynamic routing integration. Routing protocols can be used to exchange network reachability information between hybrid environments.

2:49And of course, we always want to consider redundancy. Multiple connectivity paths may be required to support high availability and fault tolerance. Application communication patterns may also introduce latency and routing concerns. So again, we have to consider our regional deployment strategy. Deploying workloads within specific regions can reduce communication delays between services and users.

3:23This is directly related to our availability zone or AZ proximity. Placing application tiers within the same availability zone may reduce latency between the different components. And of course, we also need to be concerned about where the users are and what the user access patterns are. Workload placement may be influenced by geographic user distribution. Of course, another concern is inter-service communication.

3:55Multi-tiered applications frequently exchange data and may benefit greatly from close network placement. And the application itself may be performance sensitive. They may require low latency network paths. One example from a network administrator's perspective is connecting in to manage something through the command line, using something, for example, like SSH. When you're having an interactive session and you're typing back and forth on a console, or even something like RDP, Remote Desktop Protocol, when you're remote accessing a server to do management and administration, think about how frustrating that is if there's too much latency in the path.

4:42You move the mouse, you click on something, or you're typing and you're trying to back up over a mistake, and all of a sudden the cursor jumps 14 spaces further than you wanted because you were having too much latency. Or, again, in Remote Desktop, you click on something, you don't think you clicked on it, so you click on it again, and all of a sudden you're in rename mode instead of opening the item. So, again, it can be very, very frustrating if you have performance-based applications, which, again, is going to be in a large part interactive applications.

5:13Now, we're going to want to do things like multi-region deployments, but keep in mind that these can introduce additional routing and failover considerations. Multi-regional deployments are, however, going to give us global application availability. Deploying applications across multiple regions can improve service continuity during outages. Applications may require failover capabilities between regions to maintain our availability.

5:45However, we're going to need traffic routing mechanisms in order to direct users to the nearest or healthiest deployment. Another big consideration is going to be replication. Data replication between regions may introduce latency or bandwidth requirements. But, again, if our service or application is available in multiple regions, having that data synchronization or replication may be required. And keep in mind that depending on the situation, inter-region communication may actually require dedicated routing paths.

6:23And keep in mind our shared services must also be accessible across application environments. So, things like, for example, authentication services. Identity providers may need network connectivity to cloud-hosted workloads. Things like logging platforms. Centralized logging systems often require access across application environments. And right along with logging would be real-time monitoring systems.

6:53Monitoring platforms may collect telemetry from multiple network segments in multiple different regions. Also, things like configuration management tools. Automation platforms may manage workloads across environments. And we also could be doing it manually as well. And we're also probably going to want some form of centralized update services. Patch management systems may require connectivity, again, across various deployments.

7:23So, these technical requirements are going to influence the architectural connectivity decisions. The first thing it's going to influence would be the connectivity model selection. Hybrid deployments, we have to decide if we want to use VPN, which are generally a little less expensive, or private interconnect solutions. Generally a better connection, but also more costly. We have to choose what our routing architecture is going to be.

7:54Routing strategies must support communication between the environments. We're also going to need to consider our network segmentation placement. Shared services may require access across segmented environments. Of course, we also need to consider our failover strategy. Connectivity design must support service continuity during outages. And we have to make sure that we always have access to our central services. Workloads must maintain connectivity to the required services.

8:29So, by identifying technical requirements early in the cloud network design process, architects can ensure that workload communication, hybrid connectivity, and shared service access are supported by the network architecture. These inputs influence connectivity models, routing strategies, and failover mechanisms that maintain application performance and availability.

0:01Next, let's examine how workload communication patterns influence cloud network architecture decisions. Applications deployed in cloud environments often consist of multiple interconnected components that must exchange data across network boundaries. Understanding how these components communicate allows architects to identify trust zones, routing paths, and segmentation requirements before selecting a network topology or connectivity model.

0:39Cloud-hosted applications commonly follow multi-tier architectural models consisting of web application and database layers. Each of these tiers must exchange information to process user requests and deliver application functionality. These communication paths must be supported by secure routing and segmentation policies within the network architecture.

1:09In addition, administrative access introduces management plane traffic into the cloud environment. This may include remote administrative sessions, automation tools, or configuration management platforms that interact with workload resources. These communication pathways often require elevated privileges and should be carefully controlled within the network design. Next up for consideration would be monitoring platforms.

1:41These often collect telemetry and performance data from application components and infrastructure resources. This communication typically spans multiple network segments and may require centralized access to workloads across environments. Something else we may need to consider is external service integrations. Cloud-hosted applications may interact with third-party services such as payment gateways, identity providers, or analytics platforms.

2:15These integrations introduce additional network communication paths that must be supported within the architecture. So let's take a look at how we can categorize some of this workload communication based on traffic direction within the cloud network. Let's begin by talking about what we refer to as north-south traffic. This is going to be client-to-application access. North-south traffic refers to communication between external users and cloud-hosted applications.

2:51This traffic typically enters the cloud network through publicly facing endpoints such as load balancers or application gateways. This could also, however, be an external API. Applications may exchange data with external platforms through API integrations. These communication paths may require secure routing and inspection within the network architecture. Public service endpoints often serve as entry points for user traffic entering the cloud-hosted application environment and must be protected through application segmentation and access controls.

3:35Internal communication between application components introduces additional architectural considerations. This is generally considered east-west traffic. This is going to include things like inter-tier communication. Multi-tier applications require internal communication between web application and database components. These internal communication paths must be supported within the network architecture.

4:07We can also have service-to-service interaction. Cloud-native applications may consist of distributed services that exchange data across internal network segments. These service interactions often require secure routing and segmentation. This would also include database access requests. Application components frequently communicate with back-end databases to retrieve or store information. These communication pathways must be carefully controlled to prevent unauthorized access.

4:44And we can have internal API calls as well. Microservices architectures often rely on internal APIs to exchange data between services. These communication flows typically occur within private network segments. And containerized workloads may communicate across internal service boundaries. These communication patterns may influence segmentation requirements and routing policies.

5:14Administrative access introduces privileged communication paths into the cloud network. For example, remote administrative access. Administrators may require secure network access to manage workloads or infrastructure components within the cloud environment. We may also be using configuration management systems. Automation platforms may configure workloads across environments by interacting with cloud-hosted resources through network pathways.

5:48In addition, we may have patch management services. Update services may require connectivity to workload segments to apply security updates or system patches. And of course, there's also identity provider communication. Applications may authenticate users through centralized ID platforms, requiring network communication between workloads and identity services. In addition to management and control traffic, we also need to be concerned with monitoring and telemetry traffic.

6:22For example, things like logging platforms. Centralized logging systems often collect application and infrastructure logs from multiple workload segments across the network. Same thing with performance monitoring tools. Monitoring platforms may measure system performance metrics, such as resource utilization or response times. Another incredibly important component would be security event collectors. Security monitoring tools collect threat detection data from application components and infrastructure resources.

6:59And then we have, of course, telemetry platforms, which gather application and infrastructure data. And then we have, of course, telemetry platforms, which gather application performance information to support operational analysis. And oftentimes when that analysis doesn't go as planned, we're also going to want alerting services. Monitoring systems generate alerts based on workload conditions or performance thresholds. So finally, let's take a look at how these communication patterns influence segmentation and our routing decisions.

7:33First, we're going to have to consider our segmentation requirements. Workload communication paths may require network segmentation to isolate sensitive services from other application components. We also have to be concerned with trust boundary placement. Architects must define trust zones between application components based on communication requirements. And in order for these things to talk to each other, we also have to have routing in place.

8:05Routing paths must support secure communication between workload tiers while also preventing unauthorized access. We may also have inspection requirements. Traffic inspection may be required between workload segments to detect or prevent malicious activity. And of course, connectivity paths must support required workload interactions across application environments.

8:35By understanding workload communication patterns within cloud environments, architects can design network architectures that support secure and effective interaction between application components, identifying north-south, east-west, administrative, and monitoring traffic flows helps determine segmentation boundaries, routing requirements, and inspection placement.

0:01In this lesson, we're going to examine how availability requirements influence workload placement across cloud environments. Cloud network architects must consider recovery objectives and service availability targets when determining how application components should be distributed across availability zones or geographic regions in order to maintain continuity in the available environment.

0:31Availability planning ensures that workloads remain accessible even when infrastructure disruptions occur. So the first consideration, of course, is going to be our high availability objectives. These define how consistently an application must remain accessible to users over time. These objectives often originate from business continuity requirements and may influence redundancy strategies within the cloud network architecture.

1:04This is going to include some of the components that we discussed earlier, including the RTO, the RPO, and our SLAs or our service level agreements. So these are all things that need to be considered when we're talking about availability within our design. Cloud environments provide multiple deployment options to support these availability targets. First are availability zones.

1:34These are independent infrastructure locations. Availability zones are physically separate data center locations within a cloud region that are designed to operate independently of one another. They're going to have redundant power and redundant networking. Each availability zone typically includes independent, not just power, but cooling, networking infrastructure, everything to reduce the likelihood of shared failure across deployments.

2:08Distributing workloads across multiple zones helps maintain service availability during localized infrastructure disruptions within a single zone. Again, the idea here is to isolate any localized failure. Separating application components across zones reduces the likelihood that a single failure event will impact all workload resources simultaneously. In addition to zone level deployment, regional distribution may also support availability objectives.

2:43First, geographic redundancy. Deploying workloads across multiple geographic regions may improve resiliency against regional service outages or large-scale infrastructure failures. Applications may require failover capabilities between regions to maintain availability in the event of regional disruptions. But we are going to need data replication between regions to support disaster recovery requirements and maintain workload continuity.

3:18Now, one thing we have to consider here is regional deployment may introduce latency tradeoffs between availability and application performance. And we also, of course, have to make sure that we are allowed to do what we're trying to do. Regional placement decisions may be influenced by legal or regulatory requirements related to data storage. So workload placement across failure domains must be aligned with our deployment models.

3:50First, we can do an active-active deployment. Active-active deployments distribute workloads across multiple environments simultaneously to improve availability and support traffic distribution during failure events. We can also do an active-passive deployment. These deployments maintain standby resources that can be activated when primary workloads become unavailable.

4:20And this can generally be done through automation, so it's not something that's going to necessarily require human intervention in order to bring our standby resources online. Other things we have to consider would be load balancing strategies. Load balancing mechanisms distribute traffic across available resources to maintain service continuity and improve workload utilization. And as I sort of already mentioned, we're often going to have automated failover mechanisms.

4:53Here, the failover process redirects traffic to operational resources when primary workloads experience disruption or become unavailable. Now, our different deployment models and considerations here are going to rely on proper fault domain planning. Here, what we're talking about is essentially infrastructure separation. Separating workloads across infrastructure components reduces the likelihood of shared failure impact across application environments.

5:26We also want to provide network path diversity. Multiple network paths may improve connectivity resilience during infrastructure disruptions. We also, whenever possible, want to try to avoid shared resources. Now, for some things, it is going to be required, but we also may be able to provide redundancy to those shared resources. But avoiding reliance on shared infrastructure components may reduce systematic failure risk within the environment.

5:57We also may want to isolate application tiers across failure domains, and this will improve recovery capabilities and reduce downtime. And of course, all of this needs to be planned. Architectural planning may incorporate redundancy across zones or regions to support recovery objectives. So finally, let's take a look at how the availability requirements are going to ultimately influence architectural placement decisions.

6:30So what is the impact on our network architecture? Well, first and foremost, availability requirements may determine how workloads are distributed across zones or regions to maintain service continuity. It's going to affect the connectivity model selection. Network connectivity must support communication between redundant environments across failure domains. And of course, it's also going to affect our disaster recovery topology.

7:01Recovery strategies may influence network segmentation and routing architecture across geographic regions. By analyzing availability requirements and failure domain considerations in the design process, architects can determine how workloads should be distributed across availability zones or geographic regions to maintain service continuity.

0:01So now, let's jump in and take a look at how security requirements influence cloud network architecture decisions before deployment begins. Cloud environments often host workloads with varying levels of sensitivity, requiring isolation between regulated and non-regulated systems. By identifying trust boundaries and inspection requirements early in the design process, architects can implement segmentation strategies that reduce risk exposure while supporting compliant and operational objectives.

0:39So our first consideration is trust boundaries. Trust boundaries represent logical divisions between systems that operate under different security policies or access requirements. Identifying these boundaries early in the design process allows architects to determine how workloads should be segmented within the cloud network to reduce risk exposure. Workloads may contain varying levels of sensitive information such as customer data, financial records, or intellectual property.

1:16These sensitivity levels often influence how resources are grouped and isolated within virtual network segments. Regulatory frameworks such as the aforementioned PCI DSS or HIPAA may require segmentation between regulated and non-regulated systems. Network segmentation may be necessary to enforce these compliance obligations within the cloud environment. Some workloads may even require inspection of network traffic between segments to detect or prevent unauthorized access.

1:55These requirements often influence where security controls such as firewall or inspection gateways are placed within the architecture. We also have network access control policies which may be implemented to restrict communication between workload segments based on least privilege principles. Segmentation strategies are often implemented to enforce these trust boundaries. First we have virtual network segmentation.

2:27Cloud environments often support segmentation through the use of virtual networks or virtual private clouds that isolate workloads from one another. Subnets can also be used to group resources with similar security requirements within a virtual network. Multi-tier applications may separate web application and database components across different network segments to limit unauthorized communication.

2:58It's also quite common to separate different environments. Development, testing, and production workloads may be placed within separate network environments to reduce the risk of cross-environment compromise. And quite commonly we'll have administrative access zones or essentially a dedicated management network. Management systems may be placed within dedicated network zones to restrict administrative access pathways. Segmentation policies may also be driven by regulatory compliance requirements.

3:34Compliance requirements often mandate the separation of regulated workloads from non-regulated systems to reduce exposure to unauthorized access. Segmentation also helps prevent sensitive data from being accessed by systems that do not require it for operational purposes. Another advantage is network segmentation may reduce the scope of compliance audits by limiting the number of systems that process regulated information.

4:07Communication between regulated and non-regulated systems may be restricted through defined routing or firewall policies. Segmentation also will be used to control lateral movement within cloud environments. What we're looking for here is least privilege network access. This limits communication between workloads to only what is necessary for the application to function.

4:38Internal communication or east-west traffic between workloads may be restricted to reduce unauthorized lateral movement. We're also going to implement service-to-service restrictions where microservices may be permitted to communicate only with required application components. Administrative access pathways may be restricted to specific network segments and the purpose of all of this segmentation for the most part is going to be threat containment.

5:11Segmentation may limit the spread of threats between application components. If one component gets compromised, we don't want that to be used to launch attacks against other internal systems. Something else we're going to have to consider in our design is inspection and monitoring requirements. We have to decide where traffic inspection is going to occur in the network. Inspection of network traffic between segments may be required to detect unauthorized communication.

5:45Inspection platforms may be deployed between workload segments to enforce access policies. Monitoring systems may require visibility into communication across network segments and logging platforms may collect telemetry from segmented environments to support incident detection. Ultimately, how do our security requirements impact our network architecture?

6:15First, we have to be concerned with segmentation boundaries. Security requirements may define how workloads are separated across network segments. Inspection platforms may be positioned between trust zones to enforce access policies. Routing strategies must support communication between segmented environments while maintaining isolation. We're also, of course, going to do access control enforcement where network access policies will restrict communication between workloads.

6:52And of course, as we're considering all of this in our design, we have to make sure that we are in compliance with any necessary regulations. By identifying security and segmentation requirements during the design process, cloud architects can implement network architectures that reduce risk exposure while supporting regulatory compliance. Trust boundary identification, lateral movement prevention, and inspection placement collectively influence how workloads are segmented across cloud environments.

0:01Now let's examine how IP address planning influences cloud network architecture decisions before deployment begins. Address allocation plays a critical role in enabling segmentation, supporting hybrid connectivity, and maintaining scalability across cloud environments. Proper address planning helps reduce routing complexity and avoid network conflicts as workloads expand across regions or integrate with on-premise systems.

0:34And keep in mind this is just going to be an introduction to IP address planning in the cloud. We have an entire skill coming up on this a little bit later. But our first consideration is we are usually going to be using RFC 1918 private IP address allocations. RFC 1918 addresses are commonly used within cloud environments to assign IP ranges to virtual networks or virtual private clouds.

1:04These address allocations must be carefully selected to support segmentation and prevent conflicts with existing enterprise networks. Hybrid cloud deployments often require communication between on-prem networks and cloud-hosted workloads. Address planning must account for these integration points to avoid overlapping address space between environments. Different application tiers or environments may require dedicated IP address ranges to support segmentation policies.

1:42Assigning separate CIDR blocks to workload groups helps enforce trust boundaries and routing controls. Cloud deployments that span multiple geographic regions may require unique address allocations for each region. This approach supports scalability and simplifies routing between environments. Address allocation must also account for communication between cloud and enterprise environments.

2:13The risk here is of course going to be overlapping address space. The issue is that many enterprise networks already use private RFC 1918 address space internally, which may overlap with cloud network allocations if we don't plan this carefully. We need to make sure that we don't create any conflicts. Assigning cloud network address ranges that overlap with existing enterprise networks can prevent successful routing between the environments.

2:47If we do end up with address conflicts, this may then require the use of network address translation or NAT or complex routing configurations to enable communication. And even at that, we may have some connectivity limitations. Overlapping address space may restrict workload communication across hybrid deployments. Third-party integrations may also introduce additional address planning requirements.

3:17Regional and environment-specific allocation can help prevent these conflicts. So the first thing is environment-specific CIDR blocks. Allocating separate CIDR blocks for development, testing, sandbox, and production environments may support segmentation and routing control. Assigning unique address ranges to workflows in different geographic regions simplifies routing between those environments.

3:51Subnets can also be used to group workloads based on application tier or sensitivity level within the virtual network. We also have to consider future growth when we're considering our address planning. So we need to account for future workload expansion. Cloud environments may scale over time as new services or application tiers are deployed. New workloads may require additional address space within the network architecture.

4:23Planning for unused address space may support future expansion. And address planning should consider potential changes in application architecture. And finally, we need to consider inter-region connectivity. Connectivity between regions may require sufficient address space to support routing. So let's wrap up once again with the impacts that this is going to have on our network design.

4:53Starting with segmentation boundaries. Address allocation may determine how workloads are grouped within network segments. This is also going to affect our routing architecture. Routing strategies must support communication between allocated address ranges. Hybrid deployments require address planning that supports communication between the environments. Essentially avoiding overlapping address space.

5:23This can also affect our disaster recovery topology with how addresses are going to be handled at the primary versus the fallback or secondary disaster recovery site. And finally, our deployment decisions may actually be influenced by address availability. By analyzing IP address planning inputs early in the cloud network design process, we're able to support scalable deployments across regions and environments while still reducing the risk of address conflicts.

5:59Proper allocation strategies enable segmentation, simplify routing integration, and maintain hybrid connectivity as workloads expand over time.