Fintech Blueprint on the AWS Cloud

Quick Start Reference Deployment

QS

August 2021
Paul Underwood, Yinal Ozkan, and Manish Chugh, AWS Startup team
Shivansh Singh, AWS Integration & Automation team

Visit our GitHub repository for source files and to post feedback, report bugs, or submit feature ideas for this Quick Start.

This Quick Start was created by Amazon Web Services (AWS). Quick Starts are automated reference deployments that use AWS CloudFormation templates to deploy key technologies on AWS, following AWS best practices.

Overview

This guide provides instructions for deploying the Fintech Blueprint Quick Start reference architecture on the AWS Cloud.

This Quick Start is for teams and individuals responsible for developing or hosting business-to-business (B2B) or business-to-consumer (B2C) products for a financial-technology (fintech) company. It helps you build a secure cloud environment following AWS and industry best practices.

Fintech Blueprint on AWS

The Fintech Blueprint Quick Start is called a blueprint because its architecture is analogous to an empty house. After you deploy it, you furnish it with the resources you need for your product or service.

The architecture has partitioned virtual private clouds (VPCs) that separate fintech production, management, and development processes. The Quick Start configures this architecture for identity management, virtual private network (VPN) access control, encryption, network isolation, logging, alarms, and compliance auditing.

You can develop or host your B2B or B2C fintech products in this environment. In addition, you can use the AWS Service Catalog to install prepackaged financial tools from leading fintech software vendors and open-source tools. You can also launch any applicable AWS Quick Start—such as SWIFT Client Connectivity—from the link provided on its webpage or in its deployment guide.

AWS costs

You are responsible for the cost of the AWS services and any third-party licenses used while running this Quick Start. There is no additional cost for using the Quick Start.

The AWS CloudFormation templates for Quick Starts include configuration parameters that you can customize. Some of the settings, such as the instance type, affect the cost of deployment. For cost estimates, see the pricing pages for each AWS service you use. Prices are subject to change.

After you deploy the Quick Start, create AWS Cost and Usage Reports to deliver billing metrics to an Amazon Simple Storage Service (Amazon S3) bucket in your account. These reports provide cost estimates based on usage throughout each month and aggregate the data at the end of the month. For more information, see What are AWS Cost and Usage Reports?

Software licenses

The Fintech Blueprint Quick Start is released under Apache License 2.0.

The Fintech Blueprint Software Catalog portfolio in the AWS Service Catalog includes the SWIFT Client Connectivity Quick Start. This software requires a SWIFT account and software license. To register for a SWIFT account, see How to become a swift.com user?

Architecture

Deploying this Quick Start for a new virtual private cloud (VPC) with default parameters builds the following environment in the AWS Cloud.

Architecture
Figure 1. Quick Start architecture for Fintech Blueprint on AWS

As shown in Figure 1, the Quick Start sets up the following:

  • A highly available architecture with three VPCs, each spanning two Availability Zones. The VPCs contain public and private subnets according to AWS best practices, to provide you with your own virtual networks on AWS. The isolated subnets are for sensitive resources, such as databases that should be addressable only by your internal networks and need no outbound internet access.

    • A production VPC into which you can deploy public and internal applications.

    • A management VPC with AWS Client VPN endpoints in the public subnets. This VPC helps secure connectivity to your VPCs. Your company’s employees use this VPC to access your private cloud resources.

    • A development VPC for your developers to build and test your products.

  • Peering connections so that you can connect using Secure Shell (SSH) and remote desktop access from the management VPC to private subnets in the production and development VPCs.

  • AWS Config to assess, audit, and evaluate the security compliance of your AWS resources and remediate deviations from a set of conformance packs. For more information on the AWS Config conformance packs deployed with this Quick Start, see Security and compliance later in this guide.

  • Amazon Route 53 for a private Domain Name System (DNS).

  • (Optional) An AWS Service Catalog portfolio with fintech tools that you can deploy into the production and development VPCs. For more information, see Set up permissions for the AWS Service Catalog later in this guide.

See Figure 8 for an example of the sorts of resources you might deploy into these VPCs and subnets.

Planning the deployment

Specialized knowledge

This deployment requires a moderate level of familiarity with AWS services. If you’re new to AWS, see Getting Started Resource Center and AWS Training and Certification. These sites provide materials for learning how to design, deploy, and operate your infrastructure and applications on the AWS Cloud.

This Quick Start assumes familiarity with basic concepts of networking and using VPN client software, such as Open VPN Client Connect or AWS Client VPN.

This Quick Start also requires a moderate to high understanding of how to manage the Fintech Blueprint infrastructure. And it requires a moderate understanding of the following: Service Quotas, AWS Cloud Development Kit (CDK), and AWS CloudFormation.

AWS account

If you don’t already have an AWS account, create one at https://aws.amazon.com by following the on-screen instructions. Part of the sign-up process involves receiving a phone call and entering a PIN using the phone keypad.

Your AWS account is automatically signed up for all AWS services. You are charged only for the services you use.

Technical requirements

Before you launch the Quick Start, review the following information and ensure that your account is properly configured. Otherwise, deployment might fail.

Resource quotas

If necessary, request service quota increases for the following resources. You might need to request increases if your existing deployment currently uses these resources and if this Quick Start deployment could result in exceeding the default quotas. The Service Quotas console displays your usage and quotas for some aspects of some services. For more information, see What is Service Quotas? and AWS service quotas.

Resource This deployment uses

Configuration recorders

1

AWS Config conformance packs

4

AWS Config delivery channels

1

AWS Client VPN authorization rules

3

AWS Client VPN endpoints

1

AWS Client VPN routes

4

AWS Client VPN target network associations

2

Elastic IP addresses

3

Internet gateways

3

Network address translation (NAT) gateways

3

Routes

30

Route tables

16

Security groups

1

Subnets

16

Subnet route table associations

32

VPCs

3

VPC endpoints

2

VPC gateway attachments

2

VPC peering connections

2

AWS Identity and Access Management (IAM) policies

1

IAM roles

2

AWS Lambda functions

1

Log groups

1

Log streams

1

Route 53 hosted zones

1

S3 buckets

2

S3 bucket policies

1

AWS Service Catalog AWS CloudFormation products

6

AWS Service Catalog portfolio product associations

6

AWS Service Catalog portfolios

1

Supported AWS Regions

For any Quick Start to work in a Region other than its default Region, all the services it deploys must be supported in that Region. You can launch a Quick Start in any Region and see if it works. If you get an error such as “Unrecognized resource type,” the Quick Start is not supported in that Region.

For an up-to-date list of AWS Regions and the AWS services they support, see AWS Regional Services.

Certain Regions are available on an opt-in basis. For more information, see Managing AWS Regions.

IAM permissions

Before launching the Quick Start, you must sign in to the AWS Management Console with IAM permissions for the resources that the templates deploy. The AdministratorAccess managed policy within IAM provides sufficient permissions, although your organization may choose to use a custom policy with more restrictions. For more information, see AWS managed policies for job functions.

Deployment options

To deploy this Quick Start, you use the AWS CDK. With AWS CDK, you can use familiar programming tools and syntax to define infrastructure as code and provision it through AWS CloudFormation. AWS CDK deploys all the resources described in this Quick Start. Initially, AWS CDK simplifies your deployment on AWS. Later, it simplifies managing, adapting, updating, and growing the architecture as your needs change.

For more information, see Working with the AWS CDK.

Deployment steps

Confirm your AWS account configuration

  1. Sign in to your AWS account at https://aws.amazon.com with an IAM user role that has the necessary permissions. For details, see Planning the deployment earlier in this guide.

  2. Make sure that your AWS account is configured correctly, as discussed in the Technical requirements section.

  3. Check the AWS Region that’s displayed in the upper-right corner of the navigation bar, and change it if necessary. This Region is where the network infrastructure for Fintech Blueprint is built. The template is launched in the us-east-1 Region by default. For other choices, see Supported Regions earlier in this guide.

Install the AWS CDK and bootstrap the AWS CDK Toolkit stack

Before you launch the Quick Start, you need to install the AWS CDK and bootstrap the AWS CDK Toolkit stack. One way to do this is to run the following commands in AWS CloudShell. It may take a minute or so for your first CloudShell session to start. Alternatively, you can use your own integrated development environment (IDE), such as AWS Cloud9 or Visual Studio Code.

  1. If you are not using CloudShell, verify that you have the prerequisites for installing the AWS CDK.

  2. Install the AWS CDK as follows:

    npm install -g aws-cdk typescript

    For details, see Install the AWS CDK in the AWS documentation.

  3. Verify the installation, and check the current version.

    cdk --version
  4. Bootstrap the AWS CDK Toolkit stack as follows:

    export CDK_NEW_BOOTSTRAP=1
    cdk bootstrap aws://ACCOUNT-NUMBER/REGION

    For details, see Bootstrapping.

If you’re using CloudShell, you can open it again by choosing its icon on the AWS Management Console, as shown in Figure 2.

CloudShell
Figure 2. CloudShell icon

Launch the Quick Start

The first time you launch, deployment should take about 15 minutes to complete. The template is launched in the us-east-1 Region by default.

  1. Clone the resources defined in the Fintech Blueprint Quick Start as follows:

    git clone https://github.com/aws-quickstart/quickstart-aws-fintech-blueprint.git
    cd quickstart-aws-fintech-blueprint
    npm install
  2. Launch the Quick Start by running the following:

    npm run build && cdk deploy

    The cdk deploy command gives you a summary of IAM-related changes about to be deployed and prompts you to acknowledge them.

Post-deployment steps

Connect to the VPN

After the deployment is complete, you connect to the VPN to route into the private subnets in the VPCs. The Fintech Blueprint Quick Start deploys an AWS Client VPN endpoint in the management VPC. The management VPC, which sends NAT traffic over peering connections into the production and development VPCs, acts as a hub for networking into those VPCs. The development and production VPCs do not communicate with each other, as shown in Figure 3.

VPN
Figure 3. VPN routing rules in the Fintech Blueprint Quick Start
  1. Navigate to the Amazon Virtual Private Cloud (Amazon VPC) web console, and go to the AWS Client VPN endpoint section.

  2. Select the AWS Client VPN endpoint listed, and choose Download Client Configuration, as shown in Figure 4. Your browser downloads the file client-config.ovpn.

    VPNConfig
    Figure 4. Downloading the client-configuration file
  3. Navigate to the Amazon S3 console, and open the bucket prefixed awsstartupblueprintstack-clientvpnvpnconfigbucket. Five files are listed. Download client1.domain.tld.key and client1.domain.tld.crt. The other three files are the certificate authority (CA) chain and server key/certificate. You need those later if you create additional client certificates.

  4. Open the downloaded file client-config.ovpn in a text editor.

  5. Add the following lines to the bottom of the file. Replace the <cert> and <key> sections with the contents of the two files.

    <cert>
    Contents of client certificate (client1.domain.tld.crt) file
    </cert>
    
    <key>
    Contents of private key (client1.domain.tld.key) file
    </key>
  6. Save client-config.ovpn. You should be able to open or import that file with any OpenVPN client.

AWS offers is own lightweight VPN client that works on most operating systems. For installation and usage instructions, see Connect using an AWS provided client.

For usage instructions for other OpenVPN clients, see Connect using an OpenVPN client.

If you get an error trying to connect about resolving the Client VPN endpoint’s DNS name or hostname, you may need to edit the .ovpn file. For more information, see Unable to resolve Client VPN endpoint DNS name.

(Optional) Modify the default configurations

After deploying the Quick Start, you may want to change some of the default configurations. For example, the default internal DNS apex is the generic top-level domain .corp instead of yourcompany.com. To change the DNS apex or any configuration you see in the code, make the change, build the project, and run cdk deploy. The CDK automatically figures out the necessary AWS CloudFormation change set and applies only the changes you’ve made.

For example, you can open the file lib/aws-startup-blueprint-stack.ts and update the DNS construct to use yourcompany.com instead of .corp, as shown here:

new Dns(this,'Dns', {
  ... ,
  TopLevelDomain: "yourcompany.com"
});

To apply that change, build and deploy as you did before:

npm run build && cdk deploy

The CDK automatically creates and applies an AWS CloudFormation change set. This change set creates a new private Route 53 hosted zone, attaches it to all the VPCs, and deletes the previous hosted zone in a few minutes. Updates take less time than the initial deployment because you only update resources that you’ve changed in the code.

Every new account created in AWS comes with a default VPC, such as the one highlighted in Figure 5. This VPC is listed in the VPC console along with the production, management, and development VPCs created by this Quick Start.

DeleteDefaultVPC
Figure 5. Deleting the default VPC

The default VPC has public subnets in every Availability Zone. It is a fundamentally insecure VPC. Do not use it.

If you have a new account and have never launched anything into the default VPC, delete the default VPC and use only the VPCs created by the Quick Start. If you’ve already launched resources into the default VPC, migrate them to the VPCs created by the Quick Start, and then delete the default VPC. By deleting the default VPC, you reduce the chances of a user launching a resource into an exposed public subnet.

Security and compliance

For automatic alerting when resources may have been deployed insecurely, AWS Config conformance packs provide a general-purpose compliance framework. You can use them to create security, operational, or cost-optimization governance checks. You can use managed or custom AWS Config rules and AWS Config remediation actions.

AWS Config conformance packs, as sample templates, do not ensure compliance with any specific governance or compliance standard. You are responsible for making your own assessment as to whether your use of the services meets applicable legal and regulatory requirements.

This Quick Start deploys the following conformance packs:

These conformance packs create AWS Config rules that regularly evaluate resources in your AWS account against security best practices. When AWS Config finds an offending resource, it flags that resource for your review in the AWS Config console. AWS Config also scans resources created in your account before deploying the Quick Start.

For example, the Operational Best Practices for NIST CSF conformance pack comes with 93 rules. One of those rules—encrypted-volumes-conformance-pack, highlighted in Figure 6—checks whether attached Amazon Elastic Block Store (Amazon EBS) volumes are encrypted.

Conformance packs0
Figure 6. Rules listed in the Operational Best Practices for the NIST CSF conformance pack

Choosing the rule encrypted-volumes-conformance-pack on this screen would display details related to that rule, as shown in Figure 7.

Conformance packs1
Figure 7. Details related to the encrypted-volumes rule

You can update the AWS Config delivery channel to include an Amazon Simple Notification Service (Amazon SNS) topic to send email or text notifications when resources are flagged. You might also include more sophisticated approaches: regularly reviewing AWS Config reports, using AWS Config’s automatic remediation capabilities, or integrating AWS Config with security ticketing or security event and incident management (SEIM) practices.

Conformance pack: Operational Best Practices for PCI DSS 3.2.1

While payment card industry (PCI) might not be a concern for every user of this Quick Start, many companies store, transmit, or process payment data. So even if you have no PCI requirements, consider implementing the PCI security conformance pack. This pack has over 140 rules that capture a number of best practices.

If you do have PCI needs, read Operational Best Practices for PCI DSS 3.2.1. For every AWS Config rule included in a conformance pack, there’s a corresponding PCI control ID along with AWS guidance for each check. This conformance pack was validated by AWS Security Assurance Services LLC. This is a team of PCI Qualified Security Assessors (QSAs), HITRUST certified common security framework practitioners (CCSFPs), and compliance professionals who are certified to provide guidance and assessments for various industries.

Other useful information

Where to go from here?

After you are connected to the VPN, you essentially have a private encrypted channel into your new VPCs. You can connect to any resources that you launch into your VPCs using private IP addresses without using insecure (public) bastion hosts.

Figure 8 shows examples of the sorts of resources you might deploy into your VPCs and subnets. If you aren’t sure which VPC or subnets you should deploy resources into, see the FAQ section for guidance and more examples.

Architecture filled out
Figure 8. Fintech Blueprint architecture with example resources deployed

(Optional) Set up DNS

The Quick Start sets up a private DNS with .corp as the default apex domain using Amazon Route 53 in your account. Using the Amazon Route 53 console, you can create private A or CNAME records to any private resources you create.

For example, you may decide to launch a development server that gets a private IP, such as 10.60.0.198. Instead of having to remember that IP, you can create an A record in the .corp Route 53 hosted zone for pauls-machine.corp to the private IP 10.60.0.198. Resources in all three VPCs and clients connected to the AWS Client VPN endpoint then can all resolve pauls-machine.corp from a browser, terminal, API call, etc.

(Optional) Set up permissions for the AWS Service Catalog

You can deploy fintech tools into the Fintech Blueprint environment from the AWS Service Catalog. The AWS Service Catalog requires that you give permissions to individual IAM users, groups, and roles to launch products from an AWS Service Catalog portfolio. To grant that permission, follow these steps:

  1. Navigate to the AWS Service Catalog console.

  2. Choose Fintech Blueprint Software Catalog portfolio.

  3. Choose the Groups, roles, and users tab, as shown in Figure 9.

    scpermission
    Figure 9. Granting permissions to groups, users, and roles
  4. Choose the Add groups, users, and roles button.

  5. Select the IAM users, groups, or roles that you want grant permissions to. If you need permissions, include yourself.

    Anyone you’ve added can visit the products list section of the AWS Service Catalog console, and deploy any of the tools listed. For example, you or another user could deploy the SWIFT Client Connectivity Quick Start, as shown in Figure 10. For details, see the following section of this guide.

    SwiftQS
    Figure 10. SWIFT Client Connectivity Quick Start in the AWS Service Catalog

(Optional) Deploy the SWIFT Client Connectivity Quick Start

The SWIFT Client Connectivity Quick Start is a standardized environment for connecting to the SWIFT network. You can deploy the Quick Start into your AWS account from the AWS Service Catalog (as described in the previous section), from the links on the Quick Start’s webpage, or from the links in its deployment guide.

When you deploy this Quick Start from the AWS Service Catalog, a continuous integration and continuous delivery (CI/CD) pipeline automatically deploys it in about 25 minutes. You can observe the progress in the AWS CodePipeline console, as shown in Figure 11.

SwiftQSCodePipeline
Figure 11. Deploying the SWIFT Client Connectivity Quick Start through AWS Service Catalog

(Optional) Restrict IAM actions to specific AWS Regions

You can restrict IAM actions to EU or US AWS Regions. For example, you may want to restrict the creation of Amazon Elastic Compute Cloud (Amazon EC2) instances or S3 buckets to only European Regions. You might do this for compliance reasons or because it’s a good practice to keep resources out of Regions that you don’t intend to use.

If you have a single AWS account, enforce AWS Region restrictions by creating permissions boundaries for IAM entities. Permissions boundaries restrict IAM actions to the AWS Regions that you specify. To create permissions boundaries, configure the RegionRestriction class in lib/aws-startup-blueprint-stack.ts. Example:

      new RegionRestriction(this, 'RegionRestriction', {
        AllowedRegions: ["eu-central-1","eu-west-1","eu-west-3", "eu-south-1", "eu-north-1"]
      });

The cdk.json file contains the helper context variables apply_EU_RegionRestriction and apply_US_RegionRestriction. To apply the Region restriction, set one of those variables to true, and run cdk deploy again.

For a permissions boundary to have any effect, it must be attached to all existing and future IAM users and roles. Therefore, the RegionRestriction class creates an AWS Config rule to detect and remediate any missing IAM permissions boundaries. To use this rule, navigate to the AWS Config console, and choose the AwsFintechBlueprint-RegionRestriction rule, as shown in Figure 12.

RegionRestriction
Figure 12. Region restriction rule

This AWS Config rule evaluates your IAM users and roles and lists their compliance status. To remediate a noncompliant resource, select the resource and choose Remediate, shown in Figure 13. The service control policy is applied, and that user or role can no longer perform any action outside of the specified Region.

RegionRestrictionRemediation
Figure 13. Remediating the user’s permissions to the desired Regions

After the remediation is complete, AWS CloudTrail invokes the AWS Config rule. CloudTrail tells AWS Config that the IAM principal has been updated and that it’s time to re-evaluate the resource. This takes about 15 minutes. Because the boundary has been applied, the re-evaluation reports the role or user as compliant.

Enable automatic remediation

Enabling automatic remediation impacts existing IAM users and roles that were not created by the Quick Start.

This Quick Start sets the remediation configuration to Manual instead of Automatic in case you have existing IAM users or roles. Automatically applying the remediation and attaching the permissions boundaries has an impact on existing IAM principals' permissions. Before applying the boundary, verify whether any of the flagged IAM principals depend on any nonapproved Regions. If you are working in a new account or are unconcerned about the impact on existing IAM principals, you can turn on automatic remediation as follows:

  1. In the AWS Config console, go to the Remediation action section of the AwsFintechBlueprint-RegionRestriction AWS Config rule.

  2. Choose Edit, as shown in Figure 14:

    RegionRestrictionRemediationEditAuto
    Figure 14. Editing the remediation action
  3. Choose Automatic remediation.

  4. Choose Save changes.

Restrict the AWS Region in multi-account configurations

In a multi-account setup, service control polices (SCPs) are superior to permissions boundaries. SCPs are applied across an entire account and do not need to be individually attached to IAM principals. However, if you have only one account, use permissions boundaries to restrict Regions, as discussed earlier. SCPs apply only to subaccounts. When you create a new account, the Region-restricting SCP created in this architecture will be applied automatically to any new account you create.

For more information, see the service control policies in the IAM console, as shown in Figure 15.

SCP
Figure 15. The service control policy that restricts actions in subaccounts when you create them

FAQ

Q. Which VPC and subnet should I deploy resources into?

A. Think of VPCs as houses and the subnets as rooms. When you deploy a VPC-aware resource—such as an Application Load Balancer, EC2 instance, or Amazon Relational Database Service (Amazon RDS) database—choose the house first and then the room.

  • VPC ("house"): If the resource is for production or development purposes, use the production or development VPC. With separate production and development VPCs, you can manage the environments with different levels of controls and restrictions. Use the management VPC only for more operational resources, such as a DevOps tool, Active Directory, or a security appliance. For example, the Fintech Blueprint Quick Start deploys the AWS Client VPN endpoint into the management VPC.

  • Subnet ("room"): If the resource must be publicly addressable by the internet at large, specify the public subnet. This should be only things like AWS Application Load Balancers. If you deploy an application server or other resource that needs outbound internet access but should not directly face the internet—perhaps it sits behind an Application Load Balancer—specify the private subnet. If you deploy a sensitive resource, such as a database that should be addressable only by your internal networks and needs no outbound internet access, use the isolated subnets.

Q. What are some examples of things I might launch and where they should go?

A. Here are some common situations that you might find yourself in:

  • Do you need a server to test installing an application on your own or to show a coworker?

    • Development VPC, private subnet

  • Are you restoring an Amazon RDS snapshot in development into production?

    • Production VPC, isolated subnet

  • Are you launching an Application Load Balancer to try installing a custom TLS certificate?

    • Development VPC, public subnet

  • Are you standing up a DevOps tool, such as Jenkins, to automate deployments into production and development?

    • Management VPC, private subnet

  • Are you standing up an Okta Cloud Connect appliance or Active Directory?

    • Management VPC, private subnet

See Figure 8 for a visual example of deployed resources.

Q. Why are there two subnets of the same class in each VPC?

A. This is a requirement for high availability. Each subnet of the same class is in a different Availability Zone: a physically distinct data center. If there’s an Availability Zone outage, having a subnet in another Availability Zone allows your service or AWS services to fail over. For example, AWS Auto Scaling, Amazon RDS, and the AWS Client VPN endpoint all take advantage of Multi-AZ capability for clean failover if there’s a physical disaster. Except for being in different Availability Zones, the subnets of the same class are identical from a networking perspective; it doesn’t matter which one you choose.

Q. I encountered a CREATE_FAILED error when I launched the Quick Start.

A. If AWS CloudFormation fails to create the stack, the AWS CDK reports the issue for additional troubleshooting. If the CDK is unable to clean up the resources, go the AWS CloudFormation console where you can inspect the event log or manually delete any stacks that were created.

When you set Rollback on failure to Disabled, you continue to incur AWS charges for this stack. Delete the stack when you finish troubleshooting.

For more information, see Troubleshooting AWS CloudFormation.

Q. I encountered a size-limitation error when I deployed the AWS CloudFormation templates.

A. Launch the Quick Start templates from the links in this guide or from another S3 bucket. If you deploy the templates from a local copy on your computer or from a location other than an S3 bucket, you might encounter template-size limitations. For more information, see AWS CloudFormation quotas.

Customer responsibility

After you successfully deploy this Quick Start, confirm that your resources and services are updated and configured — including any required patches — to meet your security and other needs. For more information, see the AWS Shared Responsibility Model.

Send us feedback

To post feedback, submit feature ideas, or report bugs, use the Issues section of the GitHub repository for this Quick Start. To submit code, see the Quick Start Contributor’s Guide.

Quick Start reference deployments

GitHub repository

Visit our GitHub repository to download the templates and scripts for this Quick Start, to post your comments, and to share your customizations with others.


Notices

This document is provided for informational purposes only. It represents AWS’s current product offerings and practices as of the date of issue of this document, which are subject to change without notice. Customers are responsible for making their own independent assessment of the information in this document and any use of AWS’s products or services, each of which is provided “as is” without warranty of any kind, whether expressed or implied. This document does not create any warranties, representations, contractual commitments, conditions, or assurances from AWS, its affiliates, suppliers, or licensors. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers.

The software included with this paper is licensed under the Apache License, version 2.0 (the "License"). You may not use this file except in compliance with the License. A copy of the License is located at http://aws.amazon.com/apache2.0/ or in the accompanying "license" file. This code is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either expressed or implied. See the License for specific language governing permissions and limitations.