Prospective customers for AWS ISV partners expect a representative hands-on demo environment to evaluate the solution prior to a purchase. Yet, to give customers access to intellectual property without a contract in place poses a commercial risk to SaaS vendors. In this blog, we demonstrate how Global Valuation leverages Amazon AppStream 2.0, Amazon VPC, AWS Network Firewall, and Amazon EFS to provide customers full functionality.

Financial risk modelling by Global Valuation

At Global Valuation, our team has a novel approach to create and run pricing and risk models required by financial services institutions. Global Valuation’s Esther, a unique vectorizing solution, allows quant teams to develop pricing and risk models that automatically translate into tensor algebra allowing large and complex models to execute efficiently over large multi-asset portfolios.

Walkthrough

Problem statement and context

The Global Valuation solution comprises two main components:

• Esther Server – The Visual Studio Code Server component which requires EC2 instances with GPUs. This is the “universal solver” to start models defined in the client-side IDE. The Esther server requires a GPU with large-memory EC2 instance. One server is shared by many client-side model developers. During model development, it acts as a remote compiler over SSH to the client IDE.
• Code IDE UI – A Visual Studio Code IDE which acts as the user interface for developers wanting to interact with Esther. This is hosted on AppStream 2.0 and Code IDE UI is accessed by the user once logged into the Esther user portal.

In addition, the solution requires:

• Access to a shared file system among all AppStream 2.0 users.
• A secured and inspected connectivity path to the externally hosted Global Valuation code repository from the environment.

To host their Esther development environment, Global Valuation needs a secure and isolated solution that must:

1. Inhibit exfiltration of files out of the demo environment allowed-list
2. Allow access to explicitly allow-listed destinations on the Internet
3. Support upload of their customer’s proprietary data sets
4. Feature a consistently branded experience without exposing users to the AWS console

Secure isolated sandbox with Amazon AppStream 2.0

Initially, Global Valuation sought to engage AWS prototyping to demonstrate the integration of a third-party developer IDE that runs on Amazon Elastic Kubernetes Service (EKS). During our initial requirement workshops AWS architects brought Amazon AppStream 2.0 to our intention as an alternative. It became apparent that such a solution reduces both complexity and operational overheads. As an ISV, our team want to focused on improving our software product instead of thinking about infrastructure.

Isolation of GlobalValuation’s intellectual property

AppStream 2.0, compute instances are organized into fleets. These instances use a Linux-based image. First, using the AppStream 2.0 image builder, we create a custom image that includes the IDE and tooling to work with Esther. We deploy both an AppStream 2.0 fleet with this image and the Esther server into their own dedicated sets of private subnets. Traffic between these subnets is restricted to SSH access from the IDE to the server only, and the users may only use our own, restricted, “.esh” shell.

This way the server, with the proprietary Global Valuation IP, is only accessible indirectly by our customers. Thanks to AppStream 2.0’s ability to restrict client’s download and clipboard access we can further restrict users’ ability to take information out of the environment.

Selective external communications

In order to filter allowed traffic in the VPC, an AWS Network Firewall protects the public subnets. The Network Firewall only allows outbound traffic to a list of explicitly approved domains such as URLs to specific GitLab repositories whose domains are allow-listed in the AWS Network Firewall; all Inbound traffic into the VPC is denied. As a result, the Esther environment is able to download source code from the Global Valuation git repository, yet users can’t push data to arbitrary locations on the Internet.

Brand consistent access to the environment

Our users access the environment from the convenience of their browser thanks to Amazon AppStream 2.0’s Streaming URL feature. Our solution includes a company branded Single Page App (SPA) that fronts a secure and serverless streaming URL generation API. We choose to authenticate access to this component with Amazon Cognito User Pools, but this solution can integrate with any other OAuth 2.0 compatible IDPs.

Secure developer collaboration

Our customer’s developers need to share files between them, and therefore we needed a shared file system. The below section explains why and how we use Amazon Elastic File System (EFS) and how we manage to integrate it with Amazon AppStream 2.0 fleets.

The following diagram shows the conceptual architecture of Esther on AWS.

Figure 1: Esther sandpit system architecture

How to integrate EFS mounts with AppStream 2.0 fleets

We chose Amazon EFS as a simple, serverless, pay-as-you-go, set-and-forget, elastic file system. However, for security reasons AppStream 2.0 does not allow users to “mount” additional directories at run-time, and therefore we had to get creative. We achieve our goal by performing the mount operation with AppStream 2.0 session scripts. These scripts allow administrators to schedule execution of custom scripts before a user session starts, and operate within a permission context that is able to mount drives.

The steps to mount EFS on AppStream 2.0 are:

1. Launch an Amazon Linux 2 Image Builder instance
2. Log into the Image Builder and navigate to /opt/appstream/SessionScript directory
3. In that directory, create a bash script efs-mount.shwith the same content as the file in the repository that accompanies the blog post:
   1. Replace placeholder file system ID and region with values appropriate to the environment
   2. Prefix the mount command with sudo

#!/bin/bash
sudo mkdir /efs
sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport FILE_SYSTEM.efs.AWS-REGION.amazonaws.com:/ /efs

4. Give run permissions on the script to the AppStream 2.0 instance using sudo chmod +x efs-mount.sh
5. Replace the json file, in SessionScripts, with the one provided. This file specifies that the bash script will run when the AppStream 2.0 session starts

{
  "SessionStart": {
    "Executables": [
       {
         "Context": "system",
         "Filename": "/opt/appstream/SessionScripts/efs-mount.sh",
         "Arguments": "",
         "S3LogEnabled": true
      }
    ],
    "WaitingTime": 30
  }
}

6. Create another image using sudo AppStreamImageAssistant create-image --name YOUR_IMAGE_NAME. Replace the name you want to give to the image in the command

Deploy the customized sandbox solution in your AWS account

Customers can deploy their own instance of this secure sandbox architecture and integrate their own software into the Amazon AppStream 2.0 fleet. See this GitHub repository for comprehensive documentation and deployment instructions on how to do this.

Conclusion

We have seen how to securely provide customers with a demo environment for our software using Amazon AppStream 2.0 in a secure and isolated AWS environment. We are able to run Esther’s proprietary code on AWS EC2 GPU instances, while our customers can only interact with Esther through the IDE.

We also wanted to reflect on the fact that working with AWS, we were able to build a solution, that satisfies all our requirements, in just 6 weeks compared to the original estimate of 3 months for the Kubernetes approach. In addition, instead of having to deploy, manage, and pay for a third-party IDE solution on Kubernetes, we leverage AWS managed services that reduce both our operational overheads and licensing costs. This solution has enabled us to start trials with our large financial services customers.

Looking to the future

Given the scalability of the Esther solution, we expect large clients to prefer a more custom deployment approach to meet their specific architectural standards. AWS infrastructure provides the necessary capabilities to deploy Esther in numerous configurations in a scalable and resilient manner. Once a client purchases a software license, we will help the client to deploy a customized deployment in their AWS Account.

	Claudio Albanese is the founder of Global Valuation. Claudio was tenured Professor of Mathematics at the University of Toronto and Chaired Professor of Mathematical Finance at Imperial College London. In 2006, Claudio founded Global Valuation with the purpose of developing a new generation risk analytics platform. ​ Claudio’s research work in Finance includes over 25 publications in prestigious peer reviewed journals on topics related to counterparty credit risk, capital & funding reserve management, stress testing, model risk, collateral, pricing theory and numerical analysis for risk & pricing. ​Claudio has a PhD in Theoretical Physics from ETH Zurich.
	Petri Arola is the CTO of Global Valuation.  Petri was a co-founder of Delta Capita Group in 2011, where Petri was Group CTO and CIO of the CLM business line. Responsible for the technology strategy across the group and the delivery of CLM and data platforms for managed services and consulting engagements.​ Petri spent his earlier career in business and technology advisory & solutions delivery, working for Accenture and Detica. Petri was a senior technology advisor for numerous commercial and investment banks. His focus is in front office trading and data solutions, as well as middle office and risk management.​ Petri has a M.Sc.(Econ) from the Aalto School of Business  in Helsinki.
	Claudiu Bota is a Solutions Architect at Amazon Web Services based in Madrid, Spain. His main areas of interest are containers and microservices, and more specifically, how they can solve customers’ problems. Outside of work, Claudiu enjoys travel and chess.
	Severin “Sev” Gassauer-Fleissner is a Principal Solutions Architect at Amazon Web Services currently working as the FSI Prototyping and Cloud Engineering (PACE) lead for APJ. Sev’s team helps customers prototype and prove out architectures on AWS. Sev is passionate about distributed systems, building and understanding how things work. In his spare time, Sev enjoys tinkering with technology, cycling through Singapore, and reading.