Deploying SharePoint Server Subscription Edition on AWS

Document Version: 1.0
Last Updated: March 2025
Contributors: Rob Higareda, Jarod Oliver - AWS Solutions Architect

Table of Contents

1. Introduction
   • What is SharePoint Server
   • Key Features
2. Pre-Requisites
   • Required Resources
   • AWS Account Requirements
   • Network Configuration
3. Solution Architecture
   • Core Infrastructure Components
   • Deployment Components
   • Security and Access
4. Implementation Walkthrough
   • Infrastructure Deployment
   • SQL Server Deployment
5. EC2 and SharePoint Configuration
   • Server Setup
   • Service Accounts
   • SharePoint Installation
6. Load Balancing and Network Access
   • NLB Configuration
   • SharePoint Web Applications
   • DNS Configuration
7. Verification and Cleanup
   • Deployment Verification
   • Resource Cleanup
8. Conclusion

Figures

Figure 1: Architecture diagram of SharePoint deployed environment
Figure 2: SQL Server connectivity in AWS Launch Wizard
Figure 3: Additional SQL Server settings in Launch Wizard
Figure 4: EC2 Security Group configuration

Introduction

This guide provides high-level guidance on how to set up SharePoint Server on Amazon Web Services (AWS). Customers can use this guide to see a recommended deployment configuration for SharePoint Server using Amazon Elastic Compute Cloud (Amazon EC2) instances for Microsoft SQL Server and the SharePoint application itself, as well as how to use Elastic Load Balancing (ELB) to distribute traffic to the SharePoint servers.

What is SharePoint Server?

SharePoint Server is a self-managed version of Microsoft's SharePoint Online platform. It's designed for organizations that prefer to manage their own infrastructure rather than using a software as a service implementation of SharePoint. It provides a robust environment for collaboration, document management, and content management. This self-managed approach offers maximum control.

Key features of SharePoint Server include:

• Collaboration: Create team sites for projects, departments, or other groups to share information and work together.
• Document Management: Store, organize, and manage documents with version control, metadata, and search capabilities.
• Customization: Build custom workflows, applications, and solutions tailored to your organization's needs.
• Integration: Seamlessly integrates with other Microsoft products like Office, Power BI, and Power Automate.
• Security: Offers advanced security features to protect your data and ensure compliance with organizational policies.

Pre-Requisites

To implement this solution, you should have an understanding of SharePoint and its components. In this architecture, we will deploy multiple components such as Microsoft SQL Servers to provide the database backend for SharePoint and then multiple sets of Amazon EC2 instances to host the SharePoint components such as Web Front End (WFE) and Application Servers. There are additional components that you can also use in SharePoint such as Distributed Cache and Office Online Server. These will not be part of this deployment but can be layered on to the solution as needed.

Required Resources

1. SharePoint Media: You will need the SharePoint Subscription Edition media, which is available on Microsoft's website for download. We've pulled down the latest version available on Microsoft's site in the AWS CloudFormation template and staged it to C:\SharePointMedia on each server deployed. If you need a different version of SharePoint other than Subscription Edition, you will need to update the CloudFormation template provided with the URL to the ISO file you'd like it to stage for you, or manually download the version you'd like to use.

2. AWS Account and Permissions: You will need an AWS account and a user/role to log on that has permissions to fully manage:

   • Amazon Virtual Private Cloud (Amazon VPC) and related components such as security groups
   • Amazon EC2 instances
   • Elastic Load Balancing

3. Network Configuration: In your chosen AWS Region, you'll need:

   • An Amazon VPC
   • 2 public subnets
   • 4 private subnets

   These subnets will house the Amazon EC2 instances for SharePoint and the Elastic Load Balancers necessary to distribute traffic to SharePoint. These will also be used for your Active Directory and SQL Server deployments as well.

4. Active Directory: You will need an Active Directory environment to integrate everything together for authentication. If you don't have an existing Active Directory environment, consider using AWS Directory Service for Microsoft Active Directory. It allows you to seamlessly migrate AD-dependent workloads to AWS, enhance security and productivity without having to manage and administer the domain controllers.

Checklist of Pre-Requisite Items

• [ ] Amazon Account
• [ ] IAM Account with permissions to use:
  • [ ] Amazon VPC
  • [ ] AWS Launch Wizard for SQL
  • [ ] Amazon EC2 (Create, Delete instances)
  • [ ] Elastic Load Balancing
  • [ ] Amazon EC2 Security Groups
  • [ ] AWS Directory Service for Microsoft Active Directory (optional if no existing AD environment)
• [ ] Amazon VPC
• [ ] 1 Public Subnet (Used for placing your Network Load Balancer and bastion host)
• [ ] 4 Private Subnets in different Availability Zones (same AZs as Public)
  • The private subnets are used to house:
    • 2 WFE servers for SharePoint
    • 2 APP servers for SharePoint
    • 2 Active Directory Domain Controllers & SQL Server nodes for a SQL cluster
  • If you have existing AD Domain Controllers and SQL Server, you will only need two subnets for the WFE and APP servers.
• [ ] Microsoft Active Directory Domain (with network connectivity to this domain)
  • [ ] User within Active Directory Domain to perform domain joins and manage AD objects
  • [ ] User account with permissions for SharePoint configuration (SharePoint permissions guide)

Solution Architecture

By the end of this guide, you will have an implementation that follows the architecture shown in Figure 1. The solution contains:

Core Infrastructure Components

• A single AWS Region with an Amazon VPC divided into multiple subnets
• Two Availability Zones for high availability
• Eight subnets:
  • Two public subnets
  • Six private subnets For more information about subnet types, refer to the AWS documentation.

Deployment Components

Within the subnets, we will deploy:

Private Subnets

• Web Front End (WFE) servers (one per Availability Zone)
• Application servers (one per Availability Zone)
• Highly-available Microsoft SQL Server database backend using Always On Availability Groups
• AWS Systems Manager endpoints for secure instance management

Public Subnets

• Elastic Load Balancing for SharePoint service traffic distribution
• Amazon NAT Gateway for outbound internet access from private subnets

Security and Access

The architecture implements several security best practices:

• SharePoint application and database servers remain isolated from the internet
• ELB handles ingress control to SharePoint
• Outbound access for updates/patching routes through Amazon NAT Gateway
• AWS Systems Manager Session Manager provides secure instance access through Fleet Manager

In case you're unfamiliar with or cannot use Systems Manager, the implementation also includes a Bastion host deployed in the public subnet that can be used for administration. It comes with a number of tools installed for administering the environment setup such as SQL Server Management Studio, and the Remote Server Administration Tools used for Active Directory administration.

[Figure 1: Architecture diagram of SharePoint deployed environment]

Implementation Walkthrough

Infrastructure Deployment

To deploy the bulk of the infrastructure shown above, we will use an AWS CloudFormation template. This template creates:

Network Infrastructure

• Dedicated Amazon VPC for SharePoint
• Public subnet containing:
  • Network Load Balancer (NLB)
  • NAT Gateway
• Private subnets in two different Availability Zones for SharePoint servers
• VPC endpoints for AWS Systems Manager integration

Security Components

• AWS Secrets Manager secret for initial server administration
• Security groups for:
  • NLB access (ports 80 and 443)
  • Web Front End servers
  • Application servers
• Bastion host for administrative access

Load Balancing Configuration

• Two target groups for:
  • Web Front End servers
  • Application servers

Additional Requirements

You will need to separately deploy:

1. SQL Server cluster for the SharePoint database backend
2. Active Directory domain for authentication

If you don't have an existing Active Directory environment, when you launch the SQL Server Launch Wizard deployment, you can have Active Directory deployed during the deployment. This provides a one stop way to deploy both SQL Server and Active Directory in one deployment using infrastructure as code.

In order to get a bulk of the infrastructure from the diagram above we’re going to leverage an AWS CloudFormation template to help you with the deployment. This CloudFormation template will deploy a dedicated VPC for SharePoint with multiple subnets. One public that will house a Network Load Balancer (NLB), and a NAT Gateway for the SharePoint servers. The SharePoint servers will be deployed in private subnets located in two different availability zones. The template also setups VPC endpoint for leveraging AWS Systems Manager for remote management of the servers securely. It also created a secret in AWS Secrets Manager that can be used to log onto each server as the local Administrator account. This password is just for initial setup and you can change it after launch. For access to the NLB there’s a security group created with access to ports 80 and 443 to the internet. Additionally there’s two target groups created to house the Web Front End servers and Application servers for SharePoint. There's also a Bastion Host being deployed for your use. You will still need to deploy a SQL Server cluster for the database backend for SharePoint and additionally you’ll need to have an Active Directory domain that you want to join everything to. If you don’t have an Active Directory environment already, you can leverage AWS Managed Active Directory. You can follow instructions on the AWS documentation to deploy your own AWS Managed Active Directory. We'll include using AWS Launch Wizard for the SQL deployment.

Click the button that follows to launch the CloudFormation template in your AWS Account. This provides the necessary core infrastructure to then layer on Active Directory using AWS Managed Microsoft Active Directory, or your own existing self-managed Microsoft Active Directory environment. (Defaults to us-east-1)

You can download the file from this link as well.

Now that you have your base infrastructure in place for the Web Front End and Application servers, Let’s start deploying the necessary database backed for SharePoint. This is where you’ll start to need your Active Directory environment as we’ll be deploying an always on implementation of SQL Server for a high availability database backend to SharePoint Server.

For this guide we’re going to leverage a helpful AWS service for deploying an Always On SQL Server Cluster that you can use that spans the availability zones previously created by the CloudFormation Template. AWS offers the AWS Launch Wizard for SQL Server. AWS Launch Wizard is a service that guides you through the sizing, configuration, and deployment of Microsoft SQL Server applications on AWS, following the AWS Well-Architected Framework. AWS Launch Wizard supports both single instance and high availability (HA) application deployments. We’ll suggest an HA deployment for SharePoint. In this example scenario we’re going to leverage AWS Managed AD as well for SharePoint.

AWS Launch Wizard reduces the time it takes to deploy SQL Server solutions to the cloud. You input your application requirements, including performance, number of nodes, and connectivity, on the service console. AWS Launch Wizard identifies the right AWS resources to deploy and run your SQL Server application. AWS Launch Wizard provides an estimated cost of deployment, and you can modify your resources and instantly view the updated cost assessment. When you approve, AWS Launch Wizard provisions and configures the selected resources in a few hours to create a fully-functioning production-ready SQL Server application. It also creates custom AWS CloudFormation templates, which can be reused and customized for subsequent deployments.

To launch your SQL Server backend, please follow the detailed steps provided in the documentation. As you go through the deployment steps, you need to choose SQL backend and Active Directory deployment. For SQL server AMI choice, we suggest using the latest version of Windows and SQL available in the choices. Currently that is Windows Server 2022, with SQL Server 2022. You can choose SQL Server Standard and we’ll leverage just a basic availability group for the SharePoint deployment. When deploying with AWS Managed Microsoft Active Directory, make sure to take note of your Admin username you’re creating and SQL server account that you’re setting up through the Launch Wizard.

When you are deploying SQL Server via the Launch Wizard, You will have options for connectivity. The CloudFormation you initially deployed provides both the public and private subnets needed for this deployment you can select those for where you’ll deploy SQL Server to on launch. The VPC for this will be named SharePoint Env.

You’ll find a subnet named Public Subnet in the deployment, choose this for the Public Subnet option

For Availability Zones for and private subnets, you’ll find two private subnets named Active Directory and SQL Subnet 1, and Active Directory and SQL Subnet 2 that you can use for the private subnets for this environment.

You’ll need to also create a new Key Pair for usage with this stack. We won’t use it to log onto the servers as they will be Active Directory domain joined, but you’ll still need to create one for the Launch Wizard to proceed. (Store this key in a safe location)

Figure 2 Screenshot of connectivity information for SQL Server in the AWS launch wizard

When deploying your SQL Cluster via the AWS Launch Wizard, you can make some configuration choices in your launch, We’d suggest the following configuration items when making your SQL deployment to assure you can easily find your SQL Server Listener that will be used in the SharePoint deployment. To set these you’ll need to expand the Additional SQL Server settings in the Launch Wizard configuration. We’ve provided some example names that can be used, but you can choose whatever naming standard your organization might normally follow for these items.

• Primary SQL node name: SPSQLDB1
• Secondary SQL node name: SPSQLDB2
• Database name: SPDB (this DB won’t be used for SharePoint, but is required for the create process)
• Availability group name: sqldbaoag
• Listener name: spsql
• Windows cluster virtual network name: spsqlclus

Figure 3 screenshot showing the expanded Additional SQL Server settings option in Launch Wizard.

On the following screen you can leave the default memory and CPU configuration and click next to advance through the setup and configuration of your SQL cluster.

The deployment of SQL Server will take anywhere from 45 minutes to 1.5 hours to complete. Once your Active Directory and SQL Server deployments are complete, you can continue to the next steps. Once deployed, your SQL Server application is ready to use and can be accessed on the EC2 console. You can manage your SQL Server application with AWS SSM or with the deployed Bastion Host. If you don’t have a lot of experience on AWS, or with SQL clustering, using the Launch Wizard will decrease your time to deployment.

Setting up EC2 Instances and Deploying SharePoint Server Components

The CloudFormation template previously provided has deployed the necessary Amazon EC2 instances and base infrastructure for this section, including staging the SharePoint media on each server. In this deployment scenario, we're focusing on launching the SharePoint Front End and SharePoint Application server roles. You can add additional servers into the farm using the same architecture patterns if you want to include Distributed Cache and Search Servers for your SharePoint deployment. This guide covers the basic deployment recommendation, providing a foundation for the recommended base architecture for SharePoint.

Join All Servers to Your Active Directory Domain

Before proceeding, you need to log into each server and join them to your Active Directory domain. You'll need:

• IP addresses of your domain controllers
• A domain user account with permissions to join computers to the domain

If you're new to AWS and setting up Active Directory, review this blog on implementing Hybrid DNS and using Amazon Route 53 Resolver for easier DNS setup in your environment.

Accessing EC2 Instances

To obtain the Administrator password for each EC2 instance:

1. Navigate to the AWS Secrets Manager console
2. Under Secrets, find the one titled STACKNAME-Adminpassword (where STACKNAME is your CloudFormation stack name)
3. The description should read "Administrator password for SharePoint EC2 instances"

Once you have the password, log into each server using AWS Systems Manager Fleet Manager RDP and join them to the domain as you would any other server.

Configure SQL Server Security Groups

To allow access from our EC2 instances to the SQL Server deployment:

1. Locate the SQL Server instances deployed via AWS Launch Wizard
2. For each EC2 instance: a. Select the instance b. Go to Action > Security > Change Security Group c. Add the previously created Security Group (deployed as part of the CloudFormation template)

[Figure 4: EC2 Console showing selections for changing EC2 security group]

The Security Group to add is named: SQL Server Security Group

This Security Group allows all traffic from the EC2 instances in the group, enabling access from the SharePoint WFE, APP server, and Bastion Server to your SQL Server cluster.

Create SQL Server and SharePoint Service Accounts

Instead of using the SQL Admin account created by AWS Launch Wizard (which has overly permissive access), we'll create new service accounts with appropriate permissions for SharePoint.

Create SharePoint SQL Account

1. On the Bastion host, open the Directory Service user administration tool (Start > Run > dsa.msc)
2. Navigate to your OU for the newly created domain in Active Directory
3. Create a new user (use a descriptive name, e.g., sharepointSQL)
4. Set a strong password, and configure the account:
   • Password never expires
   • User cannot change password
5. Open SQL Server Management Studio on the Bastion host
6. Expand Security and right-click on Logins
7. Add your SharePoint account to SQL Server
8. Assign the dbcreator and securityadmin SQL server roles to the user
9. Verify login access to SQL Server Management Studio with the new user, using the SQL Server listener as the connection point

Create SharePoint Managed Service Account

1. On the Bastion host, open the Directory Service user administration tool
2. Navigate to your OU for the newly created domain in Active Directory
3. Create a new user (use a descriptive name, e.g., sharepointadmin)
4. Set a strong password, and configure the account:
   • Password never expires
   • User cannot change password
5. Delegate the following permissions by adding the account to the necessary AD groups:
   • In AWS Managed AD, select:
     • AWS Delegated Kerberos Delegation Administrators
     • AWS Delegated Server Administrators
   • Note: Domain Admin will provide the needed access but avoid this if possible for security best practices
6. Click OK to finish creating the user

Deploy SharePoint WFE Role to WFE 1 and WFE 2 Servers

We'll first deploy the SharePoint Web Front End servers. You'll find these servers labeled as SharePoint WFE 1 and SharePoint WFE 2 in your environment.

For each WFE server (WFE1 and WFE2):

1. Log into the server using an account with local administrator privileges
2. Navigate to C:\SharePointMedia
3. Run prerequisiteinstaller.exe to install any missing pre-requisites for SharePoint Server
4. Restart the server after the installer completes
5. Log back in as your domain user with local admin permissions
6. Navigate to C:\SharePointMedia and run setup.exe
7. In the setup wizard: a. Enter your product key (For testing, you can get a temporary key from the Microsoft Website) b. Accept the license terms c. Proceed with installation
8. After installation, run the SharePoint Products Configuration Wizard (reboot if required)
9. In the configuration wizard: a. For WFE1: Choose "Create a new server farm" b. For WFE2: Choose "Connect to an existing server farm" c. Provide SQL Server details (use the Always On Listener endpoint, e.g., spsql.sharepoint.local) d. Create a farm passphrase (WFE1 only) e. Specify the server role as "Front-end" f. Leave the default random port for "Specify port number" g. Choose NTLM authentication (review moving to Kerberos post-deployment)
10. After configuration, the Central Administration site will open
11. Log on through the NTLM prompt using Active Directory credentials

For WFE1 only: 12. In Central Administration, run the Farm Configuration Wizard to set up basic services a. Select "Create a new managed account" and use the Active Directory service account created earlier b. Provide the password for this account 13. Enable necessary options for your environment (varies per deployment needs)

Deploy SharePoint Application Role to APP 1 and APP 2 Servers

Now we'll add the Application layer to the farm. For each Application server (APP1 and APP2):

1. Log into the server using a domain account with local administrator privileges
2. Repeat steps 2-10 from the WFE installation process
3. When running the SharePoint Products Configuration Wizard:
   • Choose "Connect to an existing server farm"
   • Provide the same database server and farm passphrase used for the WFE servers
4. After configuration, open Central Administration
5. Go to "System Settings" > "Manage servers in this farm"
6. Verify that the APP server is listed with the role "Application with Search"
7. In Central Administration, go to "Application Management" > "Service Applications" > "Manage Service Applications"
8. For each service application: a. Click on it and choose "Properties" b. Add both APP1 and APP2 as servers that can run the service application
9. Go to "System Settings" > "Manage services on server"
10. Start necessary services on both APP1 and APP2, such as:
    • SharePoint Server Search
    • Distributed Cache
    • Microsoft SharePoint Foundation Web Application
11. Verify that services are running correctly on both application servers

Configuring SharePoint Server Database for Always On

During the SQL Server Launch Wizard configuration, you deployed the SQL Server implementation using a SQL Always on Availability Group. However, the SharePoint databases are not added to this configuration when you deploy it using the installation wizard. In order to assure you're taking advantage of the high availability configuration, make sure to add your SharePoint databases to the Always On configuration of SQL Server. Microsoft documentation, on how to add your existing database to the configuration.

Configuring Load Balancing and Network Access

Setting up Amazon Network Load Balancer

Configure the Network Load Balancer (NLB) to distribute traffic to your Web Front End nodes:

1. Network Load Balancer Configuration:

   • Ensure that the NLB is configured for TCP (not TLS) on port 80 (It’s recommended to enable 443 after deployment)
   • Enable Proxy Protocol v2 on the NLB's target group to preserve client IP addresses (This should be done via the CloudFormation template, but verify the configuration)
   • Verify health check settings are appropriate for SharePoint (TCP health checks should show healthy for both WFE nodes)

2. Configure SharePoint Web Applications:

   • In Central Administration, edit the Authentication Providers for each web application
   • Under Claims Authentication Types:
     • Select "Enable Windows Authentication"
     • Choose "Negotiate (Kerberos)"

3. Configure Internet Information Services (IIS) on SharePoint Servers:

   • Open IIS Manager on each SharePoint front-end server
   • Select the website
   • Open Authentication settings
   • Configure authentication:
     • Disable Anonymous Authentication
     • Enable Windows Authentication
   • Right-click on Windows Authentication and select "Advanced Settings"
   • Set configuration values:
     • "Extended Protection" = "Accept"
     • "Enable Kernel-mode authentication" = True

4. Configure SharePoint Alternate Access Mappings:

   • Navigate to Central Administration
   • Go to "Configure alternate access mappings"
   • Ensure the public URL matches the URL users will use to access SharePoint through the NLB

5. DNS Configuration:

   • Configure your DNS record (e.g., sharepoint.yourdomain.com) to resolve to the NLB's IP address
   • If using Amazon Route 53, create an A record pointing to the NLB

Verifying SharePoint Deployment

To verify your SharePoint deployment is functioning correctly:

1. Access Verification:

   • Open a web browser
   • Navigate to your SharePoint site (e.g., https://sharepoint.yourdomain.com)
   • Verify you can:
     • Successfully authenticate
     • Access SharePoint resources
     • Navigate between pages without errors

2. Load Balancer Verification:

   • Verify traffic distribution across WFE servers
   • Check target group health status in the AWS Management Console
   • Review NLB access logs if enabled

3. Common Issues:

   • Authentication errors may require review of:
     • Active Directory permissions
   • Network connectivity issues may require:
     • Security group verification
     • Route table validation
     • Network ACL checking

Resource Cleanup

If you're not continuing with this SharePoint installation, follow these steps to remove resources and avoid ongoing costs:

1. Delete AWS CloudFormation Stacks:

   • SQL Server deployment stack
   • Core infrastructure stack This will remove:
   • Amazon EC2 instances
   • Amazon VPC and related components
   • Elastic Load Balancing resources
   • Associated security groups

2. Remove Active Directory Resources:

   • If using AWS Directory Service for Microsoft Active Directory and it's no longer needed:
     • Navigate to the AWS Directory Service console
     • Select your directory
     • Choose "Delete directory"
   • Note: Ensure no other resources depend on this directory before deletion

3. Additional Cleanup:

   • Delete any manually created:
     • Amazon Route 53 DNS records
     • Custom security groups
     • AWS Secrets Manager secrets
   • Remove any custom IAM roles or policies created for this deployment

Conclusion

In this guide we’ve provided a base architecture pattern to be used with SharePoint Server running on AWS EC2 instances. This will hopefully help you get the base infrastructure configuration setup for SharePoint server running on AWS.

This guide has provided a base architecture pattern for running SharePoint Server on AWS using:

• Amazon EC2 instances for SharePoint servers
• Elastic Load Balancing for traffic distribution
• Amazon VPC for network isolation
• AWS Directory Service for authentication
• AWS Launch Wizard for SQL Server deployment

The resulting infrastructure provides:

• High availability across multiple Availability Zones
• Secure access through proper network segmentation
• Scalable architecture for future growth
• Integration with AWS managed services

For production deployments, consider additional factors such as:

• Regular backup strategies
• Monitoring and alerting setup
• Patch management procedures
• Disaster recovery planning
• Security compliance requirements

For more information about running Microsoft workloads on AWS, visit the AWS Microsoft Workloads page.