A healthcare application stores documents in S3, connection credentials in a secret store, and customer sessions behind an HTTPS load balancer. The architecture diagram shows three padlock icons and is declared secure. During a restore drill, however, a disaster-recovery role cannot decrypt yesterday’s backup, a rotated database password is still cached by one service, and a certificate is about to expire on an old listener. Encryption was configured, but key access, credential lifecycle, and transport trust were never designed as one operational system.
The AWS SAA-C03 secure-architecture domain asks candidates to choose appropriate data controls, key management, TLS, certificate renewal, recovery, and policy boundaries. The earlier S3 access and bucket-policy discussion explains who can reach object data. This article addresses the additional question: after that access is granted, is the data protected throughout storage, transfer, rotation, and recovery?
Classify information before selecting a cipher
Start with the data owner, required retention, legal or regional constraints, authorized readers, and restoration requirement. Public website assets, internal application logs, regulated customer records, and an administrator’s API token have different threat models. A blanket instruction to encrypt everything may be sensible as a baseline, but it does not specify key ownership, sharing, audit obligations, or how deleted and replicated records are handled.
For each data flow, mark the boundary where plaintext is created, where encryption is applied, where decryption is permitted, and where keys or temporary tokens are obtained. The same object may be encrypted at rest while an old application still transmits it over an unprotected service endpoint. Architecture review should follow the complete route of the data, not rely on one storage-service setting.
Distinguish S3-managed encryption from KMS key control
Amazon S3 supports server-side encryption models including S3-managed keys and AWS Key Management Service integration. SSE-S3 offers a managed baseline without making an application team operate its own keys. SSE-KMS introduces explicit KMS key authorization and key-management options that may be useful for auditing or separation of duties. Neither mode makes bucket-level resource access irrelevant: a principal needs the applicable S3 permissions, and KMS-protected objects can additionally require the correct KMS permissions.
A proposed move from SSE-S3 to customer-managed SSE-KMS should therefore document who can administer the key, who can use it, which services act on a principal’s behalf, and what happens during a cross-account copy or cross-Region recovery. Adding an encryption setting without updating the permitted restore role can create an apparently successful backup that cannot be recovered by the designated team.
Understand the independent KMS policy decision
A KMS key has a key policy. IAM identity policies can contribute to KMS authorization only when the key policy allows the relevant use of IAM policies; grants and service context may also matter. The AWS KMS permissions guide makes that boundary explicit. A general-purpose administrator policy in a different account is not sufficient evidence that a replica key will permit the expected cryptographic operation.
Test a read using a role that should succeed, then test a second role that should be denied. Record the requested action such as decrypt, the particular key ARN and Region, and the service context. Avoid making a key policy so broad that every principal can decrypt sensitive data merely to clear an access-denied message. A correctly restricted key is allowed to deny requests.
Separate password storage from password rotation
AWS Secrets Manager can store and retrieve application credentials under controlled access, with encryption backed by KMS. Rotation, however, is an application and database integration problem as well as a schedule. If a secret changes but a long-lived service continues to use the previous credential, the secret is secure in storage while the application still fails to connect. Plan rotation workflows, the method used to update the target system, retry behavior, and observability before enabling a strict rotation policy.
A service should obtain the secret through a scoped role and handle caching deliberately. Avoid hardcoding passwords in an AMI, container image, or deployment template. Treat access to the secret and permission to decrypt its backing KMS data key as related but distinct controls. The Secrets Manager encryption model documents how requests can involve KMS on the caller’s behalf; the service itself is not a substitute for explicit IAM design.
Use TLS and ACM at the right termination points
AWS Certificate Manager supports managing certificates for supported integrated services such as application load balancers and CloudFront. TLS protects a connection between specific endpoints; terminating it at an edge does not automatically encrypt every hop to an origin or internal application. For a public application, map client-to-edge TLS, edge-to-origin protection, certificate trust, supported protocols, and how renewals reach the actual production listener.
Certificate rotation needs testing. A newly issued certificate sitting in inventory does not mean the listener is using it. Inspect the hostname, trust chain, expiration date, and the exact deployed endpoint. An internal client that does not trust the replacement issuer can fail while an external browser works normally. Prevent emergency exceptions that disable certificate verification to make deployment appear successful.
Design data replication without assuming copied data is accessible
Cross-Region replication or backup can protect data from regional disruption, but the destination’s access model may differ. Check bucket ownership, replica key, IAM role assumptions, retention controls, and whether recovery users can access the destination account. An isolated recovery copy is valuable only if it can be restored by the people or automation responsible during an actual incident.
Separate availability from data correctness. Replication can carry a logical delete, corruption, or unwanted overwrite to another Region. Point-in-time backups and version history still matter. The existing backup and cross-Region recovery analysis treats recovery objectives and failover; encryption architecture must make that recovery path operable without opening unnecessary standing privileges.
Review data retention and exposure as a lifecycle
Security controls must extend to audit logs, temporary exports, backups, and generated reports. A carefully encrypted production database can still leak through a plaintext diagnostic export uploaded to a public bucket. Classify derived data, set lifecycle and retention according to business obligations, and audit who can create public access or alter key policy. S3 Block Public Access is valuable, but it does not replace least-privilege identities or safe handling of presigned access paths.
When data reaches its authorized retention limit, determine which copies can be deleted and which must be held. KMS key deletion is a high-impact process and should never become an unreviewed shortcut for deleting records. Consider immutable retention controls where applicable, while maintaining an accountable way to correct mistaken classification or comply with legal requirements.
Rehearse a recovery that exercises every security layer
A useful lab creates a test S3 bucket, a test secret, an HTTPS front end, and a separate restoration role. Encrypt the test object, back it up or copy it through the intended route, and retrieve it using the recovery role. Then deliberately remove one permission at a time: object read, key decrypt, secret retrieval, and TLS trust. Each failure should produce different evidence rather than a generic complaint that the cloud is down.
Complete the runbook with concrete facts: which role assumed access, which key and Region were used, which certificate served the connection, how a rotated password reached the application, and which logs document the change. Protect test keys and credentials rather than publishing them. The architectural objective is controlled use of data throughout its life. Encryption, key authorization, credential rotation, TLS, and backups protect different parts of that life and must be tested together.