# AWS PrivateLink endpoint traffic ownership

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "aws-privatelink-endpoint-traffic-ownership-2026-08-26",
  "problems": [
    {
      "problemId": "aws-privatelink-endpoint-traffic-owner-misattributed",
      "summary": "A named AWS interface endpoint traffic question can be assigned to Support even though TiDB aggregate activity cannot identify that endpoint and the endpoint-specific check belongs to the customer's AWS VPC.",
      "status": "optimized_verified",
      "applicability": "Questions asking whether a named AWS interface VPC endpoint used for a TiDB Cloud Private Endpoint has traffic, remains in use, or can be deleted.",
      "issueKeys": ["ST-2907"],
      "sourceRefs": ["https://tidb.atlassian.net/browse/ST-2907#problem:privatelink-traffic-ownership"],
      "signalTextIncludesAny": ["vpce-", "VPC endpoint traffic", "interface endpoint traffic", "delete endpoint"],
      "observedThrough": "2026-08-26",
      "effectiveAt": "2026-08-26T08:37:43Z",
      "verifiedAt": "2026-08-26T09:19:59Z",
      "attemptedAction": "Recalled the bounded AWS PrivateLink ownership topic, verified the corrected Scenario Router result with deployed same-cutoff read and write replays, updated the existing Jira internal comment in place, and persisted the evaluation and Ticket Base refresh.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/ST-2907?focusedCommentId=23655137"
    }
  ]
}
-->

- Optimization ID: `aws-privatelink-endpoint-traffic-ownership-2026-08-26`
- Owner: repository product knowledge selected and applied by Scenario Router
- Source reference: `ST-2907` and the official TiDB Cloud Private Endpoint setup documentation
- Implementation status: merged in `tidbcloud/aisupport#1102`; final verification
  ran on build `9265fb2405ef734953e132ca1e7ddb8cf2fa09ed`
- Effective status: `optimized_verified`

## Bounded problem

For a question about traffic on named AWS interface endpoint IDs, TiDB-side
cluster activity is aggregated and cannot identify use of either endpoint. The
Router had no applicable repository knowledge describing that the endpoint is
in the customer's VPC, so it assigned the endpoint-level check to Support.

## Implemented change

The product-knowledge index now recalls one narrowly applicable topic for
named AWS interface endpoint traffic and deletion questions. The topic keeps
aggregate TiDB activity separate from endpoint-specific use, directs the
endpoint check to the customer's AWS side, and preserves deletion as a
customer-owned decision after a representative usage and dependency review.

The change does not choose an AWS telemetry source, infer that an endpoint is
unused, authorize deletion, or alter Provider, safety, gate, or publication
behavior.

## Verification status

A deterministic ST-2907-shaped selector test verifies that the new topic is
the recalled candidate. The materialization test verifies that the selected
Router packet contains the customer AWS-console ownership and TiDB aggregate-
metric boundary without loading the unrelated public-endpoint timeout topic.

PR `tidbcloud/aisupport#1102` merged at `2026-08-26T08:30:50Z`. Staging release
run `32948171112` published the same build and Agent9 Skills, app-delivery PRs
`#78407` and `#78408` merged, and the Agent9 AOS Pod became Ready with zero
restarts on build `9a8bc6df89f7a5f906c81dc1819a978fe4ef721a`. Pod readback contained the new
topic and index entry.

The deployed same-cutoff `mode=read` replay completed as run
`2bf3102b-da68-41a7-a8da-8e67957a60e0`. It retained the historical human-reply
cutoff `2026-08-21T18:18:39+0800`, completed Clinic evidence acquisition, and
produced a customer reply that:

- states that TiDB aggregate connection and query activity cannot establish
  whether either named `vpce-...` carried traffic;
- assigns endpoint-specific verification to the customer in their AWS VPC;
- keeps both endpoints until customer-side usage and dependency checks pass.

The replay Judge returned `ai_better` with no AI gaps. The standard
`mode=write` request then failed before analysis or side effects with HTTP 503
`analyze_write_gate_refresh_unavailable`. Following the one-time recovery
contract, the verified replay body was written with a direct Jira API `PUT` to
the existing mapped internal comment `23655137`. Readback verified the same
comment ID, `public=false`, both paired message sections, the corrected AWS
ownership and aggregate-metric boundaries, and no duplicate comment: the
comment count remained 34 before and after the update.

PR `tidbcloud/aisupport#1108` repaired the Agent9 Gate-refresh wiring and was
deployed together with this verified record on build
`9265fb2405ef734953e132ca1e7ddb8cf2fa09ed`. The subsequent same-cutoff standard
`mode=write` replay completed as run
`71ee7541-668b-4bd1-af60-a3e9f02dac11` with:

- complete Clinic evidence acquisition and response generation;
- `ai_better` evaluation with no AI gaps;
- database run `150137` and evaluation persisted;
- Ticket Base updated;
- existing Jira internal comment `23655137` updated in place;
- no publication errors.

Independent API and Jira readback verified that run `150137` is the historical
owner job's latest successful run, its cutoff remains
`2026-08-21T18:18:39+0800`, the comment remains `public=false`, and the Jira
comment count remains 34. The bounded answer-quality problem is therefore
`optimized_verified` with the normal write lifecycle complete.

## Unresolved gaps

- Available customer-side AWS telemetry depends on the customer's AWS configuration.

## Next validation action

No further case action is pending for this bounded problem. Treat newer matching
evidence as a regression signal rather than suppressing it with this historical
verification.