Analyze Requirements for Cloud Network Design

0:01In this skill, we examine how business and technical requirements influence cloud network design decisions.

0:10Understanding workload communication patterns, performance expectations, and security needs ensures the resulting architecture is scalable, resilient, and aligned with organizational objectives.

0:24In 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.

0:55Business requirements represent organizational objectives that must be supported by the network architecture.

1:04These 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.

1:33Regulatory frameworks may require isolation between sensitive and non-sensitive systems.

1:41Network segmentation may be required to enforce trust boundaries and prevent unauthorized access to regulated workloads.

1:52And of course, there's always budget limitations.

1:55Financial constraints may influence the choice between private connectivity services and VPN-based integration models when designing hybrid connectivity solutions.

2:09Legal 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.

2:30So the first thing we want to discuss is recovery time objective, or RTO.

2:36This defines the maximum acceptable duration of service disruption following a failure or outage.

2:45Next, we have the recovery point objective, or the RPO.

2:51This 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.

3:04The 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.

3:16That 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.

3:26So 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.

3:35Next, we also have SLAs, or service level agreements.

3:40These define minimum availability requirements that cloud architectures must meet through redundancy and failover mechanisms.

3:49Another way to say this is simply uptime.

3:53Out of a certain amount of time, usually measured per year, what is our uptime?

4:00And 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.

4:21And just to save you a little math, that comes out to about five minutes per year that we're allowed to have unscheduled downtime.

4:31Something 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.

4:46Distributing workloads across fault domains, such as availability zones, helps prevent localized infrastructure failures from impacting the entire application environment.

4:59If you're not really familiar with the term fault domain, we will be discussing this more throughout the rest of the course.

5:06But 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.

5:25So needless to say, we want our fault domains to be as small as possible.

5:31Now 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.

5:41In 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.

5:55For example, if we take credit cards, we have the Payment Card Industry Data Security Standard or PCI DSS.

6:05This requires the protection of cardholder data and often mandates network segmentation to isolate payment processing systems.

6:14Here 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,

6:29which may include again isolating health care data systems within dedicated network segments.

6:37In other parts of the world, we have the GDPR or the General Data Protection Regulation.

6:44This can restrict how personal data is stored, processed, or transferred across geographical boundaries.

6:52Oftentimes, there'll be data classification requirements.

6:56Organizational data classification policies often determine how workloads are grouped and segmented based on sensitivity.

7:05Segmentation requirements may be implemented to prevent unauthorized access or lateral movement between regulated and non-regulated workloads.

7:17Now, 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.

7:33So one of the big considerations here is going to be private connectivity cost considerations.

7:38In other words, having a dedicated circuit connecting two of your remote locations.

7:44This is going to be quite costly.

7:47Private connectivity services such as dedicated cloud interconnects may provide performance benefits and privacy benefits,

7:55but again, this is going to dramatically increase operational costs.

8:00Alternatively, we may choose to do a VPN deployment.

8:05Site-to-site VPN connections may provide cost-effective hybrid connectivity compared to private connectivity solutions.

8:14In most cases, our VPNs are simply going to use the internet access that we already have and we're already paying for.

8:22Something else to keep an eye on when it comes to budget and cost would be regional resource pricing.

8:28Cloud 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.

8:41Inner region and outbound traffic may incur additional costs that impact centralized inspection or replication strategies.

8:51We also have to consider operational complexity tradeoffs.

8:55Highly redundant architectures may improve availability, but they can also increase management overhead and operational expenses.

9:04In 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.

9:19The first part of this may come down to geographic data storage mandates.

9:24Some regulations require that data remain within national or regional boundaries.

9:31Data sovereignty laws may also restrict how data can be stored or transmitted across international borders.

9:39We also want to be concerned with workload placement.

9:43Applications may need to be deployed within specific cloud regions to comply with residency mandates.

9:51There can also be cross-border data transfer limitations.

9:55Replication or backup strategies may be limited by legal restrictions on the data transfers.

10:02And of course, we always have to watch out for different jurisdictions.

10:07They can impose varying legal obligations that must be supported by the network architecture.

10:15These business requirements ultimately influence architectural design outcomes.

10:21So first, it's going to affect our topology selection.

10:25Requirement analysis may influence whether hub-and-spoke or transit networking models are going to be deployed.

10:33It's also going to influence our connectivity model.

10:37Hybrid connectivity options may include VPN or private interconnect solutions.

10:43We also need to be concerned with segmentation boundaries.

10:47Compliance obligations may determine subnet or virtual network segmentation.

10:53We also have to be concerned with disaster recovery placement.

10:57Availability requirements influence regional recovery strategies.

11:01And again, this may also come down to geographical location of where we're actually allowed to place a high-availability site.

11:10And of course, we also need to be concerned with where we're going to place the workloads.

11:15They 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,

11:29architects can align technical architecture decisions with organizational objectives.

11:36Availability 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.

0:10These requirements describe how workloads must communicate within and across environments,

0:17including hybrid connectivity to on-premise systems, latency-sensitive application components,

0:25and centralized shared services such as authentication or monitoring platforms.

0:32Hybrid cloud deployments often require connectivity between on-premises or on-prem data centers

0:41and cloud-hosted workloads using VPN or private connectivity services.

0:48Enterprise applications may rely on on-prem databases or identity providers that must communicate with cloud workloads.

1:00Some 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.

1:22And we also have to consider centralized services such as authentication, logging, or monitoring platforms,

1:31which may require network access across multiple environments.

1:36These technical requirements directly influence how workloads communicate across environments.

1:43So first, let's consider site-to-site VPN connectivity.

1:47Site-to-site VPN connections provide encrypted connectivity between on-prem networks and cloud virtual networks.

1:57We also may need to support client-based remote access.

2:03Remote 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.

2:18These services, such as dedicated interconnects, provide low-latency communication between on-prem environments and the cloud.

2:29We also, however, are going to need reachability regardless of what type of connectivity we use,

2:36so we also probably want some form of dynamic routing integration.

2:41Routing protocols can be used to exchange network reachability information between hybrid environments.

2:49And of course, we always want to consider redundancy.

2:53Multiple connectivity paths may be required to support high availability and fault tolerance.

3:01Application communication patterns may also introduce latency and routing concerns.

3:09So again, we have to consider our regional deployment strategy.

3:14Deploying workloads within specific regions can reduce communication delays between services and users.

3:23This is directly related to our availability zone or AZ proximity.

3:29Placing application tiers within the same availability zone may reduce latency between the different components.

3:39And of course, we also need to be concerned about where the users are and what the user access patterns are.

3:45Workload placement may be influenced by geographic user distribution.

3:51Of course, another concern is inter-service communication.

3:55Multi-tiered applications frequently exchange data and may benefit greatly from close network placement.

4:04And the application itself may be performance sensitive.

4:09They may require low latency network paths.

4:13One example from a network administrator's perspective is connecting in to manage something through the command line,

4:20using something, for example, like SSH.

4:23When you're having an interactive session and you're typing back and forth on a console,

4:28or even something like RDP, Remote Desktop Protocol, when you're remote accessing a server to do management and administration,

4:36think 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,

4:47and all of a sudden the cursor jumps 14 spaces further than you wanted because you were having too much latency.

4:54Or, again, in Remote Desktop, you click on something, you don't think you clicked on it, so you click on it again,

4:59and all of a sudden you're in rename mode instead of opening the item.

5:02So, again, it can be very, very frustrating if you have performance-based applications,

5:08which, 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,

5:17but keep in mind that these can introduce additional routing and failover considerations.

5:23Multi-regional deployments are, however, going to give us global application availability.

5:29Deploying applications across multiple regions can improve service continuity during outages.

5:37Applications 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.

5:54Another big consideration is going to be replication.

5:58Data replication between regions may introduce latency or bandwidth requirements.

6:04But, again, if our service or application is available in multiple regions,

6:08having that data synchronization or replication may be required.

6:14And keep in mind that depending on the situation,

6:17inter-region communication may actually require dedicated routing paths.

6:23And keep in mind our shared services must also be accessible across application environments.

6:30So, things like, for example, authentication services.

6:34Identity providers may need network connectivity to cloud-hosted workloads.

6:40Things like logging platforms.

6:43Centralized logging systems often require access across application environments.

6:49And right along with logging would be real-time monitoring systems.

6:53Monitoring platforms may collect telemetry from multiple network segments in multiple different regions.

7:00Also, things like configuration management tools.

7:04Automation platforms may manage workloads across environments.

7:09And we also could be doing it manually as well.

7:12And we're also probably going to want some form of centralized update services.

7:17Patch management systems may require connectivity, again, across various deployments.

7:23So, these technical requirements are going to influence the architectural connectivity decisions.

7:30The first thing it's going to influence would be the connectivity model selection.

7:35Hybrid deployments, we have to decide if we want to use VPN, which are generally a little less expensive,

7:43or private interconnect solutions.

7:46Generally a better connection, but also more costly.

7:50We have to choose what our routing architecture is going to be.

7:54Routing strategies must support communication between the environments.

7:59We're also going to need to consider our network segmentation placement.

8:03Shared services may require access across segmented environments.

8:08Of course, we also need to consider our failover strategy.

8:13Connectivity design must support service continuity during outages.

8:18And we have to make sure that we always have access to our central services.

8:23Workloads must maintain connectivity to the required services.

8:29So, by identifying technical requirements early in the cloud network design process,

8:35architects can ensure that workload communication, hybrid connectivity,

8:40and shared service access are supported by the network architecture.

8:46These inputs influence connectivity models, routing strategies, and failover mechanisms

8:52that maintain application performance and availability.

0:01Next, let's examine how workload communication patterns influence cloud network architecture decisions.

0:11Applications deployed in cloud environments often consist of multiple interconnected components that must exchange data across network boundaries.

0:22Understanding 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.

0:50Each of these tiers must exchange information to process user requests and deliver application functionality.

0:59These 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.

1:17This may include remote administrative sessions, automation tools, or configuration management platforms that interact with workload resources.

1:29These communication pathways often require elevated privileges and should be carefully controlled within the network design.

1:38Next up for consideration would be monitoring platforms.

1:41These often collect telemetry and performance data from application components and infrastructure resources.

1:50This communication typically spans multiple network segments and may require centralized access to workloads across environments.

1:59Something else we may need to consider is external service integrations.

2:03Cloud-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.

2:23So let's take a look at how we can categorize some of this workload communication based on traffic direction within the cloud network.

2:31Let's begin by talking about what we refer to as north-south traffic.

2:37This is going to be client-to-application access.

2:43North-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.

3:01This could also, however, be an external API.

3:05Applications may exchange data with external platforms through API integrations.

3:12These communication paths may require secure routing and inspection within the network architecture.

3:19Public 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.

3:43This is generally considered east-west traffic.

3:46This is going to include things like inter-tier communication.

3:51Multi-tier applications require internal communication between web application and database components.

4:01These internal communication paths must be supported within the network architecture.

4:07We can also have service-to-service interaction.

4:10Cloud-native applications may consist of distributed services that exchange data across internal network segments.

4:19These service interactions often require secure routing and segmentation.

4:25This would also include database access requests.

4:29Application components frequently communicate with back-end databases to retrieve or store information.

4:36These communication pathways must be carefully controlled to prevent unauthorized access.

4:44And we can have internal API calls as well.

4:48Microservices architectures often rely on internal APIs to exchange data between services.

4:56These communication flows typically occur within private network segments.

5:01And containerized workloads may communicate across internal service boundaries.

5:07These communication patterns may influence segmentation requirements and routing policies.

5:14Administrative access introduces privileged communication paths into the cloud network.

5:21For example, remote administrative access.

5:25Administrators may require secure network access to manage workloads or infrastructure components within the cloud environment.

5:34We may also be using configuration management systems.

5:38Automation platforms may configure workloads across environments by interacting with cloud-hosted resources through network pathways.

5:48In addition, we may have patch management services.

5:51Update services may require connectivity to workload segments to apply security updates or system patches.

5:59And of course, there's also identity provider communication.

6:04Applications may authenticate users through centralized ID platforms,

6:10requiring network communication between workloads and identity services.

6:14In addition to management and control traffic, we also need to be concerned with monitoring and telemetry traffic.

6:22For example, things like logging platforms.

6:26Centralized logging systems often collect application and infrastructure logs from multiple workload segments across the network.

6:35Same thing with performance monitoring tools.

6:38Monitoring platforms may measure system performance metrics, such as resource utilization or response times.

6:45Another incredibly important component would be security event collectors.

6:50Security 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.

7:05And then we have, of course, telemetry platforms, which gather application performance information to support operational analysis.

7:14And oftentimes when that analysis doesn't go as planned, we're also going to want alerting services.

7:21Monitoring systems generate alerts based on workload conditions or performance thresholds.

7:27So 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.

7:38Workload communication paths may require network segmentation to isolate sensitive services from other application components.

7:48We also have to be concerned with trust boundary placement.

7:52Architects must define trust zones between application components based on communication requirements.

7:59And 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.

8:15We may also have inspection requirements.

8:19Traffic inspection may be required between workload segments to detect or prevent malicious activity.

8:26And of course, connectivity paths must support required workload interactions across application environments.

8:35By understanding workload communication patterns within cloud environments,

8:41architects can design network architectures that support secure and effective interaction between application components,

8:49identifying 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.

0:11Cloud 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.

0:39So the first consideration, of course, is going to be our high availability objectives.

0:45These define how consistently an application must remain accessible to users over time.

0:52These 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.

1:16So these are all things that need to be considered when we're talking about availability within our design.

1:24Cloud environments provide multiple deployment options to support these availability targets.

1:31First are availability zones.

1:34These are independent infrastructure locations.

1:38Availability zones are physically separate data center locations within a cloud region that are designed to operate independently of one another.

1:49They're going to have redundant power and redundant networking.

1:54Each 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.

2:19Again, the idea here is to isolate any localized failure.

2:24Separating application components across zones reduces the likelihood that a single failure event will impact all workload resources simultaneously.

2:35In addition to zone level deployment, regional distribution may also support availability objectives.

2:43First, geographic redundancy.

2:45Deploying workloads across multiple geographic regions may improve resiliency against regional service outages or large-scale infrastructure failures.

2:57Applications may require failover capabilities between regions to maintain availability in the event of regional disruptions.

3:07But 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.

3:29And we also, of course, have to make sure that we are allowed to do what we're trying to do.

3:34Regional placement decisions may be influenced by legal or regulatory requirements related to data storage.

3:43So workload placement across failure domains must be aligned with our deployment models.

3:50First, we can do an active-active deployment.

3:54Active-active deployments distribute workloads across multiple environments simultaneously to improve availability and support traffic distribution during failure events.

4:08We can also do an active-passive deployment.

4:12These 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.

4:32Other things we have to consider would be load balancing strategies.

4:37Load balancing mechanisms distribute traffic across available resources to maintain service continuity and improve workload utilization.

4:46And 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.

5:03Now, our different deployment models and considerations here are going to rely on proper fault domain planning.

5:10Here, what we're talking about is essentially infrastructure separation.

5:16Separating workloads across infrastructure components reduces the likelihood of shared failure impact across application environments.

5:26We also want to provide network path diversity.

5:30Multiple network paths may improve connectivity resilience during infrastructure disruptions.

5:36We also, whenever possible, want to try to avoid shared resources.

5:42Now, for some things, it is going to be required, but we also may be able to provide redundancy to those shared resources.

5:49But 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.

6:09And of course, all of this needs to be planned.

6:13Architectural planning may incorporate redundancy across zones or regions to support recovery objectives.

6:21So 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?

6:33Well, first and foremost, availability requirements may determine how workloads are distributed across zones or regions to maintain service continuity.

6:44It's going to affect the connectivity model selection.

6:48Network connectivity must support communication between redundant environments across failure domains.

6:56And 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.

7:08By 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.

0:12Cloud environments often host workloads with varying levels of sensitivity, requiring isolation between regulated and non-regulated systems.

0:23By 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.

0:44Trust boundaries represent logical divisions between systems that operate under different security policies or access requirements.

0:53Identifying these boundaries early in the design process allows architects to determine how workloads should be segmented within the cloud network to reduce risk exposure.

1:05Workloads 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.

1:25Regulatory frameworks such as the aforementioned PCI DSS or HIPAA may require segmentation between regulated and non-regulated systems.

1:37Network segmentation may be necessary to enforce these compliance obligations within the cloud environment.

1:45Some 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.

2:05We also have network access control policies which may be implemented to restrict communication between workload segments based on least privilege principles.

2:17Segmentation strategies are often implemented to enforce these trust boundaries.

2:24First 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.

2:37Subnets can also be used to group resources with similar security requirements within a virtual network.

2:47Multi-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.

3:03Development, testing, and production workloads may be placed within separate network environments to reduce the risk of cross-environment compromise.

3:13And quite commonly we'll have administrative access zones or essentially a dedicated management network.

3:20Management systems may be placed within dedicated network zones to restrict administrative access pathways.

3:27Segmentation 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.

3:45Segmentation also helps prevent sensitive data from being accessed by systems that do not require it for operational purposes.

3:55Another 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.

4:17Segmentation also will be used to control lateral movement within cloud environments.

4:24What we're looking for here is least privilege network access.

4:29This 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.

4:48We're also going to implement service-to-service restrictions where microservices may be permitted to communicate only with required application components.

4:58Administrative 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.

5:17If one component gets compromised, we don't want that to be used to launch attacks against other internal systems.

5:26Something else we're going to have to consider in our design is inspection and monitoring requirements.

5:33We have to decide where traffic inspection is going to occur in the network.

5:38Inspection 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.

5:53Monitoring systems may require visibility into communication across network segments and logging platforms may collect telemetry from segmented environments to support incident detection.

6:09Ultimately, how do our security requirements impact our network architecture?

6:15First, we have to be concerned with segmentation boundaries.

6:20Security requirements may define how workloads are separated across network segments.

6:26Inspection platforms may be positioned between trust zones to enforce access policies.

6:34Routing strategies must support communication between segmented environments while maintaining isolation.

6:43We'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.

7:02By identifying security and segmentation requirements during the design process,

7:07cloud architects can implement network architectures that reduce risk exposure while supporting regulatory compliance.

7:16Trust 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.

0:11Address allocation plays a critical role in enabling segmentation, supporting hybrid connectivity, and maintaining scalability across cloud environments.

0:22Proper 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.

0:40We have an entire skill coming up on this a little bit later.

0:44But our first consideration is we are usually going to be using RFC 1918 private IP address allocations.

0:54RFC 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.

1:15Hybrid cloud deployments often require communication between on-prem networks and cloud-hosted workloads.

1:23Address planning must account for these integration points to avoid overlapping address space between environments.

1:32Different 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.

1:51Cloud deployments that span multiple geographic regions may require unique address allocations for each region.

2:00This approach supports scalability and simplifies routing between environments.

2:06Address allocation must also account for communication between cloud and enterprise environments.

2:13The risk here is of course going to be overlapping address space.

2:19The issue is that many enterprise networks already use private RFC 1918 address space internally,

2:28which may overlap with cloud network allocations if we don't plan this carefully.

2:34We need to make sure that we don't create any conflicts.

2:38Assigning 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

2:55or complex routing configurations to enable communication.

3:00And even at that, we may have some connectivity limitations.

3:04Overlapping address space may restrict workload communication across hybrid deployments.

3:11Third-party integrations may also introduce additional address planning requirements.

3:17Regional and environment-specific allocation can help prevent these conflicts.

3:24So the first thing is environment-specific CIDR blocks.

3:30Allocating separate CIDR blocks for development, testing, sandbox, and production environments may support segmentation and routing control.

3:41Assigning 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.

4:00We also have to consider future growth when we're considering our address planning.

4:06So we need to account for future workload expansion.

4:10Cloud environments may scale over time as new services or application tiers are deployed.

4:17New workloads may require additional address space within the network architecture.

4:23Planning for unused address space may support future expansion.

4:29And address planning should consider potential changes in application architecture.

4:36And finally, we need to consider inter-region connectivity.

4:40Connectivity between regions may require sufficient address space to support routing.

4:46So let's wrap up once again with the impacts that this is going to have on our network design.

4:53Starting with segmentation boundaries.

4:56Address allocation may determine how workloads are grouped within network segments.

5:03This is also going to affect our routing architecture.

5:07Routing strategies must support communication between allocated address ranges.

5:12Hybrid deployments require address planning that supports communication between the environments.

5:19Essentially 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.

5:35And finally, our deployment decisions may actually be influenced by address availability.

5:44By analyzing IP address planning inputs early in the cloud network design process,

5:50we'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.