1. IaaS
1.1. Virtual Machines
1.1.1. Status
1.1.1.1. Running
1.1.1.1.1. The VM is on and running normally
1.1.1.2. Stopped
1.1.1.2.1. The VM is stopped, but it is still consuming compute resources within Azure
1.1.1.3. Stopped (Deallocated)
1.1.1.3.1. The VM is stopped, and it is not consuming compute resources within Azure
1.1.2. Tiers
1.1.2.1. Basic
1.1.2.1.1. Well suited for workloads that do not require load balancing or the ability to autoscale
1.1.2.2. Standard
1.1.2.2.1. Support all Azure Virtual Machines configurations and features
1.1.3. Disks
1.1.3.1. OS disk
1.1.3.1.1. Persisted in Azure blob storage
1.1.3.1.2. Windows machines get a 127 GB C: drive
1.1.3.2. Temporary disk
1.1.3.2.1. Physical disk located within the chassis of the server
1.1.3.2.2. Referred to as the D drive for Windows VMs
1.1.3.2.3. This is a variable size disk, illustrated rather confusingly as “disk size” on the pricing site, that is for non-persistent data. The drive is local on the Azure host and is not guaranteed to be there over time. On Windows machines, the paging file is on this D: drive and some DBAs might choose to store TempDB caching databases there (see D- and G-Series virtual machines).
1.1.3.3. Data disk
1.1.3.3.1. Maximum size of 1 TB
1.1.3.3.2. Often used for storing application data
1.1.3.3.3. Need to be formatted
1.1.3.3.4. Where do you store data?
1.1.3.4. Caching
1.1.3.4.1. Data disks have caching disable by default
1.1.4. Endpoints
1.1.4.1. The Azure Load Balancer exposes endpoints for an Azure cloud service. It is the configuration of the Azure Load Balancer that controls how requests from the Internet reach a specific port using a related protocol (such as TCP or UDP) on the VM
1.1.4.2. As the Azure platform and Azure virtual machines continue to develop, endpoints will be deprecated by the Network Security Groups (NSG)
1.2. Azure Storage
1.2.1. Microsoft-managed service that provides durable, scalable, and redundant storage
1.2.2. Types
1.2.2.1. Blob service
1.2.2.1.1. The word blob is an acronym for binary large object
1.2.2.1.2. Blobs are basically files like those that you store on your computer (or tablet, mobile device, etc.). They can be pictures, Microsoft Excel files, HTML files, virtual hard drives (VHDs)—pretty much anything.
1.2.2.1.3. The Azure Blob service gives you the ability to store files and access them from anywhere in the world by using URLs, the REST interface, or one of the Azure SDK storage client libraries.
1.2.2.1.4. Two kinds of blob
1.2.2.2. File Share service
1.2.2.2.1. Highly available network file shares that can be accessed by using the SMB protocol. This means that multiple virtual machines can share the same files with both read and write access.
1.2.2.3. Table service
1.2.2.3.1. Azure Table storage is a scalable NoSQL data store that enables you to store huge amounts of semistructured, nonrelational data. It does not allow you to do complex joins, use foreign keys, or execute stored procedures. Each table has a single clustered index that can be used to query the data quickly. You also can access the data by using LINQ queries and OData with the WCF Data Service .NET libraries.
1.2.2.3.2. A common use of table storage is for diagnostics logging
1.2.2.3.3. How to use Table Storage
1.2.2.4. Queue service
1.2.2.4.1. Used to store and retrieve messages
1.2.2.4.2. Azure Storage Queue vs Azure Service Bus Queue
1.2.3. Microsoft Azure Storage Explorer
1.3. Virtual Networks
1.3.1. Overview
1.3.1.1. Used in Azure to provide a layer of security and isolation to your services.
1.3.1.2. VMs and services that are part of the same virtual network can access each other.
1.3.1.3. By default, services outside the virtual network cannot connect to services within the virtual network
1.3.1.4. Services that talk to each other within a virtual network do not travel through the Azure Load Balancer, which gives you better performance
1.3.1.5. You can add a Virtual Network Gateway to a virtual network and use it to connect your on-premises network to Azure, effectively making the virtual network in Azure an extension of your on-premises network
1.3.1.6. Complex features
1.3.1.6.1. multisite VPNs
1.3.1.6.2. in-region VNet-to-VNet
1.3.1.6.3. cross-region VNet-to-VNet
1.3.2. Definitions
1.3.2.1. Virtual network address spaces
1.3.2.1.1. Topology of the virtual network, including the available address spaces and subnets
1.3.2.1.2. If the virtual network is to be connected to other virtual networks, you should select address ranges that are not overlapping
1.3.2.2. Subnets
1.3.2.2.1. Used to reak up your network into more manageable sections
1.3.2.2.2. Example
1.3.2.2.3. By default, there is no security boundary between subnets, so services in each of these subnets can talk to one another
1.3.2.3. DNS servers
1.3.2.3.1. Used to refer to your VMs instances by host name or fully qualified domain name (FQDN) directly, rather than using an IP address and port number
1.3.2.3.2. If you create the DNS after the VMS, you will have to reboot all of the VMs in the virtual network because the DNS server information is injected into the settings at startup
1.3.2.3.3. Options
1.3.2.3.4. If you have two VMs located on the same virtual network and you want them to be able to communicate by host name, you will need your own DNS server solution
1.4. Cross-premises connection options
1.4.1. site-to-site VPN
1.4.1.1. Must set up a VPN gateway
1.4.1.2. Lets you connect securely from your on-premises network to your virtual network in Azure
1.4.1.3. You have to have a public-facing IPv4 IP address and a compatible VPN device or Routing and Remote Access (RRAS) running on Windows Server 2012
1.4.1.4. For a list of valid devices and the configuration thereof, please refer to:
1.4.2. point-to-site VPN
1.4.2.1. Overview
1.4.2.1.1. Must set up a VPN gateway
1.4.2.1.2. Point-to-site VPN enables you to connect from your local machine over a Secure Socket Tunneling Protocol (SSTP) tunnel to your virtual network in Azure
1.4.2.1.3. This uses certificate authentication between the client machine and the virtual network in Azure. This means you have to create some certificates and install them in the right places
1.4.2.1.4. It is recommended that you create a separate client certificate for each client that is going to access the point-to-site network and keep track of the certificate’s thumbnail and on which machine it was installed. If you do this, and you later need to turn off access for one person, you can do that by invalidating the client certificate
1.4.2.1.5. You can connect up to 128 clients to the virtual network in Azure
1.4.2.1.6. The maximum bandwidth is 80 MBPS per gateway
1.4.2.2. Setup
1.4.2.2.1. Create a virtual network with point-to-site connectivity enabled
1.4.2.2.2. Deploy a VM into the virtual network
1.4.2.2.3. Create a network gateway
1.4.2.2.4. Create a self-signed root certificate
1.4.2.2.5. Create a self-signed client certificate from the root certificate
1.4.2.2.6. Export the client certificate from the certificate store
1.4.2.2.7. Upload the root authentication certificate to Azure
1.4.2.2.8. Install the client certificate on the client machine to authenticate to the virtual network
1.4.2.2.9. Install the client VPN package
1.4.2.2.10. Establish and verify the VPN connection
1.4.3. private VPN (ExpressRoute)
1.4.3.1. This is called private because the network traffic occurs over your network provider and does not go across the public Internet as it does with both site-to-site and point-to-site connectivity
1.4.3.2. This capability ensures that applications with privacy requirements can be developed and run on Azure
1.4.3.3. Using ExpressRoute also gives you increased reliability and speed and lower latency