AWS Self Hosting

This section explains how to setup and create resources for self-hosting zerve using the AWS CloudFormation template. It is the widely followed and recommended workflow as it creates and configures the AWS resources automatically.

Zerve is deployed across multiple Availability Zones in a single AWS Region of your choice. Zerve's control plane services are hosted in the eu-west-1 region however we support installation in most standard AWS regions, for more information please contact support.

As part of our self-hosting integration, an AWS S3 Bucket is created and this is then used to store all data for your organisation going forward. This bucket will be named following the format "canvas-state-bucket-{UUID}" where that UUID is the ID of your organisation within Zerve. Zerve uses AWS's default server-side encryption configuration when creating this bucket.

AWS CloudFormation is a provisioning and configuration service that can ease AWS access and configuration. Zerve offers a CloudFormation template to help automate the steps to provision Zerve access to your AWS cloud storage buckets. Zerve takes roughly 10-15 minutes to deploy using Cloudformation.

Network Configuration

As part of our setup process using CloudFormation for self-hosting, Zerve creates a VPC within which your resources will run while using Zerve. This VPC contains two subnets, each assigned to a different AZ for redundancy. An Internet Gateway is created to provide outbound access for your resources and NAT Gateways are created within each availability zone. Two security groups are also created, one private security group which does not provide any ingress and a second security group which provides public access and is used for load balancers that are created as part of Zerve deployments.

The networking for a Zerve deployment is created as part of the CloudFormation during the deployment and more information can be found in this template.

IAM and Permissions

As part of Zerve's deployment, Zerve creates a role and set of policies which allow Zerve to manage resources on your behalf in your account. When designing these policies, Zerve follows a principle of "least privileged access". These policies are limited in scope so that Zerve can only manage resources that are relevant to Zerve, in order to allow this application to be safely installed alongside other workloads in your account. In general, this is achieved by only allowing Zerve access to list, create or manage resources which match a name of zerve-*, or in other words resources where the name of that resource begins with zerve-* . For the purposes of networking changes, Zerve's permissions are limited to only apply within the VPC created as part of the installation of the Zerve cloudformation. The role which is created as part of this process is limited to only be assumable by a specific role in Zerve's account.

Costs and Billing

Static Costs

Outside of your enterprise Zerve subscription, there are some static costs associated with the deployment of Zerve inside your account. These are specifically related to the initial networking setup and the costs to host the NAT Gateways in this account. Outside of these costs, the cost of the deployment of Zerve will scale with your own usage.

Variable Costs

Costs incurred while using Zerve to execute code in your account are billed to that account. These are the AWS service costs themselves, Zerve does not bill based on usage or impose any extra billing costs based on your usage. The costs of usage are primarily driven by your own usage of the Zerve platform and can be influenced by the configuration of resources used when using the Zerve platform.

AWS Services Used by Zerve

While using the Zerve platform, dependent on your usage, there are a number of services from which you may be billed. The following is a list of services (under the name for which they would be listed on any AWS Bill) from which you may be billed by Zerve while using the Zerve platform:

• Elastic Cloud Compute

• Elastic Container Service

• Elastic Load Balancing

• Virtual Private Cloud

• EC2 Container Registry (ECR)

• SageMaker

• Relational Database Service

• Lambda

• CodeBuild

• Simple Storage Service

• Data Transfer

• Route 53

• CloudWatch

• Bedrock

• API Gateway

• Key Management Service

• CloudFormation

If you make use of Zerve's AWS Bedrock integration to use 3rd party models provided by Bedrock, you may also be billed by those models via AWS Marketplace

API Key:

Before setting up self-hosting with AWS cloud formation we need Zerve developer API for permissions. This can be generated under Settings -> Developer API.

Make sure to save it securely and not share it publicly - This will not be displayed again.

Use AWS Template to create self-hosted Zerve organization:

Once an API Key is generated, follow the steps below to use AWS Cloud formation.

• In your Zerve Organization, select the "Self Hosting" tab to open the AWS QuickStart template. This will open CloudFormation in AWS, which may prompt you to log in to your account.

• Most Parameters on this page will be pre-populated for you, you will need to provide your API Key and also set the domain name for any deployments which will happen in this account. More information on these parameters is outlined below

• Once you have filled out parameters you can proceed through this process by click Next, Next and then you can submit

• AWS CloudFormation will then provision the required resources to run Zerve in your account.

Template Description:

Template Parameters:

Data Collection:

Zerve collects the following data for operational purposes in self-hosting segment.

1. Account ID The ID of the AWS account where Zerve is installed

2. Role ARN The ARN of a role which Zerve will assume in the account when necessary

3. Hosted Zone ID The ID of a Route53 Hosted Zone which is used for the DNS for deployments made via Zerve. This will be in the format *.zerve.cloud

4. Hosted Zone Name The name of the hosted zone for this organization in the AWS account

5. Region

   AWS region where the stack is deployed. Zerve currently only supports the eu-west-1 region in AWS

6. S3 Bucket Name

   The Canvas State Bucket name. The primary storage medium for storing states such as block execution outputs that are charts or images.

7. VPC ID

   The ID of the VPC created by CloudFormation

8. Public Subnet ID 1

   The first of two Public Subnets which is used for hosting loadbalancers and API Gateways.

9. Public Subnet ID 2 The second of two Public Subnets which is used for hosting loadbalancers and API Gateways.

10. Private Subnet ID 1 The first of two private subnets, which is where code execution and other non-internet accessible workloads will run.

11. Private Subnet ID 2 The first of two private subnets, which is where code execution and other non-internet accessible workloads will run.

12. Security Group ID

    A Security Group which is created in the account, allowing outbound access for workloads and will be assigned to workloads when they execute.

13. Public Security Group ID A public Security Group which is created in the account, allowing both outbound and inbound access and will be used for internet accessible resources such as APIs and NAT Gateways

14. ACM Certificate ARN The ARN of an ACM Certificate which is used to encrypt traffic to deployments

15. NAT Gateway IP Address The IP address of a NAT Gateway created in the VPC

Data Storage Methodology

Zerve does not store any of the above-listed data in the state bucket or databases. Zerve stores customer AWS account data in an encrypted vault, and this information is only retrieved during execution.

Self-Hosting Support

For any questions or assistance with using or maintaining the Zerve platform, please contact us at [email protected]

System Updates

Cloudformation Updates

Zerve may in future update or change its Cloudformation template in order to provide enhancements to features or the security of your Zerve installation. These updates can be applied by updating the Cloudformation stack which is installed in your account. If this is required, Zerve will notify your organization administrators with the steps required, and provide any assistance necessary.

Executor Updates

The default executors which are built and deployed in your account can be rebuilt and updated at any time by following these steps:

1. Go to the Self-Hosting settings page of your organisation

2. Navigate to the Status section of this page

3. Click "Re-Deploy"

4. This will re-deploy the default executors for the account, which takes roughly 5 minutes

Testing & Troubleshooting

Once the CloudFormation stack has been created you can view the status of the Zerve default executors from your organisation's Self-Hosting settings page. You should be immediately able to create a Canvas and execute Python code from within your organisation. If you have any difficulties doing this, please let us know.

Execution Errors

If at any time there are issues with the executing code on a Zerve canvas, the following steps can be taken to attempt to recover:

1. If the Canvas has no built requirements (and is therefore using the default executor for the account)

   1. Go to the Self-Hosting settings page of your organisation

   2. Navigate to the Status section of this page

   3. Click "Re-Deploy"

   4. This will re-deploy the default executors for the account, which takes roughly 5 minutes

   5. Attempt to re-run any blocks that were previously affected by this problem

   6. If problems persist, please contact Zerve Support

2. If the Canvas has had requirements built (and is therefore not using the default executor for the account)

   1. Go to the Requirements Section of the affected canvas

   2. Click Build to rebuild the executor for this canvas.

   3. Once this build process has completed, attempt to re-run any blocks that were previously affected by this problem

   4. You can view the logs of a custom executor for the Canvas by selecting "Canvas Executor Logs" in the bottom right of the screen at any time to view any potential errors.

   5. If problems persist, please contact Zerve Support

Recovering S3

If the S3 bucket where Zerve's state is stored is deleted for any reason, this can be recreated as an empty bucket by re-deploying the cloudformation template above. Please reach out to Zerve support for help with this.