This page is written for the security and compliance teams of our enterprise customers. It describes how the data we store on your behalf is encrypted while it sits on disk in our infrastructure, who manages the encryption keys, what at-rest encryption protects against, and what it does not.
This page covers stored data only. Encryption of data while it is being transmitted between your users and our service, and end-to-end encryption for video conferences, are described on separate pages.
At a glance
- Always on, by default. Every category of customer data we store is encrypted at rest. This is not configurable or opt-in.
- Industry-standard cipher. AES-256, the same algorithm used by nearly every modern cloud service and recommended by NIST.
- Keys managed by AWS on our behalf. Encryption keys are generated, stored, and rotated by AWS Key Management Service (KMS) inside FIPS-validated hardware security modules. We never see or hold the raw key material ourselves.
- Backups inherit the same protection. Automated backups, manual snapshots, and disaster-recovery replicas are all encrypted to the same standard.
- What it protects: unauthorised access to the underlying storage media — stolen disks, improperly decommissioned hardware, breach of the raw infrastructure layer.
- What it does not protect: compromised user credentials, application vulnerabilities, or any path that goes through the normal application interface. Those risks are addressed by separate controls — identity and access management, application security, and audit logging.
What “encryption at rest” means
“At rest” refers to data that has been written to persistent storage — hard drives, SSDs, backup volumes, object stores — as distinct from data that is moving across a network (in transit) or that an application is actively holding in memory (in use).
Encryption at rest ensures that if the storage media is ever accessed outside of the normal application path — for example, a hard drive removed from a server, a backup volume copied without authorisation, or a low-level breach of the cloud provider’s storage layer — the data on it is unreadable without the corresponding encryption keys.
It is one layer in a defence-in-depth approach. It complements, but does not replace, controls such as identity and access management, application security, network isolation, and audit logging.
What data we store, and where
We store the categories of data listed below. All of them are held on managed services within AWS, and all of them are encrypted at rest.
Category of stored data | Examples |
Account and configuration data | User accounts, group memberships, contacts, account settings, integrations, billing metadata. |
Communication metadata | Call detail records, conference metadata, message and chat history, in-product activity. |
Cached and ephemeral data | Short-lived state held in our caching layer (e.g. active session tokens, in-flight signaling state) so that the service responds quickly. |
Backups and snapshots | Automated daily backups, manual snapshots, and cross-region disaster-recovery copies of any of the above. |
If your organisation has questions about a specific category of data — where it lives, how long we retain it, who has access to it — your account team can provide the relevant data-handling documentation.
How encryption keys are managed
The encryption keys that protect your stored data are managed entirely by AWS Key Management Service (KMS) on our behalf. Specifically:
- Keys are generated inside FIPS-validated hardware security modules (HSMs) operated by AWS.
- AWS holds the keys. We do not see or extract the raw key material at any point.
- AWS rotates the underlying key material automatically, on a published schedule. Rotation is transparent to our application and to you.
- When our application reads or writes data, AWS performs the encrypt and decrypt operations transparently on our behalf, after verifying that our application has the appropriate permissions.
This is a deliberate design choice. By relying on AWS-managed keys we eliminate the risk of a key being copied off a server we operate, and we inherit the rotation cadence and audit posture that AWS publishes against its compliance programmes.
What at-rest encryption protects, in detail
At-rest encryption is specifically designed to address the risk of unauthorised access to the storage media itself — the disks, SSDs, snapshots, and backup volumes on which your data physically resides.
Concretely, it means the following classes of compromise cannot expose your data:
- Lost or stolen storage media. A hard drive or SSD that is removed from a data centre, improperly decommissioned, or otherwise leaves AWS’s physical custody cannot be read without the encryption keys, which never leave AWS’s control.
- Backup or snapshot exfiltration. A backup file copied to an unintended location remains encrypted; the file itself is opaque without the corresponding key.
- Low-level infrastructure compromise. An attacker who somehow gains access to the raw storage layer of the cloud infrastructure, but does not also obtain the encryption keys, cannot read the data.
- Replication traffic between data centres. When data is replicated to another region for disaster recovery, AWS encrypts the replication traffic automatically. The encryption applies to all data leaving a region, in addition to the at-rest encryption at the destination.
What at-rest encryption does not protect
We want to be precise about this. Overstating what at-rest encryption protects against would be worse than not offering it.
At-rest encryption does not address any threat that reaches your data through the normal application path. Specifically:
Compromised user credentials
If an attacker steals a valid username and password, an API token, or an SSO session, the application will decrypt and return your data to them just as it would to a legitimate user. At-rest encryption is invisible to anyone holding a valid credential. Protection against this risk comes from authentication controls (SSO, multi-factor authentication, password policy), session management, and anomaly detection.
Application vulnerabilities
If a bug or design flaw in our software allows an attacker to read data through a normal application interface (for example, by elevating privileges, bypassing authorisation checks, or exploiting an injection vulnerability), the data is served decrypted. Protection against this risk comes from secure development practices, code review, penetration testing, and vulnerability management — documented separately.
Insiders with legitimate access
Our operations staff who hold legitimate access credentials to query production systems can, by definition, read decrypted data — because the systems they query are designed to decrypt data for legitimate use. At-rest encryption is not access control. Protection against insider risk comes from least-privilege access policies, audit logging, separation of duties, background checks, and employee policies.
Data while it is being processed
Application servers must read data into memory in plaintext in order to act on it. The contents of server memory (data in use) are not covered by at-rest encryption. Protection against this comes from host hardening, isolation, and the operational controls applied to our cloud environment.
Underlying technology
For security teams that want the specifics:
- Cipher. AES-256 across all storage layers. Object storage uses AES-256 in Galois/Counter Mode (GCM), an authenticated encryption algorithm. Block storage and database storage use AES-256 in modes appropriate to disk- and volume-level encryption.
- Key management. AWS Key Management Service (KMS), using AWS-managed keys. Key material is held inside FIPS 140-validated hardware security modules and never exposed in plaintext outside the HSM boundary.
- Per-object data keys. For object storage, each stored object is encrypted with a unique data key. The data key itself is encrypted by a master key, which AWS rotates on its own schedule.
- Database storage. The underlying database volumes are encrypted in full, including the database files, transaction logs, automated backups, snapshots, and read replicas.
- Replication. Replication traffic between availability zones and between regions is encrypted automatically by AWS in transit, in addition to the at-rest encryption applied at each destination.
Standards alignment and audit
AES-256 is a NIST-approved cipher and forms the basis of encryption used across nearly every modern cloud service, including those that hold regulated data. The hardware security modules used by AWS Key Management Service are validated against FIPS 140-2 (and in more recent regions, FIPS 140-3).
Out of scope on this page
This page covers stored data only. The following are described on separate pages and are available on request:
- Encryption in transit. How data is protected while moving between your users and our service, and between components of our infrastructure (TLS for HTTPS and WebSocket, DTLS-SRTP for WebRTC media).
- End-to-end encryption for video conferences. How customers can additionally encrypt video conference media such that even our conferencing infrastructure cannot read the content.
- Identity and access management. How we authenticate users, manage staff access to production systems, and audit data access.
Contact
For deeper technical questions, security questionnaires, or to discuss customer-managed key options for your tenant, contact your account team or our security team directly.