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.
Each of our customers has their own copy of Ava, deployed into a dedicated virtual private cloud within a dedicated Amazon Web Services account.
Within the virtual private cloud there is an internet gateway through which all communication with the internet flows.
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.
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.
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).
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 is for the database server and can only communicate with the application servers It has no internet connectivity whatsoever, for the following security reasons:
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.
Each customer has a dedicated, PostgreSQL database server using Amazon's Relational Database Service.
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.
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:
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.