Skip to main content
AzureNetworkingadvanced

Azure Networking Deep Dive

Advanced networking with Private Link, Application Gateway, and ExpressRoute patterns.

CloudToolStack Team30 min readPublished Feb 22, 2026

Prerequisites

Azure Networking Deep Dive

Azure networking extends far beyond basic VNets and subnets. This advanced guide covers the full networking stack: load balancers, application gateways, Azure Front Door, traffic routing, hybrid connectivity with VPN and ExpressRoute, Azure Firewall, Private Link, DNS architecture, and network monitoring. Understanding how these services interact is essential for designing production-grade architectures that are secure, performant, and resilient.

Where the VNet Architecture guide covers foundational network design, this guide focuses on the services and patterns that run on top of that foundation. We will explore how to route traffic globally, inspect it for threats, connect to on-premises datacenters, and troubleshoot connectivity issues when things go wrong.

Start with VNet fundamentals: IP planning, hub-spoke, subnets, and peering

Load Balancing Options

Azure offers four primary load balancing services. Choosing the right one (or combination) depends on whether traffic is HTTP or non-HTTP, global or regional, and what features you need like WAF, SSL offload, or URL-based routing.

ServiceLayerScopeProtocolKey FeaturesBest For
Azure Front DoorL7GlobalHTTP/HTTPSCDN, WAF, SSL offload, caching, anycastGlobal web apps, APIs, static sites
Traffic ManagerDNSGlobalAnyDNS-based routing, health checksMulti-region failover for any protocol
Application GatewayL7RegionalHTTP/HTTPSWAF, URL routing, SSL termination, rewritesRegional web apps, path-based routing
Azure Load BalancerL4RegionalTCP/UDPHA ports, floating IP, outbound rulesNon-HTTP workloads, internal services

Combining Load Balancers

Production architectures often stack load balancers for defense in depth. A common pattern: Azure Front Door for global L7 routing, CDN caching, and WAF protection at the edge, forwarding to Application Gateway per region for path-based routing and additional WAF rules, which distributes traffic to backend pools (App Service, VMs, or AKS). For non-HTTP services (databases, message queues, custom TCP protocols), use Azure Load Balancer internally.

Decision Framework for Load Balancing

Load Balancer Selection Decision Tree
Is the traffic HTTP/HTTPS?
  YES -> Do you need global distribution?
    YES -> Azure Front Door (Premium for WAF + Private Link)
    NO  -> Application Gateway v2 (with WAF if needed)
  NO  -> Do you need global distribution?
    YES -> Traffic Manager (DNS-based, works with any protocol)
    NO  -> Azure Load Balancer
           Standard SKU: cross-zone, HA ports
           Internal: for private backend services
           Public: for internet-facing non-HTTP

Common combinations:
  Web app:        Front Door -> App Gateway -> App Service
  API + backend:  Front Door -> Load Balancer (internal) -> AKS
  Multi-region:   Front Door -> App Service (per region)
  Non-HTTP:       Traffic Manager -> Load Balancer (per region)

Azure Front Door and WAF

Azure Front Door Premium is the recommended entry point for global web applications. It combines global load balancing, SSL termination, HTTP/2 and HTTP/3 support, caching, URL-based routing, and Web Application Firewall (WAF) in a single service deployed at Microsoft's edge network with over 200 Points of Presence worldwide.

Front Door Tiers

FeatureStandardPremium
Global load balancingYesYes
SSL terminationYesYes
Caching / CDNYesYes
Custom WAF rulesYesYes
Managed WAF rule setsYes (DRS)Yes (DRS + Bot Manager)
Private Link originsNoYes
Bot protectionNoYes
DDoS protectionBasicEnhanced
front-door.bicep: Front Door Premium with WAF
resource frontDoorProfile 'Microsoft.Cdn/profiles@2023-05-01' = {
  name: 'myapp-fd'
  location: 'global'
  sku: {
    name: 'Premium_AzureFrontDoor'
  }
}

resource endpoint 'Microsoft.Cdn/profiles/afdEndpoints@2023-05-01' = {
  parent: frontDoorProfile
  name: 'myapp-endpoint'
  location: 'global'
  properties: {
    enabledState: 'Enabled'
  }
}

resource originGroup 'Microsoft.Cdn/profiles/originGroups@2023-05-01' = {
  parent: frontDoorProfile
  name: 'backend-origins'
  properties: {
    loadBalancingSettings: {
      sampleSize: 4
      successfulSamplesRequired: 3
      additionalLatencyInMilliseconds: 50
    }
    healthProbeSettings: {
      probePath: '/health'
      probeRequestType: 'HEAD'
      probeProtocol: 'Https'
      probeIntervalInSeconds: 30
    }
  }
}

resource originEastUS 'Microsoft.Cdn/profiles/originGroups/origins@2023-05-01' = {
  parent: originGroup
  name: 'eastus-origin'
  properties: {
    hostName: 'myapp-eastus.azurewebsites.net'
    httpPort: 80
    httpsPort: 443
    priority: 1
    weight: 1000
    enforceCertificateNameCheck: true
    originHostHeader: 'myapp-eastus.azurewebsites.net'
  }
}

resource originWestEurope 'Microsoft.Cdn/profiles/originGroups/origins@2023-05-01' = {
  parent: originGroup
  name: 'westeurope-origin'
  properties: {
    hostName: 'myapp-westeurope.azurewebsites.net'
    httpPort: 80
    httpsPort: 443
    priority: 1
    weight: 1000
    enforceCertificateNameCheck: true
    originHostHeader: 'myapp-westeurope.azurewebsites.net'
  }
}

resource wafPolicy 'Microsoft.Network/FrontDoorWebApplicationFirewallPolicies@2022-05-01' = {
  name: 'myappwaf'
  location: 'global'
  sku: {
    name: 'Premium_AzureFrontDoor'
  }
  properties: {
    policySettings: {
      mode: 'Prevention'
      requestBodyCheck: 'Enabled'
    }
    managedRules: {
      managedRuleSets: [
        {
          ruleSetType: 'Microsoft_DefaultRuleSet'
          ruleSetVersion: '2.1'
          ruleSetAction: 'Block'
        }
        {
          ruleSetType: 'Microsoft_BotManagerRuleSet'
          ruleSetVersion: '1.0'
        }
      ]
    }
  }
}

Front Door + Private Link for Zero-Trust

Azure Front Door Premium supports Private Link origins, meaning traffic from Front Door to your backend flows over the Microsoft backbone through a Private Endpoint, never over the public internet. Combined with disabling public access on your App Service or Load Balancer, this creates a zero-trust network path where the only way to reach your backend is through Front Door (with WAF inspection). This is the recommended pattern for production web applications.

Application Gateway v2

Azure Application Gateway is a regional L7 load balancer that provides URL-based routing, SSL termination, cookie-based session affinity, and WAF protection. It operates within a VNet (unlike Front Door which is a global edge service), making it suitable for internal applications and as a regional complement to Front Door.

Key Application Gateway Features

  • URL path-based routing: Route /api/* to backend A and /static/* to backend B
  • Multi-site hosting: Host multiple domains on a single Application Gateway
  • SSL termination and end-to-end SSL: Offload SSL at the gateway or re-encrypt to backends
  • Autoscaling: v2 SKU scales automatically from 0 to 125 instances based on traffic
  • WAF v2: OWASP Core Rule Set 3.2, custom rules, bot protection, geo-filtering
  • HTTP/2 support: Improved performance for modern web applications
  • Rewrite rules: Modify request/response headers, URLs, and query strings
Create Application Gateway with WAF
# Create a WAF policy
az network application-gateway waf-policy create \
  --name myapp-waf \
  --resource-group myRG \
  --location eastus2

# Enable managed rule set
az network application-gateway waf-policy managed-rule rule-set add \
  --policy-name myapp-waf \
  --resource-group myRG \
  --type OWASP \
  --version 3.2

# Create Application Gateway v2 with WAF
az network application-gateway create \
  --name myapp-agw \
  --resource-group myRG \
  --location eastus2 \
  --sku WAF_v2 \
  --capacity 2 \
  --vnet-name prod-spoke-vnet \
  --subnet AppGatewaySubnet \
  --http-settings-protocol Https \
  --http-settings-port 443 \
  --frontend-port 443 \
  --waf-policy /subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Network/ApplicationGatewayWebApplicationFirewallPolicies/myapp-waf

# Enable autoscaling (0-10 instances)
az network application-gateway update \
  --name myapp-agw \
  --resource-group myRG \
  --set sku.name=WAF_v2 sku.capacity=null \
  --set autoscaleConfiguration.minCapacity=0 autoscaleConfiguration.maxCapacity=10

Hybrid Connectivity: VPN vs ExpressRoute

Connecting on-premises networks to Azure is one of the most critical infrastructure decisions. Azure offers two primary connectivity options, each suited to different requirements for bandwidth, latency, reliability, and security.

FeatureSite-to-Site VPNExpressRoute
Connection typeIPSec tunnel over public internetPrivate MPLS circuit via connectivity provider
Max bandwidthUp to 10 Gbps (VpnGw5)Up to 100 Gbps (Direct)
LatencyVariable (internet-dependent, typically 20-100ms)Predictable, low latency (5-20ms)
Reliability SLA99.95% (active-active)99.95% (standard), 99.99% (Global Reach)
EncryptionIPSec encryption built-inNot encrypted by default
Setup timeMinutes to hoursWeeks to months (provider provisioning)
Monthly cost~$350-5,000 (gateway SKU)~$500-15,000 + circuit provider fees
RedundancyActive-active gatewaysDual circuits to different peering locations
Microsoft 365 accessNoYes (with Microsoft peering)
Best forDev/test, small offices, VPN backupProduction, large data transfers, compliance

ExpressRoute Is Not Encrypted by Default

A common misconception is that ExpressRoute traffic is encrypted because it uses a private circuit. It is not. Data traverses the MPLS path unencrypted. For sensitive workloads, layer IPSec VPN over ExpressRoute (VPN Gateway coexistence) or enable MACsec on ExpressRoute Direct ports for line-rate hardware encryption. Microsoft also offers ExpressRoute with encryption through the VPN gateway coexistence feature, which provides IPSec tunnels over the ExpressRoute circuit.

ExpressRoute Resiliency Patterns

ExpressRoute high-availability patterns
Pattern 1: Standard Resiliency (single circuit, two connections)
  On-Premises -> Provider -> Primary Connection -> Azure (Zone 1)
  On-Premises -> Provider -> Secondary Connection -> Azure (Zone 2)
  SLA: 99.95%
  Risk: Single provider failure takes down both connections

Pattern 2: Maximum Resiliency (two circuits, different providers)
  On-Premises -> Provider A -> Circuit 1 -> Azure Region 1
  On-Premises -> Provider B -> Circuit 2 -> Azure Region 1
  SLA: 99.99%+
  Cost: 2x circuit cost, but eliminates single provider risk

Pattern 3: ExpressRoute + VPN Failover
  Primary:   On-Premises -> ExpressRoute -> Azure
  Backup:    On-Premises -> Site-to-Site VPN -> Azure
  BGP weight: ExpressRoute preferred, VPN as automatic failover
  Cost: ExpressRoute + VPN gateway cost

Pattern 4: ExpressRoute Global Reach (multi-region)
  Datacenter A -> ExpressRoute Circuit A -> Azure Region 1
  Datacenter B -> ExpressRoute Circuit B -> Azure Region 2
  Global Reach: Circuit A <-> Circuit B (cross-region via Microsoft backbone)
  Enables: On-premises site-to-site via Azure backbone

Azure Firewall

Azure Firewall is a managed, cloud-native network security service that provides stateful packet inspection, application-level filtering, threat intelligence-based filtering, and TLS inspection. It sits in your hub VNet and inspects traffic flowing between spokes, between Azure and the internet, and between Azure and on-premises networks.

Firewall Tiers

TierKey FeaturesThroughputApproximate Cost
BasicL3-L4 filtering, fixed 250 Mbps throughput250 Mbps~$275/mo + data
StandardL3-L7 filtering, threat intel, FQDN filtering, DNS proxy30 Gbps~$912/mo + data
PremiumStandard + TLS inspection, IDPS, URL filtering, web categories100 Gbps~$1,825/mo + data
Configure Azure Firewall with policy rules
# Create Firewall Policy
az network firewall policy create \
  --name hub-firewall-policy \
  --resource-group myRG \
  --location eastus2 \
  --sku Premium \
  --threat-intel-mode Alert

# Create a rule collection group
az network firewall policy rule-collection-group create \
  --name DefaultRuleCollectionGroup \
  --policy-name hub-firewall-policy \
  --resource-group myRG \
  --priority 100

# Application rule: Allow outbound HTTPS to specific FQDNs
az network firewall policy rule-collection-group collection add-filter-collection \
  --policy-name hub-firewall-policy \
  --resource-group myRG \
  --rule-collection-group-name DefaultRuleCollectionGroup \
  --name AllowWebTraffic \
  --collection-priority 100 \
  --action Allow \
  --rule-type ApplicationRule \
  --rule-name AllowAzureServices \
  --source-addresses "10.1.0.0/16" \
  --protocols Https=443 \
  --target-fqdns "*.azure.com" "*.microsoft.com" "*.windows.net"

# Network rule: Allow spoke-to-spoke on specific ports
az network firewall policy rule-collection-group collection add-filter-collection \
  --policy-name hub-firewall-policy \
  --resource-group myRG \
  --rule-collection-group-name DefaultRuleCollectionGroup \
  --name AllowSpokeToSpoke \
  --collection-priority 200 \
  --action Allow \
  --rule-type NetworkRule \
  --rule-name AllowProdToStaging \
  --source-addresses "10.1.0.0/16" \
  --destination-addresses "10.2.0.0/16" \
  --destination-ports 443 8080 \
  --ip-protocols TCP

# Create route table to force traffic through firewall
az network route-table create \
  --name spoke-to-firewall-rt \
  --resource-group myRG \
  --location eastus2 \
  --disable-bgp-route-propagation true

# Default route through the firewall
az network route-table route create \
  --name to-internet \
  --route-table-name spoke-to-firewall-rt \
  --resource-group myRG \
  --address-prefix 0.0.0.0/0 \
  --next-hop-type VirtualAppliance \
  --next-hop-ip-address 10.0.1.4

Azure Firewall vs Third-Party NVAs

Azure Firewall is a managed service, so Microsoft handles updates, scaling, and availability. Third-party Network Virtual Appliances (Palo Alto, Fortinet, Check Point) offer more advanced features (deep packet inspection, advanced threat prevention, centralized management across on-premises and cloud) but require you to manage the infrastructure including HA, patching, and scaling. Choose Azure Firewall for simplicity and Azure-native integration. Choose a third-party NVA if you have existing security tool investments, need specific compliance certifications, or require features not available in Azure Firewall.

Private Link and Private Endpoints

Azure Private Link enables you to access Azure PaaS services (Storage, SQL, Cosmos DB, Key Vault, and 60+ services) over a private endpoint in your VNet. Traffic between your VNet and the service travels over the Microsoft backbone network, never traversing the public internet. This is the cornerstone of zero-trust networking for PaaS services.

Private Link Architecture Pattern

Private Link end-to-end flow
Application in Spoke VNet (10.1.2.5)
  |
  | DNS query: mystorageaccount.blob.core.windows.net
  | -> CNAME: mystorageaccount.privatelink.blob.core.windows.net
  | -> A record: 10.1.4.5 (from Private DNS Zone)
  |
  v
Private Endpoint (10.1.4.5 in private-endpoints subnet)
  |
  | Traffic flows over Microsoft backbone
  | (never crosses the public internet)
  |
  v
Azure Storage Account (mystorageaccount)
  Public access: DISABLED
  Only accessible via Private Endpoint

Required components:
1. Private Endpoint (NIC with private IP in your subnet)
2. Private DNS Zone (privatelink.blob.core.windows.net)
3. VNet Link (connect DNS zone to VNets that need resolution)
4. DNS Zone Group (auto-register PE IP in DNS zone)
5. PaaS service configured with publicNetworkAccess: Disabled

Common Private DNS Zones

Azure ServicePrivate DNS Zone
Storage (Blob)privatelink.blob.core.windows.net
Storage (File)privatelink.file.core.windows.net
Azure SQL Databaseprivatelink.database.windows.net
Cosmos DB (SQL API)privatelink.documents.azure.com
Key Vaultprivatelink.vaultcore.azure.net
Azure Container Registryprivatelink.azurecr.io
Event Hubs / Service Busprivatelink.servicebus.windows.net
Azure Cache for Redisprivatelink.redis.cache.windows.net
Set up Private DNS Zones, VNet links, and hybrid DNS resolution

DNS Architecture for Azure

DNS is the most underestimated component of Azure networking. Poor DNS architecture leads to Private Endpoint resolution failures, hybrid connectivity issues, and operational headaches that are difficult to diagnose. A robust DNS architecture for Azure includes:

  • Azure Private DNS Resolver: A managed DNS forwarding service deployed in the hub VNet. It forwards queries from Azure to on-premises DNS servers and from on-premises to Azure Private DNS Zones.
  • Centralized Private DNS Zones: One zone per Azure service type using Private Endpoints, all hosted in the hub subscription and linked to all VNets.
  • Conditional forwarding: On-premises DNS servers forward Azure private zone queries (*.privatelink.*.azure.com) to the Private DNS Resolver inbound endpoint. The resolver forwards on-premises domain queries to on-premises DNS.
Deploy Azure Private DNS Resolver
# Create a Private DNS Resolver in the hub VNet
az dns-resolver create \
  --name hub-dns-resolver \
  --resource-group myRG \
  --location eastus2 \
  --id /subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Network/virtualNetworks/hub-vnet

# Create inbound endpoint (on-premises queries Azure)
az dns-resolver inbound-endpoint create \
  --name inbound-endpoint \
  --dns-resolver-name hub-dns-resolver \
  --resource-group myRG \
  --location eastus2 \
  --ip-configurations '[{"id": "/subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Network/virtualNetworks/hub-vnet/subnets/DNSResolverInbound", "private-ip-allocation-method": "Dynamic"}]'

# Create outbound endpoint (Azure queries on-premises)
az dns-resolver outbound-endpoint create \
  --name outbound-endpoint \
  --dns-resolver-name hub-dns-resolver \
  --resource-group myRG \
  --location eastus2 \
  --id /subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Network/virtualNetworks/hub-vnet/subnets/DNSResolverOutbound

# Create forwarding ruleset for on-premises domains
az dns-resolver forwarding-ruleset create \
  --name onprem-forwarding \
  --resource-group myRG \
  --location eastus2 \
  --outbound-endpoints '[{"id": "/subscriptions/<sub-id>/resourceGroups/myRG/providers/Microsoft.Network/dnsResolvers/hub-dns-resolver/outboundEndpoints/outbound-endpoint"}]'

# Forward corp.contoso.com queries to on-premises DNS
az dns-resolver forwarding-rule create \
  --name forward-to-onprem \
  --ruleset-name onprem-forwarding \
  --resource-group myRG \
  --domain-name "corp.contoso.com." \
  --target-dns-servers '[{"ip-address": "192.168.1.10", "port": 53}, {"ip-address": "192.168.1.11", "port": 53}]'

DNS Is a Day-One Decision

Plan your DNS architecture before deploying your first Private Endpoint. Retroactively fixing DNS for dozens of Private Endpoints across multiple VNets is painful and error-prone. Centralize Private DNS Zones in the hub subscription. Automate zone creation and VNet linking using Azure Policy with DeployIfNotExists. Set up conditional forwarding before enabling hybrid connectivity.

Network Monitoring and Troubleshooting

Azure provides several tools for network diagnostics, each designed for different types of connectivity issues. Knowing which tool to reach for first can save hours of troubleshooting time.

Diagnostic Tools

ToolWhat It DoesWhen to Use
Network Watcher - IP flow verifyTests if a packet is allowed or denied by NSG rulesVM cannot reach a destination, suspect NSG blocking
Network Watcher - Next hopShows the next hop for a packet from a VMTraffic not reaching the expected destination (routing issue)
Network Watcher - Connection troubleshootTests TCP connectivity between source and destinationEnd-to-end connectivity failure diagnosis
Effective routesShows all routes applied to a NIC (system + UDR + BGP)Traffic taking unexpected path, firewall bypass
Effective NSG rulesShows combined effect of subnet and NIC NSGsUnderstanding actual security rules applied to a VM
NSG flow logsLogs all traffic evaluated by NSGs (allowed + denied)Security audit, traffic pattern analysis
Connection MonitorContinuous end-to-end connectivity monitoringProactive monitoring, SLA tracking
Traffic AnalyticsVisual analysis of NSG flow logsNetwork traffic visualization, anomaly detection
Network troubleshooting commands
# Test connectivity between a VM and a destination
az network watcher test-connectivity \
  --resource-group myRG \
  --source-resource myVM \
  --dest-address 10.1.3.4 \
  --dest-port 1433

# Check effective routes for a NIC (shows actual routing table)
az network nic show-effective-route-table \
  --resource-group myRG \
  --name myVM-nic \
  --output table

# Check effective NSG rules (combined subnet + NIC NSGs)
az network nic list-effective-nsg \
  --resource-group myRG \
  --name myVM-nic

# Verify IP flow (is this traffic allowed or denied by NSG?)
az network watcher test-ip-flow \
  --vm myVM \
  --resource-group myRG \
  --direction Inbound \
  --protocol TCP \
  --local 10.1.2.5:80 \
  --remote 10.1.1.10:*

# Enable NSG flow logs with Traffic Analytics
az network watcher flow-log create \
  --name myNSGFlowLog \
  --nsg myNSG \
  --resource-group myRG \
  --storage-account mystorageaccount \
  --workspace myLogAnalyticsWorkspace \
  --enabled true \
  --traffic-analytics true \
  --interval 10

Systematic Troubleshooting Approach

When debugging connectivity issues, follow this order: (1) Check effective NSG rules to rule out security blocking, (2) Check effective routes to ensure traffic takes the expected path, (3) Use Connection Troubleshoot for end-to-end path analysis, (4) Check DNS resolution if the destination is a hostname, (5) Review Azure Firewall logs if traffic passes through the firewall. Most connectivity issues are caused by NSG rules, missing UDRs, or DNS resolution failures. Check these first before investigating more complex scenarios.

Design the foundational VNet architecture for these networking servicesConfigure Azure DNS zones, records, and private DNS resolutionUnderstand networking costs: Front Door, Firewall, gateways, and egressCompare Azure networking concepts with AWS and GCP equivalentsApply network security practices from the Well-Architected Framework

Key Takeaways

  1. 1Private Link creates private endpoints for Azure PaaS services inside your VNet.
  2. 2Application Gateway provides L7 load balancing with WAF, SSL termination, and URL routing.
  3. 3ExpressRoute delivers dedicated private connectivity to on-premises with predictable latency.
  4. 4Azure Firewall provides centralized, stateful network security with threat intelligence.
  5. 5Network Watcher tools diagnose connectivity issues, capture packets, and analyze flow logs.
  6. 6Front Door provides global L7 load balancing with CDN, WAF, and SSL offloading.

Frequently Asked Questions

What is the difference between Private Endpoints and Service Endpoints?
Private Endpoints create a network interface with a private IP in your VNet for the PaaS service. Service Endpoints extend your VNet identity to the service but traffic still goes to the public IP. Private Endpoints are more secure and recommended.
When should I use Application Gateway vs Front Door?
Application Gateway is regional L7 load balancing inside a VNet. Front Door is global L7 with CDN and edge routing. Use Application Gateway for single-region apps. Use Front Door for multi-region, globally distributed applications.
What is the difference between ExpressRoute and VPN Gateway?
ExpressRoute is a dedicated private connection via a connectivity provider (not over the internet). VPN Gateway creates encrypted tunnels over the public internet. ExpressRoute offers higher bandwidth, lower latency, and more consistent performance.
How does Azure Firewall differ from NSGs?
NSGs are stateless L3/L4 filters applied to subnets or NICs. Azure Firewall is a stateful L3-L7 service with FQDN filtering, threat intelligence, TLS inspection, and centralized logging. Use both in layers for defense in depth.
What is Azure DDoS Protection?
Azure DDoS Protection provides always-on traffic monitoring and automatic mitigation of network-layer DDoS attacks. The Standard tier adds cost protection, rapid response support, and detailed attack analytics beyond the basic protection included for free.

Written by CloudToolStack Team

Cloud engineers and architects with hands-on experience across AWS, Azure, and GCP. We write guides based on real-world production patterns, not just documentation rewrites.

Disclaimer: This guide is for educational purposes. Cloud services change frequently; always refer to official documentation for the latest information. AWS, Azure, and GCP are trademarks of their respective owners.