Microsoft SharePoint Server on AWS: Reference Architecture

Transcription

1 Micrsft SharePint Server n AWS: Reference Architecture (Please cnsult fr the latest versin f this paper.) Page 1 f 36

2 Abstract Amazn Web Services (AWS) prvides a cmplete set f services and tls fr deplying Windws wrklads, including Micrsft SharePint Server, n its highly reliable and secure clud infrastructure platfrm. This white paper discusses general cncepts regarding hw t use these services and prvides detailed technical guidance n hw t cnfigure, deply, and run a SharePint Server farm n AWS. It illustrates reference architecture fr cmmn SharePint Server deplyment scenaris and discusses their netwrk, security, and deplyment cnfiguratins s yu can run SharePint Server wrklads in the clud with cnfidence. This white paper is targeted t IT infrastructure decisin- makers and administratrs. After reading it, yu shuld have a gd idea f hw t set up and deply the cmpnents f a typical SharePint Server farm n AWS. Yu learn which artifacts t use and hw t cnfigure the varius infrastructure details, such as cmpute instances, strage, security, and netwrking. Page 2 f 36

3 Intrductin Enterprises need t grw and manage their glbal cmputing infrastructures rapidly and efficiently while simultaneusly ptimizing and managing capital csts and expenses. AWS s cmputing and strage services meet this need by prviding a glbal cmputing infrastructure. The AWS infrastructure enables cmpanies t rapidly spin up cmpute capacity r quickly and flexibly extend their existing n- premise infrastructure int the clud. AWS prvides a rich set f services and rbust, enterprise- grade mechanisms fr security, netwrking, cmputatin, and strage. SharePint Server is a widely deplyed applicatin platfrm, cmmn in many rganizatins as the main prtal fr team crprate cllabratin, cntent management, wrkflw, and access t crprate applicatins. One key benefit f SharePint Server is that it enables rganizatins t rapidly respnd t changing business needs. AWS is a perfect cmplement t SharePint Server, because it enables rganizatins t rapidly prvisin the necessary cmputing infrastructure t pwer SharePint Server slutins. AWS and Micrsft have partnered t enable custmers t deply enterprise- class wrklads invlving Windws Server and Micrsft SQL Server n a pay- as- yu- g, n- demand elastic infrastructure, thereby eliminating the capital cst fr server hardware and greatly reducing the prvisining time required t create r extend a SharePint Server farm. This partnership has resulted in the ability t license and run SharePint Server n AWS under prvisins in Micrsft s License Mbility thrugh Sftware Assurance prgram. As a relevant data pint and case study, the Amazn Crprate IT team hsts Amazn s wn crprate intranet running SharePint Server n AWS. They have published a white paper detailing its evaluatin, security requirements, architecture, benefits, and lessns learned frm the deplyment. Nte that at the time the Amazn Crprate IT team deplyed their SharePint Server envirnment and wrte the white paper, a number f the AWS services discussed herein were either nt in place r limited in their availability. This current paper prvides an up- t- date and mre high- level descriptin f hw t supprt SharePint Server n AWS. Page 3 f 36

4 SharePint Server Reference Architecture and Scenaris T understand hw SharePint Server and assciated cmpnents can be hsted n AWS, let s first review the architecture and cmpnents f a typical SharePint Server farm and explre the cmmn scenaris and tplgies. SharePint Server Farm Reference Architecture Micrsft prvides cnsiderable guidance fr architecting SharePint Server farm tplgies fr many scenaris and scales. This sectin reviews the typical SharePint Server farm architecture as recmmended by Micrsft and identifies a cuple f cmmn deplyment scenaris and assciated tplgies that yu will map nt AWS later in this paper. SharePint Server has evlved ver several versins t prvide a rich set f capabilities and services. SharePint Server architecture has als evlved t supprt a service- based architecture, enabling specific services t be scaled ut t individual servers and server grups. In additin, SharePint Server reference architecture defines distinct rles and server grups that yu can create and scale ut independently. This mdel fits nicely within AWS s scale- ut apprach. The SharePint Server reference architecture tiers and services are illustrated in Figure 1. Surce: us/library/ff aspx Figure 1: The SharePint Server reference architecture Additinal infrastructure cmpnents are required r recmmended t supprt SharePint Server farms: Active Directry Dmain Services (AD DS). SharePint Server requires AD DS t serve as the authritative identity stre and authenticatin mechanism. AD DS (with ne r mre dmain cntrllers) must reside within the same netwrk as the SharePint Server farm and be accessible t SharePint Server farm instances. Page 4 f 36

5 Threat management and intrusin prtectin. This cmpnent may be an additinal element fr SharePint Server scenaris that include external r public- facing sites. In a Windws- based infrastructure, this cmpnent wuld typically be prvided by prducts such as Micrsft Frefrnt Threat Management Gateway Cmmn SharePint Server Deplyment Scenaris SharePint Server can supprt a variety f cntent and cllabratin gals. This paper discusses tw f the mst cmmn scenaris: intranet hsting f a crprate SharePint Server farm and hsting f an Internet site based n SharePint Server. Intranet SharePint Server Farm In this scenari, a cmpany wants t run SharePint Server within its enterprise t supprt internal users. The cmpany may deply its entire SharePint Server farm in the clud and scale all the cmpnents t get additinal capacity r extend its n- premise deplyment t the clud t increase capacity, imprve perfrmance, r scale the resurce- intensive cmpnents in the clud, when needed. Specific resurce- intensive services such as Micrsft Office Excel r Wrd may be hsted individually t supprt specialized wrklads. Figure 2 illustrates this scenari. Figure 2: Typical intranet SharePint Server farm tplgy Page 5 f 36

6 Internet Website r Service Based n SharePint Server In this scenari, SharePint Server is used as the basis fr hsting a website, public web applicatin, r Sftware as a Service (SaaS) site. This scenari is different frm the intranet scenari in that public- facing servers have been added. These servers require enhanced security and threat management as well as AD DS dmain cntrllers t supprt user authenticatin and authrizatin. Figure 3 depicts this scenari. Figure 3: Typical SharePint Server farm tplgy fr an Internet- facing public website Key elements that distinguish this scenari frm the previus intranet scenari are: A demilitarized zne (DMZ) t prvide firewall and threat management at the frnt- line access pints Active Directry dmain cntrllers resident within the farm (nt assciated with the user envirnment) Page 6 f 36

7 Implementing SharePint Server Architecture Scenaris in AWS The remainder f this white paper prvides step- by- step mapping fr each SharePint Server farm scenari discussed earlier t an equivalent setup in AWS, including similar resurces, netwrk and security setup, and cnfiguratin. T implement the SharePint Server scenaris in AWS, the fllwing elements are discussed: Netwrk setup and cnfiguratin. This sectin cvers the setup f the netwrk fr the SharePint Server farm within AWS, including subnets t supprt the lgical server grups fr different tiers and rles within the SharePint Server reference architecture. Server setup and cnfiguratin. This sectin cvers the services and artifacts invlved in the setup f the varius servers fr each tier and rle in the SharePint Server farm. It als includes setting up and cnfiguring SQL Server and supprting high availability. Security. This sectin discusses security mechanisms in AWS, including hw t cnfigure instance and netwrk security t enable authrized access t the verall SharePint Server farm as well as between tiers and instances within the farm. It als cvers areas such as data privacy (encryptin) and threat management (in the case f the public- facing scenari). Deplyment and management. This sectin prvides details n packaging, deplyment, mnitring, and management f the SharePint Server farm cmpnents. Netwrk Setup Let s start with the netwrk setup t prvide the envirnment in which yu instantiate and cnfigure yur servers and database. The Micrsft reference architecture is rganized arund a multi- tiered (web, applicatin, and database) apprach, allwing yu t independently scale and cnfigure each tier. Yur first task is t define a netwrk envirnment that supprts this type f tiered structure and enables yu t deply the varius server rles in each tier with suitable security cnfiguratin. Amazn Virtual Private Clud A key cmpnent f AWS netwrking is the Amazn Virtual Private Clud (Amazn VPC). Amazn VPC prvides the ability t reserve an islated prtin f the AWS clud in which t deply and manage a SharePint Server farm. Amazn VPC supprts the creatin f public and private subnets within the virtual netwrk, allwing yu t hst the different tiers and rles within the SharePint Server architecture. Amazn VPC als supprts the ability t establish a hardware virtual private netwrk (VPN) cnnectin between a VPC and an external lcatin, such as a crprate data center. Custmers use a hardware r sftware VPN appliance (the custmer gateway) and cnnect that gateway t the VPC (the virtual private gateway) t prvide seamless integratin between n- premise cmpute infrastructure and resurces within the VPC. Leveraging this VPN VPC cnnectivity extends the crprate netwrk data center t the clud. Crprate users can interact with clud instances and applicatins in a relatively transparent way, effectively supprting the ntin f an extended enterprise in the clud. T map yur SharePint Server reference architectures and scenaris t AWS, yu must first structure yur VPC and subnets t mirrr the same rganizatinal tiers, server grups, and access requirements defined there. VPC subnets that need t be accessible frm the Internet thrugh the VPC Internet gateway need t be public; therwise, yu can Page 7 f 36

8 designate them as private, and they will nt be accessible frm utside the VPC. In the case f a VPN- cnnected VPC, cnnectins thrugh the VPN ccur thrugh the virtual private gateway; therefre, instances can be in private subnets but still reachable (as lng as the security cnfiguratin allws it). Thus, VPN- nly scenaris d nt require public subnets (e.g., fr web server frnt ends). Hwever, the public- facing SharePint Server scenari des need t be accessible frm utside f AWS, s each frnt- end instance must be in a public subnet t be reached via the Internet gateway. Fault tlerance and scalability fr ur SharePint Server farm scenaris is critical t ensure they can prvide sufficient perfrmance thrugh changes in lad, and be resilient t any unfreseen issues within the farm infrastructure. The Elastic Lad Balancing (ELB) web service can be used t be used t distribute internet- based requests t internal web servers, and s this is a suitable chice fr ur internet website scenari. Hwever, since ELB at this pint nly handles traffic cming frm utside the VPC, we can t use that fr ur intranet scenari (in which user requests cme in via the private VPN cnnectin). Fr the intranet scenari, we need t utilize a 3 rd party sftware lad balancer (such as the Riverbed Stingray Traffic Manager r HAPrxy) t achieve similar functinality. Yu als want t distribute multiple instances t each Availability Zne t prvide redundancy and failver in the case f an Availability Zne failure. VPC subnets d nt span Availability Znes, s yu must set up a separate but similar subnet structure within each zne. Likewise, set up lad balancing t distribute requests t servers in multiple Availability Znes. Therefre, yu shuld set up lad balancers in each Availability Zne used t prvide high availability there, as well. NOTE: The IP address ranges fr the VPC and subnets are defined using a single Classless Inter- dmain Ruting (CIDR) IP address blck, such as /16, prviding an internal IP address space f 65,536 unique IP addresses. Subnets can then be created with their wn unique CIDR blck ranges within the verall VPC address range. VPC Setup fr the Intranet Scenari Let s lk at the specific steps fr setting up a VPC instance fr the intranet scenari. The AWS Management Cnsle prvides a wizard- based apprach t setting up Amazn VPC envirnments fr a few typical Amazn VPC cnfiguratins. Fr yur SharePint Server intranet scenari, the gal is t set up the AWS envirnment t enable crprate users t use SharePint Server via VPN access; but yu d nt need t allw access frm the public Internet. The VPC Creatin Wizard ptin VPC with a Private Subnet Only and Hardware VPN Access initiates the setup yu are lking fr. NOTE: Servers within the farm may need t exit f AWS fr things like sftware updates. Such actins can be accmplished either by adding a netwrk address translatin (NAT) instance in the VPC and cnfiguring it t be public r by having the servers traverse the VPN tunnel t use the crprate data center Internet access. Amazn VPC includes a default rute table that guides cmmunicatins t and frm instances, and the VPC Creatin Wizard enables the rute tables t allw instances t cmmunicate with each ther (using the internal VPC IP addresses) and externally ut f the VPC (fr all ther IP addresses) thrugh the NAT instance. Based n the specifics f yur SharePint Server intranet scenari, yu must add several cmpnents int the results f the basic Scenari 4 setup that the VPC Creatin Wizard prvides: One VPC created within a specific AWS regin that has cmpnents spanning multiple Availability Znes. Yur SharePint Server infrastructure will be deplyed acrss multiple Availability Znes t prvide high availability. Page 8 f 36

9 Private subnets in each Availability Zne t hld yur lad balancers. A VPC can have multiple subnets in which each subnet resides in a separate Availability Zne. Each subnet must reside entirely within ne Availability Zne. Sftware Lad Balancers in each Availability Zne. This setup establishes primary and secndary lad balancers within each f the Availability Znes, where the primary distributes traffic t any f the healthy instances in either f the Availability Znes. In the event f a failure f the primary lad balancer (r the Availability Zne verall), the secndary lad balancer takes ver and cntinues t distribute traffic t remaining healthy instances. Private subnets in each Availability Zne t hld web, applicatin, and database servers as well as AD DS dmain cntrllers. These subnets are nt directly accessed by users (everything ges thrugh the lad balancers) and hence d nt need t be accessible utside f the VPC. One virtual private gateway and ne custmer gateway. These prvide VPN cnnectivity between the crprate data center and the VPC. Putting tgether everything discussed thus far, Figure 4 shws the netwrk cnfiguratin defined fr the intranet scenari. Figure 4: Netwrk cnfiguratin fr the intranet scenari Page 9 f 36

10 VPC Setup fr the Public Website Scenari Fr the public website scenari, there are different requirements and setup cnfiguratins. The public website scenari mst resembles the VPC Creatin Wizard scenari VPC with Public and Private Subnets. The differences between the public website scenari and the intranet scenari are: In the public website scenari, yu d nt have a crprate data center, s there is n need t set up a VPN cnnectin. With a public website, there is n need fr a virtual private gateway (because yu are nt cnnecting t a VPN). In this scenari, AWS Elastic Lad Balancers are emplyed In a public- facing website, the lad balancers need t be in public subnets s that users can access them ver the Internet. Yu still want t put the web, applicatin, and database tiers in private subnets; users nly need t get at the lad balancers. The public website scenari requires additinal cmpnents at the frnt end fr firewall and threat management (mre n this tpic later). The public website scenari adds NAT instances in each Availability Zne t facilitate servers in private subnets cmmunicating ut t the Internet (t get perating system sftware updates, fr example). Given these differences, Figure 5 shws the netwrk setup fr the public website scenari. Page 10 f 36

11 Figure 5: Netwrk cnfiguratin fr the Internet- facing public website scenari AD DS Setup and DNS Cnfiguratin SharePint Server requires AD DS fr user authenticatin. Hwever, yu als want t leverage AD DS t prvide Dmain Name System (DNS) functinality within the VPC amng the varius server instances. Fr yur SharePint Server farm t perate, yu need cnnectivity t ne r mre dmain cntrllers t facilitate user authenticatin and DNS reslutin acrss servers within the farm. In the intranet scenari, yu want the SharePint Server instances t authenticate t users crprate credentials (effectively an extensin f their crprate netwrk). There are tw different ways t supprt this behavir: SharePint Server instances culd traverse the VPN VPC cnnectin back t the crprate data center and authenticate t n- premise dmain cntrllers. Dmain cntrllers culd be hsted in AWS and replicated frm n- premise dmain cntrllers via the VPN VPC cnnectin. This actin allws the servers t authenticate t lcal (within AWS) dmain cntrllers but still authenticate t crprate user identities and credentials. Amazn recmmends the secnd ptin fr better perfrmance and reliability. The dmain cntrllers can be replicated acrss Availability Znes (as with yur ther resurces) t prvide high availability. Micrsft prvides guidance n Active Directry Replicatin Over Firewalls. Page 11 f 36

12 NOTE: It is als pssible t supprt this scenari fr crprate envirnments that d nt use AD AD but rather anther Lightweight Directry Access Prtcl (LDAP) based directry service. Yu can use Active Directry Federatin Services (AD FS) with SharePint Server and ther (nn- AD DS) authenticatin prviders t facilitate federated authenticatin. AWS prvides a detailed white paper n hw t set up and cnfigure AD FS in AWS t supprt federated authenticatin. Figure 6 depicts the additins t the hsting infrastructure and AD DS replicatin details. Figure 6: Additins t the hsting infrastructure and AD DS replicatin details fr the intranet scenari In yur public- facing scenari, the SharePint Server farm is nt cnnected t a crprate infrastructure via VPN. Instead, it requires AD DS t be instantiated within the AWS envirnment t facilitate user registratin and authenticatin fr the SharePint Server instances running there. As in the intranet scenari, Amazn suggests hsting dmain cntrllers in multiple Availability Znes t prvide redundancy and high availability, as illustrated in Figure 7. Page 12 f 36

13 Figure 7: Hsting dmain cntrllers in multiple Availability Znes t prvide redundancy and high availability AD DS is typically run in n- premise, static envirnments, and there are certain typical cnfiguratin details and assumptins that are different when AD DS runs in AWS. Fr AD DS dmain cntrllers t be used fr DNS in AWS and acrss Availability Znes, each needs t be in a security grup that pens User Datagram Prtcl (UDP) prts 0 65,535. (Security grups are discussed in detail in a later sectin.) Server Setup and Cnfiguratin Nw that yur netwrk is set up in the structure yu need, let s tackle the task f setting up and instantiating the varius server instances within the VPC t supprt yur SharePint Server reference architectures. At the heart f AWS is the Amazn Elastic Cmpute Clud (Amazn EC2) web service, a clud cmputing infrastructure that supprts a variety f perating systems and machine cnfiguratins (e.g., CPU, RAM). AWS prvides precnfigured virtual machine (VM) images (Amazn Machine Images, r AMIs) with guest perating systems (Linux, Windws, etc.) and may have additinal sftware (e.g., SQL Server) used as the basis fr virtualized instances running in AWS. Yu can use these AMIs as starting pints t instantiate and install r cnfigure additinal sftware, data, and mre t create applicatin- r wrklad- specific AMIs. T implement the varius tiers and rles in the SharePint Server reference architecture, start ut with AMIs that are based n Windws Server 2008 R2, and lk at the sftware running each ne t determine which AMIs are applicable t web, applicatin, r database tier servers. At this time, several AMIs supprt sme versin f Windws Server. Sme AMIs include cmpnents like Micrsft Internet Infrmatin Services (IIS) fr the web tier rles; thers include SQL Server Standard (fr the database tier). Page 13 f 36

14 SharePint Server is nt preinstalled in any f the Windws- based AMIs because f licensing mdel restrictins. The nly supprted apprach t licensing SharePint Server n AWS is thrugh Micrsft s License Mbility thrugh Sftware Assurance prgram. Custmers cvered by active Micrsft Sftware Assurance cntracts may mve current n- premise Windws Server applicatin wrklads (such as SharePint Server) t AWS withut additinal Micrsft sftware license fees. AWS prvides a cmprehensive cllectin f infrmatin, tls, and resurces fr running Windws- based applicatins and wrklads n AWS. Als, there is detailed infrmatin abut hw Windws is supprted and used n Amazn EC2. Finally, yu can find details n the specific AMIs that include Windws, SQL Server, etc., within the Amazn EC2 AMI catalg. Mapping SharePint Server Rles and Servers t Amazn EC2 AMIs and Instance Types A key aspect f implementing yur AWS slutin is chsing the apprpriate AMI and instance type fr each rle within the farm. Each rle in the SharePint Server reference architecture has distinct requirements fr sftware and infrastructure resurces, such as CPU, RAM, and disk strage. Micrsft and AWS have partnered t publish a number f Windws- based AMIs that include additinal sftware cmpnents fr supprting typical rles (e.g. IIS fr web server, SQL Server fr database server, Windws cre fr dmain cntrller) that run n a variety f Amazn EC2 instance types. In terms f machine capacity and sizing, Micrsft prvides detailed guidance fr varius cmpnents within a SharePint Server farm, s that tpic is nt be cvered in this paper. Hwever, the basic details f typical system requirement minimums fr varius cmpnents within a SharePint Server farm are summarized in the tables that fllw. Table 1 presents the minimum system requirements Micrsft recmmends fr the different tiers and rles within a SharePint Server farm. Table 1: Minimum system requirements fr SharePint Server rles and tiers Tier/rle Scenari Prcessr RAM Hard disk Web/Applicatin Tier All 64- bit, 4 cre 8 GB 80 GB Database server Small deplyment 64- bit, 4 cre 8 GB 80 GB Database server Medium deplyment 64- bit, 8 cre 16 GB 80 GB Dmain cntrller All 64- bit, 4 cre 8 GB 80 GB Table 2 shws hw t map these requirements t Amazn EC2 AMIs and Windws instance types. Page 14 f 36

15 Table 2: Mapping minimum system requirements t AMIs and Windws instance types Tier Applicable Amazn EC2 instance type and range AMI t use Web frnt end Extra Large (m1.xl) Windws Server 2008 R2 + IIS Applicatin server Extra Large: High Memry Quad Extra Large Windws Server 2008 R2 (m2.xl m2.4xl) Database server High Memry Quadruple Extra Large (m2.4xl) Optimized SQL Server 2008 R2 AMIs frm Micrsft Dmain cntrller Extra Large (m1.xl) Windws Server (in the rle f a dmain cntrller) The AMIs listed in Table 2 include the default cnfiguratin fr Amazn EBS vlumes (frmatted as Windws file systems) fr bt drive and assciated data strage applicable t the rle. The SQL Server 2008 R2 AMIs indicated have been cnfigured with multiple EBS vlumes t supprt distinct SQL Server strage cmpnents (data, lgs, temp files), ptimizing fr strage requirements and I/O patterns f each cmpnent. Amazn EC2 als supprts the ability t custmize an instance, allwing yu t attach additinal Amazn EBS vlumes r resize an existing Amazn EBS vlume by taking a snapsht, and then creating a new, larger vlume frm the snapsht. Yu can then use this custmized instance as the basis fr a new, custmized AMI. SharePint Server Cnfiguratin As mentined earlier, SharePint Server is nt pre- installed in any publically available AMI, s yu must btain sufficient licensing fr deplying SharePint Server in AWS (thrugh Micrsft License Mbility) and then install SharePint Server int yur instances. Typically, yu will create yur wn private SharePint Server AMI, by creating a Windws Server- based instance, installing and cnfiguring SharePint Server, and then turning that instance int an AMI as described here. This private AMI will be the basis f the varius SharePint Server instances in yur farm. SQL Server Cnfiguratin The versins f SQL Server that are included and licensed fr use with the Windws Server AMIs are SQL Server Express and SQL Server Standard. SQL Server Enterprise can be installed in Windws AMIs and used in AWS as well but must be licensed fr use in the same way as SharePint Server, thrugh prvisins in the Micrsft License Mbility thrugh Sftware Assurance prgram. As in n- premise deplyments, the data tier fr SharePint Server in AWS needs t be architected and cnfigured t supprt sufficient perfrmance, high availability, and reliability t prvide a gd user experience and quickly respnd t a database failure with minimal transactin lss. Fr SQL Server instances, Amazn recmmends the High Memry Quadruple Extra Large Amazn EC2 instance type. This type prvides higher- perfrmance netwrk I/O (high). This higher perfrmance, cmbined with the ther metrics such as CPU, yields a gd perfrmance prfile fr SQL Server running n AWS. Recmmended Amazn EBS Disk Cnfiguratin fr SQL Server Amazn EBS vlumes can be cnfigured in a variety f ways (redundant array f independent disks [RAID] striping, different vlume sizes, etc.) t yield different perfrmance characteristics. The ptimized SQL Server Standard AMI mentined earlier is published jintly between Micrsft and AWS and is cnfigured with separate Amazn EBS vlumes, each string key SQL Server data cmpnents as recmmended by Micrsft fr ptimal perfrmance. Page 15 f 36

16 Fr high- I/O scenaris, it is pssible t create and attach additinal Amazn EBS vlumes and t stripe using sftware RAID t increase the ttal number f I/O peratins per secnd (IOPS). Each Amazn EBS vlume is prtected frm physical drive failure thrugh drive mirrring, s using a RAID level higher than RAID- 0 is unnecessary. Fr SharePint Server instances, it is cmmn t use Remte BLOB Strage (RBS) in cnjunctin with SQL Server fr strage f file- based cntent. This file- based cntent will reside in SQL Server instances, and the existing Amazn EBS cnfiguratin shuld be sufficient fr mst uses. Hwever, it may be desirable r necessary t extend the size r add mre Amazn EBS disks (r ther assciated strage) fr supprting large RBS stres. Fr further details regarding Amazn EBS setup, cnfiguratins, and tuning ptins, see the Amazn Elastic Cmpute Clud User Guide. High Availability fr SQL Server Yu can achieve high availability fr SQL Server in AWS by implementing SQL Server mirrring acrss multiple Availability Znes. In this cnfiguratin, SQL Server instances are launched in tw different Availability Znes (within a Regin), with a smaller witness SQL Server instance t mnitr and facilitate the failver, if needed. Figure 8 illustrates this cnfiguratin. Page 16 f 36

17 Figure 8: SQL Server mirrring acrss multiple Availability Znes AWS recently published RDBMS in the Clud: Micrsft SQL Server 2008 R2, a cmprehensive resurce that prvides a detailed discussin f cnsideratins, appraches, and ptins fr ptimizing the use f SQL Server in AWS. With the additin f yur Amazn EC2 instances and SQL Server mirrring, yur intranet scenari lks like Figure 9. Page 17 f 36

18 Figure 9: Intranet scenari with the additin f Amazn EC2 instances and SQL Server mirrring With the additin f yur Amazn EC2 instances and SQL Server mirrring, yur public site scenari lks like Figure 10. Page 18 f 36

19 Figure 10: Public site scenari with the additin f Amazn EC2 instances and SQL Server mirrring Security Security setup is critical in the implementatin f yur SharePint Server farm t enable prper netwrk access (in and ut f the VPC, specific subnets, and the instances running each subnet) t facilitate user authenticatin and apprpriate authrizatin, data privacy, and threat management (in the case f public- facing sites). These and ther key elements have t be set up crrectly t prvide the necessary security measures and enable users t access their SharePint Server cntent and applicatins with the crrect identity and authrizatin. A crnerstne f yur scenaris is the use f Amazn VPC fr prviding the verall islatin f the farm and segmenting parts f the farm (i.e., the server grups) t supprt the desired management and cntrl. Within Amazn VPC and subnet islatin, there are security details that yu must set up t enable prper access (and restrictins). The tw main appraches at yur dispsal are: Security grups. A security grup acts as a firewall that cntrls the traffic allwed in and ut f a grup f instances. When yu launch an instance in a VPC, yu can assign the instance t up t five VPC security grups. Security grups act at the instance level, nt the subnet level. In general, it is a gd idea t define distinct security grups fr each tier. Ding s allws yu t define the settings fr each tier (and vary them independently) as well as restrict access t the calling tier (e.g., allwing the database tier t be called nly frm the applicatin tier). Netwrk access cntrl lists (ACLs). A netwrk ACL is an ptinal layer f security that acts as a firewall fr cntrlling traffic in and ut f a subnet. Yu might set up ACLs with rules similar t yur security grups t add a layer f security t yur VPC. Netwrk ACLs act at the subnet level, nt the instance level. Page 19 f 36

20 Security Grups Here are the tw appraches discussed in greater detail: Elastic Lad Balancing: Elastic Lad Balancing is the pint f cntact fr users, s the Elastic Lad Balancing security grup shuld be cnfigured t supprt inbund client cnnectin types f HTTP r HTTPS (prt 80 and prt 443, respectively). Yu can cnfigure the Elastic Lad Balancing in any cmbinatin, but Amazn recmmends using HTTPS fr bth inbund client cnnectin types. Yu shuld create an utbund security rule that lists the web tier security grup as the target, restricting the lad balancer t sending requests ut t the web tier instances nly. Web tier: In the scenari, the web tier instances are nt directly expsed but receive requests via the elastic lad balancer. Yu can (and shuld) cnfigure the web instances t accept requests nly frm the lad balancer. Frtunately, the lad balancer includes a special surce security grup. Create a security rule fr yur web tier that restricts inbund access t this special security grup, ensuring that nly the lad balancers are allwed t send t and receive frm the web frnt- end instances. Yu can als set up an utbund rule t limit utging requests t the applicatin tier instances. Applicatin tier: As in the web tier case, yur applicatin tier security grup shuld be cnfigured with an inbund rule listing the web tier security grup as an allwed sender and an utbund rule listing the database security grup fr utging messages. Database tier: As in the ther cases, yu shuld require Secure Sckets Layer (SSL) fr cnnectins t and frm SQL Server. Ding s requires the use f a security grup with a rule that allws SSL (prt 443) t be used nly fr the database instances. Yu als want t restrict inbund access t the applicatin tier instances, s create a security rule that restricts inbund access t the applicatin tier security grup. The Appendix includes a chart detailing the varius recmmended security grups and settings fr yur SharePint Server farm scenaris. Netwrk ACLs Netwrk ACLs mirrr the rules specified in security grups and add an extra layer f security t allw general access rules t be hnred regardless f which instances are sending r receiving. Because netwrk ACLs act at the netwrk level (nt the instance level), yu can set up additinal rules t handle certain netwrks, IP addresses, and address ranges in a specific way. Fr instance, yu can set up a netwrk ACL that defines a rule t deny ingress t a range f surce IP addresses (blacklisted IP addresses). Fr detailed guidance n setting up Amazn VPC netwrk ACLs, see the Amazn Virtual Private Clud User Guide. Page 20 f 36

21 Windws Instance Security Yu can cnfigure Windws instances within the VPC thrugh Grup Plicy bjects (GPOs) t require IP Security (IPsec) cnnectins, further ensuring secure cnnectivity t the instances. Administratr Access In yur architecture, the middle tier and database tier instances are placed in private subnets, restricting access frm utside the VPC. This placement reduces expsure and enhances security. Hwever, it is still necessary t prvide access t thse instances fr administrative purpses, such as cnfiguratin updates and trubleshting. T help manage the instances in the private subnet, an indirect (and secure) methd is t set up ne r mre bastin servers in a public subnet t act as prxies, and then set up SSH prt frwarders r Remte Desktp Prtcl (RDP) gateways t prxy access t the applicatin r database tier instances. After bastin servers are set up, administratrs can use RDP t gain access t the bastin hst; they can then access ther instances using SSH at their VPC private IP addresses. Figure 11 illustrates this arrangement. Figure 11: Using RDP t gain access t the bastin hst Data Privacy Because sensitive cntent and data can be stred within the SharePint Server farm, sme rganizatins may require that the cntent be encrypted. T successfully supprt encryptin f data within the AWS envirnment, a few key requirements must be cnsidered and supprted: Page 21 f 36

22 Encryptin technlgy. The Amazn EBS vlumes cntain the data at rest, in the frm f SQL Server database data and files. Amazn EBS vlume encryptin is nt supprted in AWS; hwever, there are ptins fr encryptin that can be cnsidered: Encrypting File System (EFS). Windws includes EFS, which supprts the ability t encrypt individual files r flders. BitLcker Drive Encryptin. Windws Server 2008 R2 supprts BitLcker, which prvides the ability t encrypt a disk file system attached t the server instance. SQL Server Transparent Data Encryptin (TDE). SQL Server Enterprise prvides native encryptin supprt thrugh TDE. Third- party Amazn EBS vlume encryptin. Third- party cmmercial ptins are available fr encryptin f Amazn EBS vlumes. Encryptin key management. Implementing encryptin requires secure management and authrized use f the encryptin keys. In the case f Amazn EC2, instances can be stpped and started as well as recvered frm Amazn EBS snapshts. In all these cases, the Amazn EBS vlumes will be encrypted, and the Amazn EC2 subsystem must access and use the encryptin key t be able t attach and use it n subsequent restarts. The AWS Slutin Prvider site lists several third- party sftware vendrs that prvide security infrastructure that supprts Amazn EBS encryptin and key management. Deplyment T set up yur SharePint Server farm in AWS, yu must establish and cnfigure several cmplex and interrelated details t enable prper functins and the crrect security settings. Furthermre, yu will inevitably need t change the cnfiguratin ver time t perfrm such actins as adding instances fr scale ut r updating instance cnfiguratins. AWS prvides a number f tls and appraches fr facilitating deplyment in AWS: AWS Management Cnsle. The AWS Management Cnsle is an interactive tl that is gd fr starting ut r smaller deplyments. Hwever, fr mre cmplex scenaris r autmated deplyment sequences, cnsider ne f the ther ptins described belw. AWS applicatin prgramming interface (API) tls. AWS prvides several cmmand- line interface (CLI) cmmands and prgrammatic web service APIs that are typically built int scripts; these cmmands allw a set f actins t ccur in a crdinated way. AWS sample cde and libraries. AWS prvides a Sample Cde & Libraries Catalg t supprt applicatin- based setup and cnfiguratin. Several prgramming languages are supprted thrugh sftware develpment kits (SDKs) that AWS prvides. AWS CludFrmatin. AWS prvides an easy way t create and manage a cllectin f related AWS resurces, prvisining and updating them in an rderly and predictable fashin. With AWS CludFrmatin, yu d nt need t figure ut the rder in which AWS services need t be prvisined r the subtleties f hw t make thse dependencies wrk: Page 22 f 36

23 Yu can use a tl called AWS CludFrmer t reverse- engineer an existing set f resurces r settings running in an AWS accunt int an AWS CludFrmatin template. S, a typical apprach fr a cmplex setup is t manually deply r cnfigure cmpnents f the SharePint Server farm, and then use this tl t generate an apprpriate AWS CludFrmatin script. NOTE: AWS CludFrmatin des nt supprt the creatin f VPCs at this time; hwever, it des supprt the creatin f the resurces within a VPC (e.g., Amazn EC2 instances, security grups). Windws and.net Develper Center. These Windws and Micrsft.NET tls include the AWS SDK fr.net and the AWS Tlkit fr Visual Studi. A key apprach t autmating deplyment f cmpnents within an AWS slutin is t create custm AMIs fr distinct rles that have additinal sftware dependencies and cnfiguratin requirements. Fr the SharePint Server reference architecture, distinct rles are defined (web frnt end, applicatin server, database server, and thers) fr which yu can create custm AMIs. Custm AMIs fr the SharePint Server farm architecture can be based n public Windws- based AMIs (as indicated earlier) r Windws- based AMIs that yu create as a starting pint. Mnitring and Management Yu must be able t mnitr a number f cre dimensins within a SharePint Server farm t enable crrectins and updates when issues ccur r perfrmance suffers. Amazn CludWatch is an AWS service that mnitrs varius health metrics assciated with AWS resurces. Yu can use it t cllect, analyze, and view system and applicatin metrics s that yu can make peratinal and business decisins mre quickly and with greater cnfidence. Amazn CludWatch sets several predefined metrics, such as CPUUtilizatin and disk I/O perfrmance, that AWS measures and that yu can view and act upn. Yu can als publish yur wn metrics directly t Amazn CludWatch t allw statistical viewing in the AWS Management Cnsle and t issue (and react n) custm alarms. Micrsft System Center Operatins Manager is the typical tl used t mnitr and manage a Micrsft- based infrastructure. Frtunately, Operatins Manager can be used in AWS, t. The Windws- based infrastructure n AWS includes the standard Operatins Manager agents fr Windws Server, SharePint Server, and SQL Server. In the intranet scenari, Operatins Manager wrks as it des in an n- premises case, because yur VPN VPC arrangement effectively extends the enterprise netwrk int the AWS clud. In the public site scenari, Operatins Manager can be hsted in an instance and accessed ver RDP (thrugh the bastin hst methd described earlier) and prvide mnitring and management against the ther cmpnents f the SharePint Server farm. Backup and Recvery Business cntinuity is a key requirement in the SharePint Server farm scenaris discussed here. Dwntime means cre cntent and cllabratin cannt ccur r yur website is dwn. As discussed earlier, yu can imprve availability by hsting multiple instances in different tiers distributed acrss AWS Availability Znes. Hwever, there still may be situatins in which system failures (e.g., because f sftware r hardware issues, disasters) ccur, r there is a need t rll back r recver sme r all f the farm data t a previus pint in time. Thus, yu must still have a backup and recvery strategy t supprt recvery f ne r mre data cmpnents r servers r the entire farm. Typically, recvery requirements are expressed in terms f tw metrics: Recvery time bjective (RTO). RTO is the time bjective in which t restre a prcess, service, r data item t required functinal level r accessibility. Fr example, an RTO f 4 hurs means that a full recvery is required t be up and peratinal within 4 hurs after a failure in the system. Page 23 f 36

24 Recver pint bjective (RPO). The RPO is the maximum acceptable amunt f data lss, expressed in time. Fr example, an RPO f 1 hur means recvered data may be at mst 1 hur ut f date frm the mst recent changes. In terms f supprting backup and recvery f SharePint Server farms n AWS, there are essentially tw appraches t cnsider: Use the built- in back- up and recvery mechanisms in SharePint Server and SQL Server, with Micrsft tls t back up t (and recver frm) Windws file- based strage lcatins. Use AWS backup and recvery mechanisms that perate against AWS resurces such as Amazn EBS vlumes. SharePint Server and SQL Server prvide their wn built- in capabilities fr backing up cntent, applicatin data, metadata, and cnfiguratin settings. In additin, yu can use tls such as Micrsft System Center Data Prtectin Manager (DPM) t back up cnfiguratin settings and metadata stred within SQL Server. Micrsft prvides significant guidance arund SharePint Server backup and recvery that can and shuld be used t prvide back- up and recvery capabilities, bth at the farm level and at the granular server r service level. In this case, Amazn Simple Strage Service (Amazn S3) prvides the mst natural lcatin in which t stre and retrieve this data. Amazn S3 des nt natively prvide a Windws file system interface, but pen surce and cmmercial tls are available that d prvide the ability t interact with Amazn S3 in this manner. Amazn EC2 prvides the ability t take pint- in- time snapshts f Amazn EBS vlumes and save them t Amazn S3 fr durable strage and recvery. Amazn EBS snapshts are incremental backups, meaning that nly the blcks n the device that have changed since the last snapsht will be saved. Als, when yu delete a snapsht, nly the data nt needed fr any ther snapsht is remved. S, regardless f which prir snapshts have been deleted, all active snapshts will cntain all the infrmatin needed t restre the vlume. In additin, the time t restre the vlume is the same fr all snapshts, ffering the restre time f full backups with the space savings f incremental backups. Snapshts can als be used t instantiate multiple new vlumes, expand the size f a vlume, r mve vlumes acrss Availability Znes. In the case f yur SharePint Server farm, the SQL Server instances within the data tier will hld the persistent state, s taking regular snapshts f the primary SQL Server data tier Amazn EBS vlumes prvides backup f the database itself and any assciated files (e.g., RBS files, metadata files). AWS recently published AWS Disaster Recvery, a whitepaper that prvides extensive details n the varius cnsideratins and ptins available within AWS t supprt disaster recvery. Page 24 f 36

25 Putting It All Tgether With all the key tpics cvered, let s see hw yur SharePint Server deplyment scenaris are ultimately set up in an AWS envirnment. Intranet SharePint Server Farm The key cmpnents f the intranet SharePint Server farm in an AWS envirnment scenari are as fllws: Amazn VPC, with VPN cnnectin t the crprate data center Private subnets nly, cnnected t the crprate netwrk via VPN At least tw Availability Znes used t survive the lw prbability f an Availability Zne failure Elastic lad balancers acrss web frnt- end servers SQL Server in mirrred cnfiguratin acrss Availability Znes Database (Amazn EBS vlume) snapshts Figure 12 illustrates this scenari. Figure 12: Intranet SharePint Server farm in AWS Page 25 f 36

26 Internet- facing Public Website n SharePint Server The key cmpnents fr the internet website hsted n SharePint Servers in an AWS envirnment scenari are as fllws: Amazn VPC, with public and private subnets Threat management gateway servers in the public subnet Elastic Lad Balancing acrss the threat management gateway servers Bastin hst in a public subnet, hsting a sftware VPN t prvide administrative access t internal instances At least tw Availability Znes used t survive the lw prbability f an Availability Zne failure Multiple web frnt- end servers behind threat management gateway servers within each Availability Zne in a private subnet SQL Server in mirrred cnfiguratin acrss Availability Zne private subnets AD DS dmain cntrllers in AWS fr user registratin and authenticatin Figure 13 illustrates this scenari. Figure 13: Public- facing Internet website n SharePint Server in AWS Page 26 f 36

27 Althugh yu can use SharePint Server t supprt a variety f cntent and cllabratin gals, these scenaris are tw f the mst cmmn. See the next sectin fr infrmatin abut ther scenaris and additinal resurces. Page 27 f 36

28 Cnclusin This paper discusses tw cmmn deplyment scenaris fr SharePint Server intranet and public website and hw t run them in an AWS clud envirnment. It discusses hw yu can leverage different services that AWS prvides (netwrk setup, server setup, security, and deplyment) and cnfigure them specifically t run enterprise- class sftware like SharePint Server at scale in a secure fashin that is easier t maintain. Page 28 f 36

29 Further Reading Micrsft n AWS: Amazn EC2 Windws Guide: Micrsft AMIs fr Windws and SQL Server: (SQL Server) AWS Windws and.net Develper Center: Micrsft License Mbility: White papers: Amazn s Crprate IT Deplys SharePint 2010 t the Amazn Web Services Clud at Relatinal Database Management Systems in the Clud: Micrsft SQL Server 2008 R2 at in- the- clud Prviding SSO t Amazn EC2 Apps frm an On- premises Windws Dmain at C4D3-474B E7D296FBFE71/EC2- Windws%20SSO%20v1% Chappell.pdf Page 29 f 36

30 Appendix Security Grup Settings fr a SharePint Server Farm The fllwing chart prvides an example f the typical security grup settings recmmended fr the SharePint Server reference architecture. Intranet SharePint Server Farm Tier/security grup Prtcl Prt range Elastic Lad Balancing Inbund Surce Web Tier Outbund Inbund Outbund IP address range f the crprate netwrk IP address range f the crprate netwrk Destinatin Cmments TCP 80 Allw inbund HTTP access frm crprate IP surces TCP 443 Allw inbund HTTPS access frm crprate IP surces WebTierSG TCP 80 Allw utbund access t web tier servers Surce Elastic Lad Balancing Surce Security Grup Elastic Lad Balancing Surce Security Grup IP address range f crprate administratrs ActiveDirSG TCP Destinatin TCP 80 Allw inbund HTTP frm Elastic Lad Balancing nly TCP 443 Allw inbund HTTPS access frm Elastic Lad Balancing nly TCP 3389 RDP access fr crprate administratrs AD DS AppTierSG TCP Allw nly web frnt- end servers t access the applicatin tier AppTierSG UDP Allw nly web frnt- end servers t access the applicatin tier Page 30 f 36

31 Tier/security grup Prtcl Prt range AppTier DBTier Inbund Outbund Inbund Outbund Cmments /0 TCP 80 Allw utbund HTTP access t servers n the Internet (e.g., fr sftware updates) /0 TCP 443 Allw utbund HTTPS access t servers n the Internet (e.g., fr sftware updates) Surce WebTierSG UDP Allw nly web frnt- end servers t access the applicatin tier IP address range f crprate administratrs ActiveDirSG TCP Destinatin TCP 3389 RDP access fr crprate administratrs AD DS DBTierSG TCP 1433 Allw utbund SQL Server access t database tier instances /0 TCP 80 Allw utbund HTTP access t servers n the Internet (e.g., fr sftware updates) /0 TCP 443 Allw utbund HTTPS access t servers n the Internet (e.g., fr sftware updates) ActiveDirSG TCP AD DS Database primary, mirrr, and witness Surce App TierSG TCP 1433 Allw nly web frnt- end servers t access the applicatin tier DBTierSG Allw database mirrr and witness IP address range f crprate administratrs ActiveDirSG TCP Destinatin TCP 3389 RDP access fr crprate administratrs AD DS Page 31 f 36

32 Tier/security grup Prtcl Prt Cmments range ActiveDirSG TCP AD DS /0 TCP 80 Allw utbund HTTP access t servers n the Internet (e.g., fr sftware updates) /0 TCP 443 Allw utbund HTTPS access t servers n the Internet (e.g., fr sftware updates) ActiveDirSG Inbund Surce Outbund ActiveDirSG TCP Allw AD DS dmains t talk t each ther ActiveDirSG UDP Allw AD DS dmains t talk t each ther /0 TCP 53 DNS fr VPC instance /0 UDP 53 DNS fr VPC instances /0 TCP 88 Kerbers authenticatin /0 UDP 88 Kerbers authenticatin /0 UDP 123 Netwrk News Transfer Prtcl (NNTP) /0 TCP Remte Prcedure Call (RPC), NetBIOS /0 UDP RPC, NetBIOS /0 TCP 389 LDAP t directry service /0 UDP 389 LDAP t directry service /0 TCP 445 Server Message Blck (SMB) /0 UDP 500 IPsec Internet Security Assciatin and Key Management Prtcl (ISAKMP) /0 TCP 636 LDAP Secure Sckets Layer (SSL) /0 UDP 636 LDAP SSL /0 TCP LDAP t glbal catalg server /0 UDP 4500 NAT traversal (NAT- T) /0 TCP Dynamic prts IP address range f crprate administratrs Destinatin TCP 3389 RDP access fr crprate administratrs Page 32 f 36

33 Tier/security grup Prtcl Prt Cmments range /0 TCP 80 Allw utbund HTTP access t servers n the Internet (e.g., fr sftware updates) /0 TCP 443 Allw utbund HTTPS access t servers n the Internet (e.g., fr sftware updates) Internet- facing Public Website n SharePint Server Tier/security grup Prtcl Prt Cmments range Elastic lad balancer Inbund Surce /0 TCP 80 Allw inbund HTTP access frm crprate IP surces /0 TCP 443 Allw inbund HTTPS access frm crprate IP surces Outbund Destinatin WebTierSG TCP 80 Allw utbund access t web tier servers BastinSG Security grup fr (public) bastin hst Web Tier Inbund Inbund Outbund Surce IP address range f crprate administratrs Surce Elastic Lad Balancing surce security grup Elastic Lad Balancing surce security grup TCP 3389 RDP access fr crprate administratrs TCP 80 Allw inbund HTTP frm Elastic Lad Balancing nly TCP 443 Allw inbund HTTPS access frm Elastic Lad Balancing nly BastinSG TCP 22 SSH access fr crprate administratrs ActiveDirSG TCP AD DS Destinatin Page 33 f 36