AWS Overview

Amazon Web Services, AWS, uses a lot of acronyms and codenames for different services that can be confusing when being new to the service. The list below gives a quick summary of the services we use and discuss in the wiki for the Relativity Server in the Cloud feature.

Services

  • EC2, short for Elastic Cloud Computing, lets you run virtual machines, essentially full virtual server computers to run your software on. We use it to run Relativity Server. EC2 instances should be treated as "discardable" and a well-designed system will not store any data on them.
  • S3, short for Simple Storage Service, lets you create "buckets" where you can store data safely and reliably. Data stored in S3 can be publicly available or private to yourself, and S3 includes data safety guarantees and redundancy so that you can (within reason) rely on data in S3 not being lost due to hardware failures. We use S3, among other things, to store Relativity server configurations.
  • RDS, short for Relational Database Service, is a way to host databases such as Microsoft SQL Server, Oracle, MySQL or PostgreSQL on AWS, without maintaining EC2 machines to host database engine yourself. RDS supports automatic data replication and failover to backup servers, as well as automatic backups to S3.
  • DynamoDB is a no-SQL database system with built-in data protection across availability zones. Relativity server can (optionally) use DynamoDB as a distributed [Session Manager](Session Management-LINK NEEDED).
  • IAM, short for Identity and Access Management, is AWS's portal for managing users and access to other AWS services.
  • AMI, short for AWS Machine Image, is the name for a pre-configured image that can be used to boot up EC2 instances. We provide a ready-configured AMI with Relativity Server that only needs to be booted up and is ready to work, without any additional installation of Relativity server or prerequisites (see Setting up Relativity Server on AWS).

Reliability

Of the services used and described above, only S3 and DynamoDB support built-in failover support and data redundancy. Data stored in these two services will automatically be replicated by Amazon across different availability zones, so it is reasonable to expect that – short of Amazon losing not just one data center but an entire region – data stored in these systems will be save against hardware failure.

That said, of course it is always sensible to have backups of your critical business data in a different region, or possibly even with a provider that is not Amazon and not using Amazon's services. For the purpose of hosting Relativity Server in the Cloud on AWS, this data includes your Relativity Server config in the S3 bucket, as well as any RDS database backups stored in S3. Session data stored in DynamoDB will generally not be critical enough to warrant a backup strategy aside from the reliability built into DynamoDB itself.

RDS does not provide built-in data redundancy for single instances, but it allows the setup of automatic data replication between RDS instances, even between different availability zones, and it does allow for automatic and transparent failover from primary to secondary servers when an RDS server fails (which it will). For high availability services, we recommend checking these features out on Amazon's side. Relativity Server will work with them seamlessly, when set up properly. You can (and should) also set up RDS to automatically create backups onto S3.

EC2 instances provide no redundancy or failover support on their own. If physical hardware running your EC2 instance fails (and it will), your EC2 instance will die and any data stored on it along with it. That's not a problem, because EC2 ,and Relativity Server's support for EC2, is built around the assumption that EC2 instances are intrinsically discardable. No data or configuration is stored in EC2 instances (when using the [Relativity server in the Cloud]] deployment model), and instances can be killed and restarted at will without data loss (aside, of course, from an interruption to currently active network connections from clients to that instance).

It warrants repeating that both EC2 and RDS instances should be expected to fail as part of normal operation, that's plainly a question of probabilities. You will be running multiple, or even dozens of instances, 24 hours, 7 days, year round – eventually a hard disk or other hardware *will* fail. A highly available system should be designed to cope with such failures as part of normal operation.

AWS provides a lot of options for load balancing and failover support for EC2 that will work with Relativity Server in the Cloud; this ranges from creating and destroying additional instances as demand for services increases and decreases, to detecting stalled instances and killing/restarting them. The system is very flexible and powerful, and it is all provided by AWS out of the box and can be leveraged by Relativity Server in the Cloud by default.

In general, AWS allows you to build highly scalable and highly available systems, when properly configured. All of this configuration is done AWS-side and Relativity Server in the Cloud just benefits from it "for free" by nature of being designed around these concepts.

We highly recommend reviewing the documentation available from Amazon to learn more about configuring EC2, RDS and Amazon's remaining services for high reliability.