This document summarizes the key steps taken by the Federal Home Loan Bank of Chicago in moving infrastructure to AWS cloud services. It outlines communicating the transition within the organization, conducting a proof of concept to test services, evaluating AWS controls using their framework, considering costs beyond just compute hours, implementing infrastructure and security monitoring, and developing disaster recovery plans. The overall message is that due diligence across these areas is necessary to successfully adopt cloud services while maintaining control.

1. How Federal Home Loan Bank of Chicago
Maintains Control in the Cloud
Eric Geiger, Federal Home Loan Bank of Chicago
© 2013 Amazon.com, Inc. and its affiliates. All rights reserved. May not be copied, modified, or distributed in whole or in part without the express consent of Amazon.com, Inc.

2. Federal Home Loan Banks
• Created by Congress in 1932
• Each is a cooperative owned by members in its district
• Members include banks, thrifts, credit unions, insurance
companies, and housing finance institutions
• As of September 30, 2013, almost 7,500 members in the
FHLBank System
• Each FHLBank is registered with the SEC
• Each FHLBank is governed by a separate board of directors, but
regulated by a single regulator, Federal Housing Finance Agency

3. Why Did FHLBC Start Using AWS
• Exploring infrastructure options
–
–
–
Faster server provisioning
Required options and flexibility to replace existing hardware
Wanted to reduce hardware expense
• What brought us to Amazon
–
–
–
–
Leader in the space
Vast array of options
Easy entry into the services
Quickly observable results
• Our initial concerns
–
–
–
Security
Performance
Reliability/durability/availability

4. Due Diligence is Key
Communicate
Before
Proof of Concept
Framework
Cost
Security
After
Monitoring
Disaster Planning
CONTINUOUS

5. Communicate with Your Organization
•
We had many preconceived notions
–
–
•
Amazon is just a bookstore, isn’t it?
The “cloud” isn’t secure!
Get educated
–
Read the whitepapers
•
•
•
•
–
Review the AWS security and compliance sites
•
•
•
•
•
http://aws.amazon.com/whitepapers
“Overview of Amazon Web Services”
“AWS Risk and Compliance” whitepaper
“Auditing Security Checklist for Use of AWS”
http://aws.amazon.com/security
http://aws.amazon.com/compliance
This is more than simply moving infrastructure
Is there guidance from governance bodies
Ensure business buy-in early

6. Try a Small POC
• Level set your expectations
• What are you planning to use AWS for
– Only web services
– Core infrastructure
– Data and database services
• Explore the service options
• Important basics to consider
– Pick a region/zone that’s close
– Set up a VPC
– Test your network connectivity and see if it’s sufficient

7. Evaluate with a Framework
• AWS has many certifications and accreditations: HIPPA, SOC 1, SOC
2, SOC 3, PCI, ISO 27001, FISMA, FedRAMP, ITAR, FIPS 140-2
• How do the certifications pertain to you?
–
–
Certification need to be mapped back to your own compliance and control framework
The bank used the Cloud Security Alliance framework as our starting point
•
https://cloudsecurityalliance.org/
• Time-consuming process to map associations
–
–
Will draw attention to areas your own control framework needs revision
Should be done by multiple areas in your organization
•
•
•
IT security
IT operations
Internal audit

8. Aligning Your Framework to AWS
Our example using the Security Guidance for Critical Areas of Focus in Cloud Computing
•
Alignment with
Industry Control
Frameworks
Architectural
Relevance
Team Comments
Internal Risk Rating
Alignment of AWS
with Internal
Controls
Internal Controls

9. Consider All of Your Costs
•
•
•
We definitely saw a reduction in expense
The cost equation is not simply instances*hours*price
Your AWS instance usage needs monitoring
–
–
–
•
You still need to support your AWS infrastructure
–
•
Standard infrastructure jobs still apply: provisioning, patching, software installs, backups, anti-virus
and tools
Moving can generate new workloads for additional costs
–
•
Elastic provisioning makes it easy to generate instance creep increasing cost
Reserved might be cheaper over time
On-demand instances need to be reviewed regularly for conversion to reserved
Managing client side IDS and firewalls
Useful considerations
–
–
–
Auto start/stop can save considerable money
Amazon CloudWatch can be configured to report on spending thresholds
AWS Trusted Advisor can find significant cost savings based on usage stats

10. Infrastructure Monitoring
• CloudWatch is your first resource
– Pay for “Detailed Monitoring”
– Set up CloudWatch alarms on basic thresholds: CPU, network, disk usage, spend
• Monitor your events
– Watch for unexpected instance reboots and maintenance
– Use the AWS API to automate event monitor when possible
• Expand CloudWatch with your existing third-party monitoring
– CloudWatch will not replace your existing tool set
– You can run your agents on the AWS instances
• Can allow you to recycle existing scripts and code
• Monitor OS-level activity, events, services, logs, etc

11. Security Monitoring
•
•
AWS security works best when you are building apps to leverage AWS services
AWS has some limitations for traditional security monitoring
–
–
–
•
Limited Inspection and auditing of your traffic
Limited traditional integration with third-party vendor products
Better (targeted) service offerings to support “traditional” application environments
You can do some things to mitigate certain limitations
–
Always use VPCs when possible to help control traffic
•
–
–
–
•
Separate dev/test, prod and Internet apps to their own VPCs
Consider host-based firewalls and IDS
All traffic flows through your traditional data center when possible
Terminate AWS Direct Connect at firewalls to assist with traffic inspection
Locked-down AWS console
–
–
–
Multifactor authentication
Permission restrictions
Limited access

12. Disaster Planning
• Consider your real uptime need
– Amazon SLA is 99.95% availability for EC2 infrastructure each month
– That’s 3.6 hours per month of downtime
• Your zone will be degraded
• Quick recovery and redundancy can be architected
– Create an AMI (Amazon machine image) of your working, patched
server on a regular basis
– Take snapshots of your instances on a regular basis
– Use Amazon S3 service to keep images and snapshots available in
multiple regions and zones

13. Thank You
• Questions?

14. Please give us your feedback on this
presentation
ENT207
As a thank you, we will select prize
winners daily for completed surveys!