1.
© 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Prashant Prahlad
AWS Product Management
pprahlad@amazon.com
August 14, 2017
Deep Dive on AWS Management Tools
and New Launches
Lifecycle Management of Cloud Resources at Scale
Dan Peebles
Bridgewater Associates
dan.peebles@bwater.com
@copumpkin

2.
What to expect from this session
• What are AWS Management Tools?
• Visibility and control for better security at scale
• Feature deep dive: AWS CloudTrail Event History for all
• Feature deep dive: AWS Config Rules for Amazon S3
buckets
• Feature deep dive: AWS CloudFormation StackSets
• Customer deep dive: Reasoning and collaboration
• Q&A

3.
The challenge
Agility
Control
Visibility
Growth Complexity Cloud

4.
What capabilities do you need?
Control over your cloud environment
Provision
resources
Gain
visibility
Monitor
and
optimize

5.
AWS Management Tools capabilities
Model
and
automate
Gain
visibility
Respond
to
changes
Optimize
Integrate
Control

6.
Model your cloud with AWS CloudFormation
Template AWS CloudFormation Stack
JSON formatted file
Parameter definition
Resource creation
Configuration actions
Configured AWS services
Comprehensive service support
Service event aware
Customizable
Framework
Stack creation
Stack updates
Error detection and rollback
• AWS CloudFormation gives developers and systems administrators an
easy way to create and manage a collection of related AWS resources,
provisioning and updating them in an orderly and predictable fashion

7.
AWS CloudFormation key benefits
Infrastructure as code
Declarative and flexible
Easy to use
Supports a wide range
of AWS resources

8.
New feature : CloudFormation StackSets

9.
What are StackSets?
StackSet that lets you provision a common set of AWS
resources across multiple accounts and regions with a
single CloudFormation template.
Stack 2 : A2, us-west1
Stack 3 : A3, us-west -1
Stack 4: A4, us-west-1
Stack 5: A5, us-west-1
Stack 1: A1, us-west-1

10.
Common use cases
• Account factory: Set up new accounts with defaults
• Enable CloudTrail for all regions; use admin’s S3 bucket
• Set up Config Rule to tag resources correctly
• Set up IAM roles and policies
• Set up AWS KMS keys
• Deploy identical infrastructure for apps across the globe
• App services managing stacks across multiple regions
• AWS services using CFN to set up new regions
• Permissions and policies
• Set up consistent IAM policies and users across organizations
• BCDR solutions across multiple regions
• Configure Amazon S3 bucket replication
• Provision Amazon RDS read replicas

11.
StackSet Operations options
Max concurrent accounts
• Max number of accounts per region to deploy to
Failure threshold
• Max number of failures tolerated before operation should be stopped
Region order
• Specify which region to begin operation in and roll forward from
Note: Regions are serial

12.
Getting started and best practices
• Be sure that global resources (such as IAM roles and
Amazon S3 buckets) do not have naming conflicts
• Verify that adding stack instances to your initial stack set
works before you add larger numbers of stack instances
to your stack set.
• A stack set has a single template and parameter set.
The same stack is created in all accounts that are
associated with a stack set.
• Updating a stack set always touches all stack instances.

13.
Gain visibility with AWS Config
• Automatically discover resources in your account (resource inventory)
• Captures configuration of the resource and tracks all changes
• Provides rules to ensure resource configurations conform to your internal
best practices and guidelines

14.
AWS Config key benefits
• Continuously monitors and records your AWS resource configurations
• Continuously assesses the configuration of your AWS resources against desired
configurations using AWS Config rules
Continuous monitoring
Change management
Continuous assessment
Operational troubleshooting
Benefits

15.
AWS Config advanced features
Configurable and customizable rules
Configuration history of AWS resources
• Identify Amazon EC2 volumes that are not encrypted.
• Ensure that all EC2 instances in your cloud infrastructure
use AMIs from an approved list
• Identify managed EC2 instances that are running software
packages and applications that are on the blacklist
• Comply with CIS benchmarks, HIPAA and NIST
requirements

16.
AWS Config Dashboard
An overview of your resources and their compliance with AWS Config rules

17.
New Feature launch: S3 Config Rules

18.
Automated reasoning about permissions
• Answer semantic questions about policies using
constraint solving
• Combination of S3 bucket policies and ACLs evaluated
to determine
1. Is the S3 bucket publicly readable?
2. Is the S3 bucket publicly writeable?

19.
Gain visibility with AWS CloudTrail
• Increase visibility into your user and resource activity
• Discover and troubleshoot security and operational issues
• Simplify your compliance audits by automatically recording and storing
activity logs for your AWS account

20.
AWS CloudTrail advanced features
• Multiple region and multiple trail configuration
• Data events
• Log file integrity validation
• CloudWatch Logs integration

21.
New Feature launch: CloudTrail Event History

22.
CloudTrail: Event History for ALL AWS users
Capabilities
• 7 days of event
history
• All existing
filters available
• Download
filtered results
• API access
available
• No need to set
up CloudTrail
Available free of charge

23.
Automate configuration with Amazon EC2
Systems Manager
• Enables automated configuration
• Supports ongoing management of systems at scale
• Works across all of your Windows and Linux workloads
• Runs in Amazon EC2 or on-premises
• Carries no additional charge to use

24.
Amazon EC2 Systems Manager capabilities
State Manager Maintenance WindowInventory
Automation Parameter Store
Run Command
Patch manager

25.
Optimize with AWS Trusted Advisor
• Get insight into how and
where you can get the most
impact for your AWS spend
• Find opportunities to reduce
your monthly spend and
retain or increase productivity
• Receive guidance on getting
the optimal performance and
availability based on your
requirements

26.
Integrate with third-party tools

27.
AWS Management Tools capabilities
Control
 AWS CloudFormation
 AWS Service Catalog
 EC2 Systems Manager
 AWS OpsWorks
 AWS Config
 AWS CloudTrail
 Amazon CloudWatch
AWS Trusted Advisor 
Model
and
automate
Gain
visibility
Respond
to
changes
Optimize
Integrate

28.
Where to find AWS Management Tools?

29.
Customer deep dive
Dan Peebles
Bridgewater Associates

30.
Introduction
• AWS Cloud has driven a paradigm shift
• With 1 server, it’s a pet:
• Hand fed
• Loved and cuddled
• $$$ on vet bills when sick
• With 100 servers, they’re cattle:
• Automatically fed
• Don’t care if one is sick, just replace it
• Enabled by management tools

31.
Introduction
• Same with AWS accounts
• With 1 account, it’s a pet:
• Hand fed
• Loved and cuddled
• $$$ on vet bills when sick
• With 100 accounts, they’re cattle:
• Automatically fed
• Don’t care if one is sick, just replace it
• Enabled by management tools

32.
Reaching our Pet Limit
• Our very first AWS accounts were experimental pets
• Quickly ran into issues when making it real:
• “This works in our QA account, why isn’t it working in prod?”
• “Oh, I hand-tweaked this IAM policy to get it working, but
forgot to check it into source control”
• Also hard to secure:
• Need to reason about security properties of our accounts
• 100 pets are impossible to reason about
• “Hand-tweaking IAM policies” should scare you!

33.
Moving Towards Cattle Accounts
• Built a management tool for our accounts
• Manifest file declaring all accounts and their properties
• Translate manifest into unique CloudFormation template
per account
• Similar to StackSets, but this predates StackSets
• Jsonnet for composability and modularity
• CloudFormation makes pushing out updates to our account
fleet easy: More Agility
• (Plus some python for things that aren’t possible in
CloudFormation)

34.
Lessons Learned Managing Accounts at Scale
• Observed a few different patterns of accounts:
• Dev sandbox accounts disconnected from prod network
• Extremely sensitive production accounts
• A few different CloudFormation templates as building blocks
• Commonalities across ALL accounts, such as:
• CloudTrail turned on and configured properly
• Security Monkey access enabled
• Others we won’t discuss
• Insert these into ALL CloudFormation templates

35.
Results
• Much more homogeneous account fleet
• Less is more: limited set of account types
• Easier for developers not familiar with AWS to pick something
that suits them
• Easier for security operators to reason about the security
posture of our accounts
• Painful at first as we had to learn what those account
types were, but now a huge help
• Evolved features as new use cases came up

36.
Understanding our systems
• We must understand our AWS infrastructure to secure it
• Need to reason about the types of accounts we have
• Simplified with standardized account types, e.g., “sandbox”
• Which VPCs can Direct Connect to our data center?
• Need to reason about what’s inside them
• Do any IAM roles grant access to unknown principals?
• Are internal S3 buckets world-readable?
• Are internal S3 buckets at all accessible from outside?
• Can any instances in a particular account reach the internet?

37.
Reasoning today
• Manually inspecting infrastructure is tedious, error-prone
• Actual permissions can be governed by up to 3 or 4 policies
• Interaction between policies is non-local, not obvious
• Policies can be complicated! variables, conditions, resources
• People are bad at understanding this sort of thing
• Other tools (e.g., Security Monkey) have key limitations:
• Pattern matching: only find things authors think to encode
• Make assumptions about AWS semantics

38.
Why this is hard
Offline VPC
EC2 instance S3 endpoint
IAM role
S3
VPCE policy Bucket policy
ACLs

39.
Why this is hard
Offline VPC
EC2 instance S3 endpoint
IAM role
S3
VPCE policy Bucket policy
ACLs

40.
Why this is hard
Offline VPC
EC2 instance S3 endpoint
IAM role
S3
VPCE policy Bucket policy
ACLs
Who else can
assume it?
What other buckets
can we reach?
Who else can
access my
buckets?

41.
Why this is hard
Offline VPC
EC2 instance S3 endpoint
IAM role
S3
VPCE policy Bucket policy
ACLs
Who else can
assume it?
What other buckets
can we reach?
Who else can
access my
buckets?
Scary networking
gizmos??

42.
Reasoning tomorrow
• Cloud is all about automating tedious & error-prone work
• So why still manually reason about networks and IAM?
• Answer: It’s really hard to do correctly
• But: AWS has a team working to make it much easier!
• We’ve been collaborating with the AWS Automated
Reasoning Group closely over last year+ on this

43.
Automated IAM Policy Reasoning: first glimpse
• New AWS Config Rules built on a semantics-based
automated reasoning engine
• In plain English: it deeply understands the IAM language
• This means:
• We can start to encode what we actually care about:
• Saying “warn me about principal * & action *” is too narrow
• Let me say “warn me if folks outside the company have access”
• We get high confidence in answers
• Future proof: AWS keeps its models fresh so we don’t have to

44.
IAM Policy Reasoning
• Automated reasoning system is critical foundation
• Enables an entire new class of powerful tools to answer
questions about our infrastructure
• Power to reason about IAM policies will give us
unprecedented visibility into one of the most important
security facets of our AWS accounts
• Increased visibility and reasoning allows you be more
secure, and to know you’re more secure

45.
Q&A

46.
Thank you!
pprahlad@amazon.com