Azure Databases

• SQL Server:
  • SQL elastic pool: Elastic pool provide a simple and cost effective solution for managing the performance of multiple databases withing a fixed budget.
    • An elastic pool provides compute (eDTUs) and storage resources that are shared between all the databases it contains.
    • Databases within a pool only use the resources they need, when they need them, within configurable limits.
    • The price of a pool is based only on the amonunt of resources configured is independent of the number of databases it contains.
  • Advanced Threat Protection: A unified security package for discovering and classifying sensitive data, surfacing and mitigating potential database vulnerabilities, and detecting anomalous activities that could indicate a threat to your database.
  • Basic: For less demanding workloads.
  • Standard: For workloads with typical performance requirements.
  • Premium: For IO-intensive workloads.
• MySQL Server:
  • Basic: Up to 2 vCores with variable IO performance (1-2 vCores). Supports Backup Redundancy Option only Locally Redundant.
  • General Purpose: Up to 32 vCores with predictable IO performance (2-32 vCores). Supports Backup Redundancy Option both Locally Redundant and Geo-Redundant.
  • Memory Optimized: Up to 16 memory optimized vCores with predictable IO performance (2-16 vCores). Supports Backup Redundancy Option both Locally Redundant and Geo-Redundant.
  • Please note that changing to and from the Basic pricing tier or changing the backup redundancy options after server creation is not supported.

Advertisements

Azure App Services

• App Services:
  • Azure Web Apps enables you to build and host web applications in the programming language (.NET, .NET Core, Java, Ruby, Node.js, PHP, or Python) of your choice without managing infrastructure.
  • It offers auto-scaling and high availability, supports both Windows, Linux, Docker, and enables automated deployments from FTP, GitHub, Git repo, Visual Studio Team Services, Bitbucket.
  • ​Web App name must be unique across all of Azure because the web app is given a URL that ends in .azurewebsites.net.
  • You can improve performance of your state-less apps by turning off the Affinity Cookie, state-full apps should keep Affinity Cookie tuned on for increased compatibility.
  • Always on: Indicates that your web app needs to be loaded at all times. By default, web apps are unloaded after they have been idle. Its recommended that you enable this option when you have continuous web jobs running on the web app.
  • ARR Affinity: You can improve the performance of your stateless apps by turning off the Affinity Cookie. State-ful apps should keep the Affinity Cookie turned on for increased compatibility.
  • App Services Plan:
    • App Service plans represent the collection of physical resources used to host your apps, like location, scale, size and SKU.
    • The cost for the app service plans is based upon per instance, so if you use increase the instances in a selected plan then your cost will multiply as per instances used.
    • Premium:
      • V1( P1, P2, P3): 1/2/4 cores; 1.7/3.5/7 GB RAM; 250 GB storage; 20 instances; 20 slots; Traffic Manager
      • V2(P1, P2, P3): 1/2/4 cores (faster Dv2 series workers); 3.5/7/14 GB RAM; 250 GB SSD storage; 20 instances; 20 slots; Traffic Manager
    • Standard (S1, S2, S3):
      • 1/2/4 cores; 1.7/3.5/7 GB RAM; 50 GB storage; 10 instances;  5 slots; Traffic Manager
    • Basic (B1, B2, B3):
      • 1/2/4 cores; 1.7/3.5/7 GB RAM; 10 GB storage; 3 instances
    • Shared (D1): Shared infrastructure, 1 GB storage
    • Free: Shared infrastructure, 1 GB storage
    • Scale Up: Allows to scale up or down App Service Plan.
    • Scale Out: Allows to increase or decrease instance count.
      • Auto scaling: Can be enabled based upon CPU, Memory, Disk Queue, Http Queue, Data In/Out.
      • It will multiply the cost based upon number of instances increased.
  • Deployment Slots: Deployment slots let you deploy different versions of your web app to different URLs. You can test a certain version and then swap content and configuration between slots.
    • Allows you to test if the deployment works before all users are switched to that new version of the code. This is good last-minute testing to make sure nothing is broken.
    • Auto swap destinations can’t be configured from production slot.
  • Continuous Delivery: Continuous Delivery in Visual Studio Team Services simplifies setting up a robust deployment pipeline for your application. The pipeline builds, runs load tests and deploys to staging slot and then to production.
    • A post deployment action hook is a script/executable that runs after the deployment has completed successfully as part of the default deployment script.
  • Application Insights: helps you to detect and diagnose quality issues in your web apps and web services, and helps you understand what your users actually do with it.
  • Diagnostics logs: Azure Monitor diagnostic logs are logs emitted by an Azure service that provide rich, frequent data about the operation of that service. Azure Monitor makes available two types of diagnostic logs:
    • Application logging (Filesystem): Enable application logging to collect diagnostic traces from your web app code. You need to turn this on to enable the streaming log feature. This setting turn itself off after 12 hours.
    • Application logging (Blob): Logs are collected in the Blob container that’s specified under Storage settings.
    • Web server logging: Gather diagnostic information for your webs server.
    • Detailed error messages: Gather detailed error messages from your web app.
    • Failed request tracing:
    • Tenant logs: these logs come from tenant-level services that exist outside of an Azure subscription, e.g Azure Active Directory logs.
    • Resource logs: these logs come from Azure services that deploy resources within an Azure subscription, e.g Network Security Groups or Storage Accounts.
    • You can export diagnostic logs into:
      • OMS Log Analytics: analyze them with Log analytics.
      • Event Hub: for ingestion by a third-party service or custom analytics solution such as PowerBI.
      • Storage account: for auditing or manual inspection.
    • Set-AzureRmDiagnosticSetting -ResourceId [Resource Id] -Enabled $true
      • -StorageAccountId [storage account id]
      • -ServiceBusRuleId [Service Bus rule id]
      • -WorkspaceId [resource id of the log analytics workspace]
        • (Get-AzureRmOperationalInsightsWorkspace).ResourceId
    • Activity log: provides insight into the operations that were performed on resources in your subscription using Resource Manager, for example, creating a virtual machine or deleting a logic app. The Activity Log is a subscription-level log.
  • SSL certificates:
    • Configure the custom domain
    • Scale up to Basic tier or higher
    • Get an SSL certificate
      • Its signed by a trusted CA (no private CA servers)
      • It contains a private key
      • Its created for key exchange, and exported in .PFX file
      • It uses minimum 2048-bit encryption
      • Its subject name matches the custom domain it needs to secure.
      • Its merged with all the intermediate certificates used by your CA.
    • SSL bindings:
      • Certificates must be associated with your app before you can use them to create a binding.
      • You can upload a certificate you purchased externally or import an App Service Certificate.
      • You may also select  where to use Server Name Identification (SNI) or IP based SSL.
  • PowerShell cmdlets:
    • New-AzureRmResourceGroup  -Name “rg1” -Location “East US”
    • New-AzureRmAppServicePlan  -ResourceGroupName “rg1” -Location “East US” -Name “plan1” -Tier “Standard“
    • New-AzureRmWebApp  -ResourceGroupName “rg1” -Location “East US” -Name “webapp1” -AppServicePlan “plan1“
    • New-AzureRmWebAppSlot  -ResourceGroupName “rg1” -Name “webapp1” -slot “Staging”
  • Azure CLI:
    • az group create –name rg1 –location “East US”
      • az group list -o table
    • az appservice plan create –resource-group rg1 –location “East US”
      –name “plan1” –sku FREE
      • az appservice plan list -o table
    • az webapp create –resource-group rg1 –plan plan1 –name webapp1
      • az webapp list -o table

Azure Active Directory

Active Directory Domain Services (AD DS): AD DS is the traditional deployment of Windows Server-based Active Directory on a physical or virtual server. Although AD DS is commonly considered to be primarily a directory service, it is only one component of the Windows Active Directory suite of technologies, which also includes:

• Active Directory Certificate Services (AD CS)
• Active Directory Lightweight Directory Services (AD LDS)
• Active Directory Federation Services (AD FS)
• Active Directory Rights Management Services (AD RMS).
• Although you can deploy and manage AD DS in Azure virtual machines it is recommended you use Azure AD instead, unless you are targeting IaaS workloads that depend on AD DS specifically.
• True directory service with hierarchical X.500 based structure
• Uses Organization Units (OU) and Group Polices (GPOs)
• Can be queried and managed through LDAP calls
• Primarily used Kerberos for authentication
• Uses DNS for locating resources such as domain controllers.

Active Directory Domain Services (AD DS): Azure AD Domain Services provides a managed AD domain in an Azure virtual network. You can join machines to this managed domain using traditional domain-join mechanisms.

• Azure AD also enables you to manage the identity of devices used by your organization and control access to corporate resources from these devices.
• Azure AD joined devices give you the following benefits:
  • Single-sign-on (SSO) to applications secured by Azure AD.
  • Enterprise policy-compliant roaming of user settings across devices.
  • Access to the Windows Store for Business using your corporate credentials.
  • Windows Hello for Business
  • Restricted access to apps and resources from devices compliant with corporate policy.
• Authentication: Kerberos, NTLM protocols
• Management: Group policy
• Great for Server virtual machines deployed in Azure

Azure Active Directory (Azure AD):

• Azure AD is a multi-tenant cloud-based identity management system that runs within Azure.
• Its Platform as a Service (PaaS) offering and can integrate with on-premises Active Directory Directory Service (AD DS).
• It provides authentication and authorization for cloud identity, synchronized identity and federated identity.
• You only manage the users, groups, and policies.
• One of the main differences between Azure AD and Azure AD DS is the way devices are registered and joined.
• Great for End-user mobile or desktop devices
• Azure AD for cloud applications:
  • Cloud services such as Office 365, Microsoft Dynamics CRM, and Intunes require a directory
  • Each cloud service can have its own directory
  • Azure AD can serves as a single directory for multiple cloud services.
  • Azure AD can enable SSO
  • Azure AD can be integrated with custom apps.
• Azure AD is different from AD DS:
  • Identity solution: Azure AD is primarily an identity solution, and it is designed for Internet-based applications by using HTTP and HTTPS communications.
  • REST API Querying: Because Azure AD is HTTP/HTTPS based, it cannot be queried through LDAP. Instead, Azure AD uses the REST API over HTTP and HTTPS.
  • Communication Protocols: Because Azure AD is HTTP/HTTPS based, it does not use Kerberos authentication. Instead, it uses HTTP and HTTPS protocols such as SAML, WS-Federation, and OpenID Connect for authentication (and OAuth for authorization).
  • Federation Services: Azure AD includes federation services, and many third-party services (such as Facebook).
  • Flat structure: Azure AD users and groups are created in a flat structure, and there are no Organizational Units (OUs) or Group Policy Objects (GPOs).
• Benefits:
  • Seamless single sign-on (SSO)
  • Multi-factor authentication (MFA)
  • Device registration
  • Priviledged account management
  • Priviledged identity management
  • Self-service password and group management
  • Role-based access control (RBAC)
  • Application usage monitoring
  • Auditing and security alerts
  • Identity protection
• Azure Active Directory Editions:
  • Free: Designed to introduce system administrators to Azure Active Directory.
    • This version includes common features such as directory objects, user/group management, single sign-on, self-service password change, on-premises connect, and security/usage reports.
  • Basic: Designed for task workers with cloud-first needs, this edition provides cloud centric application access and self-service identity management solutions.
    • With the Basic edition of Azure Active Directory, you get productivity enhancing and cost reducing features like group-based access management, self-service password reset for cloud applications, and Azure Active Directory Application Proxy (to publish on-premises web applications using Azure Active Directory), all backed by an enterprise-level SLA of 99.9 percent uptime.
  • Premium P1: Designed to empower organizations with more demanding identity and access management needs, Azure Active Directory Premium edition adds feature-rich enterprise-level identity management capabilities and enables hybrid users to seamlessly access on-premises and cloud capabilities.
    • This edition includes everything you need for information worker and identity administrators in hybrid environments across application access, self-service identity and access management (IAM), and security in the cloud.
  • Premium P2: Azure Active Directory Premium P2 includes every feature of all other Azure Active Directory editions enhanced with advanced identity protection and privileged identity management capabilities.
• Azure Active Directory B2C: Azure Active Directory (Azure AD) B2C is an identity management service that enables you to customize and control how customers sign up, sign in, and manage their profiles when using your applications. This includes applications developed for iOS, Android, and .NET, among others. Azure AD B2C enables these actions while protecting your customer identities at the same time.

Azure Virtual Networks

• Virtual Network: Azure Virtual Network is a fundamental component that acts as an organization’s network in Azure. Organizations can use virtual networks to connect resources. Virtual networks in Microsoft Azure are network overlays that you can use to configure and control connectivity between Azure resources such as VMs and load balancers.
  • vNet: A virtual network is a logical isolation of the Azure cloud dedicated to your subscription.
    •  You can divide a VNet into multiple subnets for organization and security. It contains at least one Subnet
    • You can create up to 50 virtual networks per subscription per region. Although you have the ability to increase this limit to 500 by contacting Azure support.
    • If you connect to a VNet with a VPN or ExpressRoute, you must ensure that the address space is unique and does not overlap any of the ranges that are already in use on-premises or in other VNets.
    • Always plan to use an address space that is not already in use in your organization, either on-premises or in other VNets.
    • Even if you plan for a VNet to be cloud-only, you may want to make a VPN connection to it later. If there is any overlap in address spaces at that point, you will have to reconfigure or recreate the VNet.
    • Virtual networks (VNets) can contain both public and private (RFC 1918 address blocks) IP address spaces. When you add a public IP address range, it will be treated as part of the private VNet IP address space that is only reachable within the VNet, interconnected VNets, and from your on-premises location.
    • You add a public IP address range the same way you would add a private IP address range; by either using a netcfg file, or by adding the configuration in the Azure portal.
    • dhcpOptions: Object that contains single required property i.e dnsServers
    • dnsServers: Array of DNS servers used by the vNet. If no server is specified, then Azure internal name resolution is used.
  • Subnets: A subnet is a child resource of a vNet, and helps define segments of address spaces within a CIDR block range, using IP address prefixes.
    • You can further divide your network by using subnets for logical and security isolation of Azure resources. Each subnet contains a range of IP addresses that fall within the virtual network address space.
    • Can be one or more subnets in a single vNet.
    • The smallest subnet you can specify would be /29 subnet mask.
    • The first three and the last IP addresses are not available for use within a subnet.
    • NICs can be added to subnets, and connected to VMs, providing connectivity for various workloads.
    • Routing between subnet is automatic and ICMP is allowed within subents that belongs to the same vNet.
    • You can also configure route tables and NSGs to a subnet.
    • Keep Static and Dynamic subents separate for ease of management.
    • VMs and PaaS role instances deployed to subnets (same or different) within a VNet can communicate with each other without any extra configuration.
    • location: Azure location or region where subnet is defined.
    • addressPrefix: Single address prefix in CIDR notation that make up the subnet.
    • networkSecrurityGroup: NSG is applied to subnet.
    • routeTable: Route table applied to subnet.
    • ipConfigurations: Collection of IP configuration objects used by NICs which are connected to the subnet.
    • IaaSv2, you add the subnet to a NIC, rather than adding the VM to a subnet as you do for IaaSv1.
    • You can create user defined routes that specify the next hop for packets flowing to a specific subnet to go to your virtual appliance instead, and enabling IP forwarding for the VM running as the virtual appliance.
  • Network Security Group (NSG): List of rules that can allow or deny traffic to Azure resources.
    • Can be associated with either Subnets or Network Interfaces.
    • You can use network security groups to provide network isolation for Azure resources by defining rules that can allow or deny specific traffic to individual VMs or subnets.
    • Source: Any|IP Addresses|Service Tag
    • Source Port: port | range (1-65535) | *
    • Destination: Any|IP Addresses|VirtualNetwork
    • Destination Port: port | range (1-65535) | *
    • Protocol: Any|TCP|UDP
    • Action: Allow|Deny
    • They control inbound and outbound traffic passing through a Network Interface Card (NIC) (Resource Manage deployment model), a VM (classic deployment), or a subnet (both deployment models).
      • If the VM has multiple NICs, network security group rules are NOT automatically applied to traffic that is designated to other NICs.
    • Following are Default Rules, that you cannot delete, but can override, because they have the lowest priority:
      • allow all inbound and outbound traffic within a virtual network
      • allow outbound traffic towards the Internet
      • allow inbound traffic from Azure load balancer.
      • denies all inbound and outbound traffic with the lowest priority.
    • By default you can create 100 NSGs per region per subscription. You can raise this limit to 400 by contacting Azure support.
    • You can apply only one NSG to a NIC (RM deployment model), subnet, or VM (Classic deployment model).
    • By default, you can have up to 200 rules in a single NSG. You can raise this limit to 500 by contacting Azure support.
    • You can apply an NSG to multiple resources in the same or different resource groups.
    • If you have a NSG applied to Subnet and other associated to NIC, then subnet is evaluated first followed by NIC, with most restrictive rules winning.
  • IP addresses: VMs, Azure load balancers, and application gateways in a single virtual network require unique IP addresses in the same way as clients in an on-premises subnet do. This enables these resources to communicate with each other.
    • Private IP addresses: A private IP address is allocated to a VM dynamically or statically from the defined scope of IP addresses in the virtual network.
      • Used for communication within an Azure virtual network (VNet), and your on-premises network when you use a VPN gateway or ExpressRoute circuit to extend your network to Azure.
      • A private IP address is allocated from the address range of the subnet to which the resource is attached. The address range of the subnet itself is a part of the VNet’s address range.
      • An IP address that is allocated by DHCP has infinite duration and is released only if you deallocate (stop) the VM.
      • The RFC 1918 standard defines three private address spaces that are never used for addressing on the Internet.
      • Administrators use these ranges behind Network Address Translation (NAT) devices to ensure unique addresses used within intranets never prevent communication with Internet servers.
      • There are two methods in which a private IP address is allocated: dynamic or static.
      • The default allocation method is dynamic, where the IP address is automatically allocated from the resource’s subnet (using DHCP). This IP address can change when you stop and start the resource.
      • You can set the allocation method to static to ensure the IP address remains the same. In this case, you also need to provide a valid IP address that is part of the resource’s subnet. Static private IP addresses are commonly used for:
        • VMs that act as domain controllers or DNS servers.
        • Resources that require firewall rules using IP addresses.
        • Resources accessed by other apps/resources through an IP address.
      • These three address spaces are the only ones that are supported within an Azure VNet.
        • 10.0.0.0/8: 10.0.0.1 – 10.255.255.255.
        • 172.16.0.0/12: 172.16.0.1 – 172.31.255.255.
        • 192.168.0.0/16: 192.168.0.1 – 192.168.255.255.
      • Private IP is associated with the followings:
        • Virtual Machine (Dynamic\Static): NIC
        • Load balancer-Internal (Dynamic\Static): front end configuration.
        • Application Gateway (Dynamic): front end configuration
      • When you create a VM, a mapping for the hostname to its private IP address is added to the Azure-managed DNS servers.
      • In case of a multi-network interface VM, the hostname is mapped to the private IP address of the primary network interface.
      • You cannot set a static private IP address during the creation of a VM in the Resource Manager deployment mode by using the Azure portal. You must create the VM first, then set its private IP to be static.
    • Public IP addresses: Public IP addresses allow Azure resources to communicate with external clients and Internet.
      • Public IP addresses allow Azure resources to communicate with Internet and Azure public-facing services such as Azure Redis Cache, Azure Event Hubs, SQL databases, and Azure storage.
      • Public IP addresses are allocated dynamically when you create a VM, and are bound to the NICs.
      • VMs with multiple NICs, only one of those (primary network interface) can have a Public IP. And any interface that have public IP is also going to have private IP as well.
      • The list of IP ranges from which public IP addresses (dynamic/static) are allocated to Azure resources is published at Azure Datacenter IP ranges.
      • Public IP can be assigned to the following:
        • Virtual Machine (Dynamic|Static): Associated with NIC.
        • Load Balancer – External (Dynamic|Static): Front-end configuration.
        • Application Gateway (Dynamic): Front end configuration.
        • VPN Gateway (Dynamic): Gateway IP configuration.
      • Dynamic allocation: Its the default allocation method, where public IP address is allocated when you start (or create) the associated resource (like a VM or load balancer). The IP address is released when you stop (or delete) the resource. This causes the IP address to change when you stop and start a resource.
      • Static allocation: To ensure the IP address for the associated resource remains the same, you can set the allocation method explicitly to static. In this case an IP address is assigned immediately. It is released only when you delete the resource or change its allocation method to dynamic. Static public IP addresses are commonly used in the following scenarios:
        • First 5 static addresses are free to use, extras are charged.
        • End-users need to update firewall rules to communicate with your Azure resources.
        • DNS name resolution, where a change in IP address would require updating A records.
        • Your Azure resources communicate with other apps or services that use an IP address-based security model.
        • You use SSL certificates linked to an IP address.
      • Basic: Assigned to VM, LB, Application and VPN Gateways in specific zones.
      • Standard: Assigned with Static allocation to NIC and LB only. Zone redundant by default.
      • For public IP resource, you can specify a DNS domain label, FQDN and CNAME record.
      • The DNS domain name label for a public IP resource, which creates a mapping for label.location.cloudapp.azure.com to the public IP address in the Azure-managed DNS servers.
        • You can use this FQDN to create a custom domain CNAME record pointing to the public IP address in Azure.
        • Each domain name label created must be unique within its Azure location.
  • Network Interface: They are used to configure IP addresses, Virtual Network settings, and DNS servers that will be assigned to a VM, Azure supports attaching multiple NICs to a VM.
    • VMs communicate with other VMs and other resources on the network by using virtual network interface cards (NICs). Virtual NICs configure VMs with private and optional public IP address. VMs can have more than one NIC for different network configurations.
    • You can apply only one NSG to a NIC at a time.
    • Multiple NICs in Virtual Machines:
      • You can create virtual machines (VMs) in Azure and attach multiple network interfaces (NICs) to each of your VMs.
      • Multi NIC is a requirement for many network virtual appliances, such as application delivery and WAN optimization solutions.
      • Multi NIC also provides more network traffic management functionality, including isolation of traffic between a front end NIC and back end NIC(s), or separation of data plane traffic from management plane traffic.
      • The address for each NIC on each VM must be located in a subnet and multiple NICs on a single VM can each be assigned addresses that are in the same subnet.
      • The VM size determines the number of NICS that you can create for a VM.
      • The following limitations are applicable when using the multi NIC feature:
        • Multi NIC VMs must be created in Azure virtual networks (VNets). Non-VNet VMs cannot be configured with Multi NICs.
        • All VMs in an availability set need to use either multi NIC or single NIC. There cannot be a mixture of multi NIC VMs and single NIC VMs within an availability set. Same rules apply for VMs in a cloud service.
        • A VM with single NIC cannot be configured with multi NICs (and vice-versa) once it is deployed, without deleting and re-creating it.
  • User Defined Routes: User Defined Routes (UDR) control network traffic by defining routes that specify the next hop of the traffic flow. You can assign User Defined Routes to virtual network subnets.
  • Forced Tunneling: With forced tunneling you can redirect internet bound traffic back to the company’s on-premises infrastructure. Forced tunneling is commonly used in scenario where organizations want to implement packet inspection or corporate audit.
  • Peering (vNet to vNet Peering):  Its used to connect two Azure virtual networks with each other.
    • Connecting a virtual network to another virtual network (VNet-to-VNet) is similar to connecting a virtual network to an on-premises site location.
    • Both connectivity types use a VPN gateway to provide a secure tunnel using IPsec/IKE.
    • The VNets you connect can be in different subscriptions and different regions.
    • You can combine VNet to VNet communication with multi-site configurations. This lets you establish network topologies that combine cross-premises connectivity with inter-virtual network connectivity.
    • All traffic is routed to Azure network
    • Faster and easier to setup than VPN and no public IP is required.
    • Peering relationships are not transitive
    • Changes to address space require repeating the peering
    • Can’t use overlap addresses
    • Allow virtual network access: Select this option if you wish to allow communication between the two virtual networks. This allows the peer virtual network address space to be included as part of the Virtual_Network tag.
    • Allow forwarded traffic: This setting allows the peer’s forwarded traffic (traffic not originating from inside the peer virtual network) into your virtual network.
    • Allow gateway transit: Allows the peer virtual network to use your virtual network gateway. The peer virtual network cannot already have a gateway configured, and must select ‘use remote gateway’ in its peering settings.
      
    • Use remote gateway: Select this option if you wish to use your peer’s virtual network gateway. The peer virtual network must have a gateway configured, as well as ‘allow gateway transit’ enabled. Only one peering in this virtual network can have this enabled. You cannot use this setting if you already have a gateway configured in your virtual network.
  • Cloud-Only Virtual Networks: When you create a VM or cloud service, you can specify endpoints that external clients can connect to. An endpoint is a VIP and a port number. Therefore an endpoint can be used only for a specific protocol, such as connecting a Remote Desktop Protocol (RDP) client or browsing a website. These VNets are known as cloud-only virtual networks.
    • A dynamic routing gateway is not required in the VNet.
    • Endpoints are published to the Internet, so they can be used by anyone with an Internet connection, including your on-premises computers.
• Load Balancer: Deliver high availability and network performance to your applications.
  • Azure load balancer is a transport layer (layer 4) load balancer that distributes incoming traffic across healthy virtual machine instances in the same data center using a hash-based distribution algorithm.
  • By default, Azure load balancers use a 5–tuple (source IP, source port, destination IP, destination port, protocol type) hash to distribute traffic across available servers.
  • You can configure the load balancer to: Load balance incoming traffic across your virtual machines OR Forward traffic to and from a specific virtual machine using NAT rules.
  • Azure load balancers also support network address translation (NAT) to route traffic between public and private IP addresses.
  • SKU: Standard load balancer up to 1000 instances, greater backend pool flexibility, HA ports, zone-redundant scenarios.
  • Load balance traffic between virtual machines in a virtual network, between virtual machines in cloud services, or between on-premises computers and virtual machines in a cross-premises virtual network. This is called internal load balancing.
  • Backend pool: You can associate a LB with Availability Set, VM Scale Set or Single VM.
  • An endpoint listens on a public port and forwards traffic to an internal port. You can map the same ports for an internal or external endpoint or use a different port for them. The creation of a public endpoint triggers the creation of a load balancer instance.
  • Hash based distribution: The load balancer uses a hash-based distribution algorithm.
    • By default, it uses a 5-tuple (source IP, source port, destination IP, destination port, and protocol type) hash to map traffic to available servers.
    • It provides stickiness only within a transport session.
    • Packets in the same TCP or UDP session will be directed to the same datacenter IP instance behind the load-balanced endpoint.
    • When the client closes and reopens the connection or starts a new session from the same source IP, the source port changes. This may cause the traffic to go to a different datacenter IP endpoint.
  • Port Forwarding: The load balancer gives you control over how inbound communication is managed. This communication can include traffic that’s initiated from Internet hosts or virtual machines in other cloud services or virtual networks. This control is represented by an endpoint (also called an input endpoint).
    • An endpoint listens on a public port and forwards traffic to an internal port. You can map the same ports for an internal or external endpoint or use a different port for them.
  • Service Monitoring: The load balancer can probe the health of the various server instances. When a probe fails to respond, the load balancer stops sending new connections to the unhealthy instances. Existing connections are not impacted. There are following types of probes:
    • Guest agent probe (on PaaS VMs only): The load balancer utilizes the guest agent inside the virtual machine. It listens and responds with an HTTP 200 OK response only when the instance is in the ready state (i.e. the instance is not in a state like busy, recycling, or stopping). If the guest agent fails to respond with an HTTP 200 OK, the load balancer marks the instance as unresponsive and stops sending traffic to that instance.
      • The load balancer will continue to ping the instance. If the guest agent responds with an HTTP 200, the load balancer will send traffic to that instance again.
      • When you’re using a web role, your website code typically runs in w3wp.exe, which is not monitored by the Azure fabric or guest agent. This means that failures in w3wp.exe (e.g. HTTP 500 responses) will not be reported to the guest agent, and the load balancer will not know to take that instance out of rotation.
    • HTTP custom probe: This probe overrides the default (guest agent) probe. You can use it to create your own custom logic to determine the health of the role instance. The load balancer will regularly probe your endpoint (every 15 seconds, by default). The instance will be considered in rotation if it responds with a TCP ACK or HTTP 200 within the timeout period (default of 31 seconds).
    • TCP custom probe: This probe relies on successful TCP session establishment to a defined probe port.
  • Source NAT: All outbound traffic to the Internet that originates from your service undergoes source NAT (SNAT) by using the same VIP address as for incoming traffic.
    • It enables easy upgrade and disaster recovery of services, since the VIP can be dynamically mapped to another instance of the service.
    • It makes access control list (ACL) management easier, since the ACL can be expressed in terms of VIPs and hence do no change as services scale up or down or get redeployed.
    • The load balancer configuration supports full cone NAT for UDP. Full cone NAT is a type of NAT where the port allows inbound connections from any external host (in response to an outbound request).
    • For each new outbound connection that a VM initiates, an outbound port is also allocated by the load balancer. The external host will see traffic with a virtual IP (VIP)-allocated port. If your scenarios require a large number of outbound connections, we recommend that the VMs use instance-level public IP addresses so that they have a dedicated outbound IP address for SNAT. This will reduce the risk of port exhaustion.
    • The maximum number of ports that can be used by the VIP or an instance-level public IP (PIP) is 64,000. This is a TCP standard limitation.
  • Public load balancer: A public load balancer maps the public IP address and port number of incoming traffic to the private IP address and port number of the virtual machine and vice versa for the response traffic from the virtual machine.
    • You can associate a public IP address with an Azure Load Balancer, by assigning it to the load balancer frontend configuration.
    • The public IP address serves as a load-balanced virtual IP address (VIP).
    • You can assign either a dynamic or a static public IP address to a load balancer front-end.
    •  You can also assign multiple public IP addresses to a load balancer front-end, which enables multi-VIP scenarios like a multi-tenant environment with SSL-based websites.
  • Internal load balancer: Internal Load Balancer only directs traffic to resources that are inside a virtual network or that use a VPN to access Azure infrastructure.
    • You can assign a private IP address to the front end configuration of an Azure Internal Load Balancer (ILB) or an Azure Application Gateway.
    • This private IP address serves as an internal endpoint, accessible only to the resources within its virtual network (VNet) and the remote networks connected to the VNet.
    • You can assign either a dynamic or static private IP address. to the front end configuration.
• Application Gateway: Build secure, scalable, and highly available web front ends in Azure.
  • Azure application gateway is a dedicated virtual appliance providing application delivery controller (ADC) as a service.
  • It offers various Layer 7 load balancing capabilities for your application.
  • It allows customers to optimize web farm productivity by offloading CPU-intensive SSL termination to the application gateway.
  • It also provides other Layer 7 routing capabilities including round robin distribution of incoming traffic, cookie-based session affinity, URL path-based routing, and the ability to host multiple websites behind a single application gateway.
  • Application gateway can be configured as an Internet-facing gateway, internal-only gateway, or a combination of both.
  • A web application firewall (WAF) is also provided as part of the application gateway WAF SKU. It provides protection to web applications from common web vulnerabilities and exploits.
  • Your virtual network and public IP address must be in the same location as your gateway. Ensure that virtual network subnet to be used with Application Gateway is empty that’s it contains no other resources.
  • Works at Application Layer (layer 7) and works as reverse proxy service.
  • Application gateways provide load-balanced solutions for network traffic that is based on the HTTP/HTTPS protocol.
  • They use routing rules as application-level policies that can offload Secure Sockets Layer (SSL) processing from load-balanced VMs.
  • In addition, you can use application gateways for a cookie-based session affinity scenario.
  • You can associate a public IP address with an Azure Application Gateway, by assigning it to the gateway’s frontend configuration. This public IP address serves as a load-balanced VIP. Currently, you can only assign a dynamic public IP address to an application gateway frontend configuration.
  • The default health monitoring tests servers every 30 seconds for a healthy HTTP response. A healthy HTTP response has a status code between 200 and 399.
  • Your virtual network and public IP address must be in the same location as your Application Gateway.
  • HTTP layer 7 load balancing is useful for:
    • HTTP load balancing: Applications, such as a content delivery network, that requires multiple HTTP requests on the same long-running TCP connection to be routed or load balanced to different back-end servers.
      • URL-based content routing
      • Multi-site routing
    • Cookie-based session affinity: Applications that require requests from the same user/client session to reach the same back-end virtual machine. Examples of these applications would be shopping cart apps and web mail servers.
    • Secure Sockets Layer (SSL) offload: Applications that want to free web server farms from SSL termination overhead.
  • Application Gateway Requirements:
    • Back-end server pool: The list of IP addresses of the back-end servers. The IP addresses listed should either belong to the virtual network subnet or should be a public IP/VIP.
    • Back-end server pool settings: Every pool has settings like port, protocol, and cookie-based affinity. These settings are tied to a pool and are applied to all servers within the pool.
    • Front-end port: This port is the public port that is opened on the application gateway. Traffic hits this port, and then gets redirected to one of the back-end servers.
    • Listener: The listener has a front-end port, a protocol (Http or Https, these are case-sensitive), and the SSL certificate name (if configuring SSL offload).
    • Rule: The rule binds the listener and the back-end server pool and defines which back-end server pool the traffic should be directed to when it hits a particular listener.
• Traffic Manager: Route incoming traffic for high performance and availability.
  • Create a Traffic Manager profile to define the routing method used to distribute user traffic to service endpoints in different datacenters. Distribute traffic to your endpoints by performance, weighted value, priority, or geography. Traffic Manager endpoints can be Azure virtual machines, web apps, cloud services, and external non-Azure endpoints.
  • You can use Traffic Manager to load balance between endpoints that are located in different Azure regions, at hosted providers, or in on-premises datacenters. These endpoints can include Azure VMs, Web Apps, and cloud services.
  • Azure Traffic Manager service is global and not bound to a location. However, you must specify a location for the resource group where the metadata associated with the Traffic Manager profile will reside. This location will have no impact on the runtime availability of your profile.
  • You can configure this load-balancing service to support priority or to ensure that users connect to an endpoint that is close to their physical location for faster response.
  • Traffic Manager works at the DNS level. Traffic Manager uses DNS to direct end users to particular service endpoints. Clients then connect to the selected endpoint directly. Traffic Manager is not a proxy, and does not see the traffic passing between the client and the service.
  • When using a vanity domain with Azure Traffic Manager, you must use a CNAME to point your vanity domain name to your Traffic Manager domain name. Due to a restriction of the DNS standards, a CNAME cannot be created at the ‘apex’ (or root) of a domain.
    • Thus you cannot create a CNAME for ‘contoso.com’ (sometimes called a ‘naked’ domain). You can only crate a CNAME for a domain under ‘contoso.com’, such as ‘www.contoso.com’.
    • Thus you cannot use Traffic Manager directly with a naked domain. To work around this, we recommend using a simple HTTP re-direct to direct requests for ‘contoso.com’ to an alternative name such as ‘www.contoso.com’.
  • Traffic Manager provides two key benefits:
    • Distribution of traffic according to one of several traffic-routing methods
      • Ensure the user is directed to the closest version of an app
    • Continuous monitoring of endpoint health and automatic failover when endpoints fail
      • Stop routing users to a location if traffic goes down
  • Routing methods:
    • Performance, Weighted, Priority, Geographic, MultiValue, Subnet
  • Endpoints: Traffic Manager endpoints can be Azure virtual machines, web apps, cloud services, and external non-Azure endpoints.
    • Target resource type: Cloud Service, App Service, App Service slot, Public IP Address
  • Traffic view: Enable Traffic view to view location, volume and latency information for the connections between your users and Traffic Manager endpoints.
• Azure DNS: Host your DNS domain in Azure.
  • The Domain Name System (DNS) enables clients to resolve user-friendly fully qualified domain names (FQDNs), such as http://www.adatum.com, to IP addresses.
  • Names of resources that are created in Azure can be resolved by using Azure-provided name resolution or by using a customer provided DNS server.
  • Azure provides a DNS system to support many name resolution scenarios. However, in some cases, such as hybrid connection you might need to configure an external DNS system to provide name resolution for virtual machines on a virtual network.
  • In a hybrid scenario where your on-premises network is connected to an Azure virtual network through a VPN or ExpressRoute circuit, an on-premises computer cannot resolve the name of a VM in an Azure virtual network until you configure the DNS servers with a record for the VM.
  • Resources created in the same virtual network and deployed with Azure Resource Manager (ARM) share the same DNS suffix; therefore, in most cases name resolution by using FQDN is not required.
  • For virtual networks that are deployed by using the Azure classic deployment model, the DNS suffix is shared among VMs that belong to the same cloud service. Therefore, name resolution between VMs that belong to different cloud services in the same virtual network require the use of FQDN.
  • A DNS server should have a static IP address because clients may not be able to locate it if its address changes.
  • Azure DNS does not currently support purchasing of domain names. If you want to purchase domains, you’ll need to use a third-party domain name registrar. The domains can then be hosted in Azure DNS for management of DNS records.
  • Azure uses Anycast networking so that each DNS query is answered by the closest available DNS server. This provides both fast performance and high availability for your domain.
  • The root zone contains NS records for ‘com‘ and shows the name servers for the ‘com’ zone. In turn, the ‘com’ zone contains NS records for ‘contoso.com’, which shows the name servers for the ‘contoso.com’ zone. Setting up the NS records for a child zone in a parent zone is called delegating the domain.
  • Name Resolution Scenarios:
    • VMs in the same cloud service. VMs can resolve the names of all other VMs in the same cloud service automatically by using the internal Azure name resolution.
    • VMs in the same VNet. If the VMs are in different cloud services but within a single VNet, those VMs can resolve IP addresses for each other by using the internal Azure name resolution service and their Fully Qualified Domain Names (FQDNs). This is supported only for the first 100 cloud services in the VNet. Alternatively, use your own DNS system to support this scenario.
    • Between VMs in a VNet and on-premises computers. To support this scenario you must use your own DNS system.
    • Between VMs in different VNets. To support this scenario you must use your own DNS system.
    • Between on-premises computers and public endpoints. If you publish an endpoint from a VM in an Azure VNet, the Azure-provided external name resolution service will resolve the public VIP. This also applies for any internet-connected computers that are not on your premises.
    • If two VMs are deployed in different IaaS cloud services but not in a VNet, they cannot communicate at all, even by using DIPs. Therefore name resolution is not applicable.
  • If you are planning to use your own DNS system, you must ensure that all computers can reach a DNS server for registering and resolving IP addresses. You can either deploy DNS on a VM in the Azure VNet or have VM register their addresses with an on-premises DNS server.
  •  Your DNS server must meet the following requirements:
    • The server must support Dynamic DNS (DDNS) registration.
    • The server must have record scavenging switched off. Because DHCP leases in an Azure VNet are infinite, record scavenging can remove records that have not been renewed but are still correct.
    • The server must have DNS recursion enabled.
    • The server must be accessible on TCP/UDP port 53 from all clients.
  • Domains and Zones: The Domain Name System is a hierarchy of domains.
    • The hierarchy starts from the ‘root’ domain, whose name is simply ‘.’.
    • Below this come top-level domains, such as com, net, org, uk or jp.
    • Below these are second-level domains, such as org.uk or co.jp. And so on.
    • The domains in the DNS hierarchy are hosted using separate DNS zones. These zones are globally distributed, hosted by DNS name servers around the world.
  • Domain registrar: A domain registrar is a company who can provide Internet domain names.
    • They will verify if the Internet domain you want to use is available and allow you to purchase it.
    • Once the domain name is registered, you will be the legal owner for the domain name. If you already have an Internet domain, you will use the current domain registrar to delegate to Azure DNS.
  • Zone Delegation: Azure DNS allows you to host a DNS zone and manage the DNS records for a domain in Azure. In order for DNS queries for a domain to reach Azure DNS, the domain has to be delegated to Azure DNS from the parent domain.
    • To delegate authority to DNS zone hosted in Azure, you contact the registrar for your domain name to configure the name server (NS) records with NS records listed in the zone created in Azure.
    • NS records are created by default when DNS zone is created
    • Each delegation actually has two copies of the NS records; one in the parent zone pointing to the child, and another in the child zone itself.  The abc.com zone contains the NS records for abc.com (in addition to the NS records in com).
    • Each registrar has their own DNS management tools to change the name server records for a domain. In the registrar’s DNS management page, edit the NS records and replace the NS records with the ones Azure DNS created.
  • Record: Its property of a record set and list of individual records.
  • Record Sets: Its child resource of a DNS Zone, and is the collection of records with the same name and type.  For example:
    • http://www.abc.com.  3600
      IN   A   12.14.45.6
    • http://www.abc.com.  3600
      IN   A   18.16.56.69
  • DNS Zones: Its used to host the DNS records for a particular domain.
    • A domain is a unique name in the Domain Name System, for example contoso.com. A DNS zone is used to host the DNS records for a particular domain. For example, the domain contoso.com may contain a number of DNS records such as mail.contoso.com (for a mail server) and http://www.contoso.com (for a website).
    • You do not have to own a domain in order to create a DNS zone with that domain name in Azure DNS. However, you do need to own the domain to set up the delegation to Azure DNS with the registrar.
  • DNS Servers:
    • Authoritative DNS server hosts DNS zones. It answers DNS queries for records in those zones only.
    • Recursive DNS server does not host DNS zones. It answers all DNS queries by calling authoritative DNS servers to gather the data it needs.
    • Azure DNS provides an authoritative DNS service. It does not provide a recursive DNS service.
    • Cloud Services and VMs in Azure are automatically configured to use a recursive DNS that is provided separately as part of Azure’s infrastructure.
  • Supports Etags to prevent accidental concurrent changes.
• VPN Gateway: Establish secure, cross-premises connectivity.
  • Azure VPN Gateway is used to connect an Azure virtual network (VNet) to other Azure VNets or to an on-premises network.
  • Virtual networks in Microsoft Azure also enable you to extend your on-premises networks to the cloud. To extend your on-premises network, you can create a virtual private network (VPN) between your on-premises computers or networks and an Azure virtual network.
  • The VPN gateway routes traffic between VMs and PaaS cloud services in the virtual network, and computers at the other end of the connection.
  • A virtual network gateway is the software VPN device for your Azure virtual network.
  •  You need to assign a public IP address to its IP configuration to enable it to communicate with the remote network. Currently, you can only assign a dynamic public IP address to a VPN gateway.
  • All VPN connections require a virtual gateway in the virtual network, which routes traffic to the on-premises computers.
  • The following VPN connections are available: Point-to-site, Site-to-site, VNet-to-Vnet, IaaS v1 VNet-to-IaaS v2 VNet, Multisite, and ExpressRoute.
  • Considerations for inter-site connection:
    • Azure supports a maximum of 30 VPN tunnels per VPN gateway. Each point-to-site VPN, site-to-site VPN, or VNet-to-VNet VPN counts as one of those VPN tunnels. A single VPN gateway can support up to 128 connections from client computers.
    • Address spaces must not overlap.
    • Redundant tunnels are not supported.
    • All VPN tunnels to a virtual network share the available bandwidth on the Azure VPN gateway.
    • VPN devices must meet certain requirements. These requirements are listed on the Microsoft website
  • VPN Type:
    • Route-based: Point-to-site, inter-virtual network, and multiple site-to-site VPN connections are only supported with a route-based virtual network gateway.
      • In addition, if you are creating a VPN-type gateway to coexist with an ExpressRoute gateway, the VPN gateway must be route-based and the ExpressRoute gateway must be created first.
      • SKU: Route-based VPN gateway types are offered in three SKUs: Basic, Standard, and High Performance. Standard or High Performance must be chosen if the gateway is being created to coexist with an ExpressRoute gateway.
    • Policy-based:
      • SKU: Basic only
  • Point-to-Site VPN (P2S): This is a VPN that connects individual computers to an Azure virtual network.
    • No extra hardware is required but you must complete the configuration procedure on every computer that you want to connect to the VNet.
    • Can be used by the client computer to connect to a VNet from any location with an Internet connection.
    • Each client that connects to Azure by using Point-to-Site must have two things: the VPN client must be configured to connect, and the client must have a client certificate installed. VPN client configuration packages are available for Windows clients.
    • Configuration:
      • Configure an IP address space for clients
      • Configure a virtual gateway
      • Create root and client certificates
      • Create and install VPN client configuration
      • Connect to the VPN
  • Site-to-Site VPN (S2S): This is a VPN that connects an on-premises network and all its computers to an Azure virtual network.
    • A Site-to-Site (S2S) connection is a connection over IPsec/IKE (IKEv1 or IKEv2) VPN tunnel.
    • This type of connection requires a VPN device located on-premises that has a public IP address assigned to it and is not located behind a NAT.
    • S2S connections can be used for cross-premises and hybrid configurations.
    • To create this connection, you must configure a gateway and IP routing in the on-premises network; it is not necessary to configure individual on-premises computers.
    •  You can use a Windows Server 2012 computer running RRAS as a gateway to the VNet. Alternatively, there are a range of third-party VPN devices that are known to be compatible.
    •  If you have a VPN device that is not on the known compatible list, you may be able to use it if it satisfies the list of gateway requirements.
    • If you have overlapping subnets, your connection won’t work properly.
    • To configure your VPN device, you’ll need the public IP address of the virtual network gateway for configuring your on-premises VPN device. Work with your device manufacturer for specific configuration information and configure your device.
    • To verify the connection run the following command:
      • Get-AzureRmVirtualNetworkGatewayConnection -Name MyGWConn -ResourceGroupName MyRG
    • Configuration of a Site-to-Site VPN:
      • An IP addressing scheme in the VNet.
      • The range of IP addresses that are available on the local, on premises subnet.
      • A gateway in the local subnet.
      • A virtual gateway in the VNet.
    • Gateway Subnet: You need to create a gateway subnet for the virtual network to which you want to connect. The gateway subnet you create must be named GatewaySubnet or it won’t work properly.
      • The gateway subnet prefix needs to be /28, /27, /26 etc.
      • Associating a Network Security Group (NSG) to the GatewaySubnet will cause your VPN gateway to stop functioning as expected. DO NOT associate NSGs to Gateway subnets.
    • Virtual Network Gateway: A virtual network gateway is the software VPN device for your Azure virtual network.
      • Use this with a connection to set up a site-to-site VPN connection between an Azure virtual network and your local network, or a VNet-to-VNet VPN connection between two Azure virtual networks.
      • It can also be used to connect a virtual network to an ExpressRoute circuit.
      • Because the virtual gateway is configured with the IP addresses in the VNet and the IP addresses in the local network, it can route packets from Azure to the local network.
    • Local Network Gateway: It represents the hardware or software VPN device in your local network.
      • Use this with a connection to set up a site-to-site VPN connection between an Azure virtual network and your local network.
      • There are no additional charges for creating local network gateways in Microsoft Azure.
      • IP address: If this local network represents an on-premises location, this is the public IP address of the VPN device that you want to connect to. It cannot be behind NAT and has to be reachable by Azure. If this local network represents another VNet, you will specify the public IP address that was assigned to the virtual network gateway for that VNet.
      • Address space: refers to the address ranges for the network that this local network represents. You can add multiple address space ranges. Make sure that the ranges you specify here do not overlap with ranges of other networks that you want to connect to.
  • VNet-to-VNet:
    • Connecting a virtual network to another virtual network (VNet-to-VNet) is similar to connecting a VNet to an on-premises site location.
    •  Both connectivity types use an Azure VPN gateway to provide a secure tunnel using IPsec/IKE.
    • You can even combine VNet-to-VNet communication with multi-site configurations. This lets you establish network topologies that combine cross-premises connectivity with inter-virtual network connectivity.
    • The VNets you connect can be in the same or different Regions, Subscriptions or Deployment Models.
    • A cloud service or a load balancing endpoint CANNOT span across virtual networks, even if they are connected together.
    • VNet-to-VNet requires Azure VPN gateways with RouteBased (previously called Dynamic Routing) VPN types.
    • VNet-to-VNet traffic travels across the Microsoft Network, not the Internet.
    • VNet-to-VNet traffic within the same region is free for both directions; cross region VNet-to-VNet egress traffic is charged with the outbound inter-VNet data transfer rates based on the source regions.
    • Virtual network connectivity can be used simultaneously with multi-site VPNs, with a maximum of 10 (Default/Standard Gateways) or 30 (High Performance Gateways) VPN tunnels for a virtual network VPN gateway connecting to either other virtual networks or on-premises sites.
    • The address spaces of the virtual networks and on-premises local network sites must not overlap. Overlapping address spaces will cause the creation of VNet-to-VNet connections to fail.
    • Redundant tunnels between a pair of virtual networks are not supported.
    • When you configure a VNet-to-VNet connection, you must specify the IP address spaces in use for private IP addresses on the opposite virtual networks so that the virtual gateway can route traffic to the correct location. In the user interface, this is referred to as the local network.
    • Configurations:
      • An IP addressing scheme in the West US VNet.
      • An IP addressing scheme in the North Europe VNet.
      • A virtual gateway in the West US VNet.
      • A virtual gateway in the North Europe VNet.
    • You may want to connect virtual networks for the following reasons:
      • Cross region geo-redundancy and geo-presence
      • Regional multi-tier applications with isolation or administrative boundary
• ExpressRoute: Dedicated private fiber network connections to Azure.
  • Microsoft Azure ExpressRoute lets you extend your on-premises networks into the Microsoft cloud over a dedicated private connection facilitated by a connectivity provider.
  • With ExpressRoute, you can establish connections to Microsoft Azure services, Microsoft Office 365, and Microsoft CRM Online.
  • Connectivity can be from an any-to-any (IP VPN) network, a point-to-point Ethernet network, or a virtual cross-connection through a connectivity provider at a co-location facility.
  • ExpressRoute connections do not go over the public Internet. This allows ExpressRoute connections to offer more reliability, faster speeds, lower latencies, and higher security than typical connections over the Internet.
  • You can connect to Microsoft in one of our peering locations and have access to all regions within the geopolitical region. For example, if you connected to Microsoft in Amsterdam through ExpressRoute, you will have access to all Microsoft cloud services hosted in Northern Europe and Western Europe.
  • You can enable the ExpressRoute premium add-on feature to extend connectivity across geopolitical boundaries. For example, if you are connected to Microsoft in Amsterdam through ExpressRoute, you will have access to all Microsoft cloud services hosted in all regions across the world.
  • You can purchase ExpressRoute circuits for a wide range of bandwidths i.e 50 Mbps – 10 Gbps.
  • Connection Options:
    • Connectivity providers can offer one or more connectivity models. You can work with your connectivity provider to pick the model that works best for you.
    • ExpressRoute capabilities and features are all identical across all of the below connectivity models.
    • Co-located at a cloud exchange: If you are co-located in a facility with a cloud exchange, you can order virtual cross-connections to the Microsoft cloud through the co-location provider’s Ethernet exchange. Co-location providers can offer either Layer 2 cross-connections, or managed Layer 3 cross-connections between your infrastructure in the co-location facility and the Microsoft cloud.
    • Point-to-point Ethernet connections: You can connect your on-premises datacenters/offices to the Microsoft cloud through point-to-point Ethernet links. Point-to-point Ethernet providers can offer Layer 2 connections, or managed Layer 3 connections between your site and the Microsoft cloud.
    • Any-to-any (IPVPN) networks: You can integrate your WAN with the Microsoft cloud. IPVPN providers (typically MPLS VPN) offer any-to-any connectivity between your branch offices and datacenters. The Microsoft cloud can be interconnected to your WAN to make it look just like any other branch office. WAN providers typically offer managed Layer 3 connectivity.
  • Features:
    • Layer 3 connectivity: Microsoft uses industry standard dynamic routing protocol (BGP) to exchange routes between your on-premises network, your instances in Azure, and Microsoft public addresses. Azure establish multiple BGP sessions with your network for different traffic profiles.
    • Redundancy: Each ExpressRoute circuit consists of two connections to two Microsoft Enterprise edge routers (MSEEs) from the connectivity provider / your network edge. Microsoft will require dual BGP connection from the connectivity provider / your side – one to each MSEE. You may choose not to deploy redundant devices / Ethernet circuits at your end. A redundant Layer 3 connectivity configuration is a requirement for our SLA to be valid.
    • Dynamic scaling of bandwidth: You have the ability to increase the ExpressRoute circuit bandwidth (on a best effort basis) without having to tear down your connections.
• Virtual Appliance:
  • A pre-configured virtual machine image, ready to run on a hypervisor, virtual appliances are a subset of the broader class of software appliances.
    • Replicate on-premises equipment in the Azure cloud
    • Leaverage existing expertise and configurations
    • Need for more robust network services
    • Load balancer, firewall, Application Delivery Controller (ADC), WAN optimizer
    • Its deployed into its own subnet in the virtual network
    • You need to define user-defined routes by defining next hop in Route Tables
    • You need to enable IP forwarding in virtual appliance
• Content Delivery Network: Ensure secure, reliable network delivery with broad global reach.
• Network Watcher: Network performance monitoring and diagnostic solution.
• DDOS Protection: Protect your applications from Distributed Denial of Service (DDoS) attacks.

Azure Virtual Machines

• Azure Virtual Machines:
  • Azure Compute Unit (ACU) to provide a way of comparing compute (CPU) performance across Azure SKUs and to identify which SKU is most likely to satisfy your performance needs.
  • VM Series:
    • A Series: Entry level for Dev/Test
    • D Series: General purpose/Balanced (Infrastructure)
    • F Series: Optimized for compute (Web Apps, Analytics, Gaming)
    • G Series: Optimized for memory and storage (SQL, ERP, SAP)
    • H Series: High performance (Modeling, AI)
    • L Series: Storage optimized (Data warehousing, Cassandara, MongoDB)
    • G Series: GPU enabled (Graphics, Videos)
  • VM Sizes:
    • General Purpose: (B, DSv3, DSv2, Dv3, Dv2, DS, D, Av2, A0-7)
      • Balanced CPU-to-memory ratio.
      • Ideal for testing and development, small to medium databases, and low to medium traffic web servers.
    • Compute optimized: (Fsv2, Fs, F)
      • High CPU-to-memory ratio.
      • Good for medium traffic web servers, network appliances, batch processes, and application servers.
    • Memory optimized: (Esv3, Ev3, M, GS, G, DSv2, DS, Dv2, D)
      • High memory-to-CPU ratio.
      • Great for relational database servers, medium to large caches, and in-memory analytics.
    • Storage optimized: (Ls)
      • High disk throughput and I/O.
      • Ideal for Big Data, SQL, and NoSQL databases.
    • GPU: (NV, NC)
      • Specialized virtual machines targeted for heavy graphic rendering and video editing. Available with single or multiple GPUs.
    • High performance compute: (H, A8-11)
      • Fastest and most powerful CPU virtual machines with optional high-throughput network interfaces (RDMA).
  • Deploying VMs:
    • Azure portal: Used to create IaaS v2 (ARM) virtual machines.
    • Azure PowerShell: Can be used to create virtual machines using either Azure Service Manager (ASM) to create IaaS v1 or the Azure Resource Manager IaaS v2 virtual machines.
    • Azure CLI
    • Visual Studio
    • Azure Resource Manager templates:
      • ARM template max size can be 1 MB.
  • Connecting VMs to your infrastructure:
    • Site to Site VPN
    • Azure vNet with multiple VMs
    • Azure based DC or on-premises DC
    • ExpressRoute
  • VM images:
    • Image Types:
      • OS images: Includes only a generalized OS
      • VM images: Includes an OS and all disks attached
    • Image Sources:
      • Azure Marketplace: Contains recent version for Windows Server and Linux distributions
      • VM Depot: Community managed repository of Linux and FreeBSD VM images
    • Custom image:
      • Image you create and upload for use in Azure.
  • Availability Sets: Its a logical group of virtual machines that are deployed across fault domains and update domains. Availability sets make sure that your application is not affected by single points of failure, like the network switch or the power unit of a rack of servers.
    • Create an availability set to provide redundancy for your application. Create two or more virtual machines in the availability set to distribute their placement across Azure hardware clusters.
    • For redundancy, configure multiple virtual machines in an Availability Set.
    • Configure each application tier into separate Availability Sets.
    • Combine a Load Balancer with Availability Sets.
    • Microsoft have a SLA in place for availability sets that’s 99.95% and for premium disks, its 99.9%.
    • Each virtual machine in an availability set is placed in one update domain and two fault domains.
    • Update domain: Virtual machines in the same update domain will be restarted together during planned maintenance. Azure never restarts more than one update domain at a time.
      • Update domains are VMs that shares the same hardware host (1-20 update domains are available).
      • It allows Azure to perform incremental or rolling upgrades across a deployment.  Each update domain contains a set of virtual machines and associated physical hardware that can be updated and rebooted at the same time.
      • During planned maintenance, only one update domain is rebooted at a time. By default there are five update domains, but you configure up to twenty update domains.
    • Fault domain: Virtual machines in the same fault domain shares a common power source and physical network switch.
      • It defines a group of virtual machines that share a common set of hardware, switches, and more that share a single point of failure.
      • For example, a server rack serviced by a set of power or networking switches.
      • VMs in an availability set are placed in at least two fault domains. This mitigates against the effects of hardware failures, network outages, power interruptions, or software updates.
      • 1-3 fault domains per availability set.
  • Virtual Machine Scale Set is an Azure compute resource you can use to deploy and manage a set of identical VMs. With all VMs configured the same, VM scale sets are designed to support true auto-scale – no pre-provisioning of VMs is required – making it easier to build large-scale services targeting resource-intensive compute, data, and containerized workloads.
    • You can create both Linux and Windows VM Scale Sets from the Azure Portal. These scale sets are automatically created with load balancer NAT rules to enable SSH or RDP connections.
    • You can set the maximum, minimum and default number of VMs, and define triggers – action rules based on resource consumption.
    • When you increase the number of virtual machines in a scale set, VMs are balanced across update and fault domains to ensure, maximum availability. Similarly when you scale in, VMs are removed with maximum availability in mind.
    • Scale set are often integrated with Azure Insight, Load Balancer and NAT rules. Azure Insight is used to measure when to scale up or scale down. The Load Balance and NAT rules work together to spread the workload over the available machines as they are added.
    • A method for deploying VMs as  a set.
    • Use Cases:
      • Hyperscale workload
      • Stateless web front ends
      • Container orchestration
      • Microservices clusters
    • Azure Resource Explorer is a great tool to view and modify resources you have created in your subscription. The tool is web-based and uses your Azure portal logon credentials. This tool is particularly useful in viewing Azure scale sets. With the tool you can see the individual virtual machines and their properties.
  • Types of IP Addresses:
    • Public IP addresses: Used for communication with the Internet, including Azure public-facing services, like SQL Services. You can associate public IP addresses with virtual machines, internet facing load balancers, VPN gateways, and application gateways.
      • Dynamic allocation: the IP address is not allocated at the time of its creation. Instead, the public IP address is allocated when you start (or create) the associated resource (like a VM or load balancer). The IP address is released when you stop (or delete) the resource. This means the IP address can change.
      • Static allocation: the IP address for the associated resource does not change. In this case an IP address is assigned immediately. It is released only when you delete the resource or change its allocation method to dynamic.
    • Private IP addresses: Used for communication within an Azure virtual network (VNet), and your on-premises network when you use a VPN gateway or ExpressRoute circuit to extend your network to Azure. You can associate private IP addresses with virtual machines, internal load balancers, and application gateways.
      • The default allocation method is dynamic, where the IP address is automatically allocated from the resource’s subnet (using DHCP). This IP address can change when you stop and start the resource.
      • You can set the allocation method to static to ensure the IP address remains the same. In this case, you also need to provide a valid IP address that is part of the resource’s subnet.
  • Configuration Management Tools: Deploying and maintaining the desired state of your servers and application resources can be tedious and error prone. Azure supports several configuration management systems.
    • Desired State Configuration (DSC): With Azure automation Desired State Configuration (DSC), you can consistently deploy, reliably monitor, and automatically update the desired state of all your IT resources, at scale from the cloud. DSC is a VM agent extension and works on both Windows and Linux. DSC supports ARM templates, Azure PowerShell, and XPLAT-CLI.
    • Chef and Puppet: Chef are Puppet are other configuration management tools that lets you automate the entire lifecycle of your Azure infrastructure, from initial provisioning through application deployment. Both are popular Linux tools and VM agent extensions.
    • Ansible: Ansible is an open source, clientless automation tool that automates software and OS features provisioning, configuration management, and application deployment. Ansible includes a suite of modules for interacting with Azure Resource Manager, making possible to create and orchestrate infrastructure in Azure.
  • Monitoring and Diagnostics: The administrator enables and configures VM diagnostics from the Monitoring area of the new portal VM blade. An administrator can enable diagnostic logging for: Basic metrics, Network and web metrics, .NET metrics, Windows event system logs, Windows event security logs, Windows event application logs, Diagnostic infrastructure logs:
    • You can access host-level metrics from VMs (Azure Resource Manager-based) and virtual machine scale sets without any additional diagnostic setup.
    • These new host-level metrics are available for Windows and Linux instances. These metrics are not to be confused with the Guest-OS-level metrics that you have access to when you turn on Azure Diagnostics on your VMs or virtual machine scale sets.
    • Alerts: You can receive an https://azure.microsoft.com/en-us/documentation/articles/insights-receive-alert-notifications/ When the value of an alert rule crosses an assigned threshold, the alert rule becomes active and can send a notification. For an alert rule on events, a rule can send a notification on every event, or, only when a certain number of events happen.
      • When you create an alert rule, you can select options to send an email notification to the service administrator and co-administrators or to another administrator that you can specify. A notification email is sent when the rule becomes active, and when an alert condition is resolved.
      • For example, this alert rule will trigger when the CPU percentage guest OS value is greater than 75% in a five minute period.
      • It supports alerts via SMS, Emails and Webhook (Automation Runbook, Function, Logic App, Third party URL)
  • Security Groups: Its a group of rules that can be applied to Interfaces, vNets and Subnets.
  • Backups: Based on Recovery Services Vault. Retention Range can be either daily, weekly or monthly backup point.
  • Enable Update Management: Its enable per VM. Create Operations Management Suite (OMS) workspace and install OMS agents. Takes 15-30 mins to report results. Scans every 12 hrs by default.
  • Change Tracking: Helps identify changes in your environment (Windows and Linux) for debugging, troubleshooting and compliance. Tracks Software, File, Registry Keys (Windows) and Services/Daemons. All data is sent to Log Analytics service.
  • Extensions: VM Agent Extensions are software components that extend the VM functionality and management operations. An administrator can install multiple extensions on a VM. Currently available extensions include management tools such as Desired State Configuration (DSC), Chef, and Puppet.
    • VM Agent: Its a secured, light-weight process that installs, configures, and removes VM extensions on instances of Azure virtual machines. It intended to bootstrap these additional extensions, offered both by Microsoft and partners. The extensions that the agent loads provide specific features to increase your productivity using the instance.
  • Azure Cross-Platform Command-Line Interface (XPLAT-CLI) provides a set of open source, cross-platform commands for working with Azure. Although available for all platforms, XPLAT-CLI is primarily for use with Linux-based VMs, as Windows VMs are usually managed with Azure PowerShell commands.
  • Although Azure virtual machines are based on Windows Server Hyper-V but not all Hyper-V features are supported. For example, Multipath I/O and Network Load Balancing are not currently supported.
  • Upgrade of the Windows operating system of a Microsoft Azure virtual machine is not supported. Instead, you should create a new Azure virtual machine that is running the supported version of the operating system that is required and then migrate the workload.
  • Linux endorsed distributions supports an upgrade of the operating system of a Microsoft Azure virtual machine in case of full open source license. If licensed Linux distribution is used, then follow partner-specific rules to upgrade (BYOL or other).
  • Some of the physical hosts in the Azure data centers may not support larger virtual machine sizes, such as A5 to A11. If that happens you may get an error message such as Failed to configure virtual machine or Failed to create virtual machine.
  • Fixed size VHD disk is uploaded to Azure (VHDX disk is not supported but you can convert it using PowerShell cmdlet)
  • Source virtual machines must be generalized using Sysprep. If using ARM, must also set the status of virtual machine to generalized using the Set-AzureRMVm cmdlet.
  • For capturing IaaS v2 Azure virtual machines, you must use PowerShell or Azure Resource Explorer.
  • All Linux distributions available in Azure image gallery are endorsed distributions and Azure Platform SLA (e.g up time availability) applies only to endorsed Linux distributions. Non-endorsed distributions may run on Azure, if they meet a number of -re-requisites.
  • Azure provides a large image gallery in the Marketplace. The gallery includes recent operating system images of Windows Server, Linux, and SQL Server. You can also store your own images in Azure, by capturing an existing virtual machine and uploading the image.

Azure PowerShell and CLI

• Install PowerShell on Ubuntu 16:
  • wget https://github.com/PowerShell/PowerShell/releases/download/v6.0.2/powershell_6.0.2-1.ubuntu.16.04_amd64.deb
  • sudo apt-get update
  • sudo dpkg -i powershell_6.0.2-1.ubuntu.16.04_amd64.deb
  • sudo apt-get install -f
• Powershell Basic cmdlets:
  • pwsh                                                  (Start the PowerShell console)
  • verb-noun -param Arg1, Arg2  (General syntax)
  • Alias:
    • Get-Alias | gal
    • Get-Alias -Definition Get-Process   (Get alias for Get-Process cmdlet)
    • gal ls
    • gal sa*                                                  (List alias starting with sa)
    • pwd: Get-Location
    • cls: Clear-Host
    • dir: Get-ChildItem
    • ps: Get-Process
    • copy: Copy-Item
  • Get-Help:
    • Update-Help -force
    • help  g*process                                    (Get-Help)
    • Get-Help  Get-Process  [-Detailed | -full | -Online | -ShowWindow ]
    • Get-Verb | measure
    • Get-Noun | measure
  • Command:
    • Get-Command -Noun process
    • Get-Command -Verb new
    • Get-Command                        (List all available commands)
    • Get-Command Get-Windows*
  •  Module:
    • Import-Module ServerManager
    • Get-WindowsFeature
    • Add-WindowsFeature Web-Server, telnet-client
    • foreach  {Get-Command  -Module $_}
    • Get-Module -List-Available -Name Azure*
    • Get-InstalledModule -Name AzureRm
    • (Get-Module AzureRm).version
    • Install psm1 module files:
      • Create a folder same as module name in as:
        C:\Users\users1\Documents\WindowsPowerShell\Modules\MyMod1\MyMod1.psm1
  • Process | Service | WmiObject:
    • Get-Process | Sort-Object cpu [pm|handles, ProcessName]
    • Get-Process | Where-Object -EQ ProcessName notepad | Stop-Process
    • Get-Process | Where {$_.handles -gt 1000} | sort handles
      • Get-Process | Where handles -gt 1000 | sort handles
    • Get-Process -Name notepad|Out-File -FilePath process.txt (cat process.txt)
    • Get-Service | Select name,status
    • Get-Service | Where {$_.status -eq “Running” -and $PSItem.name -like “b*”}
    • Get-Service | select @{n=’Services’;e={$_.name}}, Status
    • Get-Service > d:\services.txt
    • Get-Service -Out-Gridview
    • Get-Service | Export-Csv -Path c:\services.csv
    • Get-Process | Export-Clixml -Path c:\services.csv
    • Get-Service | ConvertTo-html -Property name,status | out-file c:\srv.html
    • Get-Service -DisplayName “*bi*” | Stop-Service -whatif | -confirm
    • Get-AdComputer -filter * | Get-WmiObject win32_bios -ComputerName {$_.name}
  • Remoting:
    • Enable-PSRemoting
    • $s = Enter-PSSession  mypc  (mstsc /v:mypc)
    • $s = New-PSSession -ComputerName host1
      • Import-Session -Module ActiveDirectory -Prefix remote
    • Invoke-Command  -ComputerName host1,localhost [-Session $s]
      {Get-EventLog -LogName Security -Newest 10} | Sort TimeWritten |
      Format-Table -Property TimeWritten,Message
    • icm host1,host2 {get-volume} | sort sizeremaining | Select last 3
    • Measure-Command {icm -comp host1 {Get-Process}}
    • $hosts = host1, host2
      • $hosts | foreach {copy-item c:\default.htm -destination \\$_\c$\inetpub\wwwroot}
    • Install-WindowsFeature WindowsPowerShellWebAccess
    • Install-PswaWebApplication -UseTestCertificate
    • Add-PswaAuthorizationRule  * * *
    • start iexplorer https://mypc/pwsa
    • Test-NetConnection -ComputerName <IP> -TraceRoute
  • Set-Location (sl) /tmp
  • Get-WindowsFeature where installed -eq $true
  • Get-WindowsFeature web-server | Install-WindowsFeature
  • Enable-WindowsOptionalFeature
  • Install-WindowsFeature -Name Web-Server  -IncludeManagementTools `
    -ComputerName vm1 -Credential admin\password
  • Get-Volume
  • Get-WmiObject win32_logicaldisk -Filter “DeviceID=’c:'” | select @{n=’freegb’;e={$_.freespace / 1gb -as [int]}}
  • $PSVersionTable                    (Show version)
  • $env:PSModulePath -split “;”
• PowerShell Azure cmdlets:
  • Install Azure PowerShell on Windows:
    • Run Windows PowerShell ‘Run as administrator’
    • Install-Module AzureRm
    • Update-Module AzureRm
    • Get-Module -ListAvailable AzureRM | (Get-Module AzureRm).version
    • Get-Command *rmstorage*
    • Get-Help New-AzureStorageAccount -full
    • Unblock-File -Path D:\script1.ps1      (Unblock and run scrip1)
      • D:\script.ps1
    • Note: running scripts on your computer has been disabled:
      • Set-ExecutionPolicy Unrestricted [RemoteSigned]
      • Import-Module AzureRM
      • Set-ExecutionPolicy Restricted
  • Basic cmdlets:
    • Get-AzureRmLocation
    • Get-AzureRmVMSize -Location “East US”
    • Get-AzureRmVM  -ResourceGroupName “rg1“
    • Get-AzureRmStorageAccount -ResourceGroupName “rg1“
  • Login
    • Login-AzureRmAccount | Logout-AzureRmAccount
    • Set-AzureRmContext -SubscriptionId <ID>  (If multiple subscriptions)
    • Select-AzureRmSubscription -SubscriptionId <SubscriptionID>
    • Get-AzureRmSubscription | sort SubscriptionName | Select SubscriptionName
  • RBAC:
    • Get-AzureRmRoleDefinition | Select-Object Name  (List built-in roles)
    • (Get-AzureRmRoleDefinition -Name Reader).Actions
    • Get-AzureRmProviderOperation Microsoft.Compute/*/action | `
      Select-Object Operation, OperationName
    • New-AzureRmRoleAssignment -ObjectId $adGroups[0].Id.Guid `
      -RoleDefinitionName ‘Role1’ -Scope “/subscriptions/$subscriptionID”
  • Users and Groups module:
    • AzureRmAd:
      • Get-AzureRmAdUser -StartsWith “User1”
      • Get-AzureRmAdGroup -DisplayNameStartsWith “Group1”
    • AD DS:
      • New-ADOrganizationalUnit -Name Org1 -Path “DC=adatum,DC=com” -ProtectedFromAccidentalDeletion $false
      • New-ADUser -Name ‘User1’ -GivenName ‘User1’ -Surname ‘Last1’ -SamAccountName ‘user1’ -UserPrincipalName ‘user1@adatum.com’ -AccountPassword (ConvertTo-SecureString -AsPlainText ‘Passw0rd’ -Force) -Path “OU=Org1,DC=adatum,DC=com” -PassThru | Enable-ADAccount
      • Get-ADUser -Filter * | Select DistinguishedName
      • $user = Get-ADUser -Filter “SamAccountName -eq ‘user1‘” -Properties Department,Title -SearchBase ‘OU=Org1,DC=adatum,DC=com’
      • $user | Set-ADUser -Title ‘VP’ -Department ‘Marketing’
      • $user | Get-ADUser -Properties Department,Title
      • Synchronize AD DS and Azure AD:
        • Import-Module “C:\Program Files\Microsoft AZure AD Sync\Bin\ADSync\ADSync.psd1”
        • Get-ADSyncScheduler
        • Start-ADSyncSyncCycle -PolicyType Delta
    • MSOnline:
      • Install-Module MSOnline
      • Connect-MsolService
      • New-MsolUser -UserPrincipalName user1@dir.onmicrosoft.com -DisplayName ‘User1’ -FirstName ‘User1’ -LastName ‘Dir1’ -Password ‘Passw0rd’ -ForceChangePassword $false -UsageLocation ‘US’
      • $user = Get-MsolUser | Where DisplayName -eq ‘User1’
      • New-MsolGroup -DisplayName ‘Group1’ -Description ‘a group’
      • $group = Get-MsolGroup | Where DisplayName -eq ‘Group1’
      • Add-MsolGroupMember -GroupObjectId $group.ObjectId -GroupMemberType ‘User’ -GroupMemberObjectId $user.ObjectId
      • Get-MsolGroupMember -GroupObjectId $group.ObjectId
      • Get-MsolDirSyncConfiguration
      • Set-MsolDirSyncEnabled -EnableDirSync $false
  • Policies:
    • New-AzureRmPolicyDefinition -Name policy1 -Policy C:\policy1.json
    • Get-AzureRmPolicyDefinition -Name policy1
    • New-AzureRmPolicyAssignment -Name pa1 -PolicyDefinition policy1
      -Scope $rg1.ResourceId -Verbose
    • Get-AzureRmPolicyAssignment -Name pa1 -PolicyDefinition policy1
      -Scope $rg1.ResourceId -Verbose
  • Resources:
    • Get-AzureRmResource | Where ResourceType -like “*virtualMachines*”
    • Get-AzureRmResource | Where {$_.Name -like “*vm3*” -or $_.Name -like “*vm4*”} | select Name, ResourceType | sort Name
    • Get-AzureRmResource | Where {$_.Name -like “vm-*” -and $_.ResourceType -eq ‘Microsoft.Compute/virtualMachines‘}
  • Resource Groups:
    • New-AzureRmResourceGroup  -Name ‘rg1‘ -Location ‘East US‘
    • Get-AzureRmResourceGroup [-Name rg1]
    • Remove-AzureRmResourceGroup -Name ‘rg1‘
    • Set-AzureRmResourceGroup -Name rg1
      -Tag @{Dept=”IT”; Owner=”User1″}
  • Resource Providers:
    • Get-AzureRmResourceProvider |
      Select  ProviderNamespace, ResourceTypes | Sort ProviderNamespace
    • Get-AzureRmResourceProvider -ProviderNamespace Microsoft.Compute
      -Location ‘East US’ | select ProviderNamespace, ResourceTypes
    • Get-AzureRmResource | Select Name, ResourceType
  • WebApps:
    • New-AzureRmAppServicePlan -ResourceGroupName rg1 -Location centralindia -Name plan1 -Tier Free
    • New-AzureRmWebApp -ResourceGroupName rg1 -Location centralindia -AppServicePlan plan1 -Name webapp1
    • New-AzureRmWebAppSlot -ResourceGroupName rg1 -AppServicePlan plan1 -Name webapp1 -Slot Staging
    • Swap-AzureRmWebAppSlot -ResourceGroupName rg1 -Name webapp1 -SourceSlotName Staging -DestinationSlotName production
  • Basic Azure Cmdlets:
    • Get-AzureRmVM  [-ResourceGroupName rg1  -VMName vm1]
      • (Get-AzureRmVM vm1).StorageProfile.OsDisk
    • Get-AzureRmVMSize -ResourceGroupName rg1  -VMName vm1
    • Update-AzureRmVM -ResourceGroupName rg1  -VM $vm
    • Stop-AzureRmVM -ResourceGroupName rg1  -Name vm1
    • Start-AzureRmVM -ResourceGroupName rg1  -Name vm1
    • Enter-PSSession -ComputerName <Public-IP> -Credential (Get-Credential) -UseSSL -SessionOption (New-PSSsessionOption -SkipCACheck -SkipCNCheck)
    • ConvertTo-AzureRmManagedDisk -ResourceGroupName rg1  -VMName vm1
    • Add-AzureRmVhd -ResourceGroupName disks -Desitination “https://vmstorecjh.blob.core.windows.net/vhd/mydata.vhd&#8221; -LocalFilePath D:\mydata.vhd -Verbose
    • $publicIP = New-AzureRmPublicIpAddress -Name pubIp -ResourceGroupName rg1 -Location “east us” –AllocationMethod Static -DomainNameLabel loadbalancernrp
    • New-AzureRmVirtualNetwork
    • New-AzureRmResourceGroupDeployment -Name $depName `
      –ResourceGroupName $rg1.ResourceGroupName `
      -TemplateFile template.json   -TemplateParameterFile params.json `
      @additionalParameters -Verbose -Force
    • Get VM Images and Sizes:
      • Get-AzureRmVMSize -Location “East US”
      • Get-AzureRmVmImagePublisher -Location “East US”
      • Get-AzureRmVmImageOffer -Location “East US” -PublisherName “MicrosoftWindowsServer”
      • Get-AzureRmVmImageSku -Location “East US” -PublisherName “MicrosoftWindowsServer” -Offer “WindowsServer”
      • Get-AzureRmVmImage -Location “East US” -PublisherName “MicrosoftWindowsServer” -Offer “WindowsServer” -Skus “2016-Datacenter-Server-Core”
      • $AzureImageSku = Get-AzureRmVmImage -Location “East US” -PublisherName “MicrosoftWindowsServer” -Offer “WindowsServer” -Skus “2016-Datacenter-Server-Core” | `
        Sort-Object Version -Descending
      • $latestImage = $AzureImageSku[0]
    • Azure DNS:
      • PS> $zone = Get-AzureRmDnsZone -Name abc.com -ResourceGroupName rg1
      • Get-AzureRmDnsRecordSet -Name “@” -RecordType NS -Zone $zone
      • New-AzureRmDnsRecordSet  -Name abc  -ZoneName abc.com -ResourceGroupName rg1  –RecordType A -DnsRecords (New-AzureRmDnsRecordConfig -Ipv4Address “1.2.3.4“)
      • Resolve-DnsName -Server ns1-07.azure-dns.com -Name abc.com 
  • Virtual Machines/VMs:
    • Create a basic VM (latest Windows Server 2016):
      # Login to Azure
      Login-AzureRmAccount
      # Variables for common values
      $rg = “rg1”
      $loc = “EastUS”
      $vmName = “vm1”
      # Create user object
      $cred = Get-Credential -UserName “vmadmin” -Message “VM Administrator Password”
      # Create a resource group
      New-AzureRmResourceGroup -Name $rg -Location $loc
      # Create a virtual machine
      New-AzureRmVM `
      -ResourceGroupName $rg `
      -Location $loc `
      -Name $vmName `
      -Image “Win2016Datacenter” `
      -Size “Standard_B1s” `
      -Credential $cred `
      -VirtualNetworkName “vnet1” `
      -SubnetName “subnet1” `
      -SecurityGroupName “nsg1” `
      -PublicIpAddressName “ip1” `
      -OpenPorts 80,3389
      # Install IIS into VM
      $set = ‘{“commandToExecute”:”powershell Add-WindowsFeature Web-Server”}’
      Set-AzureRmVMExtension -ResourceGroupName $rg -Location $loc
      -VMName $vmName -ExtensionName “IIS” -Publisher “Microsoft.Compute” -ExtensionType “CustomScriptExtension” -TypeHandlerVersion 1.4 -SettingString $set
      #Connect to VM
      Get-AzureRmPublicIpAddress -ResourceGroupName “rg1” | Select IpAddress
      mstsc  /v:<publicIpAddress>
    • Create a detailed VM (Windows Server 2016 Core):
      $locName = “eastus”
      $rgName = “rg1”
      $nsgName = “nsg1”
      $ruleName = “AllowRDP”
      $port = “3389”
      $vnetName = “vnet1”
      $vnetAddress = “10.0.0.0/16”
      $subnetName = “vnet1-subnet”
      $subnetAddress = “10.0.1.0/24”
      $ipName = “vm1-ip”
      $nicName = “vm1-nic”
      $vmName = “vm1”
      $vmAdmin = “vmadmin”
      $password = “Pa55word5”
      $vmSize = “Standard_B1s”
      $vmSkus = “2016-Datacenter-Server-Core-smalldisk”
      $vmOffer = “WindowsServer”
      $vmPublisher = “MicrosoftWindowsServer”
      $vmVersion = “latest”#Login to Azure
      Login-AzureRmAccount#Create Resource group
      New-AzureRmResourceGroup -Name $rgName -Location $locName#Create Network Security Group and rule
      $rule = New-AzureRmNetworkSecurityRuleConfig -Name $ruleName -Priority 600 `
      -Access Allow -Protocol * -Direction Inbound `
      -SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange $port
      $nsg = New-AzureRmNetworkSecurityGroup -ResourceGroupName $rgName -Location $locName -Name $nsgName -SecurityRules $rule
      #Create Virtual network
      $subnet = New-AzureRmVirtualNetworkSubnetConfig -AddressPrefix $subnetAddress -Name $subnetName -NetworkSecurityGroup $nsg
      $vnet = New-AzureRmVirtualNetwork -ResourceGroupName $rgName -Location $locName -Name $vnetName -AddressPrefix $vnetAddress -Subnet $subnet
      # Create Public IP and Network Interface Card
      $ip = New-AzureRmPublicIpAddress -ResourceGroupName $rgName -Location $locName -Name $ipName -AllocationMethod Dynamic
      $nic = New-AzureRmNetworkInterface -ResourceGroupName $rgName -Location $locName -Name $nicName -SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $ip.Id#Get Windows Administrator credentials
      #$cred = Get-Credential -UserName $vmAdmin -Message “Password?”
      $secPassword = ConvertTo-SecureString $password -AsPlainText -Force
      $credentials = New-Object System.Management.Automation.PSCredential ($vmAdmin $secPassword)#Create VM Config
      $vm = New-AzureRmVMConfig -VMName $vmName -VMSize $vmSize
      $vm = Set-AzureRmVMOperatingSystem -VM $vm -Windows -ComputerName $vmName -Credential $credentials
      $vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id
      $vm = Set-AzureRmVMOSDisk -VM $vm -Name “$vmName.vhd” -CreateOption FromImage
      $vm = Set-AzureRmVMBootDiagnostics -VM $vm -Disable
      $vm = Set-AzureRmVMSourceImage -VM $vm -Skus $vmSkus -PublisherName “MicrosoftWindowsServer” -Offer “WindowsServer” -Version “latest”#Deploy VM
      New-AzureRmVM -ResourceGroupName $rgName -Location $locName -VM $vm$secPassword = ConvertTo-SecureString $password -AsPlainText -Force
      $credentials = New-Object System.Management.Automation.PSCredential ($vmAdmin $secPassword)
• Powershell Desired State Configuration (DSC): A declarative technology enabling the definition of what a system should be without having to detail how to make it that way.
  • Without DSC:
    Import-Module ServerManager
    If (-not (Get-WindowsFeature “Web-Server”).Installed) {
    try {
    Add-WindowsFeature Web-Server
    }
    catch {
    Write-Error $_
    }
    }
  • With DSC:
    Configuration WebConfig {
    param([string[]]$computerName=”localhost”)
    Node $comptuerName {
    WindowsFeature WebServer {
    Ensure = “Present”
    Name = “Web-Server”
    }
    }
    }
• Azure CLI 2.0
  • az login|logout
  • az account [list|show|list-locations|set –subscription <ID>] -o table
  • az provider [list|show –namespace Microsoft.Compute] -o table|tsv
  • az group [list|show -n rg1  –query tags|export -n rg1]
  • az group create -n rg1  -l eastus
  • az group update -n rg1  –set tags.Owner=User1  tags.Dept=IT
  • az resource [list {-g rg1}|show] -o table
  • az vm list [-g rg1]
  • az vm create -n vm1 -g rg1 –image UbuntuLTS
  • az vm show –resource-group rg1 –name vm1 –show-details –query [fqdns] –output tsv)
  • az vm reset-access  -g rg  -n vm1  –u LinuxAdmin  -p  NewPassw0rd2
  • az vm availability-set create
  • az network vnet create –resource-group rg1 –location EastUS –name vnet1 –address-prefix 10.0.0.0/16 –subnet-name subnet1 –subnet-prefix 10.0.1.0/24
  • az network vnet subnet create -g rg1 –vnet-name vnet1 -n Subnet2 –address-prefix 10.0.2.0/24
  • az network dns record-set ns show –resource-group rg1 –zone-name abc.com –name @
  • az provider register -n Microsoft.ContainerService
  • Azure Container Service (AKS):
    • az aks create –resource-group rg1 –name k8scluster –node-count 1 –node-vm-size Standard_B1s –generate-ssh-keys
    • az aks get-credentials –resource-group rg1 –name k8scluster
    • az aks kubernetes get-credential
    • kubectl get nodes; kubectl create -f test.yaml
  • Azure Container Registry:
    • az acr list -o table
    • az acr show -n reg1 –query loginServer
    • az acr credential show -n reg1 –query passwords[0].value

Reference:

• https://github.com/PowerShell/PowerShell/tree/master/docs/learning-powershell

 

Azure Storage

• Azure Storage:
  • Access keys: Use access keys to authenticate your applications when making requests to this Azure storage account.
    • Store your access keys securely – for example, using Azure Key Vault – and don’t share them.
    • Azure recommend regenerating your access keys regularly. You are provided two access keys so that you can maintain connections using one key while regenerating the other.
    • When you regenerate your access keys, you must update any Azure resources and applications that access this storage account to use the new keys. Additionally any existing SAS tokens will also need to be regenerated. This action will not interrupt access to disks from your virtual machines.
  • Shared Access Signature (SAS): Its a URI that grants restricted access rights to Azure Storage resources.
    • You can provide a shared access signature to clients who should not be trusted with your storage account key but whom you wish to delegate access to certain storage account resources.
    • By distributing a shared access signature URI to these clients, you grant them access to a resource for a specified period of time.
    • An account-level SAS can delegate access to multiple storage services (i.e. blob, file, queue, table).
    • Note that stored access policies are currently not supported for an account-level SAS.
    • Allowed services: Blob, File, Queue, Table
    • Allowed resource types: Service, Container, Object
  • Encryption: By default, data is encrypted using Microsoft Managed Keys for Azure Blobs, Tables, Files and Queues.
    • You may choose to bring your own key for encryption for Azure Blobs and Files. Encryption for Tables and Queues will always use Microsoft Managed Keys.
    • Please note that after enabling Storage Service Encryption, only new data will be encrypted, and any existing files in this storage account will retroactively get encrypted by a background encryption process.
  • Blob: Scalable object storage for documents, videos, pictures, and unstructured text or binary data.
    • Choose from Hot, Cool, or Archive tiers.
    • Binary Large Objects (Blobs), Unstructured object data
    • Page (VHD): Used for VM VHDs. Page blobs are optimized for writes at random locations within a blob. They also support Unmanaged Disks.
    • Block (S3): Optimized for object streaming, unstructured data
    • Append: Optimized for append operations i.e logging.
    • Managed Disks:  Persistent, secured disks that support simple and scalable virtual machine deployment. Designed for 99.999% availability. Choose Premium (SSD) Disks for low latency and high throughput.
  • Queue: Store and retrieve messages up to 64 KB in size. Used to store messages to be processed asynchronously.
    • Pub/sub messaging data
    • Reliable Message Workflow processing
  • File: Fully managed file shares in the cloud, accessible via standard Server Message Block (SMB) protocol. Enables sharing files between applications using Windows APIs or REST API.
  • Table: Table storage provides a NoSQL Key-Value semi-structured store for massive scale structured data.
• Data Redundancy/Replication:
  • Locally Redundant Storage (LRS): Designed to provide at least 99.999999999 % (11 9’s) durability of objects over a given year by keeping multiple copies of your data in one data center.
    • 3 copies within a single data center in a region
    • For premium storage account, you would be limited to LRS only.
  • Zone-Redundant Storage (ZRS): Designed to provide at least 99.9999999999 % (12 9’s) durability of objects over a given year by keeping multiple copies of your data across multiple datacenters or across regions.
    • 3 copies withing 2-3 data centers in a region
    • Block blobs only
    • Available only during Service Account creation
  • Geo-Redundant Storage (GRS): Designed to provide at least 99.99999999999999 % (16 9’s) durability of objects over a given year by keeping multiple copies of the data in one region, and asynchronously replicating to a second region.
    • 3 copies in a primary region and 3 copies in a secondary region.
    • Can access data in secondary region only after fail-over
  • Read-Access Geo-Redundant Storage (RA-GRS): Designed for to provide at least 99.99999999999999 % (16 9’s) durability of objects over a given year and 99.99 % read availability by allowing read access from the second region used for GRS.
    • 3 copies in a primary region and 3 copies in a secondary region.
    • Provides you read-only access onto secondary region storage copies
• Disks used by VMs:
  • Operating Systems Disks (Automatic):
    • Every virtual machine has one attached operating system disk. It’s registered as a SATA drive.
    • Labeled as the C: drive for Windows and /dev/sda for Linux virtual machines.
    • This disk has a maximum capacity of 2048 gigabytes (2 TB).
  • Temporary Disks (Automatic):
    • Each VM contains a temporary disk that is automatically created for you.
    • Don’t store data on the temporary disk. The temporary disk provides short-term storage for applications and processes and is intended to only store data such as page or swap files.
    • Data on the temporary disk may be lost during a maintenance event or when you redeploy a VM. Whereas, during a standard reboot of the VM, the data on the temporary drive should persist.
    • On Windows virtual machines, the temporary disk is labeled as the D: drive by default and it used for storing pagefile.sys.  The size of the temporary disk varies, based on the size of the virtual machine.
    • On Linux virtual machines, the disk is typically /dev/sdb and is formated and mounted to /mnt by the Azure Linux Agent.
    • The size of the temporary disk varies, based on the size of the virtual machine.
  • Data Disks (User Defined):
    • A data disk is a VHD that’s attached to a virtual machine to store application data, or other data you need to keep.
    • Data disks are registered as SCSI drives and are labeled with a letter that you choose.
    • Each data disk has a maximum capacity of 4095 GB (4 TB).
    • You can add data disks to a virtual machine at any time, by attaching the disk to the virtual machine.
    • Data disks are stored in a BLOB in an Azure storage account.
• Disk Types: Azure now offers three types of storage accounts: General Purpose v2, General Purpose v1, and Blob Storage. Storage accounts determine eligibility for certain storage services and features, and each is priced differently.
  • Each subscription is allowed 200 storage accounts and 500 TB per account.
  • Premium SSD disks: are backed by SSDs, and delivers high-performance, low-latency disk support for VMs running I/O-intensive workloads. Typically you can use Premium SSD disks with sizes that include an “s” in the series name. For example, there is the Dv3-Series and the Dsv3-series, the Dsv3-series can be used with Premium SSD disks.
    • SDD-based, high performance, low latency disk supports for VM running IO-intensive workloads or hosting mission critical production environment.
    • Great for I/O intensive workloads such as production and performance sensitive workloads, for example Dynamics, Exchange Server, SQL Server, SharePoint Server
    • Max Throughput per Disk = 250 MiB/s
    • Max IOPS per Disk = 7500 IOPS
    • Need a DS-, DSv2, GS- or FS-series VMs
    • Available in 3 sizes (128 GB, 512 GB, 1024 GB)
    • Not available in all regions
    • Page (VM) blobs only
    • Pre-configured disk size
  • Standard SSD disks (Preview): Standard SSD disks are designed to address the same kind of workloads as Standard HDD disks, but offer more consistent performance and reliability than HDD.
    • Standard SSD disks combine elements of Premium SSD disks and Standard HDD disks to form a cost-effective solution best suited for applications like web servers that do not need high IOPS on disks.
    • Where available, Standard SSD disks are the recommended deployment option for most workloads.
    • Standard SSD disks are only available as Managed Disks, and while in preview are only available in select regions and with the locally redundant storage (LRS) resiliency type.
    • Suitable for Web servers, lightly used enterprise applications and Dev/Test
    • Max Throughput per Disk = 60 MiB/s
    • Max IOPS per Disk = 500 IOP
  • Standard HDD disks: Standard HDD disks are backed by HDDs, and deliver cost-effective storage. Standard HDD storage can be replicated locally in one datacenter, or be geo-redundant with primary and secondary data centers. 
    • HDD-based cost effective disk support for Dev/Test virtual machines, backup, Non-critical and Infrequent access
    • agnetic based disks, having low IOPS and moderate latency
    • Default for some instances sizes, others use SSD
    • IOPS value represent maximum values
    • Can use any redundancy option
    • General Purpose: Blob, Table, Queue, File
    • Blob Storage: Hot access tier, Cool access tier
  • Managed: Managed Disks handles the storage account creation/management in the background for you, and ensures that you do not have to worry about the scalability limits of the storage account.
    • You simply specify the disk size and the performance tier (Standard/Premium), and Azure creates and manages the disk for you.
    • As you add disks or scale the VM up and down, you don’t have to worry about the storage being used.
    • RBAC, tags and Locks: Disk level.
    • Replication: LRS
    • Encryption: ADE, SSE on by default
    • Simple: Abstract storage accounts from customer
    • Granular access control: Top level ARM resource, apply Azure RBAC
    • Storage account limit don’t apply: Enables scaling free of storage account limitations
    • Secure: No public access to underline blob
    • Support VM level disk encryption: Secure data at rest
    • Better storage resiliency: Prevents single points of failure due to storage
  • Unmanaged disk: Unmanaged disks are the traditional type of disks that have been used by VMs.
    •  With these disks, you create your own storage account and specify that storage account when you create the disk.
    • Make sure you don’t put too many disks in the same storage account, because you could exceed the scalability targets of the storage account (20,000 IOPS, for example), resulting in the VMs being throttled.
    • With unmanaged disks, you have to figure out how to maximize the use of one or more storage accounts to get the best performance out of your VMs.
    • If you use unmanaged standard disks (HDD), you should enable TRIM. TRIM discards unused blocks on the disk so you are only billed for storage that you are actually using. This can save on costs if you create large files and then delete them.
      • fsutil behavior query DisableDeleteNotify   (If shows 1, then set it 0)
      • fsutil behavior set DisableDeleteNotify 0
    • RBAC, tags and Locks: Storage account level.
    • Replication: LRS, GRS, RA-GRS
    • Encryption: ADE, SSE
• Virtual Network Service Endpoints:
  • Associate a storage account with a VNet
  • Limit access to storage account from VNet
  • NAT rules to support on-premises connections
• Host Caching:
  • None: Disable on IaaS Domain Controllers (DCs). Good for random I/O
  • Read only: Write-through. Stored on disk and RAM of physical host OS
  • Read/Write: Write back. Stored in memory of physical host OS
• Azure Import/Export: Azure Import/Export service enables you to transfer large amounts of data to and from Azure using hard disk drives.
  • Azure Import/Export service is used to securely import large amounts of data to Azure Blob storage and Azure Files by shipping disk drives to an Azure datacenter.
  • Import: Data from one or more disks can be imported either to Azure Blob storage or Azure Files.
  • Export: This service can also be used to transfer data from Azure Blob storage to disk drives and ship to your on-premises sites.
  • Migrating data to the cloud: Move large amounts of data to Azure quickly and cost effectively.
  • Content distribution: Quickly send data to your customer sites.
  • Backup: Take backups of your on-premises data to store in Azure blob storage.
  • Data recovery: Recover large amount of data stored in blob storage and have it delivered to your on-premises location.
• Storage Explorer Tools:
  • Azure Storage Explorer
  • CloudBerry
• Basic Facts:
  • You can upload an existing VHD file from your on-premises data center to Azure with Azure Storage Explorer or the Add-AzureRMVHD command.
  • Storage spaces can be used to combine multiple disks into a single larger high performance volume.
• Databases:
  • Azure SQL Database (AWS RDS):
    • OTLP engine
    • Active-geo replication
    • Automatic backups
    • Database Throughput Unit (DTU) performance metrics
    • Elastic pools
  • Azure SQL Database Managed Instance:
    • Greater access to the underlying virtual machine
    • Graphical user management
    • SQL Server Agent
  • Azure SQL Data Warehouse (AWS Redshift):
    • Massively parallel processing OLAP engine
    • Data Warehouse Unit (DWU) performance metric
  • MySQL Database (ClearDB):
    • MS partner hosted option (Aventra)
    • Can be deployed alone or behind Azure App Service app
  • Azure Database for MySQL:
    • Native MySQL option in Azure
    • MySQL Community edition
    • No-downtime scaling
  • Azure Database for PostgreSQL:
    • No downtime scaling
    • Compute Units
  • Azure CosmosDB (AWS DynamoDB):
    • Multi-model NoSQL database system
    • SQL (Document DB)
    • Table (key-value)
    • MongoDB
    • Gremlin (graphs)
    • Turnkey global distribution
  • Azure HDInsight (AWS EMR):
    • Big data
    • Managed Hadoop clusters
    • HDFS distributed storages
    • MapReduce distributed processing
    • Pig scripting
    • Hive query
  • Azure Redis Cache (AWS ElasticCache):
    • Super fast in-memory key-value database
    • Can persist data
    • Good choice for rapidly changing dynamic data
    • Session state
• Windows tools:
  • diskmgmt.msc     (Run > diskmgmt)
  • sysprep                 (C:\Windows\System32\Sysprep)