Run Managed Scylla Cloud Clusters on AWS Outposts¶
Scylla Cloud is a fully managed Database-As-A-Service (DBaaS) solution, based on Scylla Enterprise, ideal for workloads that require low latency and high throughput.
AWS Outposts is a fully managed service that extends AWS infrastructure to an on-premises facility. AWS Outposts is ideal for workloads that require low latency access to on-premises systems, local data processing, or local data storage.
You can install and run Scylla Enterprise or Open source on AWS Outposts servers, in the same manner as on-prem servers.
Also, you can run fully-managed Scylla Cloud clusters, on AWS Outposts as well, including both Amazon DynamoDB compatible API (Scylla Alternator) and the Apache Cassandra CQL API (Scylla). This is the first time the DynamoDB API is available on AWS Outposts.
As Outposts are attached to a customer’s AWS account, Scylla Cloud leverages Scylla on your own AWS account. to enable this service. To run Scylla Cloud on AWS Outposts, file a Ticket with Scylla Support.
AWS Outposts follows a similar procedure to Scylla Cloud on your account (SCYA):
Validate Resources - Validate that resources are available
Collect Information - Provide your AWS account number and AWS Outpost number
Grant Permissions - Grant Scylla Cloud permissions to allow it to create and run Scylla Clusters
Scylla Cloud uses AWS resources, like EC2 instances and VPCs, to launch and manage Scylla Clusters, Monitoring and Manager servers, etc. As Outpost resources are limited compared to that of a public region, extra care needs to be taken to make sure the resources are available before launching a cluster.
3 x I3 / I3en instances for Scylla cluster
1 x m5 servers for Scylla Manager
1 x m5 servers for Scylla Monitoring stack
AWS Outposts racks need to include physical I3en servers. It is up to the Outposts administrator to slice (carve) the servers to smaller, virtual, I3 servers to be used by Scylla, and other applications. The same is true for Monitoring and Manager servers.
For a full list of AWS minimal requirements, including VPC, VPC EIPs and more see AWS Account Limits
You can check available EC2 instances from your Outpost console View Instance Types menu (as shown)
Or using the AWS API or AWS CLI tool, for example:
aws --region us-west-2 outposts get-outposts-instance-type --outpost-id op-0268f767a3066b
Refer to AWS docs get-outpost-instance-types for more information.
To enable Scylla Cloud for your account and Outpost, you need to collect the following information:
Once the information elements are provided, you are asked to grant permission to Scylla Cloud on your AWS account. The permissions are the minimal set of Credentials allowing Scylla Cloud to manage your cluster, including adding and removing nodes, replacing nodes, and managing VPCs and network resources required to manage Scylla Cloud. Refer to AWS Credentials for more information.
Scylla Cloud Support Team will provide you all the relevant permissions as JSON Security Rules files, customized with your account number. Once received, you need to review and apply them.
Once all steps above are completed, you can launch a Scylla Cloud Cluster on your AWS Outposts. Monitoring and working with Scylla Cloud on AWS Outposts is the same as running it on a public region.
Multi Data Center: Similar to any Scylla Cloud deployment, you can add a Data Center to a Scylla Cluster, either in another Outpost or in a public region.
Backups: S3 is not yet available one AWS Outpost, so backups will be done to the associated region S3 bucket. As a result, the backup takes longer and requires cross-region traffic and associated cost.
All Scylla Cloud features like VPC peering and metrics export are available on Scylla Cloud on AWS Outpost as well.
When running Scylla Cloud on AWS Outposts, the data is stored on your server, running in its local Outposts system. Scylla Cloud does not copy or hold any part of the data on a remote server. You can replicate the data to a remote AWS region (multi Data Center), or backup it to a remote S3 bucket if you choose to, as long all are under the same AWS account and are under your full control.