Windows Azure Infrastructure-as-a-Service (IaaS) provides systems engineers with a simple, cost effective way to extend their on-premises datacenter to the public cloud. New workloads can be deployed on virtual machines running on Windows Azure to reduce deployment time and expenses, and existing workloads can be migrated for these same reasons. In addition, the public cloud provides an excellent way to add capacity for systems that may require it. The flexibility of IaaS also allows for scaling back to reduce costs during times that additional processing power may not be needed. When deploying or migrating workloads to Windows Azure IaaS, careful consideration must be made for applications and services that will be accessed by external clients or processes on remote systems. Unlike with on-premises workloads where we can place the virtual machine in a public-facing perimeter network (DMZ) and create firewall access and NAT rules, or publish the service using a reverse proxy server to allow access to the service, allowing access to services hosted in Windows Azure is a bit different. For public remote access to services running on Windows Azure IaaS-hosted virtual machines, endpoints must be configured.
Windows Azure Endpoints
When you configure a virtual machine in Windows Azure, one of the steps is to configure endpoints for the virtual machine. By default, both Remote Desktop and PowerShell are enabled.
Endpoints in Windows Azure consist of a protocol, along with a public and private port. The private port is the port that the service is listening on the local computer. The public port is the port that the service is listening on externally. In some cases this is the same port, which is the case for PowerShell. For the Remote Desktop protocol, the default configuration specifies a different port, which will be configured after the machine has been provisioned. When provisioning a new virtual machine you can enable or disable endpoints as you require. Use extreme caution when disabling the default Remote Desktop protocol, however. Unlike on-premises virtual machines, there is no console access for virtual machines hosted in Windows Azure. Unless you have alternative remote access to a Windows Azure virtual machine (e.g. via site-to-site or client-based remote access VPN), you may want to leave the Remote Desktop endpoint enabled.
The virtual machine deployment wizard provides pre-defined endpoint configuration not only for Remote Desktop and PowerShell, but also SSH, FTP, SMTP, DNS, HTTP, POP3, IMAP, LDAP, HTTPS, SMTPS, IMAPS, POP3S, MSSQL, and MySQL.
If you are deploying any of these services in Windows Azure you can select the default endpoint configuration. If you are deploying a service that is not listed in the dropdown list, or are deploying a service that is configured to listen on a non-standard port, you can provide your own name for the service, and define the protocol and ports as necessary.
After you’ve deployed a virtual machine in Windows Azure, you can edit existing endpoints or add and delete endpoints and access advanced endpoint settings by highlighting the virtual machine in the Windows Azure management console and click the Endpoints link. If you need to make changes to existing endpoints, click Edit. To create new endpoints, click Add. In addition you can create access control lists (ACLs) for endpoints by clicking Manage ACL. To remove an endpoint, click Delete.
When adding a new endpoint, the wizard will prompt you to create either a Stand-alone endpoint or to Add an endpoint to an existing load-balanced set. Load-balanced endpoints allow the administrator to distribute traffic defined by endpoint rules to multiple hosts in a load-balanced array. This is common for services such as IIS. You must first create a stand-alone endpoint before you can create the load-balanced set.
Select a pre-defined service name from the list or specify your own. To enable direct server return be sure that the public and private ports are the same.
Provide a name for the load-balanced set and define the probe (health check) parameters accordingly.
Once configured, this endpoint will distribute traffic to all nodes configured to participate in this load-balanced set. You can add or remove additional nodes to this load-balanced set as necessary.
Endpoint Access Control Lists
Endpoint Access Control Lists (ACLs) also allow the administrator to enable granular network access for configured endpoints. For example, a specific service may only require access from trusted individual hosts or networks. To define an ACL for an endpoint, select the endpoint rule and click Manage ACL. Provide a description for the access rule, select an action (permit or deny) and specify the remote host or subnet. Although the wizard stipulates only Remote Subnet, individual hosts can be identified using a /32 subnet mask.
It should be noted that when no ACL is in place, all access is permitted to the service from any host from any network. However, once you configure an ACL, an implicit deny takes effect. Only access to the service from specified hosts and/or networks defined by the endpoint ACL will be allowed. All other traffic will be denied. Also, ACLs are evaluated in order, and can be reordered if required. Rules should be configured with the least restrictive rules first and the most restrictive rules last.
Endpoints allow services running on Windows Azure virtual machines to be accessed remotely. They can be configured in a secure manner using Access Control Lists (ACLs) to restrict communication to specific hosts or networks. They can also provide port translation and load balancing services, as required. Many standard services are pre-defined and can be deployed quickly and easily. In addition, Windows Azure allows for custom configuration for endpoints to support virtually any TCP or UDP-based service deployed in the Windows Azure public cloud. If you have workloads that require external network accessibility, as in the case of an IIS server, mail server, or any myriad services that can run on a Windows Server, Windows Azure endpoints enable that communication and allows for flexible network deployment. Windows Azure endpoints are by no means mutually exclusive with site-to-site VPN network access either. For those deployments where cross-premises network connectivity using site-to-site VPN is configured, traditional on-premises network access can be established as well.