Compliance

Enforce TLS on database and cache connections

One capability across RDS, Aurora, Redshift, DocumentDB, ElastiCache, DAX, MSK, EMR and DMS: every connection to a data store must be encrypted on the wire, not merely allowed to be.

15 min·10 sections·AWS

Last reviewed 16 June 2026

Remediates AWS Security Hub: DMS.9 DMS.12 DocumentDB.6 DynamoDB.7 ElastiCache.5 EMR.4 MSK.1 MSK.3 RDS.36 RDS.38 RDS.39 RDS.41 RDS.43 RDS.44 Redshift.2

Encryption in transit for data stores: the basics

Why "TLS is available" is not the same as "TLS is required"

Almost every AWS data store can speak TLS, and almost none of them require it by default. An RDS for PostgreSQL or MySQL instance presents a certificate but happily accepts a plaintext connection from any client that does not ask for SSL. A Redshift cluster speaks the PostgreSQL wire protocol and will negotiate TLS if the client wants it, or fall back to clear text if it does not. ElastiCache replication groups, DocumentDB clusters, DAX clusters, MSK brokers, EMR clusters and DMS endpoints all share the same shape: encryption is offered but optional. The risk is identical in every case, which is that a single old driver, a forgotten batch job or a misconfigured pipeline ships credentials and query data across the network in the clear.

AWS Security Hub turns each engine's version of this gap into its own control, which is why one estate can fail a dozen in-transit checks at once. RDS.38 looks at rds.force_ssl on PostgreSQL parameter groups; RDS.36, RDS.39, RDS.41, RDS.43 and RDS.44 cover the equivalent enforcement on MySQL, MariaDB, SQL Server, Aurora proxies and the RDS Proxy front door; Redshift.2 checks require_ssl on the cluster parameter group; ElastiCache.5 reads TransitEncryptionEnabled on a replication group; DocumentDB.6, DynamoDB.7 (DAX), EMR.4, MSK.1, MSK.3 and DMS.9 and DMS.12 cover the rest. They look like separate problems on the report, but they are one capability: refuse any connection to a data store that will not encrypt itself.

The mechanics differ by engine, and that detail decides how hard the fix is. RDS and Redshift enforce TLS through a parameter group flag and need a reboot. ElastiCache and MSK fix the in-cluster setting at create time, so the older engines need a rebuild and migration rather than a toggle. DMS enforces SSL on the endpoint definition. The job is to find every data store that permits plaintext, confirm its clients already speak TLS, then flip enforcement on through the right mechanism for each engine.

In this lesson you will learn how each major AWS data store expresses TLS enforcement, why "TLS available" and "TLS required" are different positions, and how to flip enforcement on without breaking a live client. The Controls this lesson covers section lists every Security Hub control in this capability, each linking to a deep page with the exact check and a copy-and-paste fix.

Fun fact

The setting that lives almost everywhere except where you look

The enforcement flag is rarely on the database itself. RDS hides it behind rds.force_ssl (PostgreSQL) or require_secure_transport (MySQL) in a parameter group, and the default parameter group is read-only, so you must create a custom one. Redshift puts require_ssl on a cluster parameter group, also read-only by default. ElastiCache and MSK fix encryption at creation time, so on older engines there is no toggle at all. The result is a control family where teams routinely assume their traffic is encrypted, because most modern drivers negotiate TLS automatically, while the store quietly accepts the one plaintext client that does not. The database never logs a warning about the unencrypted connection it just allowed.

Finding plaintext-permitting data stores across an estate

Priya is the platform lead at a payments company preparing for a PCI assessment. Security Hub shows in-transit encryption failures spread across RDS, Redshift and ElastiCache in two accounts that pre-date the team's current guardrails.

Rather than work the findings one engine at a time, she starts by listing which data stores still permit plaintext, so she can rank them by the data they hold and confirm their clients already speak TLS before changing anything.

Start with the highest-value stores. List every ElastiCache replication group and whether in-transit encryption is on, the exact property ElastiCache.5 evaluates.

$ aws elasticache describe-replication-groups --query 'ReplicationGroups[?TransitEncryptionEnabled==`false`].[ReplicationGroupId,Status]' --output table

-------------------------------------------

| sessions-prod | available |

| cart-cache-prod | available |

-------------------------------------------

# Two cache groups accept plaintext. sessions-prod holds auth tokens; fix it first.

Rank in-transit failures by what the store caches or holds. Auth and payment data first.

How each engine enforces TLSdeep dive

The enforcement mechanism falls into three patterns. The first is a parameter-group flag that needs a reboot: RDS for PostgreSQL uses rds.force_ssl, RDS for MySQL and MariaDB use require_secure_transport, and Redshift uses require_ssl on a cluster parameter group. These are static parameters, so the change takes effect only after a reboot, and the default parameter group is immutable, so you create a custom group first. Security Hub keys off the applied state, so a finding stays FAILED until the reboot lands.

The second is a create-time setting that cannot be toggled in place. ElastiCache exposes TransitEncryptionEnabled and, on Redis OSS 7+, a TransitEncryptionMode of preferred then required for a rolling cutover; older engines must be rebuilt. MSK splits encryption into ClientBroker (how producers and consumers connect) and InCluster (how brokers replicate to each other), and InCluster is immutable after creation, so MSK.1 failures need a replacement cluster and a migration. EMR sets in-transit encryption through a security configuration applied at cluster launch.

The third is an endpoint or proxy setting. DMS enforces SSL through the endpoint definition's SslMode (require, verify-ca or verify-full), covered by DMS.9 and DMS.12; the RDS Proxy enforces TLS on its own listener (RDS.41); DocumentDB requires TLS through the tls cluster parameter (DocumentDB.6); and DAX enforces in-transit encryption as a create-time cluster setting (DynamoDB.7). The common theme is that enabling TLS often surfaces a client that was silently connecting in plaintext, so confirm the clients before you enforce.

What is the impact of a data store that permits plaintext?

The direct risk is interception. With enforcement off, any client that connects without requesting TLS sends its traffic, including the authentication exchange and every row of query or cache data, across the network in clear text. An attacker positioned on the network path, a compromised host in the same VPC, a misconfigured peering link or a malicious insider with packet-capture access, can read credentials and exfiltrate data without ever authenticating to the store. Data stores are a particularly rich target because they concentrate the hottest, most sensitive data in one place.

The compliance impact is usually the one that forces action. These controls map to PCI DSS 4.0 requirement 4.2.1 and the NIST 800-53 data-in-transit family (SC-8, SC-13, SC-23). An open finding is concrete, named evidence that data-in-transit protection is not enforced on a sensitive system, exactly what surfaces in a SOC 2 review, a PCI assessment or an enterprise security questionnaire. Unlike a fuzzy posture note, "this database permits unencrypted connections" is hard to argue with, because the flag is either set or it is not.

The remediation impact varies by engine and is the reason these findings accumulate. Parameter-group fixes are free and quick but need a reboot window. ElastiCache and MSK on older engines need a rebuild and migration, which is real engineering effort, plus an application-side change so clients connect over TLS. The cost is the coordinated change, not the encryption itself, which carries negligible price and performance overhead.

There is a quieter second-order impact: every plaintext-permitting store normalises the next one. If the team's mental model is "the VPC is the boundary, so the database does not need TLS," the next store launches the same way and the finding count grows. Closing this well means changing the default so new stores are born enforcing TLS, which converts an open-ended audit line into a one-time set of migrations plus a guardrail.

How do you enforce TLS on data stores safely?

Work the capability as one loop rather than chasing individual findings. The order matters: audit the clients before you enforce, so you do not refuse a live connection mid-flight, and pick the right mechanism for each engine.

1. Inventory every store that permits plaintext, ranked by data sensitivity

List the in-transit setting for every RDS instance, Redshift cluster, ElastiCache replication group, DocumentDB cluster, DAX cluster, MSK cluster and DMS endpoint across all regions and accounts. Rank the failures by what they hold: anything in PCI scope or holding authentication data goes first. Treat this inventory as the source of truth, not the raw finding count, because one engine family can trigger several controls.

2. Confirm clients already speak TLS before enforcing

The only thing that breaks when you require TLS is a client that connects in plaintext. Query the engine (for example pg_stat_ssl on PostgreSQL) or check access logs and CloudTrail data events to find non-TLS sessions, trace each back to its application, and update the driver to require TLS pointed at the right CA bundle. Do not enforce until that list is empty.

3. Flip enforcement through the right mechanism, highest impact first

For RDS set rds.force_ssl or require_secure_transport in a custom parameter group and reboot; for Redshift set require_ssl and reboot; for DMS set the endpoint SslMode. For ElastiCache on Redis OSS 7+ use the preferred-then-required rolling migration, and for older ElastiCache and MSK build an encrypted replacement and migrate. Verify behaviour, not just the pending value: attempt a deliberate plaintext connection and confirm it is refused.

4. Make TLS-required the default for new stores

Bake the enforcement setting into the shared database and cache modules so new stores launch encrypted, and back it with AWS Config rules and Service Control Policies so the setting cannot be quietly dropped. That converts a recurring audit finding into a one-time set of migrations, after which the control can only appear for legacy stores on a known list.

# Find the highest-impact plaintext-permitting stores across engines.
aws rds describe-db-instances \
  --query 'DBInstances[].DBInstanceIdentifier' --output text
aws elasticache describe-replication-groups \
  --query 'ReplicationGroups[?TransitEncryptionEnabled==`false`].ReplicationGroupId' \
  --output text

# RDS for PostgreSQL: require TLS via rds.force_ssl (static -> needs a reboot).
PG=$(aws rds describe-db-instances --db-instance-identifier prod-orders-pg \
  --query 'DBInstances[].DBParameterGroups[].DBParameterGroupName' --output text)
aws rds modify-db-parameter-group --db-parameter-group-name "$PG" \
  --parameters 'ParameterName=rds.force_ssl,ParameterValue=1,ApplyMethod=pending-reboot'
aws rds reboot-db-instance --db-instance-identifier prod-orders-pg

# Redshift: require_ssl on a custom cluster parameter group, then reboot.
aws redshift modify-cluster-parameter-group --parameter-group-name analytics-tls \
  --parameters ParameterName=require_ssl,ParameterValue=true
aws redshift reboot-cluster --cluster-identifier analytics-prod

Quick quiz

Question 1 of 5

Security Hub shows in-transit encryption failures across RDS, Redshift and ElastiCache. What is the most efficient way to think about them?

Keep learning

Go deeper on how TLS enforcement works across the engines in this capability.

You can now treat database and cache encryption in transit as one capability rather than a scatter of findings: inventory every store that permits plaintext, rank them by the data they hold, confirm clients already speak TLS, then enforce through the right mechanism for each engine (a parameter flip and reboot on RDS and Redshift, a rolling or rebuild migration on ElastiCache and MSK, an endpoint setting on DMS), and make TLS-required the default for new stores. The Controls this lesson covers section below links every control in this group to its deep page and fix.

Back to the library

Encryption in transit for data stores: the cost and risk view

A near-zero-cost capability that maps almost verbatim to PCI, HIPAA and SOC 2

TLS on a database or cache connection costs nothing in AWS spend. There is no per-connection charge and no new infrastructure to buy; the data stores already support encryption and you are simply requiring it. So this whole capability is a compliance and risk item, not a cost-optimisation one, and it belongs on the controls dashboard rather than the bill.

The exposure is in the audit and contract layer. Encryption of data in transit appears almost word for word in PCI DSS, HIPAA, SOC 2 and the NIST 800-53 families that most customer security questionnaires reference. A failing control here is a concrete, ownable exception that can stall a SOC 2 attestation, complicate a PCI assessment or hold up an enterprise deal in security review. The financial risk is indirect: delayed deals and audit findings, not a higher monthly invoice.

The one real cost to budget is timing. Some of these fixes are a parameter flip plus a reboot in a maintenance window; others, on older ElastiCache and MSK engines, need a rebuild and migration that costs a slice of engineering time. The finance move is to prioritise the data stores holding regulated data, give them committed dates, and fund the guardrail that makes new data stores enforce TLS by default so the same findings do not reappear each audit cycle.

This lesson is for the finance or governance partner who sees a cluster of in-transit encryption findings across RDS, Redshift, ElastiCache and MSK and wants to know what the right response is and what it costs. It covers why these controls are free in AWS terms, why a few carry a real migration cost on older engines, how they map to PCI, HIPAA and SOC 2, and how to turn a list of red findings into a risk-ordered remediation plan.

Fun fact

The setting that lives almost everywhere except where you look

How a finance partner frames the in-transit encryption findings

Priya, the platform lead at the payments company, brings the Security Hub export to her finance and governance partner ahead of the PCI assessment. The first instinct in the room is to ask what the remediation will cost. The honest answer reframes the whole conversation: TLS on a database or cache connection adds nothing to the AWS bill. There is no per-connection charge and no new infrastructure to buy. The stores already speak TLS; the team is simply requiring it. So this is not a cost-optimisation item at all, it is a compliance-exposure item that belongs on the controls dashboard, not the invoice.

The real cost the finance partner needs to size is timing and engineering effort, and it is not uniform. The RDS and Redshift findings are a parameter flip plus a reboot in a maintenance window, effectively free. The older ElastiCache and MSK clusters that pre-date the guardrails are different: in-transit encryption is fixed at creation on those engines, so closing ElastiCache.5 and MSK.1 means building an encrypted replacement and migrating to it, which is a real slice of a sprint. The partner ranks the work by what each store holds, gives the PCI-scope stores committed dates, and funds the default-on guardrail so the same findings do not reappear at the next audit cycle.

Why in-transit encryption belongs on the compliance register

The dollar cost of fixing this is essentially zero. TLS on a database or cache adds negligible price and performance overhead, and the only real expense is engineering time for the few stores that need a migration. So treat this as a compliance-exposure item on the controls dashboard, not a cost line.

The exposure that matters is attestation risk. These controls map directly to PCI DSS and the NIST control families behind most enterprise commitments and customer contracts. An open finding on a store holding regulated data is the kind of specific, undeniable gap that can hold up a PCI attestation, a SOC 2 report or a large customer's security review, and those delays carry real revenue and deal-cycle cost even though the technical fix is cheap.

The budget lever is timing and prioritisation. The failure mode is drift: the parameter flip never quite gets a reboot window, or the migration never quite gets a sprint. The finance move is to give the regulated stores committed dates, and to fund the default-on guardrail that beats re-discovering the same finding every audit cycle.

What finance can do about the in-transit encryption gap

Finance cannot flip rds.force_ssl, but it can set the framing that turns a scatter of red findings into a governed, risk-ordered plan with predictable cost and clear ownership. Three levers.

1. Separate the free fixes from the funded migrations

Make the cost picture explicit so nobody treats the whole capability as a single line. The RDS and Redshift findings are a parameter-group flip plus a reboot and cost nothing but a maintenance window. The older ElastiCache and MSK findings need a rebuild and migration that costs real engineering time. Budget only the second category, and budget it as a one-time spend, not a recurring one, because once the store is rebuilt encrypted it stays that way.

2. Risk-weight the stores by the data they hold, not the finding count

The raw count of failing controls is misleading because one engine family can trip several controls at once. The number that matters for finance is which failing stores hold regulated or authentication data, since those are the ones whose open finding can stall a PCI attestation or a SOC 2 report. Put the PCI-scope and auth-data stores at the top of the remediation order with committed dates, and treat a disposable test cache as a lower-priority clean-up.

3. Fund the default-on guardrail to stop the finding recurring

The failure mode is drift: the reboot never quite gets a window, the migration never quite gets a sprint, and the same findings reappear every audit cycle. The finance move is to fund the shared database and cache modules so new stores launch with TLS required, backed by AWS Config rules and Service Control Policies. That converts an open-ended audit line into a one-time set of migrations plus a guardrail, which is far cheaper over time than re-discovering the gap each year.

Quick quiz

Question 1 of 5

What is the direct AWS spend impact of enforcing TLS on a database or cache connection?

Keep learning

Go deeper on how TLS enforcement works across the engines in this capability.

You have finished the finance view of in-transit encryption for data stores. You know the AWS spend is effectively zero, that the only real cost is the one-time engineering effort to rebuild older ElastiCache and MSK clusters, and that the exposure is attestation risk against PCI, HIPAA and SOC 2 rather than a line on the bill. Next time a cluster of in-transit findings appears, you will separate the free flips from the funded migrations, risk-weight by the data each store holds, and fund the guardrail that stops the finding coming back.

Back to the library

Encryption in transit for data stores: the headline

Whether the connections into the company's databases are encrypted by configuration or only by hope

Every database and cache the business runs is the place its most sensitive data lives. This capability is about whether the connections into those stores are encrypted on the network, or merely permitted to be. By default most AWS data stores accept a plaintext connection, which means a single misconfigured client can send customer records and credentials across the network in the clear, and the report shows this as a scatter of separate findings across many engines.

The leadership question is not "are we compliant today?" It is "do our data stores require encryption, or do they trust every client to choose it?" Required-by-configuration is a control; trusting clients is an assumption documented on an audit finding. The defensible end state is that every data store refuses unencrypted connections, enforced by default at creation.

None of this is a budget decision. TLS in transit is free in AWS terms. It is a governance decision about whether the company can answer "yes, all our databases enforce encryption" without hedging.

A short read for the leader who needs to know what unencrypted database connections expose, why requiring TLS is a governance decision rather than a budget one, and what a defensible end state looks like across every engine in the estate.

Fun fact

The setting that lives almost everywhere except where you look

What it looks like when TLS enforcement is governance, not luck

After a customer security questionnaire stalled an enterprise deal on a single line, do all databases enforce encryption in transit, the executive team stopped treating the Security Hub in-transit findings as an engineering backlog item. The scatter of failures across RDS, Redshift and ElastiCache was not a dozen separate problems; it was one question the company could not answer with a clean yes. Required-by-configuration is a control the business can attest to. Trusting every client to choose TLS is an assumption written on an audit finding.

Leadership set the end state rather than the implementation: every data store refuses unencrypted connections, the regulated stores close on a committed schedule, and new stores are born enforcing TLS by default. Because the fix is free in AWS terms, this was never a budget decision. It was a decision about whether the company could say yes, all our databases enforce encryption, without hedging, in front of an auditor, a board, or a prospect's security team.

Why this is a board-level risk

An unencrypted connection into a database is the kind of gap that turns into a breach headline or a stalled enterprise deal, and encryption in transit is named explicitly in the frameworks the business already has to answer to. A failing control here is a clean, ownable exception, not a judgement call.

Because the fix is cheap and standard but sometimes needs a planned change, it drifts unless leadership insists on a date for the regulated stores and a default-on policy for new ones. The leadership outcome is two things: the flagged stores closed on a committed schedule, and a guardrail so the finding cannot reappear from a freshly created resource.

The leadership move on database encryption in transit

The executive handle is not to approve each parameter change, it is to require encryption by default on data stores and insist that any exception is a deliberate, recorded decision with a date attached.

1. Set a deadline for the regulated stores

The fix is cheap and standard but it drifts without pressure, because a reboot window or a migration sprint always loses to feature work. Give the stores holding regulated or authentication data a committed date to be enforcing TLS, and ask to see that date met. This is the one place leadership insistence changes the outcome, since the engineering is not hard, only unscheduled.

2. Require encryption by default for new stores

Make TLS-required the default position for every new database and cache, enforced in the shared provisioning modules rather than remembered per launch. The right end state is that a freshly created store cannot permit plaintext, so the Security Hub findings can only ever appear for a known list of legacy stores being migrated, never for something new.

3. Treat any plaintext-permitting store as a recorded exception

An intentionally bare store should carry a documented, governance-visible reason, not a silently suppressed finding. The distinction between we reviewed this and accepted the risk and we never looked is exactly what makes the encryption posture defensible in a SOC 2 review, a PCI assessment, or a customer security questionnaire. Ask for the exception list, not just the pass rate.

Quick quiz

Question 1 of 5

What is the right leadership question about database encryption in transit?

Keep learning

Go deeper on how TLS enforcement works across the engines in this capability.

Two takeaways: an unencrypted database connection is a clean, ownable audit exception that can stall a deal, and the fix is free in AWS terms but drifts without a deadline. The leadership outcome is the regulated stores closed on a committed schedule and a default-on guardrail so the finding cannot reappear from a freshly created resource. The question to ask is not what will it cost, it is do our data stores require encryption or only permit it.

Back to the library

Controls this lesson covers

One capability, many AWS Security Hub controls. This lesson is the shared playbook; each control below keeps its own deep page with the exact check, severity and a copy-and-paste fix.

DMS

MSK

RDS

Redshift

Redshift.2 Medium Connections to Redshift should be encrypted in transit

Part of the learning path Encrypt everything

Enforce TLS on database and cache connections

Encryption in transit for data stores: the basics

The setting that lives almost everywhere except where you look

Finding plaintext-permitting data stores across an estate

How each engine enforces TLSdeep dive

What is the impact of a data store that permits plaintext?

How do you enforce TLS on data stores safely?

1. Inventory every store that permits plaintext, ranked by data sensitivity

2. Confirm clients already speak TLS before enforcing

3. Flip enforcement through the right mechanism, highest impact first

4. Make TLS-required the default for new stores

Quick quiz

Keep learning

Encryption in transit for data stores: the cost and risk view

The setting that lives almost everywhere except where you look

How a finance partner frames the in-transit encryption findings

Why in-transit encryption belongs on the compliance register

What finance can do about the in-transit encryption gap

1. Separate the free fixes from the funded migrations

2. Risk-weight the stores by the data they hold, not the finding count

3. Fund the default-on guardrail to stop the finding recurring

Quick quiz

Keep learning

Encryption in transit for data stores: the headline

The setting that lives almost everywhere except where you look

What it looks like when TLS enforcement is governance, not luck

Why this is a board-level risk

The leadership move on database encryption in transit

1. Set a deadline for the regulated stores

2. Require encryption by default for new stores

3. Treat any plaintext-permitting store as a recorded exception

Quick quiz

Keep learning

Controls this lesson covers

DMS

DocumentDB

DynamoDB

ElastiCache

EMR

MSK

RDS

Redshift

Related compliance lessons