AWS’ Security Model and MS AD support


Migration: Enterprise architecture challenge

Migration of a mission-critical application infrastructure should be architected from a global enterprise perspective. If ad hoc “forklift” migrations are done in an isolated “silo by silo” approach then the result will be inevitable: A costly, disjointed, inefficient, inflexible, fragile, and wasteful architecture.

AWS describes in great detail recommended migration strategies and “best practices”.[1]

Amazon security basics

Before considering AD in relation to AWS, it would be useful to review AWS security basics.

Shared responsibility model

AWS approach can be summarized as follows:

While AWS manages security of the cloud, security in the cloud is the responsibility of the customer.[2]

AWS’ basic IAAS EC2 service[3] provides a good example of the shared responsibility model:

...AWS manages the security of the following assets:

... you the customer... are responsible for the security of the following assets:

Amazon’s security model

This section briefly reviews AWS’ basic security model. The next section looks at security function implemented for specific AWS service offerings.[4]

Root account / IAM

Each AWS account has a root user account. This account has full power to provision the rest of AWS security including the IAM RBAC.

Root accounts as well as IAM accounts are authenticated with reusable passwords plus optional 2FA.

Access to the rich set of AWS APIs uses an HMAC signature based on a user secret key / access ID. AWS S3 SOAP requests are an exception. They use X.509 certificates.


IAM is the fundamental RBAC AuthN / AuthZ application:

AWS IAM allows you to create multiple users and manage the permissions for each of these users within your AWS Account. A user is an identity (within an AWS Account) with unique security credentials that can be used to access AWS Services. AWS IAM eliminates the need to share passwords or keys, and makes it easy to enable or disable a user’s access as appropriate.

AWS IAM is tightly integrated into all AWS service offerings.

IAM Roles

Roles (sets of permissions) are defined in IAM. The permissions define highly granular user AuthZ across the Amazon applications, including access to specific API function.

Roles are used to generate temporary security credentials.

An IAM role uses temporary security credentials to allow you to delegate access to users or services that normally don't have access to your AWS resources. A role is a set of permissions to access specific AWS resources, but these permissions are not tied to a specific IAM user or group. An authorized entity (e.g., mobile user, EC2 instance) assumes a role and receives temporary security credentials provide enhanced security due to their short life-span (the default expiration is 12 hours) and the fact that they cannot be reused after they expire. This can be particularly useful in providing limited, controlled access in certain situations:

The following describes how IAM facilitates use of temporary credentials for access to AWS resources by applications running on EC2 instances:

IAM and AWS “managed applications”

Beside cloud-based infrastructures services, AWS also offers “managed applications”.[5] These are cloud-based functional platforms abstracting underlying infrastructure.

The following is a typical example of IAM integration in a managed application:

Amazon SNS access is granted based on an AWS Account or a user created with AWS IAM. Once authenticated, the AWS Account has full access to all user operations. An AWS IAM user, however, only has access to the operations and topics for which they have been granted access via policy. By default, access to each individual topic is restricted to the AWS Account that created it. However, you can allow other access to SNS, using either an SNS-generated policy or a policy you write.

Security function in AWS services

The previous section briefly reviewed AWS’ basic security model. This section looks at security functions implemented for specific AWS service offerings.

The 3 kinds of AWS services

Amazon offers 3 kinds of services. These are summarized in the following table:[6]



Infrastructure Services

“Compute” services and related “Infrastructure” services


Elastic Block Store (EBS)

Auto Scaling

Virtual Private Cloud (VPC).

Container Services

Managed service application “containers”

Relational Database Services (RDS)

Elastic Map Reduce (EMR)

AWS Elastic Beanstalk

Abstracted Services

High-level storage, database, and messaging services

Abstracted platform / management layer

Access via endpoint APIs


Simple Storage Service ( S3)

AWS Glacier

AWS DynamoDB

Simple Queuing Service ( SQS)

Simple Email Service ( SES)

Customer responsibilities for security vary depending on the kind of service:

Examples of Customer responsibilities

Infrastructure Services

control the operating system, and you configure and operate any identity management system that provides access to the user layer of the virtualization stack

Container Services

setting up and managing network controls, such as firewall rules, and for managing platform-level identity and access management separately from IAM

Abstracted Services

The following diagrams illustrate the shared responsibility in a visual manner for each of the 3 types of AWS service:

EC2 instances

EC2 is Amazon’s fundamental IAAS offering. As such EC2 security function is tightly integrated with AWS’ basic security model.

SSH login to EC2 instances is protected by 1024-bit SSH-2 RSA keys. Each instance has its own key pair.[7]

Although the basic key pair approach offers robust security, it is not manageable at scale. AWS’ solution is to leverage IAM roles for generation of temporary credentials:

However, getting credentials out to new EC2 instances launched with AutoScaling can be challenging for large or elastically scaling fleets. To simplify this process, you can use roles within IAM, so that any new instances launched with a role will be given credentials automatically. When you launch an EC2 instance with an IAM role, temporary AWS security credentials with permissions specified by the role will be securely provisioned to the instance and will be made available to your application via the Amazon EC2 Instance Metadata Service. The Metadata Service will make new temporary security credentials available prior to the expiration of the current active credentials, so that valid credentials are always available on the instance. In addition, the temporary security credentials are automatically rotated multiple times per day, providing enhanced security.


S3 is the Amazon “bulk cloud storage”. Data objects are stored in “buckets”.

Access control is provided at several levels:

Audit trail logs can be configured to track S3 bucket access. [8]

AWS CloudTrail [9]

CloudTrail is the AWS “audit trail”:

CloudTrail captures information about every API call to every AWS resource you use, including sign-in events.

CloudTrail security logs across different regions can be consolidated in a single AWS S3 bucket for easy access by log management / analysis.

AWS CloudWatch[10]

In addition to CloudTrail’s user activity logs, you can use the Amazon CloudWatch Logs feature to collect and monitor system, application, and custom log files from your EC2 instances and other sources in near-real time.


Patching in the cloud can be automated. The basic approach is to relaunch a newly patched instance.

AWS provides automatic software patching for managed DBs. The user defines a maintenance window to take a given instance offline for either patching or to scale up/down.

Patching provided by Amazon includes all base AWS OS AMI images as well as managed DB software.

DynamoDB[11] (NoSql DB):

To control who can use the DynamoDB resources and API, you set up permissions in AWS IAM. In addition to controlling access at the resource-level with IAM, you can also control access at the database level—you can create database-level permissions that allow or deny access to items (rows) and attributes (columns) based on the needs of your application. These database-level permissions are called fine-grained access controls, and you create them using an IAM policy that specifies under what circumstances a user or application can access a DynamoDB table. The IAM policy can restrict access to individual items in a table, access to the attributes in those items, or both at the same time.

In addition to requiring database and user permissions, each request to the DynamoDB service must contain a valid HMAC-SHA256 signature, or the request is rejected.

RDS DB (MS Sql, Oracle, etc)[12]

When you first create a DB Instance within Amazon RDS, you will create a master user account, which is used only within the context of Amazon RDS to control access to your DB Instance(s). The master user account is a native database user account that allows you to log on to your DB Instance with all database privileges.

You can control Amazon RDS DB Instance access via DB Security Groups, which are similar to Amazon EC2 Security Groups but not interchangeable. DB Security Groups act like a firewall controlling network access to your DB Instance. …  authorizing a network IP range or authorizing an existing Amazon EC2 Security Group

AWS also provides the possibility of encrypted connections, and transparent data encryption.


The memory-based cache application includes a “Cache Security group” to limit network access to caching servers.[13]

MS AD in the AWS Cloud

The previous sections looked at the Amazon Security Model as well as security function provided for specific AWS services.

The following sections look at MS AD in the AWS cloud.

Complete reversal in Amazon orientation concerning AD

Amazon is first and foremost a Linux-centric shop. Historically this was reflected in Amazon’s attitude to all things “Microsoft”. As late as 2013, Amazon authors wrote concerning AWS “Security Best Practices”:

Make sure the AMI is not a part of a Windows domain.

Do not enable any file sharing, print spooler, RPC, and other Windows services that are not essential but are enabled by default.

In 2014-2015 Amazon completely reversed its former position concerning MS, especially MS AD.

AWS is now providing detailed guides and blog articles for integration of a corporate on-premises AD with an AWS cloud-based deployment. Amazon is offering comprehensive new services for MS AD integration and support.

Probably the main driving force in this about-face was Amazon’s push into new end-user oriented services e.g. Amazon’s Workspaces (user virtual desktop), Workdocs (user file sharing), and Workmail (user email). To be attractive, these services have to leverage corporate AD integration for function such as SSO.

The following sections start with a brief description of reference AD architectures on the AWS cloud. A discussion of remote management access is included. Finally there is an overview of the various AWS AD service offerings.

Deploying an AD on the AWS cloud[14]


The reference architecture for a cloud-based RYO MS AD DS / Dns deployment follows. A separate AD sites is configured for each Availability Zone. Each Availability Zone has autonomous function including GC and Dns.

The salient features described below.

VPC architecture:

AD architecture:

Individual host instances:

Network traffic ACLs:

Remote management access using RD GW[16]

Amazon recommends using MS Remote Desktop GW for remote access to MS EC2 instances. The reference architecture follows:

A TLS encrypted RDP connection is proxied through the RD GW on Tcp 443 to backend Windows instances in private subnets on cleartext Tcp 3389.

To lock down and automate access:

Amazon provides configurable CloudFormation templates to automate deployment of the above reference RD GW architecture.

Extend on-premises AD to the AWS cloud

The following diagram shows the reference architecture for extending on-premises AD to the cloud:

The AD architecture specifics:

AWS Directory Service[17]

AWS Directory Service offers 3 different ways to use MS AD on the AWS cloud:

The following sections consider each of the above services in turn.

Simple AD

This is a Samba 4 implementation to provide the following basic AD-like services:

The following is not supported:

AWS Directory Service for MS AD (Enterprise Edition)

This is a full-blown AWS multi-tenant managed AD in the AWS cloud.



Not supported:

AD Connector[18]

This is essentially an Ldap proxy to connect on-premises MS AD to the AWS cloud. Cleartext Ldap is used to authenticate to the corporate AD. Then temporary security credentials are provided by AWS for that user to sign-on to AWS services (e.g. AWS management console).


Functions supported:

Not supported:

Integration with AWS services

The following integration is provided for AWS base services:

Conclusions / Recommendations


“Cloud” brings with it a whole new set of function to be configured and monitored. Along with this new context comes the need to determine and mitigate the associated Security Risks.

Mature cloud offerings provide such as SFDC and AWS provide robust, highly integrated (albeit complex) security function to manage the new cloud-related Security Risks.

Operational or architectural “shortcuts” concerning cloud implementation can result in High Risk: [20]

Adapt legacy “on-premise” approaches to the new “cloud” reality

Regardless of the type of migration, the security architecture should be adapted to cloud-based realities.

This applies even for a “forklift” migration that moves on-premises servers / applications “as is” into the cloud.

Amazon documentation contains detailed guidance on how to best accomplish this.

The following sections contain some quick suggestions.[21]

Technical security architecture: Security zones[22]

In the cloud, the legacy concept of “security zone” == “network segmentation” is passé.

A network segment simply isolates one network from another, where a security zone creates a group of system components with similar security levels with common controls.

Traditional environments require separate network segments representing separate broadcast entities to route traffic via a central security enforcement system such as a firewall. The concept of security groups in the AWS cloud makes this requirement obsolete. Security groups are a logical grouping of instances, and they also allow the enforcement of inbound and outbound traffic rules on these instances regardless of the subnet where these instances reside.

AWS provides flexible security zoning options. Security engineers and architects can leverage the following AWS features to build isolated security zones/segments on AWS per Amazon VPC access control:

Inventory management

Log aggregation / monitoring

AuthN / AuthZ

Patch management

Incident Response

Bring AWS AuthN under control

AWS root accounts need to be tightly controlled. Passwords should be regularly rotated.

IAM – even if decentralized – needs to be integrated with on-premises AD using federation.

Global 2FA also needs to be layered on as the “default” approach.

Architect and implement centralized security management with multiple autonomous independent projects:

Delegate AuthN / AuthZ:[26]

Turn the question around

It would be a serious strategic error to try to manage the “cloud” as if it were an extension of legacy “on-premises”. In fact it would be better to ask:

How can the current legacy on-premises security function be evolved to harness the power of the cloud (e.g. auto-scaling, self-healing, containerization)?



Migrating your Existing Applications to the AWS Cloud / A Phase-driven Approach to Cloud Migration 

Super introduction to enterprise architecture cloud migration

An Overview of the AWS Cloud Adoption Framework 

Introduction to the (very complete) AWS Cloud Adoption Framework Series

A Practical Guide to Cloud Migration / Migrating Services to AWS 

50000’ overview of cloud migration. Too simplistic. 

All Amazon whitepapers

General AWS security-related documentation

AWS: Overview of Security Processes 

Overview of AWS services security-related function. Super read

Introduction to Auditing the Use of AWS 

Comprehensive list of cloud-related security controls

AWS Security Best Practices 

Detailed guide on implementing a full-blown ISO 27001 ISMS at Amazon. Many detailed suggestions on how to adapt legacy security to cloud realities.

Security at Scale: Logging in AWS 

Outlines major CloudTrail function / controls. Maps these to major compliance frameworks like PCI.

Security at Scale: Governance in AWS 

Maps AWS Service features to Governance req’t. Includes useful summary of main features by service (pg 15).

AD DS on the AWS Cloud: Quick Start Reference Deployment 

Recent, detailed step-by-step guide for common MS AD cloud deployments. Good read.

Deploy Remote Desktop Gateway 

Same author as previous whitepaper. Considers RDGW specifics.

AWS Directory Service - Documentation 

Official AWS documentation for the AWS Directory Service

Amazon EC2 Simple Systems Manager API documentation 

Official AWS documentation for the AWS SSM used to automate bootstrapping of EC2 instances

AWS Security Blog: How to Connect Your On-Premises AD to AWS Using AD Connector 

Good blog article describing AD Connector

Managing Your MS Windows Server Fleet with AWS Directory Service 

Talks about AD Connector and Simple AD only. Article is somewhat simplistic.

MS Technet: WMI filtering using GPMC 

Older TN article describing how a WMI filter can be used to limit the scope of a GPO


Really old whitepaper: 2010. ADFS 1.1 + 2.0 only. Out-of-date but demonstrates complexity of legacy ADFS federation


Here then are some of the acronyms and “buzz words”:


In an organization, a group that is isolated from others and lives by itself, for itself


Microsoft’s Active Directory


Amazon Web Services, used here as meaning “all of Amazon’s cloud offerings”


Infrastructure as a service


Platform as a Service e.g. SFDC’s offerings


Software as a Service


AWS’s basic IAAS offering


Amazon Machine Image


AWS Identity Management application


Hash-based message authentication code


Two-factor authentication


Multi-factor authentication as opposed to “reusable password” authentication






Protocol specification cf 


Role-based access control


Application Programming Interface


Protocol / application cf


Access control list


Read-Only / Read-Write




“Roll Your Own” refers to in-house development


Active Directory  Data Services


Domain Name System. Protocol. See 


Global catalog


AWS Virtual Private Cloud




Network Address Translation


Domain Controller / Read-Only Domain Controller


Remote Desktop Gateway. See 


Transport Layer Security, cf


Dynamic host configuration protocol cf



Cross-platform implementation of MS CIFS/SMB protocols cf 


AuthN protocol used by MS AD


Group Policy Object, used by MS AD


Function of MS AD cf


MS scripting language


AuthN / AuthZ protocol for federated organization access cf 

SFDC, a major PAAS / SAAS provider

Page  of


See also the AWS “Cloud Adoption Framework” series starting with: 

[2] pg 8

[3] pg 5

[4] This section and the next refer heavily to the following AWS whitepaper: AWS: Overview of Security Processes

[5] See the following section for the details.

[6] pg 7

[7] pg 18

[8] Op cit pg 37

[9] Op cit

[10] Op cit pg 20

[11] Op cit pg 42

[12] Op cit pg 43

[13] Op cit pg 49

[14] This section relies heavily on 

[15] There are a lot of ports to specify for DC traffic.

[16] This section relies heavily on 

[17] This section relies heavily on the AWS documentation for AWS Directory Services.

[18] This section also relies on the AWS Security Blog article concerning AD connector.

[19] Especially end-user services such as Amazon WorkSpaces, WorkDocs, WorkMail

[20] For a list of cloud-related security controls for auditors, see 

This can be viewed as a comprehensive list of “what can go wrong” in a bungled cloud implementation.

[21] Much of the following is adapted from 

[22] pg 43

[23] Cf, App C API Calls, pg 27

[24] pg 35

[25], Strategies for Multiple AWS Accounts, pg 15

[26] Op cit, pg 17