If you would like to read the other parts in this article series please go to:
- Microsoft + AWS: A Winning Combo (Part 1)
- Microsoft + AWS: A Winning Combo (Part 2)
- Microsoft + AWS: A Winning Combo (Part 3)
- Microsoft + AWS: A Winning Combo (Part 4)
Introduction
In Part 1 of this series, we took a look at how Amazon’s AWS provides a solid cloud platform for running any of the currently supported versions of Windows Server, and a wide variety of Microsoft server applications that can be migrated from your on-premises data center to the Amazon cloud. In Part 2 we continued the discussion of how to run Windows servers and applications on AWS and how to get the most bang for your buck out of this Microsoft/Amazon combination.
In Part 3, we began a discussion aimed at how to deploy popular Microsoft server applications such as Exchange and SharePoint on your Windows instances running on AWS. Specifically, we provided some tips on capacity planning for an Exchange deployment on an AWS EC2 instance. In Part 4, we continued with that discussion.
Deploying SharePoint on EC2
As with Microsoft Exchange Server, SharePoint Server can be installed on AWS without worry about buying new software licenses if your organization is part of the volume licensing program, via Microsoft License Mobility through Software Assurance. You can simply move your on-premises licenses to your AWS instances.
With Amazon Web Services as your cloud services provider, you can deploy either SharePoint 2010 or SharePoint 2013 on the AWS infrastructure as a service. The details are somewhat different, so in this article we will focus on the deployment of SharePoint 2013. You can find information on deploying SharePoint 2010 in the 2012 whitepaper titled Microsoft SharePoint Server on AWS: Reference Architecture, which can be accessed in PDF format here.
Getting Started
The easiest way to deploy SharePoint 2013 is to use the three-step Quick Start deployment, which involves:
- Launching Windows Server Failover Cluster and SQL Server AlwaysOn Quick Start
- Creating an Elastic Block Storage (EBS) volume snapshot for storing the SharePoint installation files
- Launching the SharePoint Server 2013 stack using the AWS CloudFormation template
Amazon provides a sample template to help you deploy and configure all these elements. Before you proceed with the process, please note a couple of important caveats: It takes about three hours to create the stack, and you will be charged for the cost of the AWS services that you use when you run the deployment template. Be sure that you’re aware of the pricing for the AWS services that you’ll be using.
Launching WSFC and SQL Server AlwaysOn Quick Start
The first step in setting up your SharePoint 2013 environment involves creating the Active Directory domain. For reliability and high availability, the Microsoft WSFC and SQL Server AlwaysOn Quick Start installs two Active Directory domain controllers and two SQL Server Enterprise nodes configured in a Windows Server Failover Cluster. The Amazon Virtual Private Cloud (VPC) spans two availability zones.
Your cluster nodes must be deployed inside an Amazon VPC. This is a virtual network that is very similar to an on-premises network in a traditional data center, and serves as the networking layer for Amazon’s EC2. Your VPC is logically isolated from the rest of the VPCs in the Amazon cloud, and you can create separate subnets in your VPC, defined by a range of IP addresses. The WSFC cluster nodes must be deployed in separate subnets.
Setting up Active Directory Domain Services
Once you have created the virtual network with two subnets in two availability zones, you need to configure both public and private routes and then launch Windows Server 2012 AMIs (Amazon machine images). Next you set up and configure Active Directory and DNS as you would in a traditional network.
After that, you will need to create and configure EC2 security groups. These function like virtual firewalls, to control both inbound and outbound traffic between your AD domain controllers and the member servers on your virtual network. Now you can enable administrative ingress and egress using Remote Desktop Gateway and Network Address Translation instances.
Creating and Configuring the Server Infrastructure
In this step, you need to create and configure EC2 security groups to control the traffic between your Failover Cluster nodes and set up SQL Server (this can be SQL 2012 or 2014 Enterprise edition). At that point, you’re ready to create the WSFC cluster and enable AlwaysOn High Availability.
Configuring the SQL Server AlwaysOn Availability Group
The third step involves manually creating a database and an AlwaysOn availability group. You’ll find the detailed instructions in Amazon’s documentation with the somewhat unwieldy title of Microsoft Windows Server Failover Clustering (WSFC) and SQL Server AlwaysOn Availability Groups on the AWS Cloud: Quick Start Reference Deployment. It can be accessed in PDF format here.
Creating the Media Volume Snapsnot
Now that you have launched the Microsoft WSFC and SQL Server AlwaysOn Quick Start as described above, you will have a VPC containing your Active Directory domain and SQL Server Enterprise servers. Now you need a place to store the installation media for SharePoint server. That means you must create an Amazon EBS volume snapshot.
EBS snapshots are point-in-time copies of EBS volumes in Amazon S3. The snapshots are incremental backups of the volume, and you can create a new EBS volume based on an existing snapshot.
This is done via the Amazon EC2 console, under Elastic Block Store. To begin the process, select Create Volume and select the newly created volume, then in the Actions menu select Attach Volume. Attach the volume to the appropriate instance, in this case the Remote Desktop Gateway in the first availability zone.
Now you can run the Remote Desktop Connection client (mstsc.exe) to connect to the desktop of the server instance and download SharePoint 2013 with SP1 according to your Microsoft licensing agreement. Once the ISO image has been downloaded, double click it and mount the image, then copy the installation files to the root of the empty EBS volume that you created previously.
You’ll need to download the Download-SPFiles.ps1 script for downloading the SharePoint prerequisite files. This goes in the prerequisiteinstallerfiles folder in the media volume. Then you run it, including the path to the destination folder, or you can open it in Notepad or another text editor and use the links in the script to manually download the files to that folder.
Either way, once the files are all copied into your EBS volume, you can create a snapshot of the volume from the EC2 console: Elastic Block Storage > Volumes > (volume name) > Actions > Create Snapshot. Give the snapshot a name and select Create. Be sure to take note of the snapshot ID, as you’ll need it when you launch the SharePoint CloudFormation template.
Creating the Stack
The next and final step is to create the SharePoint Server 2013 stack, using the automated AWS CloudFormation template. You can download the template here.
You can customize the template to fit your own needs by changing any of the 30 defined parameters or changing the default values. These parameters and values are listed in the document linked above.
Once you have completed the Quick Start process, you will have created a SharePoint server farm deployment in the AWS cloud that includes the following components, duplicated in two different availability zones:
- A public subnet that contains your Network Address Translation and Remote Desktop Gateway components (You can also place a reverse proxy server in the public subnet if needed).
- A private subnet that contains your internal application servers and other non-Internet facing servers, which in this case include a front-end SharePoint 2013 server, a back-end SharePoint 2013 server for batch processing, an SQL server instance with SQL database (primary replica in availability zone 1 and secondary replica in availability zone 2) and an Active Directory domain controller with Global Catalog and DNS services.Instances that are deployed in the private subnets will need to use private routes in order to transmit traffic to the NAT instances that are located in the public subnets, because there are no direct routes between the private subnets and the Internet, to protect your SharePoint servers and domain controllers from access over the Internet.
All of these components exist within your Amazon Virtual Private Cloud, with the Amazon Elastic Load Balancer automatically distributing incoming traffic across your EC2 instances for fault tolerance. Your VPC exists within the AWS cloud, and you can use remote management and administration tools to manage your servers over the Internet from outside the AWS cloud.
The Remote Desktop Gateway creates a secure encrypted connection to your EC2 instances over the Internet, via the HTTPS protocol. This means you won’t need to create a VPN connection.
Summary
This is a brief summary of the process for deploying a SharePoint 2013 server farm in an AWS VPC. You will find much more detailed information and helpful diagrams on the Amazon web site in the documents that are linked above.
This concludes this five part article on Microsoft and AWS and how it can be a winning combination for you. Of course, this doesn’t come close to covering every scenario involving the deployment of Microsoft software on AWS and in future articles, we will look at additional situations and circumstances.
If you would like to read the other parts in this article series please go to:
