Compliance

Require TLS for storage and remaining services

One capability across S3, ECS-mounted EFS file systems and load balancer cipher policies: close the leftover in-transit gaps that do not fit the database, API or listener buckets.

12 min·10 sections·AWS

Last reviewed 16 June 2026

Remediates AWS Security Hub: ECS.18 ELB.17 S3.5

The remaining in-transit gaps: the basics

Three different shapes of the same plaintext risk

Most encryption-in-transit work lands neatly on databases, APIs or load balancer listeners. This capability sweeps up the controls that do not fit those buckets but carry the identical risk: data crossing a network in clear text when it should be wrapped in TLS. The three live in very different places. An S3 bucket without an SSL-only policy accepts requests over plain HTTP. An ECS task that mounts an EFS file system without in-transit encryption sends every NFS read and write across the VPC unencrypted. A load balancer listener pinned to an old cipher policy negotiates weak, downgradable TLS even though it technically terminates encryption.

Security Hub expresses each as its own control. S3.5 fails any general-purpose bucket whose policy does not explicitly deny non-SSL requests via the aws:SecureTransport condition. ECS.18 fails a task definition whose efsVolumeConfiguration does not set transitEncryption to ENABLED. ELB.17 fails an ALB or NLB listener whose SslPolicy is not on AWS's recommended list, the only HIGH-severity control in this group because the gap between a 2016 cipher set and a current TLS 1.3 policy is the difference between protected and trivially downgradable. They look unrelated on the report, but they are one capability: refuse plaintext, and where TLS is already on, make sure it is strong.

The fixes are cheap and free in AWS terms, and each is a single configuration change. S3.5 is a bucket-policy statement, ECS.18 is one task-definition field, ELB.17 is a listener SslPolicy swap. The discipline is finding every affected resource (S3.5 in particular fails on absence, so the count tracks bucket-creation velocity) and confirming the change breaks nothing, an old HTTP client, a legacy mount, an ancient TLS client, before you enforce.

In this lesson you will learn how AWS expresses these leftover in-transit gaps across S3, ECS-mounted EFS and load balancer cipher policies, how to apply the canonical S3 SSL-only bucket policy, the one task-definition field that encrypts an EFS mount, and the listener SslPolicy swap that satisfies the cipher check. 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 most-failed control is the one that fails on silence

S3.5 sits near the top of every list of most non-compliant Security Hub findings, and not because teams refuse to fix it. The failure mode is silent: a bucket gets created during a Friday afternoon experiment, no policy is attached, and the finding fires in the background. There is no incident, no broken deploy, nothing demanding attention, so the bucket quietly fails the audit for months. The same blind spot runs through this whole group: an EFS mount works perfectly fine in plaintext, and a load balancer on a 2016 cipher policy still speaks TLS 1.2 to a modern browser. Nothing breaks, so nobody looks, which is exactly why these controls exist.

Finding the leftover plaintext gaps across an estate

Marco is the on-call engineer when a Security Hub digest lands showing dozens of S3.5 failures across the production account, plus a handful of ECS.18 and ELB.17 findings. The audit is in six weeks and the security team wants the counts at zero.

Rather than fix one resource at a time, he starts with the largest group. He checks whether a representative bucket already has a policy, because if one exists he has to merge his Deny statement in rather than overwrite it.

Check whether the bucket already has a policy. If it does, the new SSL-only Deny must be merged with what is there, not put on top of it.

$ aws s3api get-bucket-policy --bucket acme-prod-logs --query Policy --output text | jq '.Statement[] | {Sid, Effect, Condition}'

{

"Sid": "AllowCloudFrontReadAccess",

"Effect": "Allow",

"Condition": null

}

# Existing Allow for CloudFront, keep it. No SecureTransport Deny anywhere, S3.5 fails.

A bucket with an existing Allow but no insecure-transport Deny fails S3.5. Fetch first, merge, then put.

How the remaining in-transit controls workdeep dive

S3.5 turns on the global IAM condition key aws:SecureTransport, which AWS sets to true when a request arrived over TLS and false otherwise. The canonical satisfying statement is an explicit Deny gated by Bool aws:SecureTransport false, which is additive: an explicit Deny always wins over any Allow, so it sits alongside whatever Allow statements you already have and only kicks in on a non-TLS request. Security Hub reads the bucket policy and requires the Deny to cover both the bucket and its objects (arn:aws:s3:::bucket and arn:aws:s3:::bucket/*); miss either resource and the control still fails. The same condition key works on SQS, SNS and KMS resource policies, but S3 is the most visible use of it.

ECS.18 evaluates the latest active revision of each AWS::ECS::TaskDefinition and reads the efsVolumeConfiguration block of every EFS volume. When an ECS task mounts EFS it talks over NFS, which is plaintext by default; the control passes only when transitEncryption is set to ENABLED, which wraps that NFS connection in TLS. This is distinct from EFS at-rest encryption, a separate setting on the file system itself, and the two are easy to confuse: a team enables at-rest, sees a green check, and assumes end-to-end protection while the bytes between task and file system still cross the VPC in the clear.

ELB.17 reads the SslPolicy on each ALB and NLB HTTPS or TLS listener and fails it if the policy is not on AWS's recommended list. A policy is an AWS-curated bundle of allowed protocol versions plus a preference-ordered cipher list; the old ELBSecurityPolicy-2016-08 permits TLS 1.0 and 1.1 and ciphers no modern review signs off on, while the current ELBSecurityPolicy-TLS13-* family is TLS 1.3 with a TLS 1.2 fallback and no weak ciphers. It is the only HIGH-severity control here because a listener on a 2016 policy is trivially downgradable even though it terminates TLS, where S3.5 and ECS.18 are Medium.

What is the impact of leaving these gaps open?

The direct impact is data on the wire in clear text or with weak protection. An S3 request over HTTP exposes the entire payload, object names, signed-URL parameters, headers and the object body, and for private buckets the IAM credentials travel in the Authorization header on every call, so observing one HTTP request can compromise the session. An unencrypted EFS mount exposes every file read and write to anyone with VPC network visibility. A listener on a 2016 cipher policy can be forced down to a protocol an attacker on the path can break, so the connection your users trusted is already compromised.

The second-order impact is regulatory. SOC 2, ISO 27001, HIPAA, PCI DSS, FedRAMP and GDPR all require encryption of sensitive data in transit. A bucket failing S3.5 is hard to defend even if you can show the actual traffic was HTTPS, because the policy is what enforces the behaviour and "we trust clients to do the right thing" is not a control. Auditors look at configuration, not traffic logs.

The financial impact is small in dollar terms (no AWS charge differential for any of these) but large in audit-finding terms. Each non-compliant resource is a separate line item; a single account commonly has dozens to hundreds of S3.5 failures alone, and remediation and auditor hours add up even though the bill never moves.

The risk that matters most is silent. There is no error when a client uses HTTP, mounts EFS without TLS, or negotiates an old cipher; the request just succeeds. By the time you discover an old service or a legacy mount has been leaking data, it has often been doing so for months. Closing this well means fixing the flagged resources and changing the default so new ones are born compliant, which converts an open-ended audit line into a one-time cleanup plus a guardrail.

How do you require TLS across these services safely?

Work the capability as one loop. The order matters: inventory and check clients before you enforce, so a deny or a tighter cipher policy does not break a live caller, and finish with prevention so new resources do not rebuild the backlog.

1. Inventory every affected resource and check current clients

List every general-purpose S3 bucket and whether its policy has the aws:SecureTransport Deny, every ECS task definition's efsVolumeConfiguration, and every ALB and NLB listener's SslPolicy. For S3 and listeners, enable access logging or CloudTrail data events for a short window to catch any caller still using HTTP or an old TLS client, recent SDKs default to TLS but old scripts, embedded clients and copy-pasted samples sometimes do not. Catch them now or they break after the change lands.

2. Apply the canonical S3 SSL-only policy without trampling existing statements

Fetch the existing bucket policy, merge the Deny statement gated by Bool aws:SecureTransport false (covering both the bucket and bucket/*), then put it back. Never overwrite: put-bucket-policy replaces the entire policy in one call, so a one-line edit becomes a full wipe if you forget the existing Allow statements. Always fetch, merge, then put.

3. Encrypt the EFS mount and swap the listener policy

Set transitEncryption to ENABLED in the efsVolumeConfiguration of the ECS task definition and register a new revision, then update the service to use it. For listeners, modify the SslPolicy to a current recommended policy such as ELBSecurityPolicy-TLS13-1-2-2021-06. Both changes take effect on the next deployment or immediately on the listener; verify Security Hub clears each finding on its next evaluation.

4. Prevent recurrence with AWS Config and provisioning baselines

Bulk fixes are temporary because new resources are created constantly. Enable the managed Config rules s3-bucket-ssl-requests-only and elb-tls-https-listeners-only, bake the SSL-only policy, the EFS transit-encryption flag and the strong listener policy into your IaC modules, and for new accounts ship the S3 deny as part of the Control Tower baseline. An SCP can require the aws:SecureTransport deny on every PutBucketPolicy. That is what keeps the counts near zero by default.

# 1. The canonical statement Security Hub S3.5 looks for (merge into the existing policy).
cat <<'EOF'
{
  "Sid": "DenyInsecureTransport",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::acme-prod-logs",
    "arn:aws:s3:::acme-prod-logs/*"
  ],
  "Condition": { "Bool": { "aws:SecureTransport": "false" } }
}
EOF
aws s3api put-bucket-policy --bucket acme-prod-logs --policy file://acme-prod-logs-policy.json

# 2. Swap a load balancer listener onto a recommended TLS policy (closes ELB.17).
aws elbv2 modify-listener \
  --listener-arn arn:aws:elasticloadbalancing:eu-west-1:123456789012:listener/app/web-prod/abc/def \
  --ssl-policy ELBSecurityPolicy-TLS13-1-2-2021-06

Quick quiz

Question 1 of 5

Security Hub shows S3.5, ECS.18 and ELB.17 failures. What is the most efficient way to think about them?

Keep learning

Go deeper on how each of these in-transit gaps works and how to prevent it.

You can now treat the leftover in-transit gaps as one capability rather than three unrelated findings: inventory every bucket, ECS task definition and listener, check current clients, then enforce the SSL-only bucket policy, the EFS transit-encryption flag and a recommended listener policy, and finish with AWS Config and IaC defaults so new resources are born compliant. The Controls this lesson covers section below links every control in this group to its deep page and fix.

Back to the library

The remaining in-transit gaps: the cost and risk view

Zero-cost configuration changes that clear persistent audit findings

Every fix in this group is free in AWS spend. S3 charges identically for HTTP and HTTPS requests, EFS in-transit encryption adds no charge, and a load balancer cipher policy is a configuration swap. So there is no cost signal to alert you that unencrypted traffic is happening, and no remediation budget to model; this is a compliance and risk item, not a cost one.

The exposure is on the audit report. Each failing resource is a separate finding in SOC 2, ISO 27001, PCI DSS and HIPAA reviews, and S3.5 in particular is one of the most commonly failing controls in the wild because the failure mode is silent: a bucket gets created with no policy, the finding fires in the background, and it quietly fails the audit for months until someone runs a compliance report. Auditor time reviewing dozens or hundreds of these line items is real spend even though the AWS bill never moves.

The right framing is high return on a small, bounded effort. A one-time bulk remediation script plus a preventive AWS Config rule closes the existing findings and caps future exposure. The only material cost is the pre-flight check for legacy clients, a short traffic review before the deny lands, which is cheaper than a production incident.

This lesson is for the finance partner who sees S3.5, ECS.18 and ELB.17 on the compliance pack and wants to know what they cost and what it takes to clear them. The short answer: the fixes are free, so the finance role is governance, ensuring zero-cost controls actually get closed rather than deprioritised because they seem trivial, and that prevention is in place so new resources do not reopen the backlog.

Fun fact

The most-failed control is the one that fails on silence

How a finance partner frames the leftover in-transit findings

Priya, the finance and governance partner, is handed the Security Hub export six weeks before the audit: dozens of S3.5 failures across the production account, plus a handful of ECS.18 and ELB.17 findings. The room's first instinct is to ask what remediation will add to the cloud bill. The answer reframes the whole conversation: there is no AWS price differential for any of these. S3 charges identically for HTTP and HTTPS, EFS in-transit encryption adds no charge, and a load balancer cipher policy is a configuration swap. 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.

What Priya does need to size is auditor time and the one engineering risk that could turn cheap into expensive. Each failing resource is a separate line item in the SOC 2, ISO 27001, PCI DSS or HIPAA report, and S3.5 alone commonly fails on dozens of buckets, so the auditor-hours reviewing those line items are real spend even though the AWS bill never moves. The genuine risk is the pre-flight: before the SSL-only Deny or the tighter cipher policy lands, the team has to confirm no legacy client is still using plain HTTP or an old TLS stack, because that short traffic review is far cheaper than the production incident a careless enforcement would cause. Her output is simple: fund the one-time bulk remediation and the preventive Config rule, and require the client check before any deny goes live.

What these gaps actually cost the business

There is no AWS price differential for any of these controls, so the direct cloud-bill exposure is zero. The cost lands on the audit report: each non-compliant bucket, task definition or listener is a discrete finding that must be reviewed, documented and responded to in a SOC 2, ISO 27001, PCI DSS or HIPAA audit. In an account with dozens of failing buckets, that is dozens of line items in the auditor's report, and the time spent reviewing and responding to them is real spend at real rates.

The secondary impact is the tail risk of a data-in-transit breach if unencrypted traffic is actually occurring. S3 credentials travel in request headers, an unencrypted EFS mount carries whatever the application stores, and a downgradable listener exposes session data. Breach costs, regulatory fines and notification obligations under GDPR and HIPAA are the financial tail risk here, not the invoice.

Remediation cost is almost negligible: each fix is a single configuration change, and a bulk script clears an account in minutes. The only material cost is the pre-flight check for legacy clients before enforcing, which prevents a production breakage that would cost far more than the review. The return on remediating this group quickly is among the highest of any control family.

What finance can do about the leftover in-transit gaps

Finance cannot merge the bucket-policy Deny or swap the cipher policy, but it can set the framing that stops a free, trivial-looking control from being deprioritised into a permanent audit fixture. Three levers.

1. Name it as compliance exposure, not a cost item

Make explicit that there is no AWS spend signal here at all, which is exactly why it gets ignored: nothing on the bill ever flags unencrypted traffic. Frame the work as clearing persistent audit findings rather than optimising cost, so it is prioritised on the controls dashboard and not waved off as too small to bother with. The whole group is high return on a small, bounded effort.

2. Risk-weight by what the resource carries and the severity

The raw finding count is misleading because a disposable bucket and a customer-facing listener both appear as line items. ELB.17 is the only HIGH-severity control here because a downgradable listener exposes live session data, so push the listeners and any S3 buckets carrying credentials or regulated data to the top. Treat a private internal bucket with no sensitive contents as a lower-priority clean-up. The number that matters is failing resources weighted by what they expose, not the total.

3. Fund the one-time fix plus the guardrail, and budget the client check

The only material cost in this whole group is the short pre-flight traffic review for legacy clients before a deny or tighter cipher lands, which is cheap insurance against a production breakage that would cost far more. Fund that review, fund the one-time bulk remediation script, and fund the preventive AWS Config rules and IaC defaults so new resources are born compliant. That converts an open-ended audit line into a one-time cleanup plus a guardrail, far cheaper over time than re-discovering the gap every audit cycle.

Quick quiz

Question 1 of 5

What is the direct AWS spend impact of fixing S3.5, ECS.18 and ELB.17?

Keep learning

Go deeper on how each of these in-transit gaps works and how to prevent it.

You have finished the finance view of the leftover in-transit gaps. You know every fix in this group is free in AWS terms, so this is a compliance-exposure item and not a cost one, that the exposure lands on the audit report as per-resource line items plus the tail risk of an in-transit breach, and that the only material cost is the short client check before enforcement. Next time S3.5, ECS.18 and ELB.17 appear together, you will frame them as one high-return cleanup, risk-weight by what each resource carries, and fund the guardrail so they do not come back.

Back to the library

The remaining in-transit gaps: the headline

Whether data in transit is protected by configuration, or only by trust

These controls cover the leftover places data can cross a network unencrypted: object storage that allows plain HTTP, container file-system mounts that skip TLS, and load balancers using outdated ciphers. Without explicit configuration, any client, an old script, a misconfigured tool, a third-party integration, can move data in clear text with no warning.

This is a governance question as much as a technical one. Auditors under SOC 2, HIPAA, PCI DSS and ISO 27001 look at whether encryption in transit is enforced by configuration, not whether people remember to use it. A resource that relies on callers doing the right thing is not a compliant control; it is a trust assumption documented on an audit finding.

The defensible end state is straightforward: every bucket refuses unencrypted connections, every container mount uses TLS, and every listener uses a strong cipher policy, applied by default at creation and verified continuously. It converts persistent compliance liabilities into closed controls, by policy, not by accident.

A short read for the leader who wants the plain-English version of these controls and the one question to ask. You will understand what it means to enforce encryption by policy rather than by convention, why these controls appear across every major framework, and what a mature remediation posture looks like: existing findings cleared in bulk, new ones prevented by default.

Fun fact

The most-failed control is the one that fails on silence

What it looks like when in-transit protection is configuration, not trust

After an auditor noted that several buckets relied on callers choosing HTTPS rather than on a policy that required it, the executive team stopped treating the scatter of S3.5, ECS.18 and ELB.17 findings as an engineering backlog. The point the auditor made was the one that mattered: a resource that relies on every client doing the right thing is not a compliant control, it is a trust assumption written on a finding. The question was not whether the actual traffic happened to be encrypted, it was whether encryption was enforced by configuration.

Leadership set the end state rather than the implementation: every bucket refuses unencrypted connections, every container mount uses TLS, and every listener uses a strong cipher policy, applied by default at creation and verified continuously. Because the fixes are free in AWS terms, this was never a budget decision. It was a decision about whether the company could attest, in front of an auditor or a customer's security team, that data in transit is protected by policy rather than by hoping every old script and third-party integration behaves.

Why these findings keep appearing on compliance reports

These controls show up on every major framework because each requires encryption of sensitive data in transit, and a resource without an enforcement policy does not satisfy that requirement on paper regardless of whether the actual traffic happens to be encrypted. Auditors examine configuration, not traffic logs, because a configuration is a control and "our clients always use HTTPS" is an assumption.

The right signal for leadership is not the raw finding count but whether a structural prevention mechanism is in place: AWS Config rules that auto-detect new non-compliant resources within minutes, and provisioning baselines that attach the SSL-only policy, the EFS transit-encryption flag and the strong listener policy at creation. With that in place the count stabilises near zero by default; without it, these controls are a permanent fixture on the report no matter how many remediation sprints the team runs.

The leadership move on the leftover in-transit gaps

The executive handle is not to approve each policy change, it is to require encryption by configuration on these resources and insist that prevention, not repeated cleanup, keeps the count near zero.

1. Require enforcement by configuration, not convention

Make it the standard that every bucket refuses non-TLS requests, every ECS mount sets transit encryption, and every listener uses a recommended cipher policy, enforced in the provisioning baseline rather than left to whoever creates the resource. The right end state is that relying on callers to choose HTTPS is never an accepted answer, because a trust assumption is not a control an auditor will accept.

2. Watch the prevention mechanism, not the raw finding count

The signal that matters is not how many findings a remediation sprint closed but whether AWS Config rules catch new non-compliant resources within minutes and provisioning baselines attach the SSL-only policy, the EFS transit flag and the strong listener policy at creation. With that in place the count stabilises near zero by default; without it, these controls are a permanent fixture on the report no matter how many sprints the team runs.

3. Insist on the client check before enforcement

These failures are silent: nothing breaks when a client uses HTTP or an old cipher, so enforcing without checking can take a legacy integration offline with no warning. Require that the team runs a short traffic review for old clients before any deny or tighter policy goes live. It is the one place leadership insistence prevents a self-inflicted incident, and it is cheap compared with the outage it avoids.

Quick quiz

Question 1 of 5

What is the right leadership question about these in-transit findings?

Keep learning

Go deeper on how each of these in-transit gaps works and how to prevent it.

Two takeaways: a resource that relies on callers choosing TLS is a trust assumption written on an audit finding, not a control, and the fix is free in AWS terms but stays open without a prevention mechanism. The leadership outcome is enforcement by configuration on every bucket, mount and listener, a Config rule that catches new gaps in minutes, and a client check before any deny lands. The question to ask is not what it costs, it is whether our data in transit is protected by configuration or only by trust.

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.

Require TLS for storage and remaining services

The remaining in-transit gaps: the basics

The most-failed control is the one that fails on silence

Finding the leftover plaintext gaps across an estate

How the remaining in-transit controls workdeep dive

What is the impact of leaving these gaps open?

How do you require TLS across these services safely?

1. Inventory every affected resource and check current clients

2. Apply the canonical S3 SSL-only policy without trampling existing statements

3. Encrypt the EFS mount and swap the listener policy

4. Prevent recurrence with AWS Config and provisioning baselines

Quick quiz

Keep learning

The remaining in-transit gaps: the cost and risk view

The most-failed control is the one that fails on silence

How a finance partner frames the leftover in-transit findings

What these gaps actually cost the business

What finance can do about the leftover in-transit gaps

1. Name it as compliance exposure, not a cost item

2. Risk-weight by what the resource carries and the severity

3. Fund the one-time fix plus the guardrail, and budget the client check

Quick quiz

Keep learning

The remaining in-transit gaps: the headline

The most-failed control is the one that fails on silence

What it looks like when in-transit protection is configuration, not trust

Why these findings keep appearing on compliance reports

The leadership move on the leftover in-transit gaps

1. Require enforcement by configuration, not convention

2. Watch the prevention mechanism, not the raw finding count

3. Insist on the client check before enforcement

Quick quiz

Keep learning

Controls this lesson covers

ECS

ELB

S3

Related compliance lessons