LEARN. PRACTICE. GROW.1. Inventory encryption scope
An encryption indicator is useful only when its scope is known. Record volume, snapshot, database, channel, and endpoint separately. EBS encryption by default is a regional setting for new resources within its scope; it does not convert old volumes. Evidence collected in eu-west-1 does not establish configuration in eu-central-1. EBS encryption protects data at rest and the path between EC2 and attached storage without automatically turning external HTTP into TLS. In an obsolescence project, connect inventory to required migration actions and responsible teams. If legacy resources remain unencrypted, report that gap explicitly instead of counting setting enablement as completion for the entire application.
2. Treat new keys as migrations
The key associated with an existing EBS volume or snapshot does not change by editing an alias. A snapshot copy permits another key and preparation of a new volume. Plan cutover and preservation of data written after the snapshot. When an API receives an invalid KMS identifier, failure can be asynchronous; confirm final state before accepting creation. When sharing an encrypted snapshot, also check access to the customer managed key. Resource authorization and cryptographic authorization are different dependencies. The change package should identify source, copy, destination key, permissions, functional validation, and criteria for retiring old resources. Do not remove the recovery path merely because a copy request was accepted.
3. Distinguish an RDS copy from a migrated service
An encrypted RDS DB instance retains the key selected at creation. To use another key identifier, prepare a snapshot, a copy with the intended key, and restoration into a new instance. For an unencrypted source, an encrypted snapshot copy is the required step before restoration. A snapshot protected by the AWS managed key cannot be directly shared across accounts in that state. Encrypted replicas in the same Region use the source key; in another Region, define the destination key. These DB instance rules should not be generalized to every Aurora design. In the payments scenario, validate reconciliation, connectivity, and pending data before changing the application destination. DNS neither synchronizes data nor proves usable rollback.
4. Prove TLS and server identity
Encrypting RDS at rest does not prevent an authorized SQL client from obtaining plaintext results; decryption is transparent. For the PostgreSQL channel, apply effective rds.force_ssl configuration when requirements demand rejection of non-TLS connections. Test both permitted and rejected connections. In a libpq client, verify-ca checks the chain and verify-full adds hostname matching. Encryption and identity are related but distinct guarantees. During a CA change for direct RDS clients, prepare application trust before changing the server and confirm restart requirements for the version used. An old connection still open does not demonstrate a new handshake with the new chain. Include creation of new connections in acceptance criteria.
5. Locate validation in load balancers and APIs
An ALB HTTPS target group encrypts the backend path, but ALB does not validate those target certificates. Do not use that configuration as proof of expired-certificate rejection. On the client side, mutual TLS passthrough delivers the chain for target validation; verify performs authentication at ALB. If requirements include revocation, also confirm the mechanism and currency of relevant lists. In API Gateway REST, mutual TLS on a custom domain does not disable the default execute-api endpoint. Testing only the advertised hostname can overlook that alternate path. Draw each segment and identify where the certificate is presented, which identity it represents, and which component decides. An HTTPS label on the diagram does not answer all those questions.
6. Separate issuance, renewal, and deployment
ACM does not provide managed renewal for certificates imported from an external CA. The team must obtain renewal and manage reimport or replacement and associations. Exportable public certificates issued by ACM have another lifecycle: ACM manages renewal, but deployment onto the external host remains the customer responsibility. A server can present the old certificate while the central manager already shows the new version. Protect the private key and verify every endpoint after installation. For ALBs in different Regions, make the ACM certificate available in each relevant Region. For a CloudFront viewer certificate, the requirement is us-east-1 regardless of origin location. Do not generalize that exception to all load balancers.
7. Accept the change with execution evidence
The local exercise uses fictional endpoint inventory and observed serials to decide whether installation is complete. It performs no handshakes, validates no chains, and does not replace real diagnostic tools. A missing endpoint keeps acceptance pending even when every observed endpoint has the intended serial. For a real change, add chain, hostname, validity, protocol, and functional behavior to agreed criteria. Distribute tasks across PKI, cloud, application, and RUN with weekend owners. Plan recovery without assuming that an already revoked certificate can be reused. This lesson connects intended configuration to the created resource, exercised connection, and accepted service. These complementary forms of evidence should accompany reporting, handover, and decommissioning.
# Original fictional deployment-evidence model, not a TLS validator.
# No credentials, network calls, or certificate changes.
def deployment(required, observed, expected_serial):
if not required or not required.issubset(observed):
return "evidence-incomplete"
if any(observed[name]!= expected_serial for name in required):
return "old-certificate-present"
return "serials-match-further-validation-required"
assert deployment(set, {}, "new") == "evidence-incomplete"
assert deployment({"a", "b"}, {"a": "new"}, "new") == "evidence-incomplete"
assert deployment({"a", "b"}, {"a": "new", "b": "old"}, "new") == "old-certificate-present"
assert deployment({"a", "b"}, {"a": "new", "b": "new"}, "new") == "serials-match-further-validation-required"
assert deployment({"a"}, {"a": "new", "out-of-scope": "old"}, "new") == "serials-match-further-validation-required"
print("five deployment-evidence cases passed; no TLS connection was made")
The certificate manager shows renewal, but two servers still present the old version. The team validates deployment per endpoint.
Common pitfalls
Default as legacy migration; snapshot as restored service; TLS as every verification; renewal as deployment.
Related topics: Identity and data · Acceptance and continuity
Confirm the resource and endpoint in use; intended configuration and central issuance do not demonstrate the complete outcome.
Reference: EBS encryption by default · SCS-C03