Understanding Encryption: In Transit vs At Rest

Encryption is like putting your data in a locked safe. But where and when you lock it matters. In AWS, data can be encrypted in two main ways:

In Transit: This protects your data while it’s moving—like when it’s being sent over the internet or between AWS services. Think of it like sending a message through a secure envelope instead of a postcard. AWS uses HTTPS (TLS/SSL) to encrypt this traffic by default for most services.

At Rest: This secures your data while it’s stored—on a hard drive, in S3, in a database, etc. It’s like locking that envelope in a vault once it arrives. AWS offers encryption-at-rest for nearly every storage service, typically using AES-256.

How Encryption Works: Keys, Secrets, and Cryptography

At its core, encryption is the process of converting data into a scrambled format that can only be read with the right key. In the AWS world, this is crucial for protecting data across services.

There are two primary types of encryption methods:

1. Symmetric Encryption: The same key is used to encrypt and decrypt the data. It’s fast and common in AWS for services like S3, EBS, and RDS. When you use AWS-managed or customer-managed keys (CMKs) in KMS, you’re typically using symmetric encryption. AWS KMS uses AES-256 symmetric keys by default.

2. Asymmetric Encryption: There are two keys—one public, one private. The public key encrypts the data, and only the corresponding private key can decrypt it. This is often used for secure key exchange, digital signatures, and certificate-based encryption.

In asymmetric encryption:

• You can give the public key to anyone.
• Only the private key holder can decrypt the data.
• If someone encrypts data using your public key, only you can read it with your private key.

AWS KMS supports asymmetric key pairs for specific use cases, like digital signing and public key encryption workflows.

When you encrypt something in AWS, here’s what typically happens:

• The service requests a data key from KMS.
• KMS generates a data key and returns two versions: a plaintext key (used briefly) and an encrypted version.
• The service uses the plaintext key to encrypt the data and then discards it.
• The encrypted data key is stored alongside the data and used later for decryption via KMS.

This ensures the encryption keys themselves are never exposed to users or applications directly.

AWS Key Management Service (KMS)

Symmetric vs Asymmetric Keys in KMS

Symmetric keys use a single key for both encryption and decryption. These are the default and most common key types in AWS KMS. You never get to see the actual key material—KMS manages it for you. These keys are used for general-purpose encryption of resources like S3 objects, EBS volumes, and RDS storage.

Asymmetric keys use a key pair—one public, one private. You can download the public key to encrypt data or verify signatures outside AWS, but the private key stays securely in KMS. These are often used for digital signing, public-key encryption, or use cases where you need interoperability with other systems.

Four Types of KMS Keys

AWS supports different types of keys depending on who controls and creates them. These differ in cost, flexibility, and control.

1. AWS Owned Keys
   • Automatically used by AWS services when you don’t choose any encryption option (e.g. SSE-S3, SSE-SQS, SSE-DDB)
   • Not visible or configurable by you.
   • Free of charge.
2. AWS Managed Keys
   • Created by AWS for each service (e.g. aws/s3, aws/ebs).
   • Shared across all accounts using that service.
   • Visible in your KMS console, but limited control—no key policy editing.
   • Free to use, but encryption API calls (e.g. Encrypt, Decrypt) incur charges.
3. Customer Managed Keys (CMKs) - Created in KMS
   • Created and fully managed by you.
   • Key ID starts with alias/, and you can set custom names.
   • Supports key rotation (automated every 1 year by default if enabled, but can be set between 90 days and 2560 days).
   • Full control over permissions and audit logging.
   • Charged monthly + per usage call.
4. Customer Managed Keys - Imported Key Material
   • You generate your own key material and import it into KMS.
   • Useful if you have to meet compliance where key material must originate outside AWS.
   • You must manage key rotation manually.
   • Still scoped per region.
   • Priced the same as other CMKs.

Multi-Region Keys

A newer feature in KMS, Multi-Region keys allow you to replicate a key across AWS Regions, so you can use the same logical key for global applications. Use cases include:

• Global apps that need fast, local decryption
• Cross-region backups that require encryption consistency
• Amazon Aurora Global Databases, where data is replicated across regions, and encryption must be consistent across all participating regions
• DynamoDB Global Tables, which replicate table data across multiple AWS Regions; to maintain secure replication, Multi-Region KMS keys are required to ensure uniform encryption across all regions

You replicate a primary key into another region using KMS, and AWS keeps the key metadata and key material in sync. You still manage key policies per region.

Keys Are Scoped Per Region

KMS keys, by default, are regional. If you want to encrypt data in EBS between two regions, you have a few options:

• Use Multi-Region Keys, if supported by your use case.
• Or, create separate KMS keys in each region, and re-encrypt the data after replication.
• Ensure that any cross-region application or backup workflow has access to the KMS key in the destination region.

Key Policies

Key Policies in KMS are similar to S3 bucket policies. They are JSON documents that define who can use or manage a KMS key.

• Default Key Policy: When you create a CMK, AWS generates a default policy that grants full access to the creating account.
• Custom Key Policy: You can write your own policy to allow fine-grained control or cross-account access. For example, if Account A owns the key but Account B needs to encrypt/decrypt using it, you’ll need to explicitly grant those permissions in the key policy.

Key policies are powerful and must be managed carefully, especially when integrating with IAM policies. They determine the full access model for the key, including usage from Lambda, EC2, and external accounts.

S3 Replication with Encryption

S3 offers Cross-Region Replication (CRR) and Same-Region Replication (SRR), but encryption adds complexity.

• If using SSE-S3 (AWS manages key), replication just works.
• If using SSE-KMS, you must:
  • Grant the destination account permission to use the KMS key
  • Make sure the destination bucket has access to the right key

You can replicate encrypted objects, but both source and destination must handle the encryption requirements properly.

Sharing Encrypted AMIs

You can share AMIs (Amazon Machine Images) with others, but if the AMI is encrypted with a KMS key:

• You must grant the target account access to the encryption key
• The user in the target account must also have permission to launch instances with the AMI

This ensures your encrypted data isn’t leaked when sharing machine images.

SSM Parameter Store

SSM Parameter Store lets you store configuration data and secrets, like database passwords, API tokens, and application settings, in a secure and scalable way.

• Standard parameters are free and support values up to 4KB in size.
• SecureString parameters can be stored in either Standard or Advanced tier and are encrypted using AWS KMS.
• Offers optional seamless encryption using KMS — just specify the key and Parameter Store handles encryption and decryption for you.
• It’s serverless, scalable, and durable, with no infrastructure to manage.
• Includes version tracking, so you can roll back to earlier versions of a parameter if needed.
• Enforces fine-grained IAM permissions to control access at both the parameter and API level.
• Supports EventBridge notifications so you can trigger workflows or alerts on changes to parameters.
• Integrates with CloudFormation, enabling clean separation of configuration and code in infrastructure-as-code workflows.
• Can be accessed from the CLI, Lambda, EC2, ECS, CodeBuild, and other AWS services.

Standard vs Advanced Parameters

SSM Parameter Store supports two tiers of parameters:

Advanced parameters are useful when you need more control — for example, if you want to expire credentials after 30 days or store a longer history of changes. They’re especially helpful in production environments that need parameter lifecycle policies or longer payloads.

AWS Secrets Manager

Secrets Manager is a fully managed service for storing, retrieving, and rotating sensitive information like database credentials, API keys, OAuth tokens, and other secrets. While it serves a similar purpose to SSM Parameter Store, there are key differences in features, automation, and use cases.

Key Features of Secrets Manager

• Automatic rotation of secrets using AWS Lambda. You can define how often secrets should rotate—e.g., every 30 days—and AWS will rotate the credentials automatically, update the secret, and optionally update the target service (e.g., a database).
• Built-in integrations with AWS services like Amazon RDS, Redshift, DocumentDB, and Amazon ElastiCache. These services support automatic credential rotation without having to write custom rotation logic.
• Encryption using KMS. Secrets are always encrypted at rest using AWS KMS. You can choose your own customer-managed KMS key for additional control.
• Fine-grained access control using IAM and resource policies. You can control who or what can read or rotate a specific secret.
• Audit and monitoring through CloudTrail logs and CloudWatch metrics.
• Multi-region secrets, allowing you to replicate secrets across regions to support multi-region applications or cross-region RDS failover setups.
• Versioning, so you can roll back to a previous version of a secret.

Secrets Manager vs Parameter Store

RDS Integration Use Case

Suppose you’re running a production RDS MySQL database. With Secrets Manager:

1. You store the master DB credentials as a secret.
2. You configure Secrets Manager to rotate the password every 30 days using a built-in Lambda rotation function.
3. Secrets Manager will rotate the credentials, update the secret, and update the credentials in RDS at the same time—automatically.
4. Your applications retrieve the new password dynamically using the Secrets Manager API or environment variables.

This ensures your DB password is rotated frequently without any manual effort, improving security posture and reducing the risk of leaked credentials.

Multi-Region Secrets

With multi-region secrets, you can replicate a secret across multiple AWS regions automatically. Use cases include:

• Global apps that run in multiple regions and need consistent access to the same credentials.
• Cross-region failover for RDS global databases, where you replicate your secrets to the failover region to ensure availability during a disaster.
• High availability setups where apps in multiple regions need the same credentials without extra sync logic.

You choose a primary secret, enable replication to target regions, and AWS manages the replication of both the secret data and the KMS encryption context. Any rotation or update to the secret in the primary region gets synced to all replica regions.

When to Use What?

• Use Secrets Manager when:
  • You need automatic secret rotation.
  • You’re storing sensitive credentials or API keys.
  • You need RDS or Redshift credential rotation.
  • You have multi-region or high availability requirements.
• Use SSM Parameter Store when:
  • You’re storing general configuration data or non-sensitive environment variables.
  • You’re fine managing secret rotation yourself.
  • You need to keep costs down for simple setups.

AWS Certificate Manager (ACM)

ACM lets you issue, manage, and renew TLS/SSL certificates for securing websites and services.

• Supports both public and private TLS certificates
• Public certificates are free (great for HTTPS on websites)
• Integrates directly with CloudFront, ELB (ALB/NLB), and API Gateway
• Does not work directly with EC2:
  • You can’t attach an ACM certificate to an EC2 instance directly because ACM only integrates with managed AWS services that handle the TLS termination for you (like ELB).
  • For EC2, you’d need to manually install a cert (e.g., from ACM via export or third-party CA) on a web server like Apache or Nginx.

Certificate Import and Renewal

• You can import external certificates into ACM (e.g., from Let’s Encrypt or another CA).
• Imported certs don’t auto-renew.
• You’ll get a notification 45 days before expiry via Amazon EventBridge so you can renew manually.

ALB Integration with Redirects

• When attached to an Application Load Balancer (ALB):
  • ACM cert handles the HTTPS termination.
  • You can set a redirect rule in the ALB listener to redirect HTTP to HTTPS—simple toggle in the rule config.

API Gateway Integration

ACM integrates differently depending on the endpoint type:

• Edge-Optimized Endpoints:
  • Designed for global clients using Amazon CloudFront.
  • ACM cert must be in us-east-1 (N. Virginia).
  • CloudFront handles TLS using the ACM cert at the edge.
• Regional Endpoints:
  • Used when you want to serve requests directly from a specific AWS region (e.g. for latency-sensitive apps).
  • ACM cert must be in the same region as the API.
• Private Endpoints:
  • For internal use within a VPC via VPC endpoints.
  • Also uses regional certs from ACM, but access is restricted via network and IAM.

Use edge-optimized when you want CDN + global low-latency. Use regional for tighter control and local traffic handling.

AWS Web Application Firewall (WAF)

AWS WAF protects your web apps (Layer 7) from attacks like:

• SQL injection
• Cross-site scripting (XSS)
• Bot scraping or DDoS probe

It works with services like ALB, CloudFront, AppSync GraphQL API, Cognito User Pool and API Gateway. You create rules to allow/block specific patterns (IP, headers, country, etc.) called Web ACLs (Web Access Control List). These Web ACLs are Regional except for CloudFront. A rule group is a reusable set of rules that you can add to a web ACL.

Real-world example: block requests with suspicious query strings or limit request rate from a single IP.

Note: WAF does not support the Network Load Balances (this is on Layer 4). You can however, use a Global Accelerator to get a fixed IP and then implement WAF on the ALB in the same region as the ALB.

AWS Shield

Shield protects against DDoS attacks:

• Shield Standard: Automatically included, protects from common attacks
• Shield Advanced: Adds 24/7 access to the DDoS Response Team, higher-level protection, and detailed reporting. Services covered are EC2, ELB, CloudFront, Global Accelerator and Route53. It automatically creates, evaluates and deploys WAF rules to mitigate layer 7 attacks.

Use Shield Advanced for mission-critical systems exposed to the internet (e.g., ecommerce, public APIs).

AWS Firewall Manager

Use it to define a single security policy that applies across multiple accounts or apps. Rules are applied to new resources as they are created across all and future accounts in your Organization. Great for large orgs that need consistency.

This is the central policy manager for all accounts of an AWS Organization for:

• WAF
• Shield Advanced
• Security Groups for EC2, ALB and ENI resources in VPC
• AWS Network Firewall
• Route53 Resolver DNS Firewall
• Policies are created at the Region level

Amazon GuardDuty

GuardDuty is like having a security guard who intelligently watches CloudTrail logs, VPC Flow Logs, and DNS Logs for signs of trouble.

• Uses Machine Learning algorithms, anomaly detection and 3rd party data
• One click to enable, no need to install software
• Detects suspicious activity like port scanning, credential exfiltration, or anomalous behavior
• Uses machine learning and threat intel
• Alerts can be routed to EventBridge or Security Hub for automated response
• Optionally you can also include EKS Audit Logs, RDS & Aurora, EBS, Lambda, S3 Data Events
• Specific use case is protection against CryptoCurrrency attacks

You don’t install anything; just turn it on and it watches from the sidelines.

Amazon Inspector

Inspector automatically scans for vulnerabilities the following services:

• EC2 instances (running instances only)
• Lambda functions
• Container images

Scanning happens continously, only when needed. Some feautres:

• Identifies outdated libraries or insecure settings
• Package vulnerabilities (EC2, ECR & Lambda) against a database of vulnerabilities (called CVE)
• Network reachability (EC2)
• Supports automated, continuous scanning
• Integrates with Security Hub and AWS Organizations
• Findings can also be sent to EventBridge

Think of it as a vulnerability scanner that lives in your cloud.

Amazon Macie

Macie is all about sensitive data discovery, particularly in S3.

• Uses machine learning to find PII (names, credit card numbers, etc.)
• Helpful for compliance (GDPR, HIPAA)
• Alerts when sensitive data is stored in unprotected buckets

Use Macie if you store user data and need to make sure it’s secure and correctly classified.

Best Practices

• Encrypt everything by default using KMS
• Use IAM roles and policies to restrict access to keys and secrets
• Automate certificate renewals with ACM
• Centralize security policies with Firewall Manager
• Monitor logs and anomalies with GuardDuty, Macie, and Inspector
• Use Secrets Manager for dynamic secrets and automated rotation
• KMS encryption is region-bound unless you use Multi-Region Keys
• Sharing encrypted AMIs? Don’t forget to share the key too
• Secrets Manager has a higher cost than Parameter Store, but adds lifecycle features
• With WAF, your rules apply only to services it’s integrated with, not arbitrary IPs or EC2 instances
• Enabling GuardDuty is simple, but acting on its findings requires integration with other services (EventBridge, Lambda, etc.)

SSM Parameter Store lets you store configuration data and secrets, like database passwords, API tokens, and application settings, in a secure and scalable way.

Summary of AWS Security & Encryption Services