Only $2.99/month

Terms in this set (152)

Cloud Services
General Purpose (A0-A4) - See VM.
Memory Intensive (A5-A7) - See VM.
Compute & Network Intensive (A8-A9) - See VM.
Optimized Compute (D1-D14) - See VM.
- all come with integrated health, monitoring, load-balancing, and auto-scaling.
- A1 is the smallest size recommended for production workloads.

VM's
Basic
A0-A4
An economical option for development workloads, test servers, and other applications that don't require load balancing, auto-scaling, or memory-intensive virtual machines. A1 is the smallest size recommended for production workloads. Select a virtual machine with 4 or 8 CPU cores when using SQL Server Enterprise Edition.

Standard
A0 xSmall, shared core, 768MB RAM
A1 Small, 1 core and 1.75GB RAM
A2 Medium, 2 cores and 3.5GB RAM
A3 Large, 4 cores and 7GB RAM
A4 XLarge, 8 cores and 14GB RAM

A5, 2 cores and 14GB RAM
A6, 4 cores and 28GB RAM
A7, 8 cores and 56GB RAM

Compute & Network Optimized
A8 (8 cores, 56GB RAM)
A9 (16 cores, 112GB)
Ideal for Message Passing Interface (MPI) applications, high-performance clusters, modeling and simulations, video encoding, and other compute or network intensive scenarios. Network optimized with Infiniband and remote direct memory access (RDMA).

Compute Optimized D-Series
D1 (3.5GB RAM)-D4(28GB)
D11(18GB)-D14(112GB)
60% faster CPUs, more memory, and local SSD. The faster SSD is used for the D: drive that is used for temporary storage making it ideal for temp DB for a database.

G-Series
G1-G5 - will provide more memory and more local Solid State Drive (SSD) storage than any current VM size in the public cloud. The largest G-series will offer 448 GB RAM and 6.5 TB of local SSD storage.
DIP - If you deploy a VM or PaaS Cloud Service to a virtual network, the VM and each PaaS instance always receives an internal IP address (DIP) from a pool of internal IP addresses that you specify. VMs/PaaS instance communicate within the virtual network by using DIPs.
NOTE: Although Azure assigns the DIP, you can request a static DIP for your VM if you deploy the VM using PowerShell. See Configure a Static Internal IP Address for a VM.

VIP - Your VM is also associated with a VIP, although a VIP is never assigned to the VM directly. A VIP is a public IP address that can be assigned to your cloud service. It is not assigned directly to your virtual machine NIC. The VIP stays with the cloud service it is assigned to until all the virtual machines in that cloud service are all Stop (Deallocated) or deleted. At that point, it is released. You can, optionally, reserve a VIP for your cloud service. See Reserved IP Addresses.

Reserved IP (VIP) - You can also reserve static public IP addresses for your cloud service. Reserved IP allows you to reserve a public Virtual IP address (VIP) in Azure and then assign it to your cloud service. The Reserved IP/VIP address is sticky, meaning once it's associated with the cloud service, it won't change unless you decide to disassociate it. And in a Virtual Machine scenario, the Reserved IP address will remain associated with your cloud service even when all the VMs in the cloud service are stop/deallocated. Reserved IP can only be used for VM cloud services and Cloud Service Web/Worker Roles. You must reserve the IP address first, before deploying.

PIP - Your VM can, optionally, also receive an instance-level public IP address (PIP). The PIP is directly associated with the VM, rather than the cloud service. Make a virtual machine directly addressable by assigning it a public IP (PIP) address. You can assign one PIP for each VM. You can use up to 5 PIPs per subscription.PIP is currently in Preview. See Instance-level Public IP Addresses.
Use Host Header (URL host: www.mydomain.com)

You can configure your web roles in the Service Configuration (ServiceConfiguration.cscfg) to share a port by configuring the host header to direct the request to the correct location. You can also configure your web roles (websites and web applications) to listen to well-known ports on the IP address.

See below for a snippet of a Service Configuration file that shows an example. The website is configured as the default entry location on port 80, and the web applications are configured to receive requests from an alternate host header that is called "mail.mysite.cloudapp.net".

<WebRole>
<ConfigurationSettings>
<Setting name="DiagnosticsConnectionString" />
</ConfigurationSettings>
<Endpoints>
<InputEndpoint name="HttpIn" protocol="http" port="80" />
<InputEndpoint name="Https" protocol="https" port="443" certificate="SSL"/>
<InputEndpoint name="NetTcp" protocol="tcp" port="808" certificate="SSL"/>
</Endpoints>
<LocalResources>
<LocalStorage name="Sites" cleanOnRoleRecycle="true" sizeInMB="100" />
</LocalResources>
<Site name="Mysite" packageDir="Sites\Mysite">
<Bindings>
<Binding name="http" endpointName="HttpIn" />
<Binding name="https" endpointName="Https" />
<Binding name="tcp" endpointName="NetTcp" />
</Bindings>
</Site>
<Site name="MailSite" packageDir="MailSite">
<Bindings>
<Binding name="mail" endpointName="HttpIn" hostheader="mail.mysite.cloudapp.net" />
</Bindings>
<VirtualDirectory name="artifacts" />
<VirtualApplication name="storageproxy" />
<VirtualDirectory name="packages" packageDir="Sites\storageProxy\packages"/>
</VirtualApplication>
</Site>
</WebRole>
Network Access Control List (ACL)

When you create an ACL and apply it to a virtual machine endpoint, packet filtering takes place on the host node of your VM; meaning the host hardware. This means the traffic from remote IP addresses is filtered by the host node for matching ACL rules instead of on your VM. This prevents your VM from spending the precious CPU cycles on packet filtering.

When defining the Endpoint, click the Manage ACL to define these rules.

An ACL provides the ability to selectively permit or deny traffic for a virtual machine endpoint. This packet filtering capability provides an additional layer of security. Currently, you can specify network ACLs for endpoints only.

You can't specify an ACL for a virtual network or a specific subnet contained in a virtual network. ACLs can be configured by using either PowerShell or in the Management Portal.

If your VMs are in a VNet, you'll want to configure Network Security Groups (NSGs) instead of Network ACLs. NSGs provide more granular control and are available only for VMs that are deployed in VNets.

Important: Firewall configuration is done automatically for ports associated with Remote Desktop and Secure Shell (SSH), and in most cases for Windows PowerShell Remoting. However, you have option to leave these off during initial creation. For ports specified for all other endpoints, no configuration is done automatically to the firewall in the guest operating system. When you create an endpoint, you'll need to configure the appropriate ports in the firewall to allow the traffic you intend to route through the endpoint. In other words by default, when an endpoint is created, all traffic is denied to the endpoint. EXCEPTION: All traffic is allowed by default when a VNet is connected to on-premises or another VNet through a VPN or Express Route.
NSGs can be configured and modified by using PowerShell cmdlets and REST APIs only. You cannot configure NSGs by using the Management Portal.

Here are sample cmdlets...

Create a Network Security Group

New-AzureNetworkSecurityGroup -Name "MyVNetSG" -Location uswest -Label "Security group for my Vnet in West US"

Add or Update rules

Get-AzureNetworkSecurityGroup -Name "MyVNetSG" | Set-AzureNetworkSecurityRule -Name WEB -Type Inbound -Priority 100 -Action Allow -SourceAddressPrefix 'INTERNET' -SourcePortRange '' -DestinationAddressPrefix '' -DestinationPortRange '*' -Protocol TCP

Delete a rule from an NSG

Get-AzureNetworkSecurityGroup -Name "MyVNetSG" | Remove-AzureNetworkSecurityRule -Name WEB

Associate an NSG to a VM

Get-AzureVM -ServiceName "MyWebsite" -Name "Instance1" | Set-AzureNetworkSecurityGroupConfig -NetworkSecurityGroupName "MyVNetSG" | Update-AzureVM

Remove an NSG from a VM

Get-AzureVM -ServiceName "MyWebsite" -Name "Instance1" | Remove-AzureNetworkSecurityGroupConfig -NetworkSecurityGroupName "MyVNetSG" | Update-AzureVM

Associate an NSG to a subnet

Get-AzureNetworkSecurityGroup -Name "MyVNetSG" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName 'VNetUSWest' -SubnetName 'FrontEndSubnet'

Remove an NSG from the subnet

Get-AzureNetworkSecurityGroup -Name "MyVNetSG" | Remove-AzureNetworkSecurityGroupFromSubnet -VirtualNetworkName 'VNetUSWest' -SubnetName 'FrontEndSubnet'

Delete an NSG

Remove-AzureNetworkSecurityGroup -Name "MyVNetSG"

Get the details of an NSG along with rules

Get Details of Network Secuirty group along with rules
Get-AzureNetworkSecurityGroup -Name "MyVNetSG" -Detailed
No VNet - Used when VM's and cloud services do not need to communicate directly with each other.

Cloud-Only VNet - Used when VM's and cloud services need to communicate directly with each other.

Cross-Premises VNet (which includes Hybrid solutions) - VNet is needed when extended corporate network to access VM's or cloud services. This allows VNet to VNet; or configure either the VPN or Express Route option (just one; not both).

Here are some other reasons a VNet might be needed:

Name resolution
If you want to connect to your VMs and cloud services by hostname or SRV records, rather than using the IP address and/or port number, you'll need name resolution. When you deploy VMs and cloud services to a virtual network you can use Azure-provided name resolution or your own DNS solution, depending on your name resolution requirements. For information about name resolution options, see Name Resolution (DNS).

Enhanced security and isolation
Since each virtual network is run as an overlay, only virtual machines and services that are part of the same network can access each other. Services outside the virtual network have no way to identify or connect to services hosted within virtual networks. This provides an added layer of isolation to your services.

Extended trust and security boundary
The virtual network extends the trust boundary from a single service to the virtual network boundary. You can create several cloud services and virtual machines within a single virtual network and have them communicate with each other without having to go through the internet. You can also setup services that use a common backend database tier or use a shared management service.

Extend your on-premises network to the cloud
You can join VMs in Azure to your domain running on-premises. You can access and leverage all on-premises investments around monitoring and identity for your services hosted in Azure.

Use persistent private IP addresses
Virtual machines within a VNet will have a stable private IP address. We assign an IP address from the address range you specify and offer an infinite DHCP lease on it. You can also choose to configure your virtual machine with a specific private IP address from the address range when you create it. This ensures that your virtual machine retains its private IP address even when Stop/Deallocated. See Configure a static internal IP address for a VM.
Site-to-Site - VPN connection over IPsec (IKE v1 and IKE v2)
Allows you to create a secure connection between your on-premises site and your virtual network. To create a site-to-site connection, a VPN device that is located on your on-premises network is configured to create a secure connection with the Azure Virtual Network Gateway. Once the connection is created, resources on your local network and resources located in your virtual network can communicate directly and securely. Site-to-site connections do not require you to establish a separate connection for each client computer on your local network to access resources in the virtual network.
Use a site-to-site connection when, you want to create a branch office solution, OR, you want a connection between your on-premises location and your virtual network that's available without requiring additional client-side configurations.
NOTE: You must have an externally facing IPv4 IP address and a VPN device or Windows Server 2012 Routing and Remote Access (RRAS) to configure a site-to-site VPN connection.

Point-to-Site - VPN connection over SSTP (Secure Sockets Tunneling Protocol)
Also allows you to create a secure connection to your virtual network. In a point-to-site configuration, the connection is configured individually on each client computer that you want to connect to the virtual network. Point-to-site connections do not require a VPN device. They work by using a VPN client that you install on each client computer. The VPN is established by manually starting the connection from the on-premises client computer. You can also configure the VPN client to automatically restart.
NOTE: Point-to-site and site-to-site configurations can exist concurrently.

Express Route
Lets you create private connections between Azure datacenters and infrastructure that's on your premises or in a co-location environment. Express Route connections do not go over the public Internet, and offer more reliability, faster speeds, lower latencies and higher security than typical connections over the Internet. In some cases, using Express Route connections to transfer data between on-premises and Azure can also yield significant cost benefits. With Express Route, you can establish connections to Azure at an Express Route location (Exchange Provider facility) or directly connect to Azure from your existing MPLS/WAN network provided by a network service provider.
Advantages of IaaS
Business: Quick transition to Cloud - Due to the excellent portability enabled by IaaS, ISVs now can easily start offering cloud hosted services to their customers with minimal effort

Technology: Mature ISV Ecosystem - Mature ISV ecosystem readily offers various solution and operational components that are popular in an on-premise setting.

Technology: Complete Control - The developers and IT professionals have access to the complete app platform stack, user mode subsystems and kernel level control so that the VM can be customized to the needs of the business domains they serve.

Technology: Solution Portability - IaaS allows excellent design time portability of the application assets as the granularity of the deployment is a Virtual Hard Drive (VHD) containing both OS and application bits.

Disadvantages of IaaS

Business: Expensive to Operate - Expensive to operate as the solutions have to factor in the higher server maintenance for software patching and upgrades.

Business: Slows Down Innovation - The complete control on the OS and application server stack encourages developers to take dependencies on specific versions of the OS and app server. As a result, application migration to future versions of the OS and app server ecosystem becomes progressively harder and harder.

Business: Security Risks from Unpatched Servers - An unpatched server hosting sensitive data and processing logic can pose a huge PR risk for the company. There are no such problems with PaaS as server patching is automatically taken care of.

Technology: Difficult to Maintain Legacy Apps - Can be stuck with the older version of the operating systems and application stacks. This can result in applications that are difficult to maintain and add new functionality over the period of time.

Technology: Requires Rigorous Processes for Enabling DevOps - IaaS based applications suffer from the same DevOps issues that plague on-premise deployments. It requires rigorous processes to bring developers and IT Pros together to build operations' friendly applications.

Technology: Requires Rigorous Server Maintenance Processes - Diligent processes are required for server patching and upgrades; this is more so for smaller companies than larger companies with mature server maintenance practices.
Advantages of PaaS
Business: Low Total Cost of Ownership - Automated server maintenance and auto scaling of compute resources for meeting temporal resource demands are the two significant contributors towards lowering the cost of operations. Optimizing operational cost is a key requirement for services operated by cost centers like corporate IT shops which services internal employees.

Business: Accelerates Innovation - Due to the surface area between the application and the underlying platform is optimal in PaaS, developers will be able to move to new releases easily and build innovative solutions to meet the market demands. With IaaS, applications tend to be sticky to the underlying platform due to the tight coupling resulting from the complete control developers have on the OS and application platform stack.

Technology: Better Development Operations - Developers are no longer needed to work at the levels that require deep understanding of the OS and the networking infrastructure. OS patch management and upgrades are no longer needed to be part of the runbook for operating PaaS hosted applications.

Technology: Mitigates Vulnerability Risks - Azure PaaS team takes care of the infrastructure health by keeping the infrastructure updated against all the known vulnerabilities for which fixes have been distributed.

Disadvantages of PaaS
Harder Transition to Cloud - Applications that rely on local file system, expect locally stored data to be persistent between restarts, applications that rely on dynamic TCP and UDP ports, applications that rely on MAC address for licensing, and applications that require reboots during installation (e.g. installation of a driver) are some examples that require rework if at all if they can be migrated to Azure PaaS without sacrificing the core functionality.

Technology: Application Portability Issues - Due to the run time environment differences between Azure PaaS and the on-premise setup, applications have to be modified to be more transparent in terms of the telemetry they generate so that IT Professional can gain more insights into the operations and proactively mitigate the availability and scalability risks. Rewiring the diagnostics, accommodating resource governance in a multi-tenant setting, local file system access and implementing software metering are a few PaaS specific work items that will impact time-to-market and application portability.

Technology: PaaS ISV Ecosystem is not as mature as IaaS - If an app requires a specific RMS implementation, management & monitoring product or a specific license enforcement product, the chances are that these may not be available on Azure PaaS yet.

Technology: Different Codebases for Cloud and Premise - ISVs will have to maintain two different build scripts and two sets of libraries that will adapt the build to multiple deployment and run time environments.