Good day! Please review the items listed below. Please, review before accepting the bid. Plagiarism will be checked. Thanks for your assistance. Part 1: Quality Management and Quality Assurance You ha

Where We Were Where We Wanted to Go and Why Our Deployment Success Criteria How We Launched Lessons We Learned What Benefits Emerged Where We Go From Here Where We Were We launched SharePoint 2007 when it was released. W e did this to provide teams worldwide with self-service portal site creation features and to give our corporate offices in various countries content publishing tools to manage our new global intranet site. Our employees use the self-se rvice features to create and manage sites that help them accomplish many tasks, including controlling access to central ly managed documents, communicating to their custom ers, publishing processes and procedures, sharing ideas and knowled ge, implementing business workflows, capturing and reporting on metrics, and other mission-critical use cases. Empl oyees were using SharePoint to drive mission critic al processes and store highly confidential corporate data. Over the past three years, usage and capacity have exploded due the massive growth across all teams wo rldwide. More than 30,000 employees per month worldwide regularly use our corporate intranet. Employees create separate Team Sites to collaborate with other team mates and mana gers create “My Sites” for projects and programs. The system now consists of thousands of Team Sites and My Sites, s everal SQL Server database servers, and a few web a nd application servers for serving content, central administration , and search. Due to the rapid growth of the service, corporate I T was looking to simplify the management of the har dware infrastructure, and the performing of common tasks such as lease returns, provisioning new hardware, supporting data center moves, and expanding SharePoint to support n ew geocentric requirements.

1 See http://sharepoint.microsoft.com . 2 See http://www.microsoft.com/sqlserver . 3 Throughout this document, the term ‘we’ refers to Amazon corporate IT. Amazon’s Corporate IT Deploys SharePoint 2010 to the Amazon Web Services Cloud Sep 2011 Page 3 of 13 Just like any other central IT department of any large enterprise, we also spent several weeks procuri ng hardware and several hours installing and configuring Windows op erating systems. Typically, our new hardware procur ement was taking four to six weeks. Our team was spending app roximately six hours per server rebuilding the hardware with the latest Windows operating system and patches. We wer e approaching the capacity limits of our current hardware and would need to make a significant investment to supp ort continued growth “on-premise.” Additionally, the business was demanding enterprise features that were available only in SharePoint 2010. In discussions with Microsoft, we determined that multiple disrupt ive upgrades would have to take place on our produc tion farm to support an in-place upgrade to SharePoint 2010, so it was a logical time to consider relocating the service.

Where We Wanted to Go and Why Given our desire to reduce infrastructure administr ation costs and to be able to scale on demand, we q uickly realized that the combination of SharePoint 2010 and AWS was the perfect marriage.

Some of the main reasons that the combination of th ese two technologies create a best-in-class service include the following:

Windows servers that typically take four to six wee ks to procure can be acquired and provisioned in mi nutes.

By bundling a Windows Server 2008 Amazon Machine Im age (AMI) 4, the host build process is completely automated.

Amazon Elastic Compute Cloud (EC2) 5 hosts would take us out of the business of lease r eturns.

Amazon Elastic Block Store (EBS) 6 would be used to scale SharePoint storage capacity within minutes independently from its compute resources.

Amazon Virtual Private Cloud (VPC) 7 would let us keep the SharePoint installation insi de our corporate network perimeter.

We wanted to prove that cloud resources would offer cost savings when compared to our corresponding hardware total cost of ownership (TCO).

Unhealthy SharePoint servers can be instantly repla ced. The replaced servers can either be discarded or saved for in-depth troubleshooting offline, reducing the customer impact.

The new SharePoint 2010 service application archite cture would allow services to be scaled independent ly— making scaling SharePoint 2010 application services and server roles a great fit for deployment to the cloud.

Taking SharePoint to the cloud would allow us to re alize the benefits of reduced hardware overhead, simplified operational support, improved service scalability, and infrastructure cost savings. Even with little knowledge of SharePoint 2010, we could learn as we built knowing that it is cheap to experiment in the cloud. If at any point we ran into problems, we could simply tear it down, evalua te what we learned, and start over with new design ideas. 4 See http://aws.amazon.com/amis?_encoding=UTF8&jiveRedir ect=1 . 5 See http://aws.amazon.com/ec2 . 6 See http://aws.amazon.com/ebs . 7 See http://aws.amazon.com/vpc . Amazon’s Corporate IT Deploys SharePoint 2010 to the Amazon Web Services Cloud Sep 2011 Page 4 of 13 Deploying a new instance of SharePoint 2010 would enable us to validate the functionality, benefits, and supportability of both the new release and enterprise features tha t have been in such high demand by the business. Ad ditionally, it would allow our users to begin realizing the benefi ts of SharePoint 2010 now, while pursuing a more le isurely migration from SharePoint 2007. Launching SharePoint 2010 in the cloud quickly rose to the top of our project list after considering the preceding benefits.

Our Deployment Success Criteria An enterprise cloud deployment requires a significa nt investment of engineering time and resources. Ha ving clearly defined success criteria ensures continued momentum when challenges arise. During our system assessment phase, we identified four main criteria as keys to success an d summarized why SharePoint 2010 met these success criteria. This gave us the justification to proceed with our cloud deployment plan. 1. Strong executive commitment. Top management must support the application as a v iable candidate for migrating to the cloud. After reviewing our case, o ur senior executives were heavily in favor of investing in a SharePoint cloud deployment. Our organization had s enior executives who were passionate about the scalability of a cloud IT infrastructure and made our cloud mig ration program one of our organization’s top priorities.

Strong executive commitment ensured that our engine ers stayed the course in the face of challenges. We knew that without such support, the deployment would hav e been much more difficult to accomplish.

2. Motivated Engineers. The engineers who owned the application had to be excited about the promise of the cloud, and had to be willing to tackle challenging problems head on. Our SharePoint engineers were exc ited about the opportunity to blaze a trail for other te ams while working with new technology. The engineer s wanted to stop managing hardware infrastructure processes in general and start creating and customizing nimble enterprise applications geared toward our employees ’ needs. The team knew that the knowledge we gained deploying these applications in the cloud would hel p us to discover and resolve perceived obstacles for future cloud deployments. 3. High cloud readiness and low migration effort. The application had to lend itself to a cloud depl oyment, as was the case with both SharePoint 2010 and SQL Server 2 008. The number of Working Front End (WFE) and Web Application servers was easily scaled horizontally as needed in a SharePoint farm, and application ser vices could also be scaled independently of each other. We felt that these scalability characteristics were a great fit for the flexibility and scalability of EC2 and EBS resource s. Furthermore, SharePoint 2010 provided applicatio n-level data persistence and availability solutions that wo uld protect us in the unlikely event of an EC2 or EBS failure. As we opted to implement a stand-alone instance of Sha rePoint 2010, site migration could occur at a later date using one of the many third-party tools recommended by Microsoft.

4. Strong vendor partnership on cloud licensing and su pport. The vendor has to allow customers to leverage thei r application licenses on the AWS cloud. By leveragi ng Microsoft’s License Mobility 8 through Software Assurance, we could deploy SharePoint 2010 and SQL Server 2008 Enterprise Edition with active Software Assurance in the cloud under our existing Microsoft Volume Licensing agreement. We are therefore able to license and operate our SharePoint and SQL Server environments on AWS t he same as we do for an on-premise environment. 8 See http://aws.amazon.com/windows/mslicensemobility . Amazon’s Corporate IT Deploys SharePoint 2010 to the Amazon Web Services Cloud Sep 2011 Page 5 of 13 How We Launched Deployment Support The deployment plan brought a number of enterprise and cloud technologies together for the first time in corporate IT.

We opted to purchase AWS Premium Support so that we could maximize pre-implementation support advice (solution architects) and receive post-implementation assista nce (support engineers). AWS solution architects helped us solve key challenges and share best practices from the field. AWS Premium Support was engaged as needed to help resolve issues and keep us on track. Having access to AWS Premium Support was critical to the project’s success. Initial Requirements Analysis Working with AWS solution architects, we studied the application dependencies and requirements. We sel ected the following EC2 types for our SharePoint server roles :

SharePoint Role EC2 Type Working Front End (WFE) Servers (x2) High Memory Quad Extra Large (m2.4xl) Web Application Servers (x2) High Memory Quad Extra Large (m2.4xl) SQL Server Database (Content, Witness) High Memory Quad Extra Large (m2.4xl) We used Microsoft’s SharePoint architecture design recommendations 9 because they were the simplest and were recommended for most large companies. The configura tion works well for hosting a large number of sites for a single company on the same farm. This design would enable us to optimize the EC2 resources required to run services within a farm with all services available to all web applica tion servers. All sites would have access to all of the service applications that are deployed in the farm. We would measure the performance of the farm, determine which services were overused, and consider whether to scale these on in dependent web application servers as needed. Security Review All applications underwent a risk assessment by our corporate information security team. The security team set a high security bar for SharePoint because they determined that the employees would store highly sensitive company data. Because the SharePoint data was so sensitive, the r equirements from our security review included the f ollowing:

SharePoint must be deployed in a Virtual Private Cl oud (VPC) 10 to restrict access to only our corporate network.

All SharePoint data must be encrypted, both at rest and in flight.

All SharePoint traffic in the VPC must be encrypted , in addition to traffic coming in and out of the VPC.

SharePoint encryption keys must be protected and ca nnot be stored in the same location as the data they are protecting.

These significant requirements are due to the sensi tive nature of the data stored in our SharePoint application, and were taken into consideration as the team revisited the application design. 9 See http://download.microsoft.com/download/2/E/5/2E54AB 34-2AB4-4779-9C61- 1370381FEF67/SvsSingleFarm_SharePointProducts2010.pdf . 10 See http://aws.amazon.com/vpc . Amazon’s Corporate IT Deploys SharePoint 2010 to the Amazon Web Services Cloud Sep 2011 Page 6 of 13 Application Security Design We implemented the following design elements to accommodate both application and security requirements .

Data Encryption at Rest While a number of encryption solutions were considered, BitLocker 11 met the security requirements as a block-level encryption solution that was included with Windows at no additional cost. We used Windows Server 2008 BitLocker to encrypt all SharePoint application logs and indexes to protect confidential data on EBS volumes. The o perating system volume did not need to be encrypted because tempora ry files that were normally stored on the operating system volume were instead stored on a separate encrypted EBS data volume.

Transparent Data Encryption (TDE) in SQL Server 200 8 Enterprise was the optimal choice for bulk database encryption and it met data security standards. Because TDE act s at the application level and possesses knowledge of database file formats, it performs more optimally than BitLocker. Therefore, we decided to use TDE to encrypt ShareP oint databases in SQL Server 2008 databases that contained confide ntial information.

The following is an overview of transparent data en cryption:

TDE encrypts databases, log files, and any informat ion written to TempDB, snapshots, backups, and mirr ored DB instances, if applicable.

TDE operates at the input/output level through the buffer pool, so any data written into the database file (*.mdf) is encrypted.

TDE can be selectively enabled on specific database s.

Backups cannot be restored to other servers without a copy of the private key, so stolen MDF files do not disclose any confidential data.

Easier administration, minimal server resources req uired (3 to 5 percent performance overhead). Data Encryption in Flight We implemented several methods for securing communi cation with EC2 hosts in our VPC. The following describes our security design for data in flight at the network a nd application level.

All Windows hosts were configured to request IPsec connections via Group Policy Object (GPO).

All SharePoint services running in the VPC require clients to connect over HTTPS (SSL).

All SQL Server deployments to the VPC force all cli ent connections to use SSL.

Remote Desktop Protocol (RDP) connections enforce 1 28-bit SSL encryption.

11 See http://technet.microsoft.com/en-us/library/cc731549 (WS.10).aspx . Amazon’s Corporate IT Deploys SharePoint 2010 to the Amazon Web Services Cloud Sep 2011 Page 7 of 13 Windows DPAPI Encryption Key Management One of our biggest challenges was to solve the problem of how we can securely manage our BitLocker key s. BitLocker keys needed to be managed such that Windows can aut o-unlock EBS volumes on reboot. However, we did not have a Windows-based key management service that could be used to automate this process. As an alternative to implementing a custom Windows key-store service, we chose to use the Windows Data Protection API (DPAPI) 12.

DPAPI is a core service of Windows and is used by m any parts of the operating system: Internet Explorer (7, 8, and 9), Encrypting File System (EFS), Outlook (S/MIME), Int ernet Information Services Secure Socket Layer/Tran sport Layer Security (SSL/TLS), Rights Management Services (RMS ), 802.1x (EAP/TLS), CredMan, and almost all .NET apps requiring some form of protected storage. DPAPI uses the host machine account password, which is randomly genera ted when the machine account is created, to generate a key t hat protects the BitLocker encryption keys. The com puter account password is never stored in clear text. An irrevers ible hash (known as a “password verifier”) is store d in Credential Manager and is accessible only via Local Security A uthority Subsystem (LSASS). The BitLocker keys are encrypted using DPAPI (configured to use AES 128-bit encryption) an d stored in the host registry with access control lists (ACLs) applied to the hive node. This can be done using a script in conjunction with a service and a key-store file protected by the server’s machine account DPAPI key. The following summarizes the pro cess: 1. When a data volume is encrypted with BitLocker, the script retrieves the volume’s encryption key and passes it to the service (which is running as LocalService).

2. The service manages the key-store file and keeps it s contents encrypted using DPAPI. (This is very similar to how BitLocker protects data volume keys when a Trusted Platform Module (TPM) is present; however, in this case, the master key is the DPAPI key rather than the BitLock er key.) 3. When a server boots, the script calls the service t o retrieve the encryption key for each volume and p asses that key to BitLocker’s command-line utility to mount the en crypted volume.

4. Because the key-store file is encrypted with the co mputer’s DPAPI key, the file cannot be used on any machine other than the one that initially created and encrypted i t.

Proof of Concept The proof of concept was an integral step in demons trating the applicability of the AWS platform, our Windows infrastructure, our first SharePoint 2010 design an d deployment, and our security requirements. We wer e able to prototype each element independently, and tear down the environment after each proof while spending very little money.

Windows Infrastructure Implementing Windows infrastructure included the fo llowing: 1. Connecting a VPC located in the AWS US East region to our corporate network in a nearby on-premise Eas t Coast data center.

2. Submitting an EC2 limit increase request to change the maximum on-demand instances limit per AWS Accou nt 13 to the maximum number needed for our organization.

3. Provisioning Windows Server instances on Amazon EC2 and attaching Amazon EBS Volumes using the AWS Management Console. 12 See http://msdn.microsoft.com/en-us/library/ms995355.as px . 13 Form to increase to your Amazon EC2 instance limit: http://aws.amazon.com/contact-us/ec2-request . Amazon’s Corporate IT Deploys SharePoint 2010 to the Amazon Web Services Cloud Sep 2011 Page 8 of 13 4. Bundling corporate IT standard patches, updates, an d settings on the Windows Server 2008 64-bit Data C enter Edition Amazon Machine Image (AMI) with patches, up dates, and settings for internal use.

5. Configuring a test domain that is separate from the corporate domain using two cloud-based test domain controllers.

6. Launching Windows Server 2008 EC2 hosts using the c ustom AMI and joining the hosts to the test domain. Security Implementing the security design included the following: 1. Testing Windows BitLocker configuration on EBS volu mes.

2. Writing and testing a script to retrieve the encryp tion key during boot-up that passes the keys to aut omatically unlock any BitLocker-encrypted volume on reboot usi ng DPAPI.

3. Enabling SQL Server 2008 Enterprise and enabling TD E on databases.

4. Issuing SSL certificates and applying the certifica tes to Internet Information Services (IIS).

5. Enabling IPsec for all traffic between Windows host s. SQL Server Deployment Implementing the SQL Server deployment included the following: 1. Deploying mirrored primary and secondary servers ru nning SQL Server.

2. Configuring SharePoint databases.

3. Testing SQL Server failover. SharePoint Deployment Implementing the SharePoint deployment included the following: 1. Installing SharePoint using the default configurati on wizard.

2. Learning how to configure SharePoint 2010 to corpor ate IT specification.

3. Executing a SharePoint functionality test plan.

4. Executing a SharePoint WFE and application server f ailover test plan. Production Deployment The knowledge gained in the proof of concept enable d us to develop a solid deployment plan, which we executed as follows.

EC2 Capacity As we moved into production, we were in a position to pay for reserved EC2 instances 14. This ensured that we got more favorable reserved pricing for “always on” SharePoi nt capacity. This pricing option for EC2 enabled us to make a low one-time payment to further reduce hourly usage cha rges. Reserved Instances complement our existing EC2 on-demand instances to reduce our EC2 costs. 14 To learn more about Reserved Instances, go to http://aws.amazon.com/ec2/reserved-instances . Amazon’s Corporate IT Deploys SharePoint 2010 to the Amazon Web Services Cloud Sep 2011 Page 9 of 13 Windows Infrastructure First, we extended the corporate active directory and domain to the VPC. This enabled us to leverage o ur existing Windows identity and access model into AWS.

Windows IPsec A GPO was created to enable IPsec between Windows h osts in the VPC. Windows Encryption and Key Management Windows BitLocker was used to encrypt all SharePoint volumes containing potentially confidential data. SQL Server TDE was used to encrypt the SharePoint databases. As an alternative to implementing a custom Windows key-s tore service, we used DPAPI, custom scripts, and a service to man age the BitLocker keys that encrypted log, index, and temporary file volumes. SharePoint Availability We chose to implement high availability using Share Point instances on-premise in a nearby corporate IT data center.

This ensured that our deployment had a failover sol ution off the cloud for each of our SharePoint Working Front End servers, Web Application servers, and SQL Server in stances. A primary and secondary SQL Server pair we re installed with database mirroring. The primary server was installe d in the VPC, with the secondary deployed to a near by on-premise East Coast data center. A separate witness server w as deployed to the VPC running SQL Server Express t o monitor the databases and handle failovers.

SharePoint Data Redundancy SharePoint WFE and application servers run stateles s services that do not require any data persistence. Should any of the corresponding EC2 hosts become corrupted or los t, they would simply be replaced by a freshly configured SharePoint EC2 host and EBS volume. The only data t hat must be persisted is stored in SQL Server databases and these databases are automatically mirrored to a secondary on-premise server to ensure that data is persisted off the cloud on every transaction.

SharePoint Backups and Recovery The only backups that need to take place are at the database level. We backup the database every eight hours to mitigate major disasters that might cause the loss of significant amounts of data. Should a disaster occur, a full database restore would be implemented to recover the farm to the last database snapshot. SharePoint and SQL Server Monitoring Our SharePoint and SQL Server cloud and on-premise deployments both used Microsoft System Center Opera tions Manager (SCOM) as the monitoring solution. SharePoi nt and SQL Server management packs were installed to help detect and respond to critical events generated by these specific applications.

Amazon’s Corporate IT Deploys SharePoint 2010 to the Amazon Web Services Cloud Sep 2011 Page 10 of 13 Architecture Diagram The following diagram outlines how we deployed our SharePoint 2010 architecture across both our corporate AWS VPC and a nearby on-premise east coast data center. Wh en we designed this solution, AWS VPC was available only in a single Availability Zone in the AWS Region where we were deploying (AWS has since made VPC available i n multiple AZ's per Region 15). Deploying each SharePoint component across an AW S Availability Zone in our VPC and our own east coast data center ensured high availability across two da ta centers. On-premise load balancers direct traffic appropriately across the four SharePoint front-end servers that a re connected to four application servers to balance the processing of the application services load. The primary SQL Ser ver database handles all data, with SQL Server mirr oring set up to handle data redundancy to a secondary on-premise se rver. Figure 1. SharePoint 2010 Enterprise Component Brea kdown 15 http://aws.amazon.com/about-aws/whats-new/2011/08/0 3/Announcing-VPC-GA . Amazon’s Corporate IT Deploys SharePoint 2010 to the Amazon Web Services Cloud Sep 2011 Page 11 of 13 Lessons We Learned As with any major enterprise migration, we encountered a few challenges during the deployment. We will apply the knowledge gained from these lessons to drive future cloud migration projects and share them with other teams.

Licensing Many vendor licensing agreements are not yet writte n anticipating the use of a cloud-based infrastructure. This will change, but in the meantime, be sure to engage your vendor early in the project, as we did with our Microsoft account representatives, to understand how their licensing and support agreements can be applied to AWS. We le arned that it is important to educate the vendor about the cloud arc hitectural patterns and to help them to develop new licensing models to support the cloud if their existing licen sing models don’t apply. By investing in this proce ss early, all parties were able to agree on the conditions that would all ow corporate IT to launch both SharePoint Server 20 10 and SQL Server 2008 Enterprise Edition for production use i n our VPC. Forecast VPC Resources The goal for our corporate IT was to use a single AWS account for all EC2 capacity in our VPC. As a large enterprise customer, we went through a forecasting process wit h AWS to fulfill our VPC capacity requirements. This process began with a request to increase the EC2 limit for our AW S account 16. We then worked with AWS sales and solution archit ects to determine how many reserved versus on-demand ins tances we would need over three years. Use Standard Scalability and High Availability Prac tices Corporate IT best practices state that we should deploy applications to at least two data centers for high availability.

Therefore, we deployed SharePoint and SQL Server in the VPC and in an on-premise nearby data center. We also leveraged our existing on-premise load balancers to direct traffic across SharePoint web front-end instances on-premise and in the VPC. In the future, we want to expand ou r cloud footprint to a second VPC Availability Zone and use Amazon Elastic Load Balancing to direct traffic. This allo ws us to consider the option of decommissioning on- premise servers and load balancers.

Plan an Access Control Strategy for Cloud Resources With the power and flexibility of having on-demand hosts, comes the power of terminating hosts just as easily. We needed to think through the processes and controls needed to protect these resources from accidental d eletion or misidentification. Our approach relied on the use o f AWS Identity and Access Management (IAM) 17 policies and tagging for resource identification. We assigned AWS user p olicies to engineers across teams where limiting access to various AWS APIs helped us to avoid accidental deletions. D efining a tagging convention also helped us to easily identify EC2 and Amazon EBS resources. We gave feedback to the AWS t eam about how resource-level controls could simplify and improve our IAM strategy. 16 Form to increase to your AWS EC2 instance limit: http://aws.amazon.com/contact-us/ec2-request . 17 See http://aws.amazon.com/documentation/iam . Amazon’s Corporate IT Deploys SharePoint 2010 to the Amazon Web Services Cloud Sep 2011 Page 12 of 13 Security Is a Shared Responsibility Our Corporate Information Security team held AWS to the same standards as any external vendor. We learned that security is a shared responsibility. Although AWS o ffers a variety of different security features like Security Groups that help us protect instances, data volumes, and networ k traffic, it is our responsibility to protect the corporate data that is stored and running in the cloud. Because of the sen sitive nature of SharePoint data, Corporate Information Security required us to encrypt all data at rest and in flig ht. From these requirements, the team learned about the architectural challenges and operational overhead that comes with supporting a robust data encryption and key management solution. We overcame these challenges by investing the time and resources needed to incorporate these critical security components into our cloud deployment. Thes e are now core framework components that we will us e in other similar Windows cloud deployment projects. Start Conservatively and Scale Over Time Through early experimentation, we discovered that W indows EBS volume performance varies over time. As an application, SharePoint has very specific storage p erformance requirements, which equate to about 0.75 IOPS/GB stored. Based on our limited experience with ShareP oint 2010 requirements and the impact that storage performance variability will have on the SharePoint farm, we de cided to start conservatively by initially launching only 100 production team sites. Over time, we will monitor performance of these initial SharePoint sites and architect the best cloud-based deployment model, which will likely require us to s cale our cloud resources horizontally. Given the relatively high input/output requirements for SharePoint storage on SQL Server, we have requested that AWS consider pr oviding more consistent, high-performance storage offerings that require less direct managing and mapping of Window s EBS volumes.

What Benefits Emerged The deployment of SharePoint 2010 self-service portals and a back-end SQL Server 2008 Enterprise database farm to the AWS cloud was completed quickly and efficiently. Th e deployment enabled us to deliver the SharePoint 2010 Enterprise application’s overall business value to our employe es.

Specific benefits include the following:

Infrastructure procurement time was reduced from ov er four to six weeks to minutes.

Server image build process that had previously take n a half day is now automated.

Annual infrastructure costs were cut by 22 percent when on-premise hardware was replaced with equivale nt cloud resources.

Operational overhead of server lease returns were e liminated, freeing up approximately 2 weeks of engineering overhead per year by replacing servers with equival ent cloud resources.

Amazon’s Corporate IT Deploys SharePoint 2010 to the Amazon Web Services Cloud Sep 2011 Page 13 of 13 Where We Go From Here With SharePoint now running on AWS in a VPC and key lessons learned in the process, we are sharing our story with internal peers and external customers. We solved a number of key availability, performance, scalability, and security concerns that can be leveraged within the company a nd to drive other internal teams to adopt AWS as their cloud provider. This will build visibility and separate t he truths from myths that are prevalent among many enterprise IT organizations. We are now in a position to make more cloud optimiz ations. We plan to optimize for the cloud by exploring ways we can further reduce operational overhead by automating S harePoint and SQL Server deployments. We are explor ing how to expand our cloud footprint into other geographies t o meet stakeholder demand for a SharePoint presence in Europe and Asia. In the end, our goal is to decommission a ll on-premise SharePoint hardware in favor of a fully redundant and highly available presence on the AWS cloud.