Amazon EC2 Capacity Planning
For the complete documentation index see: llms.txt
All documentation pages available in markdown.
This page describes capacity planning for Aerospike Database on Amazon EC2, including instance selection, storage options, network planning, and autoscaling considerations. Use the following workload categories to narrow your instance selection, then validate the specific instance generation, architecture, memory, network bandwidth, and storage limits against your workload.
| Instance category | Use case |
|---|---|
| General purpose | Development, test, and smaller mixed workloads |
| Memory optimized | In-memory namespaces and workloads with large primary indexes |
| Compute optimized | Low-latency or high-throughput workloads where CPU is the bottleneck |
| Storage optimized | Persistent namespaces that need a higher local NVMe SSD capacity relative to memory and CPU |
- Do not use burstable or Spot instances for production Aerospike nodes. CPU credit exhaustion, shared-resource contention, and Spot interruptions can cause latency spikes or node loss.
- Check the selected instance’s local NVMe SSD capacity, memory, CPU, network bandwidth, and whether local SSD controllers are shared or dedicated.
- Amazon Linux 2023 is recommended for compatibility and performance.
- For AWS Graviton or other ARM-based instances, choose an Aerospike package for a supported Linux distribution and architecture. See Platform support and compatibility.
Aerospike as In-Memory with no persistence
In-memory without storage-backed persistence is ideal for a cache based use-case. See Configure namespace storage.
Aerospike network planning
Select an instance type with enough network bandwidth and packet-processing capacity for your workload. Adding Elastic Network Interfaces (ENIs) does not increase an instance’s aggregate network bandwidth limit.
Use additional ENIs when you need to:
- Segregate client, fabric, heartbeat, XDR, or administrative traffic.
- Assign additional private IP addresses to the instance.
- Connect the instance to multiple subnets.
Additional ENIs add operational complexity. Validate the network layout and traffic isolation model before deploying to production. For more information about EC2 IP addressing patterns, see Aerospike on Amazon EC2 - IP Addressing.
Aerospike as a fast persistent data store
The storage engine suited for this use case is the SSD Storage Engine.
Amazon EC2 instances provide storage in the form of Elastic Block Storage (EBS). These are network attached to virtual machine instances.
EBS performance depends on the selected volume type and provisioned throughput or IOPS. Provisioned IOPS volumes, such as io2, provide more predictable I/O for latency-sensitive workloads. General Purpose volumes, such as gp3, can be configured independently for size, IOPS, and throughput. See Amazon EBS volume types.
High Availability using Availability Zones
Amazon EC2 is hosted in multiple locations world-wide. These locations are composed of regions and Availability Zones. Each region is a separate geographic area. Each region has multiple, isolated locations known as Availability Zones. Amazon EC2 provides you the ability to place resources, such as instances, and data in multiple locations. Resources aren’t replicated across regions unless you do so specifically. Amazon operates state-of-the-art, highly-available datacenters. Although rare, failures can occur that affect the availability of instances that are in the same location.
Ephemeral SSD-based cache backed by EBS persistence
Benefits:
- RAM requirement is same as the EBS persistence model only.
- Provides persistence offered by EBS while surpassing the performance bottleneck of EBS by making use of ephemeral SSDs performance as caching layer.
- Provides the best of performance and persistence possible by using Ephemeral SSDs as aRAM alternative along with EBS for persistence storage.
Drawbacks:
- More operational overhead than any other storage models.
- Must use instances supporting the required number and amount of ephemeral SSD instance storage volumes.
Autoscaling
Amazon EC2 Auto Scaling groups do not account for Aerospike Database internal processes, such as migrations, rack-aware replica placement, or cluster stability, before terminating, replacing, or adding nodes.
When using Auto Scaling groups with Aerospike:
- Base thresholds and step sizes on workload characteristics and Aerospike metrics, not default CloudWatch metrics alone.
- Ensure scale-in logic respects the minimum safe cluster size and does not remove nodes while migrations or rebalance operations are in progress.
- Account for the cost of data migrations. Scaling up and down for daily traffic cycles can cost more in cross-AZ network transfer than it saves in compute.