Ava Infrastructure

Name Server

To improve security, each customer has their own dedicated Hosted Zone in Route 53 to respond to DNS queries. Typically, a customer chooses a subdomain of ava.app (e.g. acme.ava.app) and we add a corresponding NS record in the hosted zone for ava.app. Alternatively customers can choose a custom domain name, or a subdomain of their existing domain.

To minimize costs, Ava uses round-robin DNS to load balance between application servers.

Content Delivery Network

Each customer has their own CloudFront that serves Ava's static assets (e.g. JavaScript bundles, audio recodings, images, etc) to improve performance.

Virtual Private Cloud

Each of our customers has their own copy of Ava, deployed into a dedicated virtual private cloud within a dedicated Amazon Web Services account.

Internet Gateway

Within the virtual private cloud there is an internet gateway through which all communication with the internet flows.

Public Subnet

Within the virtual private cloud there is a subnet intended for the application servers. This subnet is public-facing (i.e. there is a 0.0.0.0/0 route to the internet gateway) so that the application servers can communicate with the internet.

Server Firewall

Within the public subnet there is a virtual firewall (a.k.a. security group) for the application servers, which only allows incoming internet traffic on the ports we expect.

Auto-scaling Group

Behind the server firewall is an auto scaling group that enables horizontally scaling.

This means that new application servers are automatically created or destroyed as the resource demand changes. The main sources of resource demand in Ava are the number of ongoing phone calls and the number of employees using the application (e.g. searching contacts, viewing profiles, composing emails, etc).

Application Server

The servers which run Ava are ephemeral, immutable EC2 instances. These instances are created from a disk image (a.k.a. AMI) build using Packer. The image is based on Amazon Linux and includes a fat JAR file with the latest version of Ava as well as its dependencies (i.e. Amazon Corretto, Certbot, ClamAV) and a few debugging tools. This is what is known as immutable infrastructure.

Private Subnet

The private subnet is for the database server and can only communicate with the application servers It has no internet connectivity whatsoever, for the following security reasons:

Database Firewall

In addition to residing inside the private subnet, the database server is further protected by a a virtual firewall (a.k.a. security group) that blocks all network traffic that did not originate from an application server and/or is not destined for port 5432, the port on which PostgreSQL is listening.

Database

Each customer has a dedicated, PostgreSQL database server using Amazon's Relational Database Service.

File Storage

Each customer has their own private, encrypted file storage (a.k.a. an S3 bucket) to house their emails, voicemails and phone call recordings. This bucket is configured so that only the application servers are allowed to read the files or add new files.

Internet Telephony Service Provider

Each customer's application servers communicate with a third-party internet telephony service provider through the internet gateway. Ava can work with any provider that supports SIP and RTP. If our customer does not already have a provider, we will select and configure one on their behalf, weighing the following criteria based on our understanding of their priorities:

  1. An excellent service level agreement with respect to reliability
  2. Support for sending text messages via RFC 3428
  3. Support for encryption of audio communication via SRTP
  4. Support for encryption of signalling via TLS
  5. A point of presence server close to the customer's environment with respect to audio latency.

Email Provider

Each customer's application servers communicate with a third-party email provider through the internet gateway. Ava can work with any provider that supports IMAP and SMTP, which is virtually all of them — Gmail, Office 365, etc — with the odd exception like ProtonMail.

It's fairly typical for our customers to already have an email provider, though we will select and configure one on their behalf if they do not.