Lync Server on AWS
Lync Server Quick Start

Design Considerations

Lync Server 2013 is a robust communications platform that can be architected and deployed in a number of ways, depending on your requirements. This Quick Start is designed to give you a starting point for implementing a small or medium-sized Lync Server 2013 deployment on the AWS Cloud. We also cover considerations for large deployments that you can implement on your own.

Lync Server 2013 Standard and Enterprise Editions

The Standard Edition of Lync Server 2013 is intended for small organizations, and a single Standard Edition Front End Server can support approximately 5,000 users. The user and application databases are stored locally on a SQL Server Express instance. You can pair two Standard Edition pools to provide a disaster recovery failover option in the case of a lost server or Availability Zone. In this scenario, you would home 50% of your users on each pool, for an active/active deployment. If one Standard Edition server fails, you can fail the pool over to the remaining server, which can support a total of 5,000 active users.

To provide the quickest deployment option, this Quick Start deploys paired Standard Edition servers with one server in each Availability Zone.

The Enterprise Edition of Lync Server 2013 provides support for large deployments and additional high availability features. The user and application databases run on a dedicated pool of SQL servers. Larger deployments will require a number of additional servers in your topology. Additional sizing guidance and considerations for large deployments are covered later in this guide.

Selecting an Instance Type

To select the appropriate instance type for servers in your Lync deployment, you should map the recommended requirements in the following sections to compatible Amazon EC2 instance types. Additionally, we recommend that you select an instance type that supports Amazon EBS optimization, enhanced networking, and high or 10-gigabit network performance, which results in higher performance (packets per second), lower latency, and lower jitter. The following sections provide examples of how to choose an instance type depending on the workload.

Front End Servers, Back End Servers, Standard Edition Servers, and Persistent Chat Servers

For these workloads, use the minimum requirements set by Microsoft to determine the Amazon EC2 instance type:

  • CPU: 6 cores

  • Memory: 32 GiB

  • Disk: Solid state drives (SSDs)

  • Network: 1 Gbps network adapter

When starting your design, you should choose an instance type that can provide enough vCPUs and memory to match these minimum requirements as closely as possible.

Amazon EBS General Purpose or Provisioned IOPS volumes are SSD-backed and should be used for both the root OS volume and for any database and log volumes you’ll need. Amazon EBS Magnetic volumes can be used for testing, but should not be used for production workloads. Currently all M4, R3, C3, D2, and I2 instances support enhanced networking, so these instance types should be your primary candidates.

For each Lync Standard Edition Server, by default, this Quick Start uses the m4.2xlarge instance type, which provides 8 vCPUs, 32 GiB of memory, high network performance, Amazon EBS optimization, and enhanced networking. Amazon EBS General Purpose (SSD) volumes are used for storage.

Edge Servers, Standalone Mediation Servers, and Directors

For these workloads, use the minimum requirements set by Microsoft to determine the Amazon EC2 instance type:

  • CPU: 4 cores

  • Memory: 16 GiB

  • Disk: Solid state drives (SSDs)

  • Network: 1 Gbps network adapter

You should choose an instance type that can provide enough vCPUs and memory to match these minimum requirements as closely as possible.

For the Edge Server, by default, this Quick Start uses the m4.xlarge instance type, which provides 4 vCPUs, 16 GiB of memory, high network performance, and enhanced networking. Amazon EBS General Purpose (SSD) volumes are used for storage.

Additional Planning Tools

Microsoft provides the following tools to assist you in planning your deployment, sizing your servers, and testing the performance before moving into production:

  • Lync Server 2013 Planning Tool – Asks you questions about your organization and the features that you are interested in. The tool then provides guidance for designing your site topology, based on your answers and on the tested Microsoft Lync Server 2013 user model.

  • Lync Server 2013 Capacity Calculator – Calculates Lync Server hardware requirements based number of users, types of communication, traffic estimates, and similar information.

  • Lync Server 2013 Stress and Performance Tool (LSS) – Assists in hardware and capacity planning for Lync Server. You can use LSS to configure user scenarios and measure the performance of your Lync Server 2013 deployment. LSS includes modules for simulating different types of user activity, such as IM and presence, VoIP, and conferencing, and can simulate simultaneous users on multiple Lync Servers.

We recommend using the capacity and planning tools to create more complex designs and to validate your assumptions. We also highly recommend validating the performance of those proposed designs with the LSS tool before moving into production.

Load Balancing

When designing for high availability, Front End pools, Director pools, and Edge Server pools will require load balancing. Lync Server 2013 supports two types of load balancing: Domain Name System (DNS) load balancing and hardware load balancing.

DNS load balancing can make administration and troubleshooting easier, compared with hardware load balancing, but remember that HTTP traffic will require a virtual load balancer. Many organizations often use a mix of these two load balancing options to provide load distribution and high availability for large deployments.

The AWS Marketplace includes a number of third-party load balancing solutions. Some examples of commonly used solutions are:

For details and general guidance on load balancing for Lync Server 2013, see the Additional Resources section.

Edge and Reverse Proxy Servers

Edge Servers make it possible for external users to use Lync services remotely without the use of a VPN connection. However, although the Edge Server role provides signaling and media support for external users, it does not support HTTP-based services. HTTP-based services run on the Front End Standard Edition or Enterprise Edition servers in your topology. Examples of HTTP-based services include your meeting join page and the web service used by mobile clients.

To make HTTP-based services available externally, we recommend that you use a reverse proxy server, which typically sits in a DMZ network. In the case of AWS, you can think of your public Amazon VPC subnets as your DMZ networks, and this is where your Edge Servers and reverse proxy servers should reside.

Some common reverse proxy solutions from Microsoft include IIS Application Request Routing (ARR) and the Web Application Proxy server. You can deploy either one of these as a post-configuration task after launching the Quick Start.


Lync Server requires SSL certificates for securing both internal and external services. Although an internal enterprise certificate authority (CA) is recommended for internal servers, you can also use a public CA. External services are typically secured with commercial certificates that are purchased and issued from a public CA.

This Quick Start leverages an internal enterprise CA running on the Active Directory domain controllers. Both the internal and external services are secured using certificates issued for the internal enterprise CA. If you choose to deploy Edge and reverse proxy servers, keep in mind that you’ll likely want to purchase certificates from a public CA to secure those external services. This will allow external devices that are not part of your organization to trust the issuing CA and therefore make use of your external Edge and reverse proxy infrastructure.

For details, see the Certificate infrastructure requirements for Lync Server 2013 on Microsoft TechNet.

Enterprise Voice

Enterprise Voice is a set of features that provides a complete telephony solution with connectivity to the Public Switched Telephone Network (PSTN). For a cloud-based deployment of Lync Server on AWS, you can utilize Session Initiation Protocol (SIP) trunks from an IP telephony provider to deliver PSTN calling capabilities to your Lync users.

To connect a SIP trunk to your Lync environment, you can deploy a Session Border Controller (SBC) appliance into the public DMZ subnets in your Amazon VPC. This will keep your Lync servers in the private subnets shielded from the internet, and you can benefit from the additional security features offered by most SBC appliances.

There are a number of SIP trunking and SBC providers that you can use to enable Lync Enterprise Voice with your deployment on AWS. IntelePeer ( is a well-known provider of SIP trunking services, and Sansay ( offers their VSXi SBC appliance as an Amazon Machine Image (AMI). Your AWS Direct Connect partner may be able to connect you to other Microsoft-certified SIP trunk providers.

Office Web Apps Server

Lync Server 2013 uses Office Web Apps Server to deliver Microsoft PowerPoint presentations. You may need to deploy at least one additional server if you intend to use this functionality in your deployment. You can make this role highly available by deploying at least two servers and load balancing them with a virtual load balancer.

Considerations for Large Deployments

To design large deployments for the best performance and high availability, you'll need the Enterprise Edition of Lync Server, and a topology with more than one server per Availability Zone. Here are some considerations for the various server roles in a large deployment

  • Front End Servers – Microsoft states that you should have one Front End Server for every 6,600 users homed in the pool. The maximum number of users in a Front End pool is 80,000, which means that a Front End pool can have a maximum of 12 servers. This Quick Start deploys Standard Edition servers (one Front End per pool). For larger deployments you'll want to use Enterprise Edition and scale out accordingly; see the Sample Enterprise Deployment section for details.

  • Mediation Servers – For smaller deployments, you can collocate the Mediation Server role on your Front End Servers. You may benefit from deploying a dedicated Mediation Server pool if you need to support a large number of users. This depends on several factors, such as the number of Enterprise Voice users and concurrent calls.

  • Back End Servers – The Enterprise Edition of Lync Server moves some of the Lync databases to dedicated Back End Servers (which are SQL servers). You should use SQL servers that run on Amazon EC2 instances, as opposed to Amazon Relational Database Service (Amazon RDS) DB instances. You can easily deploy these Back End Servers using a SQL Server Standard AMI, or you can manually build your own SQL servers on Amazon EC2 instances. The Back End Servers can be made highly available through SQL mirroring. Note that Microsoft has announced the deprecation of SQL mirroring, but will support SQL AlwaysOn Availability Groups in future versions of the Lync/Skype server platform.

  • Monitoring and Archiving Servers – If installed, the Monitoring and Archiving services run on your Front End Servers. However, these services use a SQL store that is separate from the Back End Servers. You should use SQL servers that run on Amazon EC2 instances, as opposed to Amazon RDS DB instances. You can easily deploy these servers using a SQL Server Standard AMI, or you can manually build your own SQL servers on Amazon EC2 instances.

  • Persistent Chat Server – The Persistent Chat Server is available with Enterprise Edition as a dedicated pool, separate from your Front End Servers. Persistent Chat Server requires a Back End Server to store chat room content and metadata. Microsoft recommends that you install Persistent Chat content on a dedicated Back End Server, but also states that you can choose to install it on an existing Back End Server if needed.

  • Stress testing – Use the Lync Server 2013 Stress Testing Guide to validate capacity planning assumptions through a stress testing exercise.

  • Operations management – Systems Center Operations Manager 2007 R2 and 2012 support a Lync Server 2013 management pack that will monitor the operational metrics of your Lync environment. This will require installing an additional instance of SQL Server. For more information, see Configuring Lync Server 2013 to work with System Center Operations Manager on Microsoft TechNet.

For additional details on planning a Lync Server 2013 deployment, see Capacity planning for Lync Server 2013 on Microsoft TechNet.

Sample Enterprise Deployment

The following diagram shows an enterprise deployment of Lync Server 2013 on AWS in a single Availability Zone. This will provide high availability for Lync within the Availability Zone in the event of a server failure. To design a solution that spans an entire AWS region, you can deploy an identical pool in a second Availability Zone, and then pair those pools for disaster recovery purposes.

		Lync 2013 Enterprise Deployment in a Single Availability Zone

Figure 2: Lync 2013 Enterprise Deployment in a Single Availability Zone


There are several key points to take into consideration based on the architecture shown in Figure 2:

  • The public subnet contains a pool of two Lync 2013 Edge Servers. These servers make it possible for external users to use Lync without a VPN connection. These Edge Servers can be load balanced with DNS load balancing or by using a virtual load balancer appliance.

  • The public subnet contains a pair of HTTP proxy servers. These provide external access to various Lync components that operate over HTTP. These servers can be running the reverse proxy solutions mentioned earlier in this guide, or many others. These reverse proxy servers can be load balanced using a virtual load balancer appliance, or with Route 53 failover record sets.

  • The private subnet contains a pool of three Lync Server 2013 Enterprise Edition Front End Servers. Front End pools use a distributed model where user data is kept on three Front End Servers in the pool. Microsoft recommends that all your Enterprise Edition Front End pools include at least three Front End Servers.

  • The private subnet contains two SQL Server 2014 servers to act as the database back end. These servers use SQL mirroring for failover.

  • The private subnet contains two Active Directory domain controllers. Although it is possible to use one server for this role, a second domain controller is included in this architecture to make every service redundant and highly available within the Availability Zone.

For further details on highly available Lync Server 2013 architectures, see Topologies and components for Front End Servers, instant messaging, and presence in Lync Server 2013 on Microsoft TechNet.