

# What is AWS CloudHSM?
<a name="introduction"></a>

AWS CloudHSM combines the benefits of the AWS cloud with the security of hardware security modules (HSMs). A hardware security module (HSM) is a computing device that processes cryptographic operations and provides secure storage for cryptographic keys. With AWS CloudHSM, you have complete control over high availability HSMs that are in the AWS Cloud, have low-latency access, and a secure root of trust that automates HSM management (including backups, provisioning, configuration, and maintenance). 

AWS CloudHSM offers customers a variety of benefits:

**Access to FIPS and non-FIPS clusters**  
AWS CloudHSM offers clusters in two modes: *FIPS* and *non-FIPS*. In FIPS mode, only Federal Information Processing Standard (FIPS) validated keys and algorithms can be used. Non-FIPS mode offers all the keys and algorithms that are supported by AWS CloudHSM, regardless of FIPS approval. For more information, see [AWS CloudHSM cluster modes](cluster-hsm-types.md).

**HSMs are general purpose, single tenant, and either FIPS 140-2 level-3 or FIPS 140-3 level-3 validated for clusters in FIPS mode**  
AWS CloudHSM uses general purpose HSMs that provide more flexibility when compared to the fully-managed AWS services that have predetermined algorithms and key lengths for your application. We offer HSMs that are standards-compliant, single-tenant, and are either FIPS 140-2 level-3 or FIPS 140-3 level-3 validated for clusters in FIPS mode. For customers with use cases outside the restrictions of FIPS 140-2 or FIPS 140-3 level-3 validation, AWS CloudHSM also offers clusters in non-FIPS mode. See [AWS CloudHSM clusters](clusters.md) for more information.

**E2E encryption is not visible to AWS**  
Because your data plane is end-to-end (E2E) encrypted and not visible to AWS, you control your own user management (outside of IAM roles). The trade off for this control is you have more responsibility than if you used a managed AWS service. 

**Full control of your keys, algorithms, and application development**  
AWS CloudHSM gives you full control of the algorithms and keys you use. You can generate, store, import, export, manage, and use cryptographic keys (including, session keys, token keys, symmetric keys and asymmetric key pairs). Additionally, AWS CloudHSM SDKs give you full control over application development, application language, threading, and where your applications physically exist.

**Migrate your cryptographic workloads to the cloud**  
Customers migrating public key infrastructure that use Public Key Cryptography Standards \$111 (PKCS \$111), Java Cryptographic Extension (JCE), Cryptography API: Next Generation (CNG), or Key Storage Provider (KSP) can migrate to AWS CloudHSM with fewer changes to their application.

To learn more about what you can do with AWS CloudHSM, see the following topics. When you are ready to get started with AWS CloudHSM, see [Getting started](getting-started.md). 

**Note**  
If you want a managed service for creating and controlling your encryption keys but you don't want or need to operate your own HSMs, consider using [AWS Key Management Service](https://aws.amazon.com/kms/).  
If you are looking for an elastic service that manages payment HSMs and keys for payment processing applications in the cloud, consider using [AWS Payment Cryptography](https://aws.amazon.com/payment-cryptography/). 

**Topics**
+ [Use cases](use-cases.md)
+ [How it works](whatis-concepts.md)
+ [Pricing for AWS CloudHSM](pricing.md)

# AWS CloudHSM use cases
<a name="use-cases"></a>

AWS CloudHSM can be used to accomplish a variety of goals. The content in this topic provides an overview of what you can do with AWS CloudHSM.

**Achieve regulatory compliance**  
Businesses that need to align with enterprise security standards can use AWS CloudHSM to manage private keys that protect highly confidential data. The HSMs provided by AWS CloudHSM are FIPS 140-2 level 3 certified and comply with PCI DSS. Additionally, AWS CloudHSM is PCI PIN compliant and PCI-3DS compliant. For more information, see [Compliance validation for AWS CloudHSM](fips-validation.md).

**Encrypt and decrypt data**  
Use AWS CloudHSM to manage private keys that protect highly confidential data, encryption in transit, and encryption at rest. Additionally, AWS CloudHSM offers standards-compliant integration with multiple cryptographic SDKs.

**Sign and verify documents with private and public keys**  
In cryptography, using a private key to **sign** a document allows recipients to use a public key to **verify** that you (and not someone else) actually sent the document. Use AWS CloudHSM to create asymmetric public and private key pairs that are specifically designed for this purpose.

**Authenticate messages using HMACs and CMACs**  
In cryptography, Cipher Message Authentication Codes (CMACs) and Hash-based Message Authentication Codes (HMACs) are used to authenticate and ensure the integrity of messages sent over unsafe networks. With AWS CloudHSM, you can securely create and manage symmetric keys that support HMACs and CMACs.

**Leverage the benefits of AWS CloudHSM and AWS Key Management Service**  
Customers can combine AWS CloudHSM and [AWS KMS](https://aws.amazon.com/kms/) to store key material in a single-tenant environment while also getting the key management, scaling, and cloud integration benefits of AWS KMS. For details on how to do this, see [AWS CloudHSM key stores](https://docs.aws.amazon.com/kms/latest/developerguide/keystore-cloudhsm.html) in the *AWS Key Management Service Developer Guide*.

**Offload SSL/TLS processing for web servers**  
To securely send data over the internet, web servers use public–private key pairs and SSL/TLS public key certificate to establish HTTPS sessions. This process involves a lot of computation for web servers, but you can reduce computational burden while providing extra security by offloading some of this to your AWS CloudHSM cluster. For information about setting up SSL/TLS offload with AWS CloudHSM, see [SSL/TLS offload](ssl-offload.md).

**Enable transparent data encryption (TDE)**  
Transparent Data Encryption (TDE) is used to encrypt database files. Using TDE, database software encrypts data before storing it on disk. You can achieve greater security by storing the TDE master encryption key in HSMs in your AWS CloudHSM. For information about setting up Oracle TDE with AWS CloudHSM, see [Oracle database encryption](oracle-tde.md).

**Manage the private keys of an issuing certificate authority (CA)**  
A certificate authority (CA) is a trusted entity that issues digital certificates that bind a public key to an identity (a person or organization). To operate a CA, you must maintain trust by protecting the private key that signs certificates issued by your CA. You can store such private keys in your AWS CloudHSM cluster and then use your HSMs to perform cryptographic signing operations.

**Generate random numbers**  
Generating random numbers to create encryption keys is core to online security. AWS CloudHSM can be used to securely generate random numbers in HSMs you control and are only visible to you.

# How AWS CloudHSM works
<a name="whatis-concepts"></a>

This topic provides an overview of the basic concepts and architecture you use to securely encrypt data and perform cryptographic operations in HSMs. AWS CloudHSM operates in your own Amazon Virtual Private Cloud (VPC). Before you can use AWS CloudHSM, you first create a cluster, add HSMs to it, create users and keys, and then use Client SDKs to integrate your HSMs with your application. Once this is done, you use Client SDK logs, AWS CloudTrail, audit logs, and Amazon CloudWatch to [monitor AWS CloudHSM](get-logs.md).

Learn AWS CloudHSM's basic concepts and how they work together to help protect your data.

**Topics**
+ [AWS CloudHSM clusters](clusters.md)
+ [Users in AWS CloudHSM](hsm-users.md)
+ [Keys in AWS CloudHSM](whatis-hsm-keys.md)
+ [Client SDKs for AWS CloudHSM](client-tools-and-libraries.md)
+ [AWS CloudHSM cluster backups](backups.md)
+ [Supported Regions for AWS CloudHSM](regions.md)

# AWS CloudHSM clusters
<a name="clusters"></a>

Making individual HSMs work together in a synchronized, redundant, and highly-available way can be difficult, but AWS CloudHSM does the heavy lifting for you by providing hardware security modules (HSMs) in *clusters*. A cluster is a collection of individual HSMs that AWS CloudHSM keeps in sync. When you perform a task or operation on one HSM in a cluster, the other HSMs in that cluster are automatically kept up to date.

AWS CloudHSM offers clusters in two modes: *FIPS* and *non-FIPS*. In FIPS mode, only Federal Information Processing Standard (FIPS) validated keys and algorithms can be used. Non-FIPS mode offers all the keys and algorithms that are supported by AWS CloudHSM, regardless of FIPS approval. AWS CloudHSM also offers two types of HSMs: *hsm1.medium* and *hsm2m.medium*. For details on the differences between each HSM type and cluster mode, see [AWS CloudHSM cluster modes](cluster-hsm-types.md). The *hsm1.medium* HSM type is reaching end of support so new clusters cannot be created with this type. For more information, see [Deprecation notifications](compliance-dep-notif.md#hsm-dep-1) for details.

To meet your availability, durability, and scalability goals, you set the number of HSMs in your cluster across multiple availability zones. You can create a cluster that has 1 to 28 HSMs (the [default limit](limits.md) is 6 HSMs per AWS account per [AWS Region](https://docs.aws.amazon.com/cloudhsm/latest/userguide/regions.html)). You can place the HSMs in different [Availability Zones](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.az.en.html) in an AWS region. Adding more HSMs to a cluster provides higher performance. Spreading clusters across Availability Zones provides redundancy and high availability.

For more information about clusters, see [Clusters in AWS CloudHSM](manage-clusters.md).

To create a cluster, see [Getting started](getting-started.md).

# Users in AWS CloudHSM
<a name="hsm-users"></a>

Unlike most AWS services and resources, you do not use AWS Identity and Access Management (IAM) users or IAM policies to access resources within your AWS CloudHSM cluster. Instead, you use *HSM users* directly on HSMs in your AWS CloudHSM cluster.

HSM users are distinct from IAM users. IAM users who have the correct credentials can create HSMs by interacting with resources through the AWS API. Since E2E encryption is not visible to AWS, you must use HSM user credentials to authenticate operations on the HSM because credentials takes place directly on the HSM. The HSM authenticates each HSM user by means of credentials that you define and manage. Each HSM user has a *type* that determines which operations that user can perform on the HSM. Each HSM authenticates each HSM user by means of credentials that you define using [CloudHSM CLI](cloudhsm_cli.md). 

If you are using the [previous SDK version series](choose-client-sdk.md), then you will use [CloudHSM Management Utility (CMU)](cloudhsm_mgmt_util.md).

# Keys in AWS CloudHSM
<a name="whatis-hsm-keys"></a>

AWS CloudHSM allows you to securely generate, store, and manage your encryption keys in single-tenant HSMs that are in your AWS CloudHSM cluster. Keys can be symmetric or asymmetric, can be session keys (ephemeral keys) for single sessions, token keys (persistent keys) for long-term use, and can be exported from and imported into AWS CloudHSM Keys can also be used to complete common cryptographic tasks and functions:
+ Perform cryptographic data signing and signature verification with both symmetric and asymmetric encryption algorithms.
+ Work with hash functions to compute message digests and hash-based message authentication codes (HMACs).
+ Wrap and protect other keys.
+ Access cryptographically secure random data.

The maximum keys a cluster can have depends on the type of HSMs that are in the cluster. For example, hsm2m.medium stores more keys than hsm1,medium. For a comparison, see [AWS CloudHSM quotas](limits.md).

Additionally, AWS CloudHSM follows a few foundational principles for key usage and management:

**Many key types and algorithms to choose from**  
To allow you to customize your own solutions, AWS CloudHSM provides many key types and algorithms to choose from algorithms support a range of key sizes. For more information, refer to the attributes and mechanism pages of each [Offload operations with AWS CloudHSM Client SDKs](use-hsm.md).

**How you manage keys**  
AWS CloudHSM keys are managed through SDKs and command line tools. For information on how to use these tools to manage keys, see [Keys in AWS CloudHSM](manage-keys.md) and [Best practices for AWS CloudHSM](best-practices.md).

**Who owns keys**  
In AWS CloudHSM, the crypto user (CU) who creates the key owns it. The owner can use the **key share** and **key unshare** commands to share and unshare the key with other CUs. For more information, see [Share and unshare keys using CloudHSM CLI](manage-keys-cloudhsm-cli-share.md).

**Access and usage can be controlled with attribute-based encryption**  
AWS CloudHSM allows you to use attribute-based encryption, a form of encryption that lets you use key attributes to control who can decrypt data based on policies.

# Client SDKs for AWS CloudHSM
<a name="client-tools-and-libraries"></a>

When using AWS CloudHSM, you perform cryptographic operations with [AWS CloudHSM Client Software Development Kits (SDKs)](use-hsm.md). AWS CloudHSM Client SDKs include:
+ Public Key Cryptography Standards \$111 (PKCS \$111)
+ JCE provider
+ OpenSSL Dynamic Engine
+ Key Storage Provider (KSP) for Microsoft Windows

You can use any or all of these SDKS in your AWS CloudHSM cluster. Write your application code to use these SDKs to perform cryptographic operations in your HSMs. To see what platforms and HSM types support each SDK, see [AWS CloudHSM Client SDK 5 supported platforms](client-supported-platforms.md)

Utility and command line tools are needed not only to use SDKs but also to configure the credentials, policies, and settings of your application. For more information, refer to [AWS CloudHSM command line tools](command-line-tools.md).

 For more information about installing and using the Client SDK or the security of the client connection, see [Client SDKs](use-hsm.md) and [End-to-end encryption](client-end-to-end-encryption.md). 

# AWS CloudHSM cluster backups
<a name="backups"></a>

AWS CloudHSM makes periodic backups of the users, keys, and policies in the cluster. Backups are secure, durable, and updated on a predictable schedule. The following illustration shows the relationship of your backups to the cluster. 

![\[AWS CloudHSM cluster backups encrypted in a service-controlled Amazon S3 bucket.\]](http://docs.aws.amazon.com/cloudhsm/latest/userguide/images/cluster-backup.png)


For more information about working with backups, see [Cluster backups](manage-backups.md).

**Security**  
When AWS CloudHSM makes a backup from the HSM, the HSM encrypts all of its data before sending it to AWS CloudHSM. The data never leaves the HSM in plaintext form. Additionally, backups cannot be decrypted by AWS because AWS doesn’t have access to key used to decrypt the backups. For more information, see [Security of cluster backups](data-protection-backup-security.md)

**Durability**  
AWS CloudHSM stores backups in a service-controlled Amazon Simple Storage Service (Amazon S3) bucket in the same region as your cluster. Backups have a 99.999999999% durability level, the same as any object stored in Amazon S3.

# Supported Regions for AWS CloudHSM
<a name="regions"></a>

For information about the supported Regions for AWS CloudHSM, see [AWS CloudHSM Regions and Endpoints](https://docs.aws.amazon.com/general/latest/gr/cloudhsm.html) in the *AWS General Reference*, or the [Region Table](https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/).

AWS CloudHSM might not be available in all Availability Zones in a given Region. However, this should not affect performance, as AWS CloudHSM automatically load balances across all HSMs in a cluster.

Like most AWS resources, clusters and HSMs are regional resources. You cannot reuse or extend a cluster across Regions. You must perform all the required steps listed in [Getting started with AWS CloudHSM](getting-started.md) to create a cluster in a new Region.

For disaster recovery purposes, AWS CloudHSM allows you to copy backups of your AWS CloudHSM Cluster from one region to another. For more information, see [AWS CloudHSM cluster backups](backups.md).

# Pricing for AWS CloudHSM
<a name="pricing"></a>

With AWS CloudHSM, you pay by the hour with no long-term commitments or upfront payments. For more information, see [AWS CloudHSM Pricing](https://aws.amazon.com/cloudhsm/pricing/) on the AWS website. 