Beruflich Dokumente
Kultur Dokumente
February 2012
(Please
consult
http://aws.amazon.com/whitepapers
for
the
latest
version
of
this
paper.)
Page 1 of 36
February 2012
Abstract
Amazon
Web
Services
(AWS)
provides
a
complete
set
of
services
and
tools
for
deploying
Windows
workloads,
including
Microsoft
SharePoint
Server,
on
its
highly
reliable
and
secure
cloud
infrastructure
platform.
This
white
paper
discusses
general
concepts
regarding
how
to
use
these
services
and
provides
detailed
technical
guidance
on
how
to
configure,
deploy,
and
run
a
SharePoint
Server
farm
on
AWS.
It
illustrates
reference
architecture
for
common
SharePoint
Server
deployment
scenarios
and
discusses
their
network,
security,
and
deployment
configurations
so
you
can
run
SharePoint
Server
workloads
in
the
cloud
with
confidence.
This
white
paper
is
targeted
to
IT
infrastructure
decision-makers
and
administrators.
After
reading
it,
you
should
have
a
good
idea
of
how
to
set
up
and
deploy
the
components
of
a
typical
SharePoint
Server
farm
on
AWS.
You
learn
which
artifacts
to
use
and
how
to
configure
the
various
infrastructure
details,
such
as
compute
instances,
storage,
security,
and
networking.
Page 2 of 36
February 2012
Introduction
Enterprises
need
to
grow
and
manage
their
global
computing
infrastructures
rapidly
and
efficiently
while
simultaneously
optimizing
and
managing
capital
costs
and
expenses.
AWSs
computing
and
storage
services
meet
this
need
by
providing
a
global
computing
infrastructure.
The
AWS
infrastructure
enables
companies
to
rapidly
spin
up
compute
capacity
or
quickly
and
flexibly
extend
their
existing
on-premise
infrastructure
into
the
cloud.
AWS
provides
a
rich
set
of
services
and
robust,
enterprise-grade
mechanisms
for
security,
networking,
computation,
and
storage.
SharePoint
Server
is
a
widely
deployed
application
platform,
common
in
many
organizations
as
the
main
portal
for
teamcorporate
collaboration,
content
management,
workflow,
and
access
to
corporate
applications.
One
key
benefit
of
SharePoint
Server
is
that
it
enables
organizations
to
rapidly
respond
to
changing
business
needs.
AWS
is
a
perfect
complement
to
SharePoint
Server,
because
it
enables
organizations
to
rapidly
provision
the
necessary
computing
infrastructure
to
power
SharePoint
Server
solutions.
AWS
and
Microsoft
have
partnered
to
enable
customers
to
deploy
enterprise-class
workloads
involving
Windows
Server
and
Microsoft
SQL
Server
on
a
pay-as-you-go,
on-demand
elastic
infrastructure,
thereby
eliminating
the
capital
cost
for
server
hardware
and
greatly
reducing
the
provisioning
time
required
to
create
or
extend
a
SharePoint
Server
farm.
This
partnership
has
resulted
in
the
ability
to
license
and
run
SharePoint
Server
on
AWS
under
provisions
in
Microsofts
License
Mobility
through
Software
Assurance
program.
As
a
relevant
data
point
and
case
study,
the
Amazon
Corporate
IT
team
hosts
Amazons
own
corporate
intranet
running
SharePoint
Server
on
AWS.
They
have
published
a
white
paper
detailing
its
evaluation,
security
requirements,
architecture,
benefits,
and
lessons
learned
from
the
deployment.
Note
that
at
the
time
the
Amazon
Corporate
IT
team
deployed
their
SharePoint
Server
environment
and
wrote
the
white
paper,
a
number
of
the
AWS
services
discussed
herein
were
either
not
in
place
or
limited
in
their
availability.
This
current
paper
provides
an
up-to-date
and
more
high- level
description
of
how
to
support
SharePoint
Server
on
AWS.
Page 3 of 36
February 2012
Source:
http://technet.microsoft.com/en-us/library/ff758647.aspx
Figure
1:
The
SharePoint
Server
reference
architecture
Additional infrastructure components are required or recommended to support SharePoint Server farms: Active Directory Domain Services (AD DS). SharePoint Server requires AD DS to serve as the authoritative identity store and authentication mechanism. AD DS (with one or more domain controllers) must reside within the same network as the SharePoint Server farm and be accessible to SharePoint Server farm instances.
Page 4 of 36
February 2012
Threat management and intrusion protection. This component may be an additional element for SharePoint Server scenarios that include external or public-facing sites. In a Windows-based infrastructure, this component would typically be provided by products such as Microsoft Forefront Threat Management Gateway 2010.
Figure
2:
Typical
intranet
SharePoint
Server
farm
topology
Page 5 of 36
February 2012
Figure
3:
Typical
SharePoint
Server
farm
topology
for
an
Internet-facing
public
website
Key elements that distinguish this scenario from the previous intranet scenario are: A demilitarized zone (DMZ) to provide firewall and threat management at the front-line access points Active Directory domain controllers resident within the farm (not associated with the user environment)
Page 6 of 36
February 2012
Network
Setup
Lets
start
with
the
network
setup
to
provide
the
environment
in
which
you
instantiate
and
configure
your
servers
and
database.
The
Microsoft
reference
architecture
is
organized
around
a
multi-tiered
(web,
application,
and
database)
approach,
allowing
you
to
independently
scale
and
configure
each
tier.
Your
first
task
is
to
define
a
network
environment
that
supports
this
type
of
tiered
structure
and
enables
you
to
deploy
the
various
server
roles
in
each
tier
with
suitable
security
configuration.
Page 7 of 36
February 2012
designate them as private, and they will not be accessible from outside the VPC. In the case of a VPN-connected VPC, connections through the VPN occur through the virtual private gateway; therefore, instances can be in private subnets but still reachable (as long as the security configuration allows it). Thus, VPN-only scenarios do not require public subnets (e.g., for web server front ends). However, the public-facing SharePoint Server scenario does need to be accessible from outside of AWS, so each front-end instance must be in a public subnet to be reached via the Internet gateway. Fault tolerance and scalability for our SharePoint Server farm scenarios is critical to ensure they can provide sufficient performance through changes in load, and be resilient to any unforeseen issues within the farm infrastructure. The Elastic Load Balancing (ELB) web service can be used to be used to distribute internet-based requests to internal web servers, and so this is a suitable choice for our internet website scenario. However, since ELB at this point only handles traffic coming from outside the VPC, we cant use that for our intranet scenario (in which user requests come in via the private VPN connection). For the intranet scenario, we need to utilize a 3rd party software load balancer (such as the Riverbed Stingray Traffic Manager or HAProxy) to achieve similar functionality. You also want to distribute multiple instances to each Availability Zone to provide redundancy and failover in the case of an Availability Zone failure. VPC subnets do not span Availability Zones, so you must set up a separate but similar subnet structure within each zone. Likewise, set up load balancing to distribute requests to servers in multiple Availability Zones. Therefore, you should set up load balancers in each Availability Zone used to provide high availability there, as well. NOTE: The IP address ranges for the VPC and subnets are defined using a single Classless Inter-domain Routing (CIDR) IP address block, such as 10.0.0.0/16, providing an internal IP address space of 65,536 unique IP addresses. Subnets can then be created with their own unique CIDR block ranges within the overall VPC address range.
Page 8 of 36
February 2012
Private subnets in each Availability Zone to hold your load balancers. A VPC can have multiple subnets in which each subnet resides in a separate Availability Zone. Each subnet must reside entirely within one Availability Zone. Software Load Balancers in each Availability Zone. This setup establishes primary and secondary load balancers within each of the Availability Zones, where the primary distributes traffic to any of the healthy instances in either of the Availability Zones. In the event of a failure of the primary load balancer (or the Availability Zone overall), the secondary load balancer takes over and continues to distribute traffic to remaining healthy instances. Private subnets in each Availability Zone to hold web, application, and database servers as well as AD DS domain controllers. These subnets are not directly accessed by users (everything goes through the load balancers) and hence do not need to be accessible outside of the VPC. One virtual private gateway and one customer gateway. These provide VPN connectivity between the corporate data center and the VPC.
Putting together everything discussed thus far, Figure 4 shows the network configuration defined for the intranet scenario.
Figure
4:
Network
configuration
for
the
intranet
scenario
Page 9 of 36
February 2012
Given these differences, Figure 5 shows the network setup for the public website scenario.
Page 10 of 36
February 2012
Figure
5:
Network
configuration
for
the
Internet-facing
public
website
scenario
Amazon recommends the second option for better performance and reliability. The domain controllers can be replicated across Availability Zones (as with your other resources) to provide high availability. Microsoft provides guidance on Active Directory Replication Over Firewalls.
Page 11 of 36
February 2012
NOTE: It is also possible to support this scenario for corporate environments that do not use AD AD but rather another Lightweight Directory Access Protocol (LDAP)based directory service. You can use Active Directory Federation Services (AD FS) with SharePoint Server and other (non-AD DS) authentication providers to facilitate federated authentication. AWS provides a detailed white paper on how to set up and configure AD FS in AWS to support federated authentication. Figure 6 depicts the additions to the hosting infrastructure and AD DS replication details.
Figure
6:
Additions
to
the
hosting
infrastructure
and
AD
DS
replication
details
for
the
intranet
scenario
In your public-facing scenario, the SharePoint Server farm is not connected to a corporate infrastructure via VPN. Instead, it requires AD DS to be instantiated within the AWS environment to facilitate user registration and authentication for the SharePoint Server instances running there. As in the intranet scenario, Amazon suggests hosting domain controllers in multiple Availability Zones to provide redundancy and high availability, as illustrated in Figure 7.
Page 12 of 36
February 2012
Figure
7:
Hosting
domain
controllers
in
multiple
Availability
Zones
to
provide
redundancy
and
high
availability
AD DS is typically run in on-premise, static environments, and there are certain typical configuration details and assumptions that are different when AD DS runs in AWS. For AD DS domain controllers to be used for DNS in AWS and across Availability Zones, each needs to be in a security group that opens User Datagram Protocol (UDP) ports 065,535. (Security groups are discussed in detail in a later section.)
Page 13 of 36
February 2012
SharePoint Server is not preinstalled in any of the Windows-based AMIs because of licensing model restrictions. The only supported approach to licensing SharePoint Server on AWS is through Microsofts License Mobility through Software Assurance program. Customers covered by active Microsoft Software Assurance contracts may move current on-premise Windows Server application workloads (such as SharePoint Server) to AWS without additional Microsoft software license fees. AWS provides a comprehensive collection of information, tools, and resources for running Windows-based applications and workloads on AWS. Also, there is detailed information about how Windows is supported and used on Amazon EC2. Finally, you can find details on the specific AMIs that include Windows, SQL Server, etc., within the Amazon EC2 AMI catalog.
Mapping
SharePoint
Server
Roles
and
Servers
to
Amazon
EC2
AMIs
and
Instance
Types
A
key
aspect
of
implementing
your
AWS
solution
is
choosing
the
appropriate
AMI
and
instance
type
for
each
role
within
the
farm.
Each
role
in
the
SharePoint
Server
reference
architecture
has
distinct
requirements
for
software
and
infrastructure
resources,
such
as
CPU,
RAM,
and
disk
storage.
Microsoft
and
AWS
have
partnered
to
publish
a
number
of
Windows-based
AMIs
that
include
additional
software
components
for
supporting
typical
roles
(e.g.
IIS
for
web
server,
SQL
Server
for
database
server,
Windows
core
for
domain
controller)
that
run
on
a
variety
of
Amazon
EC2
instance
types.
In
terms
of
machine
capacity
and
sizing,
Microsoft
provides
detailed
guidance
for
various
components
within
a
SharePoint
Server
farm,
so
that
topic
is
not
be
covered
in
this
paper.
However,
the
basic
details
of
typical
system
requirement
minimums
for
various
components
within
a
SharePoint
Server
farm
are
summarized
in
the
tables
that
follow.
Table
1
presents
the
minimum
system
requirements
Microsoft
recommends
for
the
different
tiers
and
roles
within
a
SharePoint
Server
farm.
Table
1:
Minimum
system
requirements
for
SharePoint
Server
roles
and
tiers
RAM 8 GB 8 GB 16 GB 8 GB
Hard disk 80 GB 80 GB 80 GB 80 GB
Table 2 shows how to map these requirements to Amazon EC2 AMIs and Windows instance types.
Page 14 of 36
February 2012
Table 2: Mapping minimum system requirements to AMIs and Windows instance types
Tier Web front end Application server Database server Domain controller
Applicable Amazon EC2 instance type and range Extra Large (m1.xl) Extra Large: High Memory Quad Extra Large (m2.xlm2.4xl) High Memory Quadruple Extra Large (m2.4xl) Extra Large (m1.xl)
AMI to use Windows Server 2008 R2 + IIS Windows Server 2008 R2 Optimized SQL Server 2008 R2 AMIs from Microsoft Windows Server (in the role of a domain controller)
The AMIs listed in Table 2 include the default configuration for Amazon EBS volumes (formatted as Windows file systems) for boot drive and associated data storage applicable to the role. The SQL Server 2008 R2 AMIs indicated have been configured with multiple EBS volumes to support distinct SQL Server storage components (data, logs, temp files), optimizing for storage requirements and I/O patterns of each component. Amazon EC2 also supports the ability to customize an instance, allowing you to attach additional Amazon EBS volumes or resize an existing Amazon EBS volume by taking a snapshot, and then creating a new, larger volume from the snapshot. You can then use this customized instance as the basis for a new, customized AMI.
Page 15 of 36
February 2012
For high-I/O scenarios, it is possible to create and attach additional Amazon EBS volumes and to stripe using software RAID to increase the total number of I/O operations per second (IOPS). Each Amazon EBS volume is protected from physical drive failure through drive mirroring, so using a RAID level higher than RAID-0 is unnecessary. For SharePoint Server instances, it is common to use Remote BLOB Storage (RBS) in conjunction with SQL Server for storage of file-based content. This file-based content will reside in SQL Server instances, and the existing Amazon EBS configuration should be sufficient for most uses. However, it may be desirable or necessary to extend the size or add more Amazon EBS disks (or other associated storage) for supporting large RBS stores. For further details regarding Amazon EBS setup, configurations, and tuning options, see the Amazon Elastic Compute Cloud User Guide. High Availability for SQL Server You can achieve high availability for SQL Server in AWS by implementing SQL Server mirroring across multiple Availability Zones. In this configuration, SQL Server instances are launched in two different Availability Zones (within a Region), with a smaller witness SQL Server instance to monitor and facilitate the failover, if needed. Figure 8 illustrates this configuration.
Page 16 of 36
February 2012
Figure
8:
SQL
Server
mirroring
across
multiple
Availability
Zones
AWS recently published RDBMS in the Cloud: Microsoft SQL Server 2008 R2, a comprehensive resource that provides a detailed discussion of considerations, approaches, and options for optimizing the use of SQL Server in AWS. With the addition of your Amazon EC2 instances and SQL Server mirroring, your intranet scenario looks like Figure 9.
Page 17 of 36
February 2012
Figure
9:
Intranet
scenario
with
the
addition
of
Amazon
EC2
instances
and
SQL
Server
mirroring
With the addition of your Amazon EC2 instances and SQL Server mirroring, your public site scenario looks like Figure 10.
Page 18 of 36
February 2012
Figure
10:
Public
site
scenario
with
the
addition
of
Amazon
EC2
instances
and
SQL
Server
mirroring
Security
Security
setup
is
critical
in
the
implementation
of
your
SharePoint
Server
farm
to
enable
proper
network
access
(in
and
out
of
the
VPC,
specific
subnets,
and
the
instances
running
each
subnet)
to
facilitate
user
authentication
and
appropriate
authorization,
data
privacy,
and
threat
management
(in
the
case
of
public-facing
sites).
These
and
other
key
elements
have
to
be
set
up
correctly
to
provide
the
necessary
security
measures
and
enable
users
to
access
their
SharePoint
Server
content
and
applications
with
the
correct
identity
and
authorization.
A
cornerstone
of
your
scenarios
is
the
use
of
Amazon
VPC
for
providing
the
overall
isolation
of
the
farm
and
segmenting
parts
of
the
farm
(i.e.,
the
server
groups)
to
support
the
desired
management
and
control.
Within
Amazon
VPC
and
subnet
isolation,
there
are
security
details
that
you
must
set
up
to
enable
proper
access
(and
restrictions).
The
two
main
approaches
at
your
disposal
are:
Security
groups.
A
security
group
acts
as
a
firewall
that
controls
the
traffic
allowed
in
and
out
of
a
group
of
instances.
When
you
launch
an
instance
in
a
VPC,
you
can
assign
the
instance
to
up
to
five
VPC
security
groups.
Security
groups
act
at
the
instance
level,
not
the
subnet
level.
o
In general, it is a good idea to define distinct security groups for each tier. Doing so allows you to define the settings for each tier (and vary them independently) as well as restrict access to the calling tier (e.g., allowing the database tier to be called only from the application tier).
Network access control lists (ACLs). A network ACL is an optional layer of security that acts as a firewall for controlling traffic in and out of a subnet. You might set up ACLs with rules similar to your security groups to add a layer of security to your VPC. Network ACLs act at the subnet level, not the instance level.
Page 19 of 36
February 2012
Security
Groups
Here
are
the
two
approaches
discussed
in
greater
detail:
Elastic
Load
Balancing:
o
Elastic Load Balancing is the point of contact for users, so the Elastic Load Balancing security group should be configured to support inbound client connection types of HTTP or HTTPS (port 80 and port 443, respectively). You can configure the Elastic Load Balancing in any combination, but Amazon recommends using HTTPS for both inbound client connection types. You should create an outbound security rule that lists the web tier security group as the target, restricting the load balancer to sending requests out to the web tier instances only.
Web
tier:
o
In the scenario, the web tier instances are not directly exposed but receive requests via the elastic load balancer. You can (and should) configure the web instances to accept requests only from the load balancer. Fortunately, the load balancer includes a special source security group. Create a security rule for your web tier that restricts inbound access to this special security group, ensuring that only the load balancers are allowed to send to and receive from the web front-end instances. You can also set up an outbound rule to limit outgoing requests to the application tier instances.
Application
tier:
o
As in the web tier case, your application tier security group should be configured with an inbound rule listing the web tier security group as an allowed sender and an outbound rule listing the database security group for outgoing messages.
Database
tier:
o
As in the other cases, you should require Secure Sockets Layer (SSL) for connections to and from SQL Server. Doing so requires the use of a security group with a rule that allows SSL (port 443) to be used only for the database instances. You also want to restrict inbound access to the application tier instances, so create a security rule that restricts inbound access to the application tier security group.
The Appendix includes a chart detailing the various recommended security groups and settings for your SharePoint Server farm scenarios.
Network
ACLs
Network
ACLs
mirror
the
rules
specified
in
security
groups
and
add
an
extra
layer
of
security
to
allow
general
access
rules
to
be
honored
regardless
of
which
instances
are
sending
or
receiving.
Because
network
ACLs
act
at
the
network
level
(not
the
instance
level),
you
can
set
up
additional
rules
to
handle
certain
networks,
IP
addresses,
and
address
ranges
in
a
specific
way.
For
instance,
you
can
set
up
a
network
ACL
that
defines
a
rule
to
deny
ingress
to
a
range
of
source
IP
addresses
(blacklisted
IP
addresses).
For
detailed
guidance
on
setting
up
Amazon
VPC
network
ACLs,
see
the
Amazon
Virtual
Private
Cloud
User
Guide.
Page 20 of 36
February 2012
Administrator
Access
In
your
architecture,
the
middle
tier
and
database
tier
instances
are
placed
in
private
subnets,
restricting
access
from
outside
the
VPC.
This
placement
reduces
exposure
and
enhances
security.
However,
it
is
still
necessary
to
provide
access
to
those
instances
for
administrative
purposes,
such
as
configuration
updates
and
troubleshooting.
To
help
manage
the
instances
in
the
private
subnet,
an
indirect
(and
secure)
method
is
to
set
up
one
or
more
bastion
servers
in
a
public
subnet
to
act
as
proxies,
and
then
set
up
SSH
port
forwarders
or
Remote
Desktop
Protocol
(RDP)
gateways
to
proxy
access
to
the
application
or
database
tier
instances.
After
bastion
servers
are
set
up,
administrators
can
use
RDP
to
gain
access
to
the
bastion
host;
they
can
then
access
other
instances
using
SSH
at
their
VPC
private
IP
addresses.
Figure
11
illustrates
this
arrangement.
Figure
11:
Using
RDP
to
gain
access
to
the
bastion
host
Data
Privacy
Because
sensitive
content
and
data
can
be
stored
within
the
SharePoint
Server
farm,
some
organizations
may
require
that
the
content
be
encrypted.
To
successfully
support
encryption
of
data
within
the
AWS
environment,
a
few
key
requirements
must
be
considered
and
supported:
Page 21 of 36
February 2012
Encryption
technology.
The
Amazon
EBS
volumes
contain
the
data
at
rest,
in
the
form
of
SQL
Server
database
data
and
files.
Amazon
EBS
volume
encryption
is
not
supported
in
AWS;
however,
there
are
options
for
encryption
that
can
be
considered:
o
Encrypting File System (EFS). Windows includes EFS, which supports the ability to encrypt individual files or folders. BitLocker Drive Encryption. Windows Server 2008 R2 supports BitLocker, which provides the ability to encrypt a disk file system attached to the server instance. SQL Server Transparent Data Encryption (TDE). SQL Server Enterprise provides native encryption support through TDE. Third-party Amazon EBS volume encryption. Third-party commercial options are available for encryption of Amazon EBS volumes.
Encryption key management. Implementing encryption requires secure management and authorized use of the encryption keys. In the case of Amazon EC2, instances can be stopped and started as well as recovered from Amazon EBS snapshots. In all these cases, the Amazon EBS volumes will be encrypted, and the Amazon EC2 subsystem must access and use the encryption key to be able to attach and use it on subsequent restarts.
The AWS Solution Provider site lists several third-party software vendors that provide security infrastructure that supports Amazon EBS encryption and key management.
Deployment
To
set
up
your
SharePoint
Server
farm
in
AWS,
you
must
establish
and
configure
several
complex
and
interrelated
details
to
enable
proper
functions
and
the
correct
security
settings.
Furthermore,
you
will
inevitably
need
to
change
the
configuration
over
time
to
perform
such
actions
as
adding
instances
for
scale
out
or
updating
instance
configurations.
AWS
provides
a
number
of
tools
and
approaches
for
facilitating
deployment
in
AWS:
AWS
Management
Console.
The
AWS
Management
Console
is
an
interactive
tool
that
is
good
for
starting
out
or
smaller
deployments.
However,
for
more
complex
scenarios
or
automated
deployment
sequences,
consider
one
of
the
other
options
described
below.
AWS
application
programming
interface
(API)
tools.
AWS
provides
several
command-line
interface
(CLI)
commands
and
programmatic
web
service
APIs
that
are
typically
built
into
scripts;
these
commands
allow
a
set
of
actions
to
occur
in
a
coordinated
way.
AWS
sample
code
and
libraries.
AWS
provides
a
Sample
Code
&
Libraries
Catalog
to
support
application-based
setup
and
configuration.
Several
programming
languages
are
supported
through
software
development
kits
(SDKs)
that
AWS
provides.
AWS
CloudFormation.
AWS
provides
an
easy
way
to
create
and
manage
a
collection
of
related
AWS
resources,
provisioning
and
updating
them
in
an
orderly
and
predictable
fashion.
With
AWS
CloudFormation,
you
do
not
need
to
figure
out
the
order
in
which
AWS
services
need
to
be
provisioned
or
the
subtleties
of
how
to
make
those
dependencies
work:
Page 22 of 36
February 2012
You can use a tool called AWS CloudFormer to reverse-engineer an existing set of resources or settings running in an AWS account into an AWS CloudFormation template. So, a typical approach for a complex setup is to manually deploy or configure components of the SharePoint Server farm, and then use this tool to generate an appropriate AWS CloudFormation script. NOTE: AWS CloudFormation does not support the creation of VPCs at this time; however, it does support the creation of the resources within a VPC (e.g., Amazon EC2 instances, security groups).
Windows and .NET Developer Center. These Windows and Microsoft .NET tools include the AWS SDK for .NET and the AWS Toolkit for Visual Studio.
A key approach to automating deployment of components within an AWS solution is to create custom AMIs for distinct roles that have additional software dependencies and configuration requirements. For the SharePoint Server reference architecture, distinct roles are defined (web front end, application server, database server, and others) for which you can create custom AMIs. Custom AMIs for the SharePoint Server farm architecture can be based on public Windows- based AMIs (as indicated earlier) or Windows-based AMIs that you create as a starting point.
Page 23 of 36
February 2012
Recover point objective (RPO). The RPO is the maximum acceptable amount of data loss, expressed in time. For example, an RPO of 1 hour means recovered data may be at most 1 hour out of date from the most recent changes.
In terms of supporting backup and recovery of SharePoint Server farms on AWS, there are essentially two approaches to consider: Use the built-in back-up and recovery mechanisms in SharePoint Server and SQL Server, with Microsoft tools to back up to (and recover from) Windows file-based storage locations. Use AWS backup and recovery mechanisms that operate against AWS resources such as Amazon EBS volumes.
SharePoint Server and SQL Server provide their own built-in capabilities for backing up content, application data, metadata, and configuration settings. In addition, you can use tools such as Microsoft System Center Data Protection Manager (DPM) to back up configuration settings and metadata stored within SQL Server. Microsoft provides significant guidance around SharePoint Server backup and recovery that can and should be used to provide back-up and recovery capabilities, both at the farm level and at the granular server or service level. In this case, Amazon Simple Storage Service (Amazon S3) provides the most natural location in which to store and retrieve this data. Amazon S3 does not natively provide a Windows file system interface, but open source and commercial tools are available that do provide the ability to interact with Amazon S3 in this manner. Amazon EC2 provides the ability to take point-in-time snapshots of Amazon EBS volumes and save them to Amazon S3 for durable storage and recovery. Amazon EBS snapshots are incremental backups, meaning that only the blocks on the device that have changed since the last snapshot will be saved. Also, when you delete a snapshot, only the data not needed for any other snapshot is removed. So, regardless of which prior snapshots have been deleted, all active snapshots will contain all the information needed to restore the volume. In addition, the time to restore the volume is the same for all snapshots, offering the restore time of full backups with the space savings of incremental backups. Snapshots can also be used to instantiate multiple new volumes, expand the size of a volume, or move volumes across Availability Zones. In the case of your SharePoint Server farm, the SQL Server instances within the data tier will hold the persistent state, so taking regular snapshots of the primary SQL Server data tier Amazon EBS volumes provides backup of the database itself and any associated files (e.g., RBS files, metadata files). AWS recently published AWS Disaster Recovery, a whitepaper that provides extensive details on the various considerations and options available within AWS to support disaster recovery.
Page 24 of 36
February 2012
Figure
12:
Intranet
SharePoint
Server
farm
in
AWS
Page 25 of 36
February 2012
Figure
13:
Public-facing
Internet
website
on
SharePoint
Server
in
AWS
Page 26 of 36
February 2012
Although you can use SharePoint Server to support a variety of content and collaboration goals, these scenarios are two of the most common. See the next section for information about other scenarios and additional resources.
Page 27 of 36
February 2012
Conclusion
This
paper
discusses
two
common
deployment
scenarios
for
SharePoint
Serverintranet
and
public
websiteand
how
to
run
them
in
an
AWS
cloud
environment.
It
discusses
how
you
can
leverage
different
services
that
AWS
provides
(network
setup,
server
setup,
security,
and
deployment)
and
configure
them
specifically
to
run
enterprise-class
software
like
SharePoint
Server
at
scale
in
a
secure
fashion
that
is
easier
to
maintain.
Page 28 of 36
February 2012
Further
Reading
Microsoft
on
AWS:
o
http://www.awsmicrosite.com
http://docs.amazonwebservices.com/AWSEC2/latest/WindowsGuide/Welcome.html?r=7870
http://aws.amazon.com/net
http://aws.amazon.com/windows/mslicensemobility
White
papers:
o
Amazons Corporate IT Deploys SharePoint 2010 to the Amazon Web Services Cloud at http://media.amazonwebservices.com/AWS_Amazon_SharePoint_Deployment.pdf Relational Database Management Systems in the Cloud: Microsoft SQL Server 2008 R2 at http://aws.amazon.com/whitepapers/rdbms-in-the-cloud Providing SSO to Amazon EC2 Apps from an On-premises Windows Domain at http://download.microsoft.com/download/6/C/2/6C2DBA25-C4D3-474B-8977-E7D296FBFE71/EC2- Windows%20SSO%20v1%200--Chappell.pdf
Page 29 of 36
February 2012
Appendix
Security
Group
Settings
for
a
SharePoint
Server
Farm
The
following
chart
provides
an
example
of
the
typical
security
group
settings
recommended
for
the
SharePoint
Server
reference
architecture.
TCP
443
Web Tier
Outbound
TCP TCP
80 80
TCP
443
Allow inbound HTTPS access from Elastic Load Balancing only RDP access for corporate administrators AD DS
TCP
3389
Outbound
TCP TCP
49152 65535
AppTierSG
UDP
065535 Allow only web front-end servers to access the application tier 065535 Allow only web front-end servers to access the application tier
Page 30 of 36
February 2012
Tier/security group
0.0.0.0/0
Protocol TCP
Port range 80
Comments Allow outbound HTTP access to servers on the Internet (e.g., for software updates) Allow outbound HTTPS access to servers on the Internet (e.g., for software updates)
0.0.0.0/0
TCP
443
AppTier
Inbound
Source WebTierSG
UDP
Outbound
TCP
065535 Allow only web front-end servers to access the application tier 3389 RDP access for corporate administrators 49152 65535 1433 AD DS Allow outbound SQL Server access to database tier instances Allow outbound HTTP access to servers on the Internet (e.g., for software updates) Allow outbound HTTPS access to servers on the Internet (e.g., for software updates) AD DS Database primary, mirror, and witness Allow only web front-end servers to access the application tier Allow database mirror and witness RDP access for corporate administrators AD DS
TCP TCP
0.0.0.0/0
TCP
80
0.0.0.0/0
TCP
443
DBTier
Inbound
TCP TCP
TCP
3389
TCP
49152 65535
Page 31 of 36
February 2012
Tier/security group
ActiveDirSG 0.0.0.0/0
Comments AD DS Allow outbound HTTP access to servers on the Internet (e.g., for software updates) Allow outbound HTTPS access to servers on the Internet (e.g., for software updates)
0.0.0.0/0
TCP
443
ActiveDirSG
Inbound
Source ActiveDirSG ActiveDirSG 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0
TCP UDP TCP UDP TCP UDP UDP TCP UDP TCP UDP TCP UDP
0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 IP address range of corporate administrators Destination
165535 Allow AD DS domains to talk to each other 165535 Allow AD DS domains to talk to each other 53 DNS for VPC instance 53 DNS for VPC instances 88 Kerberos authentication 88 Kerberos authentication 123 Network News Transfer Protocol (NNTP) 135139 Remote Procedure Call (RPC), NetBIOS 135139 RPC, NetBIOS 389 LDAP to directory service 389 LDAP to directory service 445 Server Message Block (SMB) 500 IPsec Internet Security Association and Key Management Protocol (ISAKMP) 636 LDAP Secure Sockets Layer (SSL) 636 LDAP SSL 3268 LDAP to global catalog 3269 server 4500 NAT traversal (NAT-T) 49152 Dynamic ports 65535 3389 RDP access for corporate administrators
Outbound
Page 32 of 36
February 2012
Tier/security group
0.0.0.0/0
Protocol TCP
Port range 80
Comments Allow outbound HTTP access to servers on the Internet (e.g., for software updates) Allow outbound HTTPS access to servers on the Internet (e.g., for software updates)
0.0.0.0/0
TCP
443
Web Tier
Inbound
TCP
80
TCP
443
Allow inbound HTTPS access from Elastic Load Balancing only SSH access for corporate administrators AD DS
TCP TCP
22 49152 65535
Page 33 of 36
February 2012
Tier/security group
AppTierSG
Protocol TCP
AppTierSG
UDP
0.0.0.0/0
TCP
0.0.0.0/0
TCP
AppTier
Inbound
Source WebTierSG
UDP
Port Comments range 065535 Allow only web front-end servers to access the application tier 065535 Allow only web front-end servers to access the application tier 80 Allow outbound HTTP access to servers on the Internet (e.g., for software updates) 443 Allow outbound HTTPS access to servers on the Internet (e.g., for software updates) 065535 Allow only web front-end servers to access the application tier 22 SSH access for corporate administrators 49152 AD DS 65535 1433 Allow outbound SQL Server access to database tier instances Allow outbound HTTP access to servers on the Internet (e.g., for software updates) Allow outbound HTTPS access to servers on the Internet (e.g., for software updates) AD DS DB primary, mirror, and witness Allow only web front-end servers to access the application tier Allow database mirror, witness
Outbound
0.0.0.0/0
TCP
80
0.0.0.0/0
TCP
443
DBTier
Inbound
TCP TCP
DBTierSG
Page 34 of 36
February 2012
Tier/security group
Outbound
Comments SSH access for corporate administrators AD DS AD DS Allow outbound HTTP access to servers on the Internet (e.g., for software updates) Allow outbound HTTPS access to servers on the Internet (e.g., for software updates)
0.0.0.0/0
TCP
443
ActiveDirSG
Inbound
Source ActiveDirSG ActiveDirSG 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 0.0.0.0/0 BastionSG
TCP UDP TCP UDP TCP UDP UDP TCP UDP TCP UDP TCP UDP TCP UDP TCP UDP TCP TCP
Outbound
Destination
165535 Allow AD DS domains to talk to each other 165535 Allow AD DS domains to talk to each other 53 DNS for VPC instances 53 DNS for VPC instances 88 Kerberos authentication 88 Kerberos authentication 123 NNTP 135139 RPC, NetBIOS 135139 RPC, NetBIOS 389 LDAP to directory service 389 LDAP to directory service 445 SMB 500 IPsec ISAKMP 636 LDAP SSL 636 LDAP SSL 3268 LDAP to global catalog 3269 server 4500 NAT-T 49152 Dynamic ports 65535 3389 RDP access for corporate administrators through a bastion host
Page 35 of 36
February 2012
Tier/security group
0.0.0.0/0
Protocol TCP
Port range 80
Comments Allow outbound HTTP access to servers on the Internet (e.g., for software updates) Allow outbound HTTPS access to servers on the Internet (e.g., for software updates)
0.0.0.0/0
TCP
443
For detailed guidance on setting up VPC security groups, see the Amazon Virtual Private Cloud User Guide.
Page 36 of 36