Configuring Internal Endpoints

There are many scenarios where Internal Endpoints make sense. Imagine a web application that needs to communicate with a middle tier. The communication between both Cloud Services does not need to leave Microsoft Azure networks. The diagram above depicts a scenario where a Web Role has access to a middle tier Cloud Service without going through the public Internet.

Role instances running in a Cloud Service on Microsoft Azure communicate through internal and external connections that vary depending on the type of communication that is needed. An internal endpoint can connect by using a protocol of HTTP, TCP or UDP.

The configuration of an Internal Endpoint is done through the Service Definition. Below is the template used to describe what can be done in terms of Endpoint configurations. 

Service Definition Endpoint Template

  <InputEndpoint certificate="<certificate-name>" ignoreRoleInstanceStatus="[true|false]" name="<input-endpoint-name>" protocol="[http|https|tcp|udp]" localPort="<port-number>" port="<port-number>" loadBalancerProbe=”<load-balancer-probe-name>” />
  <InternalEndpoint name="<internal-endpoint-name>" protocol="[http|tcp|udp|any]" port="<port-number>">
     <FixedPort port="<port-number>"/>
     <FixedPortRange min="<minium-port-number>" max="<maximum-port-number>"/>
  <InstanceInputEndpoint name="<instance-input-endpoint-name>" localPort="<port-number>" protocol="[udp|tcp]">
        <FixedPortRange min="<minium-port-number>" max="<maximum-port-number>"/>

The Endpoints Element

Describes the collection of input (external), internal, and instance input endpoints for a role. This element is the parent of the InputEndpoint, InternalEndpoint, and InstanceInputEndpoint elements.

Input and Internal endpoints are allocated separately. A service can have a total of 25 input, internal, and instance input endpoints which can be allocated across the 25 roles allowed in a service. For example, if have 5 roles you can allocate 5 input endpoints per role or you can allocate 25 input endpoints to a single role or you can allocate 1 input endpoint each to 25 roles.

Sample ServiceDefinition

The following sample defines an Internal Endpoint names TcpListener which opens ports between 1000 and 2000.

<?xml version="1.0" encoding="utf-16"?>
<ServiceDefinition xmlns:xsd="" xmlns:xsi="" name="briseboisDemo3" xmlns="">
  <WorkerRole name="Compute">
      <Task commandLine="setup_worker.cmd &gt; log.txt" executionContext="elevated">
          <Variable name="EMULATED">
            <RoleInstanceValue xpath="/RoleEnvironment/Deployment/@emulated" />
          <Variable name="RUNTIMEID" value="" />
          <Variable name="RUNTIMEURL" value="" />
      <Task commandLine=".\startup.cmd &gt; startup_log.txt" executionContext="elevated" />
      <InternalEndpoint name="TcpListener" protocol="tcp">
        <FixedPortRange min="1000" max="2000" />
        <Variable name="EMULATED">
          <RoleInstanceValue xpath="/RoleEnvironment/Deployment/@emulated" />
        <ProgramEntryPoint commandLine="worker.cmd" setReadyOnProcessStart="true" />

Deploying the Cloud Service

There is nothing different about deploying a Cloud Service that exposes Internal Endpoints. Using your tool of preference, create a new Cloud Service package and deploy it to Microsoft Azure.

Using PowerShell to package the Cloud Service requires you to navigate to the Cloud Service directory and execute the Save-AzureServiceProjectPackage command. This will produce a cloud_package.cspkg package file.

To deploy Azure Cloud Services, I usually use PowerShell. This is an example of what you may write yourself.

New-AzureDeployment `
                -Package 'C:\\cloud_package.cspkg' `
                -Configuration 'C:\\ServiceConfiguration.Cloud.cscfg' `
                -Slot Production `
                -Label 'Compute-2015-02-17' `
                -ServiceName  'DemoCloudService' `
                -Name 'DemoCloudService' `


Trackbacks and Pingbacks:

  1. Dew Drop – February 18, 2015 (#1957) | Morning Dew - February 18, 2015

    […] Configuring Internal Endpoints on #Azure Cloud Services (Alexandre Brisebois) […]


  2. Opening Windows Firewall Ports on #Azure Cloud Services « Alexandre Brisebois ☁ - February 19, 2015

    […] the Virtual Machine and Cloud Service are deployed to a Virtual Network on Microsoft Azure. Using Internal Endpoints in this scenario, would not yield the desired configuration. Endpoints are defined at the Cloud […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.