Lesson 1.6: Secrets and encryption architecture
Protecting sensitive data in AWS requires deliberate architectural decisions. AWS provides encryption services, secret storage services, and access control mechanisms, but none are secure by default without correct configuration. Developers are responsible for deciding how data is encrypted, where secrets are stored, and how access to storage services such as Amazon S3 is controlled. This lesson examines AWS Key Management Service (KMS), envelope encryption, secret storage options, and S3 access control mechanisms.
Encrypting data with AWS KMS and envelope encryption
AWS Key Management Service (KMS) manages cryptographic keys used to encrypt data across AWS services. KMS supports customer-managed keys (CMKs), which define key usage policies, access control, and rotation configuration. Many AWS services integrate directly with KMS:
- Amazon S3 can use KMS keys for server-side encryption (SSE-KMS)
- Amazon RDS can encrypt storage using KMS keys
- Amazon EBS volumes can be encrypted with KMS-managed keys
- AWS Lambda environment variables can be encrypted using KMS
KMS enforces access control through IAM policies and key policies. Access to use a key (for encryption or decryption) must be explicitly allowed.
Envelope encryption is a common pattern used by AWS services and applications. In this model:
- Data is encrypted with a data key
- The data key is encrypted with a KMS CMK
This allows KMS to handle small key encryption rather than encrypting large datasets directly.
import boto3
import base64
kms_client = boto3.client('kms')
# Generate data key
response = kms_client.generate_data_key(KeyId='alias/MyKey', KeySpec='AES_256')
data_key_plain = response['Plaintext']
data_key_encrypted = response['CiphertextBlob']
# Use data key to encrypt application data
ciphertext = my_encrypt_function(data, data_key_plain)
Design considerations include:
- Whether to use AWS-managed keys or customer-managed keys
- Whether key rotation is required
- Whether cross-account key usage is necessary
Encryption configuration is not automatic. Developers must explicitly enable it and ensure IAM policies allow proper key usage.
Secrets Manager vs. Parameter Store
Applications require secrets such as database credentials, API keys, and OAuth tokens. Hardcoding secrets in code or environment variables is risky. AWS provides two primary secret storage services:
- AWS Secrets Manager: Designed for secret management, supports automatic rotation, versioning, and fine-grained access control. Secrets are encrypted using KMS and retrieved via API calls at runtime.Use Secrets Manager when:
- Automatic rotation is required
- Secrets are database credentials or frequently rotated keys
- Built-in life cycle management is needed
- AWS Systems Manager Parameter Store: A general-purpose configuration store that can also hold secrets. Values are encrypted using KMS, and automatic rotation must be implemented externally. Use Parameter Store when:
- Storing configuration values or less-critical secrets
- Rotation is handled externally
- Cost sensitivity is important
aws secretsmanager create-secret \
--name MyDbPassword \
--secret-string '{"username":"admin","password":"Pa$$w0rd"}' \
--description "Database credentials for MyApp"
At runtime, applications retrieve secrets using SDK calls. IAM policies attached to EC2 instance roles or Lambda execution roles control access. Developers must ensure:
- Least privilege access to secrets
- Encryption using KMS
- No logging of secret values
- Secure handling in memory
Secret management is part of application architecture, not infrastructure maintenance.
Integrating encryption and secret architecture
Secure application architecture on AWS requires alignment between data encryption, secret management, and access control. These components work together to protect sensitive information, ensure authorized access, and maintain compliance.
Encryption at rest and in transit
Data at rest should always be encrypted using service-native encryption options or AWS KMS-managed keys. For example, S3 objects can use SSE-KMS, RDS databases can use KMS-encrypted storage, and DynamoDB tables can enable KMS encryption. Data in transit should be protected using TLS or HTTPS, ensuring that network communication between clients, applications, and AWS services remains secure.
Secret management
Secrets, such as database passwords, API keys, or OAuth tokens, should never be hardcoded in application code or configuration files. AWS provides services like Secrets Manager or Parameter Store to store secrets securely, manage rotation, and enforce access policies. Secrets are retrieved programmatically at runtime using SDKs or service integrations.
Access control alignment
IAM roles and policies define which identities or resources can access secrets and encrypted data. Properly scoped identity-based and resource-based policies prevent unauthorized access. For example, a Lambda function should assume an execution role that permits reading a specific secret, and an S3 bucket should enforce encryption and restrict access using bucket policies or Block Public Access settings.
Putting it together
A secure workflow might involve:
- A Lambda function retrieving a database password from Secrets Manager.
- The Lambda execution role is scoped to access only that secret.
- The database (RDS or DynamoDB) stores data encrypted with KMS.
- S3 buckets storing application data enforce SSE-KMS encryption and block public access.
- All network communication uses TLS endpoints.
My name is Naeem ul Haq. I’ve been working with AWS since its early days and have deep expertise across its evolving ecosystem.
