book

Cloud Networking and Resilience: Designing Scalable, Fault-Tolerant, and Highly-Available Cloud Network Architectures

Name: Cloud Networking and Resilience: Designing Scalable, Fault-Tolerant, and Highly-Available Cloud Network Architectures
Author: Cristian Critelli
ISBN: 9798868824364

by Cristian Critelli

May 2026

Intermediate

730 pages

19h 33m

English

Apress

Read now

Unlock full access

Cloud Networking and Resilience
Introduction
Prerequisites and Recommended BackgroundCompanion Repository
Acknowledgments
Table of Contents
About the Author
About the Technical Reviewer
1. What Is Resilience in the Cloud Era
Section 1.1: Introduction to Cloud Computing and ResilienceWhat Is Resilience?Resilience of the Cloud vs. Resilience in the CloudCategories of Failure for ResilienceDesired Resilient PropertiesPrinciples of Architecting Resilient SystemsReal-World Failure Examples and Lessons LearnedWhat’s Next?Section 1.2: Resilience vs. Availability vs. Disaster RecoveryAvailabilityResilienceDisaster Recovery (DR)Disaster Recovery Strategies in the CloudDisaster Recovery Strategies in the CloudBackup and RestorePilot LightWarm StandbyActive-ActiveOperational and Regulatory ConsiderationsBlended Models and EvolutionKey Differences Resilience vs. Availability vs. Disaster RecoverySection 1.3: Why Network Resilience Matters: From Downtime to Brand DamageThe Technical StakesFrom Uptime to Business ContinuityNetwork Resilience in PracticeRedundant Paths and Transport DiversityFailover Mechanisms and Routing PolicySegmentation and Fault DomainsDistributed Control PlanesDynamic Reconfiguration and Infrastructure as CodeObservability: The Foundation of ResilienceThe Three Pillars of ObservabilityAWS Observability Services for Networking in AWSWhy Observability Enables ResilienceObservability Design PrinciplesObservability Is a LifecycleThe Business CaseSection 1.4: Understanding Resilient Architectures in the CloudResilience in Action: Applying Properties to the ArchitectureA Narrative WalkthroughControl Plane vs. Data Plane: The Hidden Layer of RiskLooking AheadThe Hybrid Angle: Beyond the VPCObservability and ValidationAnatomy of the Hybrid Resilience DesignApplying Resilience PrinciplesFailure Scenarios and MitigationControl Plane Resilience and ObservabilityThe Foundation of Hybrid ResilienceSection 1.5: Common Challenges in Achieving Resilience1. Misalignment Between RPO/RTO Expectations and Operational Realities2. The Complexity of Multi-region and Multi-cloud Designs3. CAP Theorem and Data Integrity Trade-Offs4. Over-Reliance on Manual Recovery5. Lack of End-to-End Observability6. Budget Constraints and Partial Resilience Implementations7. Change Management and Deployment Risk8. Limited Control in Managed Services9. The New Regulatory Mandate: Testing and DORA10. The Missing Discipline: Testing As the Cornerstone of ResilienceWhy Testing MattersTypes of Testing and What They RevealBarriers to TestingHow to Overcome ThemStrategic Example: Simulating Hybrid Link FailureFrom Optional to EssentialWhat's Next?
2. Fundamentals of Cloud Networking and Network Topologies
Section 2.1: Virtualization and Network Functions Virtualization (NFV)The Evolution from Hardware to VirtualizationSection 2.2: Software-Defined Networking (SDN)Defining SDNControl Plane and Data PlaneStatic Stability in the CloudFrom Distribution to CentralizationLayers of SDNCase Study: Google B4 BackboneCase Study: Netflix on AWSCase Study: Financial ServicesThe Future of SDNWhat's Next?Section 2.3: Cloud Network Architectures and Topologies ExamplesFrom On-Premises to Cloud: A Paradigm Shift in TopologiesFault Domains: From Data Centers to Availability ZonesThe WAN ReimaginedDMZs and the Evolution of Centralized Inspection TiersPros and Cons Revisited Through Failure CategoriesCommonly Used Cloud TopologiesSingle VPC/Flat TopologyHub-and-Spoke TopologyMesh TopologyHybrid TopologiesMulti-region TopologiesWhat's Next?
3. DNS Fundamentals
Section 3.1: What Is DNS?Domains, Zones, and DelegationDNS As a Distributed DatabaseDNS As a Control Plane: AWS Route 53 ExampleDNS and Dynamic Cloud WorkloadsDNS in Troubleshooting: “The Internet Is Down”Why DNS Is Foundational for Cloud ResilienceSection 3.2: The DNS Resolution Process in DepthFrom Flat Files to Distributed ResolutionStep One: The Stub ResolverStep Two: The Recursive ResolverStep Three: The Root ServersStep Four: TLD ServersSteps Five and Six: Authoritative ServersCase Study: The 2016 Dyn DDoSCase Study: Cloudflare 2019 OutageCase Study: AWS Route 53 2019 DDoSCaching, TTLs, and Trade-OffsDNS in the CloudTroubleshooting ResolutionSummarySection 3.3: The DNS Data Model—Records and ZonesA Records: IPv4’s Fundamental ConstructAAAA Records: IPv6 in ActionCNAME Records: Aliases and AbstractionMX Records: The Lifeline of EmailNS Records: The Glue of DelegationTXT Records: Flexibility, Authentication, and RiskPTR Records: Reverse DNSSRV Records: Service DiscoveryCAA Records: Controlling Certificate AuthoritiesBringing It TogetherSection 3.4: DNS Hierarchy and Root InfrastructureThe DNS Tree StructureDelegation and GlueThe Root Zone and Root Servers (2026 Perspective)TLD Servers and National OutagesWalking the Hierarchy: Why Again?Failure Mapping with the Resilience Analysis Framework (RAF)Split-Horizon DNSHybrid ResolutionBest Practices for Hierarchical DNS ResilienceWhat's Next?Section 3.5: Recursive vs. Authoritative DNS—Roles and ResponsibilitiesIterative vs. Recursive Queries: Protocol-Level MechanicsRecursive Resolvers: Fault Domains and RisksAuthoritative Servers: Source of Truth and FragilityResilience Trade-Offs and the AWS Resilience Analysis FrameworkAWS Perspective: Route 53 and ResolverHybrid Resolution and Split HorizonWhat's Next?Section 3.6: DNS in the Cloud ContextWhy Resilient DNS Resolution Is the First Success Condition in the CloudHow Thinking Changes in the CloudImplementing Resilient Resolution in AWS: Scope and AssumptionsThe In-VPC Resolver and DHCP Option SetsPrivate Hosted Zones: Centralize Authority or Delegate It—IntentionallyHybrid Resolution with Route 53 Resolver EndpointsFrom AWS to On-PremisesFrom On-Premises to AWSRule Precedence, Scope, and SharingSecurity and Observability at the Resolver LayerRegional Scope, Multi-account Design, and Shared RulesOperational Best Practices for VPC and Hybrid DNSReference Architecture ExamplesSingle-Region, Multi-AZ Application with a Private Entry PointHub-and-Spoke with Centralized DNS and HybridCross-Region Private ResolutionWhy Prefer Local Resolution—And When to ForwardImplementation Notes That the Diagram ImpliesMulti-account Estates Without Endpoint SprawlCoordinating DNS During Disaster Recovery EventsCommon Failure Modes and How to Avoid ThemCommon DNS Misconfigurations and How to Avoid ThemSummaryWhy DNS Deserves a Touch of AutomationKey Takeaways
4. Resilient DNS Architectures and Techniques
Section 4.1: Anycast Routing for DNS High AvailabilityWhy Anycast Is Essential for DNS ResilienceHow Cloud Providers Implement ItBehavior During FailuresDesign Discipline Behind the ScenesPutting It All TogetherWhat’s Next?Section 4.2: Routing Policies for Global Traffic Management and Load DistributionThe Philosophy of DNS-Level RoutingSimple Routing—The Straight PathFailover Routing—The Safety NetWeighted Routing—Controlled DistributionLatency-Based Routing—Performance As a PolicyGeolocation Routing—Serving by GeographyGeoproximity Routing—Steering by Distance and BiasIP-Based Routing—Deterministic ControlMulti-value Answer Routing—Lightweight RedundancyUnderstanding EDNS0 Client Subnet (ECS)—Precision in DNS Decision-MakingThe Origin of EDNS0 and ECSHow Route 53 Uses ECSPrivacy and Adoption LandscapeImplications for ResilienceCloud Provider PerspectivesDesign RecommendationsBest Practices and Operational ConsiderationsWhat’s Next?Section 4.3: DNS Failover Strategies with Amazon Route 53 and Application Recovery Controller (ARC)The Two Planes, Revisited: From Reachability to OrchestrationWorking TogetherPatterns of Regional ResilienceActive–Passive—Predictable and ControlledActive–Active—Continuous Availability Through DistributionCell-Based Resilience—Isolate, Don’t CollapseChoosing the Right PatternDesign TakeawaysRoute 53 Health Checks—The Heartbeat of DNS FailoverAggregating and Acting on ResultsAdvanced Configurations and IntegrationBest Practices for Reliable Health MonitoringExample: Layered Detection and ActionOrchestrating Failover with ARC: Routing Controls, Safety Rules, and Region SwitchRouting Controls—The Data Plane SwitchboardSafety Rules—Guardrails for AutomationRegion Switch—Coordinated Recovery Across RegionsOperating Region Switch EffectivelySection 4.4: Using Multiple DNS Providers for RedundancyWhy Multi-DNS Architectures ExistOperating Modes at a GlanceHow It Works in PracticeZone Synchronization and AutomationTTL Alignment and ConvergenceHealth Checks Across ProvidersMulti-cloud with DNS: Steering Across CloudsOperational ExampleWhen Active–Active Becomes OverkillConsistency, Propagation, and Control Trade-OffsPropagation AsymmetrySOA Serial Tracking and Version ControlResolver Behavior and Cache DivergenceControl-Plane ComplexityActive–Active vs. Active–Passive Multi-DNS DeploymentsBalancing Speed and SafetySecurity, Integrity, and Trust Between DNS ProvidersSection 4.5: DNSSEC for Security and IntegrityHow Route 53 Implements DNSSECOperating DNSSEC at ScaleResilience ConsiderationsMulti-DNS and Multi-signer OperationsSecurity and Governance PracticesCompleting the Chain of TrustSection 4.6: Private DNS and Hybrid Cloud ConsiderationsThe Role of Private DNS in Hybrid ArchitecturesResilience Patterns for Private DNSMulti-region Private DNSHow the Pieces Cooperate Under FailureImplementation Best PracticesA Quick Walk-Through (How a Failure Plays Out)Multi-region and Cross-Account Private DNS ResilienceUnifying Names Without Losing ControlDeploying Regional Resolver EndpointsBuilding the Transport That Keeps It AliveGoverning Change Across AccountsRegional Isolation and RecoveryBringing It All TogetherLesson Learned from Chapter 4Practice: Turning DNS Resilience into Operational Behavior

5. Implementing Resilience Throughout the OSI Model with AWS Examples
Building from the FoundationsThe Physical Reality of the CloudSection 5.1: Layer 1 (Physical): Redundant Circuits and Direct Connect ModelsWhy Direct Connect Belongs in Layer 1Failure Modes Are Physical FirstThe Direct Connect Resiliency Patterns—Read As Physical, Not LogicalDXGW As Blast-Radius Containment, Physically ExpressedCommissioning, Acceptance, and Monitoring—Treat the Glass As ObservableHosted vs. Dedicated—What Changes PhysicallyThe Internet Is Not the Enemy—Use It As Physical InsuranceWhat Not to Do at Layer 1The Layer-1 Contract with the Layers AboveSection 5.2: Layer 2 (Data Link): LAGs and Active/Standby Failover in Hybrid LinksTurning Many into One: Link Aggregation GroupsFlow Distribution and Member Failure BehaviorSegmentation, Frame Integrity, and Link-Layer ProtectionVLANs (IEEE 802.1Q)—Isolation on Shared WiresMTU and Jumbo Frames—Size MattersMACsec—Protecting the Hop at Layer 2Bringing It All TogetherSection 5.3: Layer 3 (Network): BGP Path Selection, AWS TGW, DX + VPN BackupIntroduction to BGP in AWS and Hybrid ArchitecturesHow BGP Thinks: Attributes That Shape ResilienceBGP in the AWS Hybrid EdgeOperational Simplicity As a Resilience StrategyThe Convergence ImperativeDX + VPN Hybrid Failover PatternsClosing Thoughts for Section 5.3Section 5.4: Layer 4 (Transport): Load Balancing Strategies in AWS (NLB) and Session ContinuityFrom Reachability to Reliability: How Transport Protocols Create ResilienceNetwork Load Balancer: Keeping Flows Consistent Through DisruptionGateway Load Balancer in an Inspection VPCThe Inspection VPC PatternFrom Transport Integrity to Application AwarenessSection 5.5: Layer 7 (Application): Rate Limiting, Caching, and Failover Logic (ALB)Connection Semantics at the EdgeShaping Load Before It Hurts: Rate Limiting and Back-PressureBuying Time with Distance: Caching As a Resilience PrimitiveFailover Where Users Notice: ALB Routing, Health, and Steady HandoversPutting the Pieces TogetherOperational Checklist: Making Layer-7 Resilience RealFrom Layers to BoundariesLessons Learned from Chapter 5Looking Ahead—From Layers to Boundaries
6. Building Network Isolation with Cell-Based Architectures, Availability Zones, and Regions
Section 6.1: What Is Cell-Based Architecture?What a Cell Is NotThe Problem Cells SolveCorrelated Failures and the Limits of Layer 7Control-Plane FragilityWhen Multi-region Isn’t EnoughFrom Redundancy to IndependenceCore Design Principles of Cellular ArchitectureRouting and Tenant PlacementRouting in PracticeControl-Plane Design Inside CellsInteraction with AWS Fault DomainsOperational Advantages and Engineering EconomicsSection 6.2: Designing for Fault Domains and Blast Radius ReductionReasoning About Fault Domains and Blast RadiusChoosing Cell Granularity (One-AZ vs. Multi-AZ vs. Multi-region Cells)One-AZ Cells: Maximum Isolation, Minimum Safety NetMulti-AZ Cells: Balancing Independence and DurabilityMulti-region Cells: Continuity at Planetary ScaleDesigning Blast-Radius Containment StrategiesSection 6.3: Traffic Isolation and Fault Domain SeparationDNS as the Routing Brain, Not the TeacherEdge Entry with Anycast: When to Use AWS Global AcceleratorIn-Region Traffic Isolation and Ingress BoundariesIn-Cell Load Balancing and Resilient Path SelectionSection 6.4: Multi-AZ and Multi-region Architectures in AWSAvailability Zones as the Physical Perimeter of ResilienceService Scope in Practice: Global, Regional, and ZonalFundamental #1—Understanding the RequirementsFundamental #2—Understanding the DataFundamental #3—Understanding the DependenciesFundamental #4—Operational ReadinessPatterns on the Wire: From Multi-region to Multi-AZMulti-AZ Within a RegionMulti-region ResilienceSection 6.5: Active-Active vs. Active-Passive on Multi-AZ or Multi-region: When and How to ChooseChoosing the Right Scale: Multi-AZ or Multi-regionUnderstanding Operational Stances: From Active-Passive to Active-ActiveDecision Framework: Requirements ➤ Data ➤ Network ➤ OperationsStep 1—Start with RequirementsStep 2—Shape the Data ModelStep 3—Design the Network to Match the DataStep 4—Operationalize the StanceBringing It TogetherActive-Passive Done RightKeeping the Network WarmKeeping the Data CurrentKeeping the Control Plane SafeWhen Promotion HappensTrade-Offs and EvolutionActive-Active: Resilience in MotionNetworking Foundations of Active-Active1. The Global Entry Layer—Directing the World2. The Regional Ingress Layer—Owning Traffic Locally3. The Inter-Region Backbone—Synchronizing Without Sharing FateData Consistency and the CAP RealityWrite-Local, Read-Local: The Practical DefaultWhen Strong Consistency MattersDesigning for Predictable DivergenceReading and Writing the Right WayRouting Patterns for Active-ActiveFrom “policy” to “behavior”DNS Is Fast—But Not Instantaneous (and That’s OK)Health Models Must Prove the Path You Care AboutAffinity and Stickiness: Who Holds the Session?Private Clients and Split-HorizonWhy Global Accelerator Plus DNS Is the Steady ComboARC for Guardrails, Not GuessesPutting It TogetherFailure Scenarios and Blast-Radius BehaviorHow a Failure Unfolds—On PurposeWhy It Stays ContainedAddressing Hidden CouplingsThe Return to Steady StateOperational Discipline and Cost RealitiesLessons Learned from Chapter 6
7. Traffic Engineering for Cloud Resilience and Performance
Section 7.1: The Cloud–Hybrid Reality: Why Traffic Engineering MattersWhy “Hybrid” Is the Center of Gravity (Now)The Stakes: Outages, Cost, and Customer TrustWhat Leading Organizations Are Actually DoingPain and Challenges You Must Design ForHow This Chapter Addresses ItSection 7.2: Building the Foundation: Hybrid Connectivity and Routing BasicsBuilding Blocks: VPNs, Direct Connect, Exchanges, and Edge LinksInternet IPsec VPN TunnelsDedicated Private Interconnects (AWS Direct Connect and Others)Cloud Exchange FabricsSD-WAN OverlaysEdge Links (Including Private 5G)Understanding Failure PatternsRegulatory Constraints on RoutingVolume Demands Control: Policy and Telemetry over GuessworkRoute and Scale Guardrails (Key Limits and Considerations)Traffic Engineering ConsiderationsHow Data Travels in a Hybrid Network: The JourneyInside AWS: Transit Gateway and VPC Routing DetailsControl Planes: Who Tells the Packets Where to Go?Hybrid Connectivity Options: VPN and Direct ConnectSite-to-Site VPN: The Universal On-RampAccelerated VPN: Squeezing Performance from the InternetOperational BehaviorPerformance CharacteristicsWhen to Use WhichAWS Direct Connect: Determinism by DesignVPN vs. Direct Connect—When to Use Which?Section 7.3: Engineering Traffic Paths with BGPUsing BGP Attributes to Express Routing IntentHow AWS’s Own Infrastructure Handles Routing ManipulationsApplying BGP Policy to Real-World Hybrid DesignsFrom Concept to ConfigurationInfluencing Return PathsThe Role of the Longest PrefixWhen VPN Joins the MixA View from AboveWhat About Resilient Public Virtual Interface Design?A Note on Security PosturePattern 1—Prefer Direct Connect over the Internet Using LPMPattern 2—Regional Primary, Global Backup Using Scope CommunitiesPattern 3—High and Maximum Resiliency for Public VIFsBridging Toward ResilienceSection 7.4: Hybrid Connectivity Resilience Models—High vs. Maximum Resilience, VPN as BackupHigh vs. Maximum Resilience with AWS Direct ConnectHigh Resilience: Multi-site Non-redundant TopologyMaximum Resilience: Multi-site Redundant TopologyVPN as a Backup for Direct ConnectDesign Considerations and Best PracticesSection 7.5: Measuring Success: Performance and Resilience Tuning AutomationKey Metrics for Network Resilience and PerformanceResilience Tuning and Continuous OptimizationMeasuring What Matters: Resilience Tuning Automation On-Premises RoutersPattern 1—Outbound (Egress) Steering by Measured PerformancePattern 2—Inbound (Ingress) Steering by Measured PerformanceGuardrails That Keep Tuning StableWhere SD-WAN FitsValidation: Show, Don’t AssumeWhat This Gives UsCapacity Planning and Headroom As a Resilience PracticeObservability and Feedback Loops for Traffic-Engineering ResilienceBridging to Multi-cloud Traffic ManagementSection 7.6: Multi-cloud Traffic ManagementPrivate Interconnect and Exchange Fabric SolutionsTraffic Engineering Across Cloud BackbonesControl-Plane Federation and Policy ChallengesFailover Routing and Resilience PatternsCoordinating Route 53 and Traffic ManagerAutomating and Testing Multi-Cloud FailoverLessons from the EdgeMTU, Route Propagation, and Asymmetric FlowsOperational Best Practices: Observability and TestingLessons Learned from Chapter 7Looking Ahead—From Federation to Operation and Disaster Recovery
8. Operational Resilience and Disaster Recovery
Section 8.1: Monitoring and Observability for Cloud Networking and ResilienceMonitoring: Watching for SymptomsWhy the Difference Matters for ResilienceObservability Applied to NetworkingNetwork Observability Instruments in AWSDirect Connect ObservabilitySite-to-Site VPN ObservabilityTransit Gateway ObservabilityFlow Logs as a Data-Plane SignalRoute 53 Behavior in FailoverInternet Monitor and External Path HealthElastic Load Balancing ObservabilityNetwork Manager—Infrastructure PerformanceControl Plane Observability (CloudTrail + EventBridge)Athena and Search-Driven Log AnalysisEvent-Driven Automation and AlertingLet’s summarize what we learned so far...Best Practices and the Bridge to Chaos EngineeringDesigning Signals That MatterDesigning Alarms That Support ResilienceDashboards That Reflect How Systems FailIntegrating Observability with RPO, RTO, and HA ObjectivesBuilding a Feedback LoopSection 8.2: Chaos Engineering (Resilience Testing): Validating Resilience Before Disaster HitsFoundations of Resilience TestingTypes of Resilience TestsLearning Tests—Discovering the UnknownRehearsals—Training People and Validating ProcessExperiments—Hypothesis-Driven Fault InjectionValidation Tests—Proving That Resilience Guarantees HoldGame Days—Realistic, End-to-End ExercisesContinuous Fault Injection—Making Resilience Part of Daily LifeDesigning and Running ExperimentsImplementing Resilience Testing on AWSLearning from ExperimentsBuilding a Continuous Resilience Testing PracticeBridging Toward Disaster RecoverySection 8.3: Designing for Disaster RecoveryFoundations of Disaster RecoveryAWS Disaster Recovery StrategiesBackup and RestorePilot LightWarm StandbyMulti-region Active/ActiveAWS Tools That Enable Disaster RecoveryAWS Backup: Foundation for Backup and RestoreAWS Elastic Disaster Recovery (DRS): Acceleration for Pilot Light and Warm StandbyCross-Region Data ReplicationInfrastructure-As-Code and Configuration Drift ControlRouting and Redirection MechanismsNetworking for Disaster RecoveryOperating a Disaster Recovery PlanTesting Disaster RecoveryThe Economics and Governance of Disaster RecoveryLessons LearnedTo the Final Chapter
9. The Next Decade of Cloud Resilience
Section 9.1: From Observability to Prediction: AIOps for Network ResilienceThe Next Decade of Cloud ResilienceSection 9.1: From Observability to Prediction: AIOps for Network ResilienceThe Data Substrate of AIOpsFrom Raw Signals to Interpretable BehaviorTime As the Missing DimensionResilience Boundaries As the Skeleton of the DataWhy This Foundation MattersHow Predictive Models Learn Behaviors a Human Could Never SeeUnsupervised Learning: Discovering Normality in a System That Never Sits StillSupervised Learning: Giving Meaning to DeviationForecasting Models: Predicting the Moment of Boundary ViolationWhy All Three Models Matter—TogetherHow Correlation Engines Identify the Root of Soft Network FailuresForecasting Resilience Drift: Predicting When the Network Will Cross Its ThresholdsClosing the Loop: Turning Predictions into Safe, Automated ActionFrom Prediction to Prevention: How AIOps Reshapes Incident Response ModelsA Reference Architecture for Predictive Network Resilience on AWS1. Network Telemetry and Logs (Left Column)2. Data Lake and ML Analytics (Center Column)3. Operational Loop and Automation (Right Column)Section 9.2: Beyond BGP: Path-Aware and Quantum NetworksThe Limits of Classical Networking (and Why They Matter for Resilience)Quantum Key Distribution: The First Practical Step Toward Quantum NetworkingPath-Aware Networking: Rethinking Routing in a Post-BGP EraQuantum Networking: Entanglement, Quantum Repeaters, and the Future of ConnectivitySection 9.3: Final Thoughts: Building for the Inevitable OutageThe Practical Roadmap: What You Should Do on Monday MorningThe Continuous Resilience LoopFinal Thoughts: Building for the Inevitable Outage
Epilogue
Epilogas
Epilogo
Index

Content preview from Cloud Networking and Resilience: Designing Scalable, Fault-Tolerant, and Highly-Available Cloud Network Architectures

About the Technical Reviewer

Venkat Kondepati

is a seasoned technology leader with over two decades of experience driving digital transformation and cloud architecture initiatives across global enterprises. As former Director of Software Engineering at S&P Global, he led multi-million dollar modernization projects, including the migration of 60+ applications to AWS cloud infrastructure and the development of AI-driven data platforms that delivered 70% cost savings. Currently serving as Manager of Data Architecture and Engineering at Ascentt, Venkat specializes in cloud-native architectures, generative AI implementation, and building high-performance ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9798868824364

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Cloud Networking and Resilience: Designing Scalable, Fault-Tolerant, and Highly-Available Cloud Network Architectures

by Cristian Critelli

About the Technical Reviewer

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.