Skip to content

Latest commit

 

History

History
214 lines (169 loc) · 11.6 KB

5.5. Networking Azure Application Components.md

File metadata and controls

214 lines (169 loc) · 11.6 KB
Raw

Networking Azure Application Components

Virtual Networks

  • VNet: the logical unit of multiple or all network resources in an Azure region.
  • Within a VNet, you create one or more subnets.
    • 💡 All traffic within a subnet is allowed, but communication across different subnets is blocked by default
  • Several Azure Resources are making use of VNets and subnets for IP addressing
    • IaaS e.g. Virtual Machines, VM Scale Sets, Load Balancers, Azure Traffic Manager,…
    • PaaS e.g. Service Fabric, Azure Container Services, Hadoop, Azure Application Services,…

Network Security Groups (NSGs)

  • Software-defined firewalling
  • Protects incoming traffic to Azure public IP addresses.
  • Top level object that is associated to your subscription.
  • Rules
    • Inbound rules are applied on the incoming packets to a VM.
    • Outbound rules are applied to the outgoing packets from the VM.
    • Can be changed at any time, and changes are applied to all associated instances.
    • An incoming or outgoing packet has to match an Allow rule for it be permitted, if not it will be dropped.
    • By default
      • Connectivity to the internet is allowed for Outbound direction.
      • Blocked for Inbound direction¨
    • 💡 The default rules cannot be deleted, but because they are assigned the lowest priority, they can be overridden by the rules that you create.
      • For example, a rule with a lower priority number (e.g. 100) is processed before rules with a higher priority numbers (e.g. 200). Once a match is found, no more rules are processed.
  • Can be assigned to both VNet and VM (individual NIC).
  • ❗ Limitations:
    • A VM or subnet can be associated with only 1 NSG, and each NSG can contain up to 200 rules.
    • You can have 100 NSGs per subscription.
    • NSGs cannot span Azure Regions.

Multi-Region Virtual Network Architecture

  • Applies for cross regions and on-premises
  • 💡 From the Public Internet, Azure allows for load balancing across multiple Azure Regions by deploying Azure Traffic Manager.
  • Interconnecting Azure Regions with each other is possible in three different ways:
    1. Configuring Azure Site-to-Site VPN between both regions
      • Encrypted tunnel connection over internet.
    2. Configuring Azure ExpressRoute communication tunnels
    3. Azure VNET Peering
      • Networking without encryption.
  • Interconnecting Azure Regions with on-premises data centers is possible in two different ways:
    1. Configuring Azure Site-to-Site VPN between Azure and on-premises
    2. Configuring Azure ExpressRoute communication tunnels between Azure and on-premises

IP Addressing

  • IP-address gets allocated to a NIC during provisioning of the NIC
  • First available IP-address in a subnet range is x.x.x.4
  • Azure Subnets support dynamic (=default) and static IP addressing
  • Public IP-addressing
    • Used for all public internet-facing communication
    • Required parameter when creating a VM from the portal
  • Private IP-addressing
    • Used for all inter-VNET communication
    • Used for all communication between an Azure VNET and an on-premises VNET

Azure DNS Resolving

  • DNS server settings are configured on VNET level
  • Using Azure DNS is the default configuration setting, but this can be modified
    • Use your custom DNS configuration:
      • Azure DNS Appliance (from Azure MarketPlace)
      • Azure VM (e.g. Windows ADDS with DNS)
      • On-premises DNS solution (requires connectivity)
  • Public DNS names (available for VMs and App Services) must be unique across Azure regions.
    • An example of such Public DNS name is host.region.cloudapp.azure.com

Load Balancing

Azure Load Balancer

  • Uses private IP addresses in back-end pools.
    • You can associate it to a Availability set, Single virtual machine or Virtual machine scale set
      • 💡 In an availability set, it allows it to grow to 10x the number of instances (100 in Basic to 1000 in Standard in a single Availability Set).
  • Can handle almost any TCP or UDP traffic e.g. RDS (Remote Desktop Services Farm), Linux SSH.

Azure Load Balancer Types

External load balancer
  • The load balancer front-end is configured with a Public-facing IP-address
  • Sends all traffic along to the back-end pool servers, using their internal IP-addresses.
Internal Load Balancer
  • Doesn't have a Public-facing IP-address, and all communication is based on internal IP-addressing and IP-routing.
  • Used for e.g. database server backends

Azure Load Balancer SKUs

Basic Standard
Up to 100 backend instances Up to 1000 backend instances
Single Availability Set Availability Sets are not required; providing support for Availability Zones
Basic NAT and Probe health status Integrated Frontend and Backend health metrics
No HA Ports Support for HA Ports
Network Security Groups (NSG) are optional Network Security Groups are required during configuration and deployment
Free Charged hourly based on number of rules configured (except NAT) & data processed

Azure Application Gateway

  • Load Balancing, active on Layer 7 of the network stack; this mainly means it is "application intelligent."
  • Main features Application Gateway provides, compared to Azure Load Balancer, are:
    • HTTP/HTTPS traffic only, no other ports allowed
    • SSL Offloading
    • Cookie Affinity
    • Web Application Firewall (WAF)
    • URL Based Routing
  • SSL Termination
    • SSL Offloading, by importing the SSL Certificate onto the App Gateway; traffic to the backend servers don't require HTTPS communication, also that would still be an option.
    • HTTP to HTTPS redirect ; this means that, whenever a user is connecting to the web app using HTTP, the request will be redirected to HTTPS, forcing SSL Tunneling for this given request.
  • Web Application Firewall (WAF)
    • Protection against several common attacks and threats on application workloads.
      • E.g. SQL Injection, Cross-site scripting, Protocol violations, Generic attacks, HTTP rate limiting, Scanner detection, Session fixation, LFI/RFI.

Azure Marketplace Load Balancing Appliance

  • Recommended for more capabilities around management, monitoring and control.
  • Support is initially provided by Microsoft, backed by SLAs, and acting as a SPOC (Single point of contact).

Licensing Models

Bring Your Own License (BYOL)
  • This is an ideal candidate if you are removing or downsizing on your on-premises running third-party load balancer.
  • Depending on the specific licensing terms of the vendor, one can reuse the license key on the Azure VM Appliance.
Pay-Per-Use
  • The monthly Azure VM consumption cost is based on the VM Size allocation to the Appliance, as well as a monthly licensing fee for the third party load balancing application within the VM.

Azure Traffic Manager

  • Control the distribution of user traffic to your specified endpoints.
  • Works by applying an intelligent policy engine to Domain Name System (DNS) queries for the domain names of your internet resources.
  • Flexible as it allows you to mix various endpoints behind the same DNS name.
  • Easy to integrate with Web Apps.

Example Azure Traffic Manager use cases

  • Failover
    • Can poll to determine if and endpoint is online or offline.
    • Traffic is routed in the next online endpoint that's highest in the priority list.
  • Geography Uses Internet Latency Table to find closes endpoint to the client.
  • Distribution
    • Near-random way to distribute evenly across set of endpoints.
    • Distribution can optionally be weighted.
      • 💡 Weighting is good if you have a smaller recovery site and want to keep majority of the traffic to the primary site using larger service tiers.

Azure Traffic Manager Workflow

  1. User traffic to company domain name, e.g. fabrikam.com
  2. Company domain name to Traffic Manager domain name
    • CNAME resource record that maps the company domain name (e.g. fabrikam.com) to traffic manager domain name (e.g. fabrikamweb.trafficmanager.net)
  3. Traffic Manager domain name and profile: The user's DNS server sends a new DNS query for the Traffic Manager domain name (e.g., fabrikamweb.trafficmanager.net), which is received by the Traffic Manager DNS name servers.
  4. Traffic Manager profile rules processed: load balancing method and monitoring status to determine endpoint.
  5. Endpoint domain name to user:
    • Returns CNAME that maps Traffic Manager domain name to the domain name of the endpoint.
    • Users DNS server resolves domain name to IP and sends it to user.
  6. User calls the returned endpoint directly by using its IP address.

Connectivity options

On-Premises to Azure Connectivity

  • This can be between an on-premises network and one or more Azure regions, or between multiple Azure regions
    Connectivity Benefits
    ExpressRoute • 💡 Use ExpressRoute as primary cross-premises connectivity. • Multiple circuits for redundancy & better routing. • 💡 Use ExpressRoute-VPN co-existence for highly available, redundant paths.
    Site-to-Site VPN • 💡 S2S VPN over internet for remote branch locations • BGP & active-active configuration for HA and transit
    Point-to-Site VPN • P2S VPN for mobile users & developers to connect from anywhere with macOS & Windows • AD/radius authentication for enterprise grade security
  • Multi-Region VPN Connectivity
    • Forced Tunneling
      • Azure traffic can be rerouted to an on-premises virtual network, to be routed through an existing Site-to-Site VPN or ExpressRoute, into the internal Azure VNET.
      • Security improvement as internal Azure VMs are no longer accessible through the public internet.

Securing Access to PaaS Services

  • Goal is to disable access to PaaS services from public internet.

Service Endpoints

  • Use VNET service endpoints, where you define which PaaS services are no longer accessible through the public internet
  • Virtual network service endpoint
    • ❗ Only available to Azure Storage Accounts, SQL DB Services in PaaS and Web Apps.
    • Provides the identity of your virtual network to the Azure service.
    • Service endpoints are configured on a subnet in a virtual network
    • You can configure multiple service endpoints for all supported Azure services on a subnet.
    • VNets and resources can be in different subscriptions and regions with exceptions:
      • ❗ SQL VNet must be in same region.
      • ❗ Storages Storage Account must be in same region.
  • Flow:
    1. Connect storage account to a VNet.
    2. Add service endpoints to the VNet.
    3. Once service endpoints are enabled in VNet, you can secure Azure service resources to your virtual network by adding a VNet rule to the resources.
  • Access from on-premises
    • You must also allow public (typically NAT) IP addresses from your on-premises or ExpressRoute.
    • Those IP addresses can be added through the IP firewall configuration for Azure service resources.

VNET Peering

  • Uses the Microsoft Backbone (not the public internet).
  • Communication relies on internal IP addressing.
  • Primary features
    • Allows you to interconnect 2 Azure VNET as if they are 1 large VNET.
    • Possible within the same Azure region, or across Azure regions
    • Supported to interconnect an Azure Classic VNET with an ARM VNET (e.g., for migrating workloads).
  • 💡 If VNET peering is not an option, because you might want to encrypt your traffic within the VNET tunnel, deploy a VPN Gateway on both Azure Regional VNETs to create a Site-to-Site VPN tunnel across those regions.