Load Balanced

Posit Connect can be configured to run on AWS in a load balanced, high availability (HA) cluster configuration. This architecture is designed to provide high availability and fault tolerance for Connect, ensuring that the service remains available even in the event of a failure.

This architecture is best used when at least one of the following apply:

Architectural overview

This implementation of Posit Connect utilizes a High Availability configuration and includes the following components:

Architecture diagram

Architecture Diagram

Nodes

This architecture utilizes a high availability configuration with two EC2 instances running Posit Connect. During our performance tests, we used two t3.large instances running Ubuntu 22.04.

The EC2 instances in an HA configuration require the following configuration:

  • Matching versions of Posit Connect.
  • Shared configuration file for every node.
  • All the necessary versions of Python, R, and Quarto.

For detailed instructions on setting up this configuration, refer to the HA checklist in the Connect Admin Guide: HA Checklist.

Database

This architecture utilizes an RDS instance with PostgreSQL running on a db.m5.large instance, provisioned with a minumum of 15 GB of storage and running the latest minor version of PostgreSQL 15 (see supported versions). Both the instance type and the storage can be scaled up for more demanding workloads.

  • The RDS instance should be configured with an empty PostgreSQL database for the Connect metadata.

Shared file storage

This architecture utilizes an encrypted AWS Elastic File System (EFS). EFS does not require initial sizing as it autoscales with usage.

Load balancer

This architecture utilizes an AWS Application Load Balancer (ALB) in order to provide public ingress and load balancing to the Connect instances.

Networking

The architecture is implemented in a VPC, utilizing both public and private subnets across multiple availability zones. This setup ensures high availability and fault tolerance for all deployed resources. The RDS database instance, EFS mount targets, and the EC2 instances are located within the private subnets and ingress to these resources is managed through an ALB.

Resiliency and availability

This implementation of Connect is resilient to within-AZ failures. With two nodes of Connect, a failure in either node results in disruption to user sessions on the failed node, but does not result in overall service downtime.

We recommend using proper backup and disaster recovery procedures with the RDS and EFS instances of the cluster.

Performance

The Connect team conducts smoke and performance testing on this architecture. During our testing, we published a Python-based FastAPI and a R-based Plumber application (using jumpstart examples included in the product) to Connect, simulating a load of 1000 concurrent users.

Based on our performance test results, the system’s response times meet acceptable criteria for the majority of users. The system was able to handle the load without any issues, and the response times were within acceptable limits.

These tests demonstrate the capability of Connect to manage and serve applications to users. However, it is important to note that the computational footprint of the content used in testing was minimal. For most Connect installations, the majority of computational power is dedicated to the Python and R content that publisher-users deploy, rather than Connect itself. If your team is deploying lightweight apps, APIs, and jobs to Connect, our testing results are likely to be applicable. However, if your team is deploying APIs or apps that involve heavy-duty data processing, machine learning, or other computationally intensive tasks, you may need larger or more compute optimized EC2 instances, but upgrading other architecture components may not be necessary.