Build an AWS KMS Key Decision Lab

Create KMS keys to test encryption, HMAC authentication, and lifecycle choices.

Introduction

30 Second Summary

A file can need to stay secret. It can also need proof that nobody changed it after you sent it.

In this project, you will build a hands-on lab with AWS Key Management Service (AWS KMS) that uses symmetric encryption, asymmetric encryption, plus HMAC authentication. The terminal results will show which operation each key permits.

What You'll Build

Your finished lab turns three customer managed keys into a live terminal demonstration of successful encryption, successful authentication, plus an enforced failure.

By the end of this project, you'll have:

Two encryption round trips that recover the original plaintext from symmetric plus RSA ciphertext.
An enforced operation boundary that lets you show an HMAC key rejecting encryption before authenticating the message correctly.
The confidence to justify a key choice among customer managed keys, AWS managed keys, plus AWS owned keys based on control, visibility, rotation, lifecycle, plus cost.
Secret Mission: Change the authenticated message while preserving the original authentication result. Prove that verification rejects the altered input.

Are there any prerequisites?

You need a macOS device with the AWS Command Line Interface (AWS CLI) configured with credentials plus a Region. Your AWS account needs permission to create KMS keys, use them, plus schedule their deletion.

Before We Start

This planning note connects your example data to the confidentiality, authenticity, auditability, or operational-control property that each lab operation should prove. It gives the later symmetric encryption, asymmetric encryption, and HMAC authentication results a clear purpose.

Verify Your AWS CLI Session

The next steps create billable customer managed keys in AWS Key Management Service (AWS KMS). A stale CLI session can place those keys in the wrong account or Region.

This step uses macOS Terminal to test the active AWS Command Line Interface (AWS CLI). It creates no AWS resources, so these checks do not start key storage charges.

In this step, get ready to:

Confirm that AWS CLI v2 is available.
Verify the active AWS session context.
Prepare the local ~/kms-key-lab folder.

Verify AWS CLI v2

The AWS CLI major version determines which command behavior this lab can rely on. AWS CLI v2 is the required baseline.

Press Cmd+Space to open Spotlight.
Type Terminal into the Spotlight search field.
Press Enter to open Terminal.
Check the installed AWS CLI version by running this command:

aws --version

What Does This Command Show?

The command prints the installed AWS CLI release. The output prefix identifies its major version.

✔️ I see aws-cli/2

You have the required major version. Your AWS CLI is ready for the session checks.

Continue to the identity check below.

ⓧ I see aws-cli/1

The installed major version is too old for this lab. Install AWS CLI v2 for your macOS user.

Install the current AWS CLI release by running this command:

curl -fsSL https://awscli.amazonaws.com/v2/install.sh | bash

What Does This Command Do?

The command downloads the official AWS CLI installation script. The script installs the current release for your macOS user.

Close the current Terminal window.
Open a fresh Terminal session through Spotlight.
Rerun the version check shown above.

The new output should begin with aws-cli/2.

Still Seeing AWS CLI v1?

A fresh Terminal session reloads the command search path. Confirm that the installer completed before checking the version again.

Ask for targeted help with finding why the old AWS CLI still runs.

ⓧ Command not found

Terminal cannot find an AWS CLI installation. Install AWS CLI v2 before continuing.

Install the current AWS CLI release by running this command:

curl -fsSL https://awscli.amazonaws.com/v2/install.sh | bash

What Does This Command Do?

The command downloads the official AWS CLI installation script. The script installs the current release for your macOS user.

Close the current Terminal window.
Open a fresh Terminal session through Spotlight.
Rerun the version check shown above.

The output should begin with aws-cli/2.

AWS CLI Still Is Not Available?

Confirm that the installation command completed without a download failure. Start a fresh Terminal session before retrying the version check.

Ask for targeted help with making AWS CLI available in Terminal.

Confirm the active AWS identity

Configured credentials decide which AWS identity sends each request. The identity response exposes the account number through Account.

The Arn field identifies the active user or role. Both values must match the identity you intend to use for this lab.

Before you run the check, which AWS account and identity do you expect to see?

Reveal the active AWS identity by running this command:

aws sts get-caller-identity

What Does This Command Show?

The response includes UserId, Account, and Arn. This read-only identity check does not require AWS permissions.

Compare the returned Account value with your intended AWS account.
Confirm that the returned Arn belongs to your intended lab identity.

That is the first safety boundary confirmed. Your commands now point to the AWS identity you expect.

Seeing the Wrong Identity?

Stop before creating any KMS keys.
Correct the local AWS CLI credentials for your intended account.
Rerun the identity check after correcting the credentials.

Ask for help with diagnosing the active AWS identity.

Check the Region and prepare the lab folder

KMS keys belong to a specific AWS Region. Confirming the configured Region keeps every later key in one deliberate location.

Read the configured AWS Region by running this command:

aws configure get region

What Does This Command Show?

The command reads the Region stored for the active AWS CLI configuration. A non-empty result gives later KMS commands a default Region.

You should see a non-empty Region value. This confirms where the lab keys are created.

Is the Region Blank?

Stop before creating any KMS keys.
Correct the Region in your AWS CLI configuration.
Rerun the Region check after updating the configuration.

Ask for help with configuring a non-empty AWS Region.

The local lab folder keeps plaintext, ciphertext, decoded plaintext, encoded messages, and MAC evidence in one place. Its home-folder location remains stable across Terminal sessions.

Create the ~/kms-key-lab folder by running these commands:

mkdir ~/kms-key-lab
cd ~/kms-key-lab

What Do These Commands Do?

The first command creates kms-key-lab inside your macOS home folder. The second command moves the Terminal session into that folder.

Does the Folder Already Exist?

An existing folder does not need to be created again. Use the second command to switch into it.

Ask for help with entering the existing lab folder.

Before the final check, what account identity, Region state, and folder path do you expect the three commands to confirm?

Verify the complete AWS CLI session by running these commands:

aws sts get-caller-identity
aws configure get region
pwd

What Does This Final Check Prove?

The first command confirms the active AWS identity. The second command confirms the configured Region.

The final command prints your current folder. Together these results establish the safe starting point for the KMS lab.

The first output should contain your intended Account and Arn. The second output should contain a non-empty Region.

The final output should end with /kms-key-lab. You now have a verified AWS session and a local workspace without creating any KMS keys.

Your AWS CLI session now points to the intended account and Region. Next, you will use that verified context for the symmetric encryption round trip.

Encrypt and Decrypt with a Symmetric Key

Your verified AWS CLI session confirms where this first billable key belongs. The verified Region confirms where AWS Key Management Service (AWS KMS) creates it.

Symmetric encryption is the default KMS path for protecting data. This step gives you the smallest working encryption round trip before you compare specialized keys.

In this step, get ready to:

Create a customer managed symmetric KMS key.
Encrypt a plaintext file into ciphertext.
Decrypt the ciphertext into a recovered plaintext file.

Create the symmetric KMS key

A customer managed key gives you control over its policy. The default KeySpec supports the encryption round trip used in this lab.

Why Use the CLI?

The AWS Management Console is useful for viewing key ownership. The AWS CLI exposes the result of each cryptographic operation in your terminal.

That terminal evidence makes supported operations visible. It also makes rejected operations visible later in the lab.

This action creates a customer-created KMS key that costs $1/month (prorated hourly). The cleanup section schedules deletion for every lab key.

Create the default symmetric key in your verified Region by running this command:

aws kms create-key

What Does This Command Do?

The command creates a customer managed KMS key with default symmetric settings.
The response provides the new KeyId inside the key metadata.
The metadata identifies the key's cryptographic purpose.

Find the KeyId field in the returned metadata.
Record the returned value as SymmetricKeyId: your symmetric KeyId.
Confirm that KeySpec shows SYMMETRIC_DEFAULT.
Confirm that KeyUsage shows ENCRYPT_DECRYPT.
Confirm that KeyManager shows CUSTOMER.
Confirm that Origin shows AWS_KMS.
Confirm that KeyState shows Enabled.

That first billable resource is now under your control in the verified Region. Its metadata confirms that it is ready for encryption.

Key Creation Failed?

Check that your active identity has permission to create KMS keys.
Confirm that your configured Region is still the intended lab Region.

Ask for targeted help with diagnosing the KMS key creation failure.

Encrypt a plaintext file

The plaintext file gives the key a small non-sensitive input. The encrypted output becomes evidence that this key accepts the KMS Encrypt operation.

Create ExamplePlaintextFile inside ~/kms-key-lab by running the first command below:
Display the saved message by running the second command below:

echo "KMS protects this non-sensitive lab message." > ExamplePlaintextFile
cat ExamplePlaintextFile

What Do These Commands Do?

The first command redirects the sample message into ExamplePlaintextFile.
The second command displays the file contents in Terminal.

Confirm that Terminal displays KMS protects this non-sensitive lab message..

Plaintext File Missing?

Confirm that your Terminal prompt is inside ~/kms-key-lab.
Check that the filename uses the exact capitalization shown above.

Ask for help with creating the plaintext evidence file.

Encrypt ExamplePlaintextFile with your symmetric key by running this command:

aws kms encrypt \
    --key-id [[SYMMETRIC_KEY_ID="your symmetric KeyId"]] \
    --plaintext fileb://ExamplePlaintextFile \
    --output text \
    --query CiphertextBlob | base64 \
    --decode > ExampleEncryptedFile

What Does This Command Do?

The --key-id parameter selects your customer managed symmetric key.
The fileb://ExamplePlaintextFile value loads the plaintext as binary input.
The --query CiphertextBlob parameter extracts the encrypted value from the response.
The base64 --decode stage converts the returned value into binary ciphertext.
The final redirection stores that ciphertext in ExampleEncryptedFile.

Confirm that ExampleEncryptedFile exists by running this command:

ls ExampleEncryptedFile

What Does This Check Prove?

The command asks macOS to list this exact evidence file. Seeing its name confirms that the encryption workflow wrote the ciphertext to disk.

Terminal should display ExampleEncryptedFile. Your first KMS encryption operation has produced a ciphertext file.

Ciphertext File Missing?

Check that the symmetric key ID matches the KeyId returned by the create command.
Confirm that ExamplePlaintextFile uses the exact capitalization shown above.
Wait briefly before retrying if the new key is temporarily unavailable.

Ask for help with diagnosing the failed symmetric encryption.

Decrypt and compare the recovered plaintext

Decryption closes the round trip. A matching recovered file proves that the same symmetric key can restore the original message.

Decrypt ExampleEncryptedFile into ExamplePlaintextFile.decrypted by running this command:

aws kms decrypt \
    --ciphertext-blob fileb://ExampleEncryptedFile \
    --key-id [[SYMMETRIC_KEY_ID="your symmetric KeyId"]] \
    --output text \
    --query Plaintext | base64 \
    --decode > ExamplePlaintextFile.decrypted

What Does This Command Do?

The --ciphertext-blob parameter loads the binary ciphertext from ExampleEncryptedFile.
The --key-id parameter identifies the intended decryption key.
The --query Plaintext parameter extracts the recovered plaintext from the response.
The decoded result is stored in ExamplePlaintextFile.decrypted.

Before you display the files, what do you expect the recovered message to show?

Compare the original plaintext with the recovered plaintext by running these commands:

cat ExamplePlaintextFile
cat ExamplePlaintextFile.decrypted

What Does This Check Prove?

The first command displays the original message. The second command displays the plaintext recovered by AWS KMS.

Matching output proves that the ciphertext completed a successful symmetric encryption round trip.

Both lines should display KMS protects this non-sensitive lab message. The recovered contents match the original exactly.

Recovered Plaintext Does Not Match?

Confirm that the decrypt command reads ExampleEncryptedFile.
Check that the decrypt command uses the same symmetric key ID as the encrypt command.
Rerun the encryption command if the ciphertext file was replaced or edited.

Ask for help with diagnosing the symmetric decryption mismatch.

That's the first KMS behavior proven through a complete round trip. Next, you will create an RSA key to test the public and private key model.

Encrypt with an Asymmetric Key

Your AWS Key Management Service (AWS KMS) key completed a symmetric encryption round trip in the last step. A partner who needs a public key cannot use that shared-secret workflow.

The separate public and private model solves that handoff. This step creates an RSA key pair for asymmetric encryption.

In this step, get ready to:

Create a customer managed RSA encryption key.
Encrypt ExamplePlaintextFile with the key's supported algorithm.
Recover the original message from the asymmetric ciphertext.

Create the RSA encryption key

An asymmetric key pair has a public key for encryption. AWS KMS keeps the private key protected for decryption.

This is the point where the lab starts another small charge. The customer-created key costs $1/month (prorated hourly).

Create the RSA key pair by running this command in the macOS Terminal session from earlier:

aws kms create-key --key-spec RSA_4096 --key-usage ENCRYPT_DECRYPT

What Does This Command Do?

The --key-spec RSA_4096 option creates an RSA key pair with a 4096-bit modulus.
The --key-usage ENCRYPT_DECRYPT option limits the key to encryption operations.
These properties become permanent when AWS KMS creates the key.

Record the returned KeyId as AsymmetricKeyId here: your asymmetric key ID.
Confirm that KeySpec shows RSA_4096.
Confirm that KeyUsage shows ENCRYPT_DECRYPT.
Confirm that KeyManager identifies the key as customer managed.
Confirm that Origin shows AWS_KMS.
Confirm that the key is enabled.
Confirm that EncryptionAlgorithms includes RSAES_OAEP_SHA_256.

You have created the lab's public and private key pair. Its metadata now defines the operations it can perform.

The RSA Key Was Not Created?

Check that your CLI session still uses the verified AWS account and Region. Your active identity also needs permission to create AWS KMS keys.

Ask for targeted help with diagnosing the RSA key creation failure.

Encrypt with the RSA public side

Asymmetric encryption requires an algorithm that matches the RSA key. The algorithm becomes part of the contract needed to recover the plaintext.

Create ExampleAsymmetricEncryptedFile from the existing plaintext by running this command:

aws kms encrypt \
  --key-id [[ASYMMETRIC_KEY_ID="your asymmetric key ID"]] \
  --plaintext fileb://ExamplePlaintextFile \
  --encryption-algorithm RSAES_OAEP_SHA_256 \
  --output text \
  --query CiphertextBlob | base64 --decode > ExampleAsymmetricEncryptedFile

What Does This Command Do?

The --key-id option selects the RSA key you just created.
The fileb://ExamplePlaintextFile value sends the file's bytes to AWS KMS.
The RSAES_OAEP_SHA_256 value selects the recommended asymmetric encryption algorithm.
The final pipeline decodes CiphertextBlob into ExampleAsymmetricEncryptedFile.

Confirm that Terminal returns to the command prompt without an error.

The successful return proves that AWS KMS accepted the RSA key plus its supported algorithm. The ExampleAsymmetricEncryptedFile ciphertext is now stored in ~/kms-key-lab.

The Encryption Request Failed?

Check that you entered the returned asymmetric key ID. Confirm that the plaintext file is still named ExamplePlaintextFile.

A newly created key can take a short time to become available. Wait briefly before retrying the same workflow.

Ask for help with troubleshooting the asymmetric encryption request.

Recover the plaintext

Asymmetric decryption needs the same KMS key ID used for encryption. It also needs the same encryption algorithm.

Before you run this, do you expect decryption to succeed when both values match the encryption request?

Recover the message into ExampleAsymmetricPlaintextFile.decrypted by running this command:

aws kms decrypt \
  --ciphertext-blob fileb://ExampleAsymmetricEncryptedFile \
  --key-id [[ASYMMETRIC_KEY_ID="your asymmetric key ID"]] \
  --encryption-algorithm RSAES_OAEP_SHA_256 \
  --output text \
  --query Plaintext | base64 --decode > ExampleAsymmetricPlaintextFile.decrypted

What Does This Command Do?

The --ciphertext-blob option reads the asymmetric ciphertext file.
The --key-id option identifies the private key material protected by AWS KMS.
The --encryption-algorithm RSAES_OAEP_SHA_256 option matches the earlier encryption request.
The final pipeline writes the recovered bytes into ExampleAsymmetricPlaintextFile.decrypted.

Confirm that Terminal returns to the command prompt without an error.

Before you display both files, do you expect their visible text to match character for character?

Display the original message plus the recovered message by running these commands:

cat ExamplePlaintextFile
cat ExampleAsymmetricPlaintextFile.decrypted

What Does This Check Prove?

The first command prints the original plaintext. The second command prints the plaintext recovered with the RSA private key.

Matching text proves that the asymmetric ciphertext completed a successful round trip.

You'll see the same non-sensitive message twice. That's the second encryption round trip complete.

The Recovered Text Does Not Match?

Confirm that decryption read ExampleAsymmetricEncryptedFile. Check that the request used your recorded AsymmetricKeyId.

Confirm that both asymmetric operations used RSAES_OAEP_SHA_256.

Ask for help with diagnosing the asymmetric round trip.

Your RSA key now demonstrates the public and private encryption model. Next, you'll test whether a different cryptographic key type can perform the same job.

Make the Wrong Key Do the Wrong Job

Your symmetric encryption key completed an encryption round trip. Your asymmetric encryption key completed one too.

Metadata can feel descriptive until a live request tests it. In this step, you will put KeyUsage under pressure with an HMAC key. AWS Key Management Service (AWS KMS) decides whether the request fits the key.

In this step, get ready to:

Create a customer managed HMAC_384 key for GENERATE_VERIFY_MAC usage.
Apply the known-good Encrypt request to HmacKeyId.
Connect the observed response to the key's KeyUsage.

Create the HMAC key

An HMAC key carries a different KeySpec from either encryption key. Its KeyUsage becomes fixed when AWS KMS creates it.

Before You Create the Key

This action creates your third billable customer managed key. AWS charges $1/month (prorated hourly) for each customer-created key.

The cleanup section schedules all three lab keys for deletion. That stops their key-storage charges during the pending-deletion period.

Create the HMAC key in the verified account by running this command:

aws kms create-key --key-spec HMAC_384 --key-usage GENERATE_VERIFY_MAC

What Does This Command Do?

The command asks AWS KMS to create a customer managed key with the requested cryptographic specification. The returned metadata provides the evidence you inspect next.

Locate KeyId in the returned JSON.
Record the returned value as HmacKeyId here: your HMAC key ID.
Confirm that KeySpec shows HMAC_384.
Confirm that KeyUsage shows GENERATE_VERIFY_MAC.
Confirm that KeyManager shows CUSTOMER.
Confirm that Origin shows AWS_KMS.
Confirm that MacAlgorithms includes HMAC_SHA_384.
Confirm that the new key is enabled.

You should see all seven properties in the returned metadata. That is the third key created for your decision lab.

Key Creation Did Not Complete?

Confirm that Terminal still uses the verified AWS account. Check that your identity has permission to create KMS keys.

Ask for targeted help with troubleshooting the HMAC key creation.

Reuse the known-good encryption request

The same plaintext already produced ExampleEncryptedFile with SymmetricKeyId. Reusing that request with HmacKeyId isolates the key as the only changed input.

Before you run this request, do you expect AWS KMS to return ciphertext or reject the operation?

Send ExamplePlaintextFile to Encrypt with your saved HMAC key ID by running this command:

aws kms encrypt \
    --key-id [[HMAC_KEY_ID="your HMAC key ID"]] \
    --plaintext fileb://ExamplePlaintextFile

What Does This Request Test?

The request sends the existing plaintext to the same Encrypt operation used earlier. Only the supplied key changes.

This Failure Is Intentional

AWS KMS returns an error. It does not return a CiphertextBlob.

The service accepted the request shape. The key's fixed usage rejected the requested cryptographic operation.

You have now made the key boundary visible. The failed request is evidence that AWS KMS enforces the metadata.

Did You See a Different Error?

If the error points to the plaintext file, confirm that Terminal remains in ~/kms-key-lab. Check that ExamplePlaintextFile still exists there.

A newly created key can briefly be unavailable because KMS uses eventual consistency. Pause briefly before retrying the same request.

Ask for targeted help with diagnosing the negative encryption test.

Connect the error to KeyUsage

Before you compare the keys, which KeyUsage value do you think separates the successful requests from the rejected request?

Compare the saved metadata for SymmetricKeyId with its successful round trip.
Compare the saved metadata for AsymmetricKeyId with its successful round trip.
Compare the returned metadata for HmacKeyId with the rejected request.

Why Did AWS KMS Reject the Request?

For SymmetricKeyId, ENCRYPT_DECRYPT permits the successful symmetric round trip.
For AsymmetricKeyId, ENCRYPT_DECRYPT permits the successful RSA round trip.
For HmacKeyId, GENERATE_VERIFY_MAC excludes the Encrypt operation.

The terminal error now has a precise cause. KeyUsage controls which operation family a KMS key can perform.

The enforced boundary is now visible. Next, you will give HmacKeyId the message-authentication job its metadata allows.

Authenticate the Message with HMAC

The rejected Encrypt request proved that KeyUsage is enforced by AWS Key Management Service (AWS KMS). Your HMAC key still has a purpose-built job.

The GenerateMac operation creates proof tied to a message. The VerifyMac operation tests that proof to demonstrate message authentication.

In this step, get ready to:

Generate a MAC for a base64-encoded message.
Verify the original message with the saved MAC.
Compare the three KMS ownership models.

Generate the HMAC

Base64 converts the message bytes into a text representation. AWS KMS authenticates those encoded bytes without revealing the HMAC key material.

Create EncodedMessage with a short non-sensitive message by running these commands:

echo -n "KMS HMAC lab message" | base64 -b 0 > EncodedMessage
base64 -d EncodedMessage

What Do These Commands Do?

The first command converts the message into an unbroken base64 stream. It saves the result in EncodedMessage.
The second command decodes the file for a quick integrity check. This confirms which message the encoded bytes represent.

Your terminal prints KMS HMAC lab message. The visible text confirms that EncodedMessage contains the intended message bytes.

Encoded Message Looks Wrong?

Confirm that the first command uses -n so the message does not gain a trailing newline. Check that both commands reference EncodedMessage with the same capitalization.

Ask for help with diagnosing the base64 message file.

Generate ExampleMac with the HmacKeyId from earlier by running these commands:

aws kms generate-mac \
    --key-id "$HmacKeyId" \
    --message fileb://EncodedMessage \
    --mac-algorithm HMAC_SHA_384 \
    --output text \
    --query Mac | base64 --decode > ExampleMac
base64 -i ExampleMac

What Do These Commands Do?

The generate-mac request authenticates the exact bytes in EncodedMessage.
The HMAC_SHA_384 algorithm matches the supported algorithm on your HMAC_384 key.
The pipeline decodes the returned MAC into raw bytes. It stores those bytes in ExampleMac.
The final command displays a base64 representation of the saved MAC. This gives you visible evidence that the file contains data.

Your terminal prints a base64 string for ExampleMac. The MAC is now tied to the original encoded message.

MAC File Was Not Created?

Confirm that HmacKeyId contains the key ID returned in the verified Region. Check that EncodedMessage uses the same capitalization as the file you created.

A newly created KMS key can briefly be unavailable. Pause for a moment before retrying the same command.

Ask for help with troubleshooting the GenerateMac request.

Verify the original message

Verification recomputes the authentication result inside AWS KMS. A match proves that the supplied message corresponds to the saved MAC.

Before you verify, do you expect the unchanged message to pass or fail?

Verify the original encoded message against ExampleMac by running this command:

aws kms verify-mac \
    --key-id "$HmacKeyId" \
    --message fileb://EncodedMessage \
    --mac-algorithm HMAC_SHA_384 \
    --mac fileb://ExampleMac

What Does This Command Do?

The request sends the same encoded message used during MAC generation.
The request selects the same HMAC key through HmacKeyId.
The request uses HMAC_SHA_384 again.
The request compares the recomputed result with the raw bytes in ExampleMac.

The response contains "MacValid": true. It also contains "MacAlgorithm": "HMAC_SHA_384".

You have closed the HMAC loop. Your key now proves the original message is authentic without exposing its secret material.

Verification Did Not Return True?

Confirm that the request uses the original EncodedMessage file. Confirm that ExampleMac still contains the raw MAC bytes created by generate-mac.

Check that both operations use the same HmacKeyId and HMAC_SHA_384 algorithm.

Ask for help with diagnosing the VerifyMac inputs.

Compare KMS ownership choices

Cryptographic purpose is one part of a key decision. Ownership determines visibility, policy control, rotation, lifecycle control, and cost.

Inspect the metadata for all three customer managed keys by running these commands:

aws kms describe-key --key-id "$SymmetricKeyId"
aws kms describe-key --key-id "$AsymmetricKeyId"
aws kms describe-key --key-id "$HmacKeyId"

What Do These Commands Show?

Each response includes KeySpec. This field identifies the cryptographic key type.
Each response includes KeyUsage. This field identifies the permitted operation family.
Each response includes KeyManager and Origin. These fields identify management responsibility and key-material origin.
The supported algorithm fields connect each key to its valid operations.

The three responses show SYMMETRIC_DEFAULT, RSA_4096, and HMAC_384 as distinct customer managed key specifications.

Cannot Describe a Key?

Confirm that each shell variable contains the key ID from the verified account and Region. Check the capitalization of SymmetricKeyId, AsymmetricKeyId, and HmacKeyId.

Ask for help with troubleshooting the DescribeKey requests.

The AWS Management Console exposes customer managed keys and AWS managed keys inside your account. AWS owned keys remain outside your account.

Before you check the console, which ownership models do you expect to see listed in your account?

Sign in to the AWS Management Console with the same lab account.
Search for AWS Key Management Service (AWS KMS) in the console search bar.
Select Customer managed keys in the left navigation.
Confirm that your symmetric, asymmetric, and HMAC keys are visible on the page.
Select AWS managed keys in the left navigation.
Confirm that service-managed entries are visible on the page.

The Customer managed keys page lists the three lab keys you control. The AWS managed keys page lists keys whose permissions and lifecycle AWS manages.

AWS owned keys have no visible entry in your account. AWS manages those keys outside your account.

Build Your Key Decision Framework

Customer managed keys offer policy and lifecycle control. Your symmetric encryption key can use automatic rotation because it has AWS_KMS origin.
Customer managed asymmetric and HMAC keys require manual rotation. Each customer managed key costs $1/month (prorated hourly) plus applicable request charges.
AWS managed keys are visible under AWS managed keys. AWS controls their permissions and lifecycle.
AWS managed keys rotate every year on a fixed schedule. They have no monthly key-storage fee.
AWS owned keys are outside your account. They provide no customer policy or lifecycle control.
AWS owned keys have no storage or usage charge. Their metadata is not visible in your account.

Secret mission

Prove Tampering Breaks Authentication

Change only the authenticated message while preserving the original MAC. Prove that the changed message fails verification before the original message succeeds again.

Clean Up Your Resources

Choose whether to keep your AWS Key Management Service (AWS KMS) keys enabled, disable them for a pause, or schedule them for deletion. The local ~/kms-key-lab folder has no AWS cost, but each customer managed key continues to incur storage charges until deletion is scheduled.

Cost warning

Each customer managed KMS key costs $1/month (prorated hourly). Applicable cryptographic request charges may also apply.

Key storage charges stop while a key is scheduled for deletion. Charges resume if deletion is canceled.

Resources you used:

A customer managed symmetric encryption key recorded as SymmetricKeyId.
A customer managed asymmetric encryption key recorded as AsymmetricKeyId.
A customer managed HMAC key recorded as HmacKeyId.
The local ~/kms-key-lab folder containing encryption files, authentication files, and tampering-test evidence.

Keep everything running

No action needed. Choose this if you want to repeat the encryption and authentication experiments later.

Keep SymmetricKeyId enabled for symmetric encryption experiments.
Keep AsymmetricKeyId enabled for RSA encryption experiments.
Keep HmacKeyId enabled for message authentication experiments.
Keep ~/kms-key-lab on your Mac as evidence of the completed round trips and tampering test.

All three keys remain ready for more cryptographic operations. Each key continues to incur its storage charge.

Pause - I'll come back to this later

Disabling the three keys blocks new cryptographic operations while preserving them for later. Key storage charges continue while the keys are disabled.

Return to the AWS Management Console from your earlier key comparison.
Open AWS KMS from the service search.
Select Customer managed keys in the navigation pane.
Choose the key whose ID matches SymmetricKeyId.
Use the key controls to disable the selected key.

The symmetric key now shows a disabled state. New encryption requests using that key are blocked.

Choose the key whose ID matches AsymmetricKeyId.
Use the key controls to disable the selected key.
Choose the key whose ID matches HmacKeyId.
Use the key controls to disable the selected key.

All three customer managed keys now show a disabled state. Your files remain available in ~/kms-key-lab.

Delete - I don't want to use this again

This option schedules all three keys for deletion with a 15-day pending window. It also removes ~/kms-key-lab from your Mac.

Permanent key deletion deserves a careful pause. The waiting period gives you time to cancel before AWS KMS removes the key material.

Switch back to macOS Terminal from earlier.
Replace arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab in the command below with the value recorded as SymmetricKeyId.
Schedule the symmetric key for deletion by running the edited command:

aws kms schedule-key-deletion --key-id arn:aws:kms:us-west-2:123456789012:key/1234abcd-12ab-34cd-56ef-1234567890ab --pending-window-in-days 15

What does this command do?

The aws kms schedule-key-deletion command starts the deletion lifecycle for the selected customer managed key.
The --pending-window-in-days 15 option sets a 15-day waiting period.
AWS KMS stops charging for key storage while the key is scheduled for deletion.

Confirm the response shows KeyState as PendingDeletion.
Press the Up Arrow key in Terminal to recall the deletion command.
Replace the current key ID with AsymmetricKeyId.
Run the edited command again.

You should see KeyState as PendingDeletion for the asymmetric key.

Press the Up Arrow key in Terminal to recall the deletion command.
Replace the current key ID with HmacKeyId.
Run the edited command again.

You should see KeyState as PendingDeletion for the HMAC key. That is the risky part handled. All three keys are now inside their deletion waiting periods.

Do you not see PendingDeletion?

Check that the AWS Command Line Interface (AWS CLI) still points to the verified Region.
Check that the active identity has permission to schedule deletion for the selected key.
Retry after a short pause if the updated key state has not propagated.
Help me diagnose why my KMS key deletion was not scheduled.

Local deletion is permanent

Deleting ~/kms-key-lab permanently removes your plaintext, ciphertext, MAC, and tampering-test evidence files from that folder.

Leave the lab directory and remove it by running these commands:

cd ~
rm -rf ~/kms-key-lab

What do these commands do?

The cd ~ command moves your Terminal session out of the lab directory.
The rm -rf ~/kms-key-lab command removes the lab folder and every evidence file inside it.

List the contents of your home directory by running this command:

ls ~

You should no longer see kms-key-lab in the output. Your local lab evidence is now removed.

Still see the lab folder?

Check that the first cleanup command moved your Terminal session to your home directory.
Check that the deletion path exactly matches ~/kms-key-lab.
Help me remove the remaining lab folder safely.

Nice Work!

You did it! Your AWS Key Management Service (AWS KMS) key decision lab now turns cryptographic key choices into visible evidence.

You've learned how to:

Complete symmetric encryption and asymmetric encryption round trips that recover the original plaintext with the correct key type and algorithm.
Expose an enforced boundary by watching an HMAC key reject an incompatible encryption operation. Generate a valid MAC to prove message authenticity without exposing secret key material.
Build a KMS key decision framework by comparing customer managed keys with AWS managed keys and AWS owned keys across control, visibility, rotation, lifecycle, and cost.
Secret Mission: Prove that tampering breaks authentication by verifying TamperedEncodedMessage against the unchanged ExampleMac. Restore EncodedMessage and confirm that the same MAC succeeds.

Ready to quiz yourself?