See the previous part “Security in AWS – Part 4

Domain 5: Data Protection

Data protection in AWS focuses on keeping information secure throughout its entire lifecycle while stored, in transit and during processing. It combines encryption, key management and secret handling to make sure that sensitive data remains private even if the underlying storage or infrastructure is compromised. AWS provides multiple layers of protection allowing organizations to meet security, regulatory and operational requirements without adding unnecessary complexity.

This domain covers how AWS services such as AWS Key Management Service (KMS), CloudHSM, Secrets Manager and encryption features built into services like RDS or Application Load Balancer (ALB) work together to protect data. It also explains how encryption keys are created, stored and used through mechanisms like envelope encryption and imported key material.

AWS Key Management Service (KMS) and CloudHSM

AWS Key Management Service (KMS) is the central service that creates, stores and manages encryption keys across AWS. It provides a consistent and secure way to protect data at rest and supports services that use encryption for data in transit. KMS integrates with most AWS services (including S3, RDS, EBS, SNS, SQS, Secrets Manger and other) so that encryption can happen automatically as part of normal operations, rather than being an extra step in application code.

With KMS, organizations can choose between AWS managed keys and customer managed keys. AWS managed keys are created and rotated automatically by AWS and are ideal for workloads that only need encryption without customization. Customer managed keys (CMK), on the other hand, offer full control over key rotation, usage permissions and lifecycle management. They can be used to define key policies, enable automatic rotation every year and restrict which IAM roles or AWS services can use them.

Figure 1 – KMS managed key

Each KMS key is backed by a secure root of trust stored in AWS Hardware Security Modules (HSMs), which are validated under FIPS 140-3 Security Level 3. These devices perform all cryptographic operations in isolated hardware so that plaintext key material never leaves the boundary of AWS control. When an application or AWS service encrypts or decrypts data using KMS, the service never receives the actual key. Instead, it asks KMS to perform the cryptographic operation on a small piece of data called a data key. This approach is known as envelope encryption.

Envelope Encryption

Envelope encryption uses two layers of protection. A data key is first generated locally to encrypt the actual content, such as an S3 object, a database record or a log file. That data key is then itself encrypted with a KMS master key (CMK). The encrypted data key and the ciphertext are stored together, while the master key remains protected and managed by KMS.

This model provides both performance and security. Applications can encrypt large amounts of data quickly using local data keys while maintaining centralized control over key access and audit through KMS. Even if encrypted data and the wrapped data key are leaked, they remain unreadable without access to the master key. All requests to use a KMS key are logged in AWS CloudTrail, providing full traceability for every encryption and decryption event.

CloudHSM

For organizations that require full control over their cryptographic infrastructure, AWS offers CloudHSM. It is a managed hardware security module service that provides customers with dedicated FIPS 140-3 Security Level 3 validated devices. Unlike AWS KMS, where keys are managed by AWS within a shared service, each CloudHSM appliance is fully owned and operated by the customer, giving exclusive access to the cryptographic material stored inside. AWS administrators cannot view or retrieve the keys, ensuring complete isolation.

CloudHSM is commonly used in industries that must meet strict regulatory and compliance standards such as finance, healthcare or government. It enables customers to generate and manage their own encryption keys, digital signatures and certificate authorities while still benefiting from the scalability and automation of the AWS Cloud.

Storage and Encryption at Rest

EBS Data Protection

Protecting stored data is a key part of infrastructure security. Amazon Elastic Block Store (EBS) provides persistent storage for EC2 instances, so each volume can be encrypted using AWS Key Management Service (KMS). Encryption ensures that data remains secure both while stored and while being transferred between the instance and the disk. Organizations can use either AWS-managed keys or create their own CMK keys for tighter control.

Automatic encryption can also be applied to snapshots and backups. This makes sure that copies of data maintain the same level of protection as the original source. The process is transparent to applications, meaning performance remains the same while security improves.

Amazon S3 Data Protection

Amazon S3 is one of the most widely used AWS services for storing data, which makes its protection a critical part of any security strategy. AWS provides multiple layers of built-in and configurable features to ensure that data stored in S3 remains private, durable and compliant with organizational and legal requirements. These features include encryption, access control, versioning and immutability through Object Lock.

S3 supports several encryption methods, giving flexibility depending on the level of control required. The simplest option is SSE-S3, which uses AWS managed keys to encrypt each object automatically. This approach requires no setup and protects data transparently without changing how applications access it. The encryption keys are fully managed by AWS, and the process is enabled by default for all new buckets created today.

For organizations that need more control over key management, SSE-KMS integrates S3 with AWS KMS. Each object is encrypted with a data key and that data key is protected by a KMS customer master key. This allows fine-grained auditing and access control, since every key use is logged in CloudTrail. Administrators can define who can use or manage encryption keys and apply policies that restrict specific operations or require multi-factor authentication for sensitive actions.

There is also the option to use SSE-C, where customers provide their own encryption keys directly when uploading or downloading objects. In this case AWS performs the encryption and decryption but never stores the keys, which means full responsibility for key management stays with the customer.

To prevent accidental deletions or overwrites, S3 supports versioning. When enabled, each change to an object creates a new version rather than replacing the previous one. This allows recovery from mistakes or corruption by simply restoring an earlier version. Versioning also works together with lifecycle policies so that older versions can be archived or deleted automatically after a set time, keeping storage usage under control. S3 also maintains integrity checks for each object using checksums. When data is uploaded or downloaded, these checksums ensure that the content has not been altered or corrupted during transmission or storage.

For data that must remain immutable for compliance or audit purposes, S3 Object Lock prevents objects from being deleted or modified for a defined retention period. It supports two modes: governance mode, where only authorized users with special permissions can override the lock, and compliance mode, which enforces full immutability even for administrators. Object Lock is often used for regulatory archiving, legal holds or tamper-proof log storage. When combined with CloudTrail or Security Hub, it guarantees that audit data cannot be changed or removed, preserving an accurate record of activity across the environment.

Even with strong encryption, data security also depends on who can access it. S3 provides several layers of access control. Bucket policies define permissions at the bucket level, specifying which users or accounts can perform actions such as uploading or listing objects. S3 also includes Block Public Access settings that prevent accidental exposure of data on the internet. These settings override any policy that would otherwise make objects public. This ensures that data stays private by default, even if someone misconfigures permissions.

All data stored in S3 is automatically distributed across multiple availability zones within a region. This built-in redundancy protects against hardware failures and ensures high durability without manual intervention.

AWS Secrets Manager

AWS Secrets Manager protects sensitive information such as database passwords, API keys or OAuth tokens. Instead of hardcoding credentials into applications or storing them in configuration files, Secrets Manager provides a secure and centralized vault where secrets can be stored, retrieved and rotated automatically.

Secrets are encrypted with AWS KMS keys ensuring that they remain protected at rest. Secrets Manager can automatically rotate credentials for supported services like RDS reducing the risk associated with long-lived passwords. Access to each secret is controlled through IAM policies so only authorized users or applications can retrieve them.

By using Secrets Manager, organizations can eliminate one of the most common security risks, storing plain-text credentials in code or version control systems. Combined with AWS CloudTrail and CloudWatch, every access or change to a secret is logged and can be monitored in real time.

Application Load Balancer (ALB) Security Policies

Data protection also covers how information is transmitted. Application Load Balancers handle encrypted traffic between users and AWS applications through TLS (Transport Layer Security) and mTLS. ALB security policies define which encryption protocols and ciphers are allowed, ensuring that only modern, secure versions such as TLS 1.2 or TLS 1.3 are used.

These policies can be customized to meet compliance requirements or align with organizational standards. For example, older protocols like SSLv3 or TLS 1.0 can be disabled to prevent known vulnerabilities. ALB integrates with AWS Certificate Manager to automatically manage and renew SSL or TLS certificates, ensuring that encrypted connections remain valid and secure without manual intervention.

Figure 2 – ALB listener settings

Amazon RDS Encryption and IAM Authentication

Amazon RDS (Relational Database Service) supports encryption at rest and in transit, ensuring that sensitive data is protected whether it is stored on disk, backed up or transmitted between applications. RDS encryption is handled by KMS which secures both the underlying database storage and any snapshots or replicas derived from it.

For additional security, RDS supports IAM database authentication. Instead of using static passwords, database users can connect using temporary authentication tokens issued by IAM. These tokens are valid only for a short period, removing the need to store or rotate database passwords manually. This reduces the risk of credential exposure while keeping the connection process smooth for legitimate users and applications.

RDS encryption and IAM authentication together ensure that sensitive data stored in databases is secure by design both technically and operationally.

Real-Use Case Scenario

In this section, we demonstrate how services, representing AWS Data Protection Domain, can be implemented through a real-life architecture example.

Imagine an infrastructure where a backend application, running in a container within an Amazon EKS cluster, needs to access an Amazon RDS database.

We do not want to store RDS credentials or connection strings directly in the application code. Instead, this sensitive information is securely stored in AWS Systems Manager Parameter Store. When the application starts, it retrieves the necessary parameters, such as connection strings and database credentials, securely in transit using IAM-based access. This ensures that no secrets are hardcoded or exposed within the code or container image.

To further enhance security and performance, Amazon RDS Proxy is introduced as an intermediary between the containerized workload in EKS and the RDS instance. RDS Proxy manages and pools database connections, reducing load on the database and preventing connection exhaustion. It also adds an additional security layer by isolating direct database access from the application.

RDS Proxy relies on AWS Secrets Manager to store and manage database credentials. For each proxy, Secrets Manager holds the username and password credentials for the database users that the proxy connects to. A separate secret is created for every database user account. When an application connects to the RDS Proxy, the proxy retrieves the corresponding credentials from Secrets Manager and uses them to authenticate against the RDS instance. This means that the application authenticates only to RDS Proxy, while Secrets Manager securely handles the actual database credentials behind the scenes.

Importantly, that all the components in this architecture, like AWS Secrets Manager, AWS Systems Manager Parameter Store, Amazon RDS storage and EKS worker nodes EBS volumes use AWS Key Management Service (KMS) for encryption and decryption of data at rest. KMS ensures that all stored data, credentials and parameters remain encrypted and protected according to AWS best practices for data protection.

This architecture ensures that application secrets are securely managed, database credentials are not exposed and communication between all components is encrypted both in transit and at rest, providing a robust, compliant and maintainable security model.

Figure 3 – Data Protection

Data Protection Recap

FunctionPrimary ServicesObjective
Centralized key management and Layered encryption modelAWS Key Management Service (KMS), Envelope EncryptionCreate, manage and control encryption keys across AWS servicesCombine data keys and master keys for scalable and secure data protection
Hardware-based key controlAWS CloudHSMProvide dedicated cryptographic hardware for complete ownership of keys
External key integrationKMS with Imported Key MaterialAllow customer-generated keys while keeping AWS lifecycle and audit features
Secret storage and rotationAWS Secrets ManagerSecurely store, encrypt and automatically rotate passwords or tokens
Encrypted communicationApplication Load Balancer (TLS Policies, ACM)Enforce secure protocols and manage SSL or TLS certificates
Encrypted data storageAmazon RDS with KMS and IAM AuthenticationEBS and S3 with KMS encryptionProtect data at rest and in transit and replace static passwords with temporary credentials

See the next part: Security in AWS – Part 6

By Pavel Luksha, Senior DevOps Engineer, Klika Tech, Inc.