rds-sqlserver

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Amazon RDS for SQL Server

Safety guidance

安全指导

This skill covers creating and modifying RDS for SQL Server resources when the user requests it. The agent MUST confirm the action with the user before executing. Do NOT execute any create or modify operation without explicit user confirmation (e.g., "yes", "proceed", "confirmed", "go ahead"). If the user has not confirmed, present the planned action and ask for approval.

本技能涵盖在用户请求时创建和修改RDS for SQL Server资源。Agent在执行操作前必须与用户确认。未经用户明确确认（例如“yes”、“proceed”、“confirmed”、“go ahead”），不得执行任何创建或修改操作。如果用户尚未确认，请告知计划执行的操作并请求批准。

Execute these operations (after user confirmation)

执行以下操作（需用户确认后）

Create an instance:
```
create-db-instance
```
(requires a DB subnet group; RDS SQL Server is VPC-only and not publicly accessible by default)
Create a custom parameter group:
```
create-db-parameter-group
```
(family
```
sqlserver-ex-15.00
```
,
```
sqlserver-se-15.00
```
, etc.) — needed to set
```
rds.force_ssl=1
```
among others
Create an option group:
```
create-option-group
```
(for TDE, S3 integration, SQLServer Audit, Native Backup/Restore, SSIS, SSAS, SSRS)
Create an RDS Proxy:
```
create-db-proxy
```
,
```
register-db-proxy-targets
```
(for IAM DB auth in front of SQL Server — see the rds-proxy reference)
Create an AWS Managed Microsoft AD directory for Windows auth:
```
create-directory
```
(then associate via
```
modify-db-instance --domain
```
)

Create a Secrets Manager secret with rotation:

create-secret

rotate-secret --rotation-rules AutomaticallyAfterDays=N

Change backup retention, deletion protection, log exports:

modify-db-instance --backup-retention-period

--deletion-protection

--cloudwatch-logs-export-configuration

Attach/detach parameter group or option group:

modify-db-instance --db-parameter-group-name / --option-group-name

Tag resources:

add-tags-to-resource

remove-tags-from-resource

创建实例：
```
create-db-instance
```
（需要DB子网组；RDS SQL Server仅支持VPC，默认不公开访问）

创建自定义参数组：

create-db-parameter-group

（系列为

sqlserver-ex-15.00

、

sqlserver-se-15.00

等）——用于设置

rds.force_ssl=1

等参数

创建选项组：
```
create-option-group
```
（用于TDE、S3集成、SQLServer Audit、原生备份/恢复、SSIS、SSAS、SSRS）
创建RDS Proxy：
```
create-db-proxy
```
、
```
register-db-proxy-targets
```
（用于SQL Server前端的IAM数据库认证——请参阅rds-proxy参考文档）
创建用于Windows认证的AWS托管Microsoft AD目录：
```
create-directory
```
（然后通过
```
modify-db-instance --domain
```
关联）

创建带轮换功能的Secrets Manager密钥：

create-secret

、

rotate-secret --rotation-rules AutomaticallyAfterDays=N

修改备份保留期、删除保护、日志导出：

modify-db-instance --backup-retention-period

--deletion-protection

--cloudwatch-logs-export-configuration

附加/分离参数组或选项组：

modify-db-instance --db-parameter-group-name / --option-group-name

标记资源：

add-tags-to-resource

、

remove-tags-from-resource

Resource tagging (always apply on resource creation)

资源标记（创建资源时始终应用）

When creating any RDS for SQL Server resource (

create-db-instance

create-db-parameter-group

create-option-group

create-db-proxy

create-secret

for RDS credentials,

create-directory

for Windows auth), ALWAYS include these tags using the RDS list-of-records

--tags

syntax (AWS Directory Service and Secrets Manager use the same shape):

--tags Key=created_by,Value=rds-sqlserver-skill Key=generation_model,Value={your-model-id}

Example:

--tags Key=created_by,Value=rds-sqlserver-skill Key=generation_model,Value=claude-sonnet-4-20250514

Include these tags even if the user does not mention tagging, so that they can identify the resources created via this skill. If the user provides additional tags, append these to their tags rather than replacing them. The same applies when tagging via

add-tags-to-resource

on existing resources.

创建任何RDS for SQL Server资源（

create-db-instance

、

create-db-parameter-group

、

create-option-group

、

create-db-proxy

、用于RDS凭证的

create-secret

、用于Windows认证的

create-directory

）时，必须使用RDS的记录列表格式

--tags

语法添加以下标记（AWS Directory Service和Secrets Manager使用相同格式）：

--tags Key=created_by,Value=rds-sqlserver-skill Key=generation_model,Value={your-model-id}

示例：

--tags Key=created_by,Value=rds-sqlserver-skill Key=generation_model,Value=claude-sonnet-4-20250514

即使用户未提及标记，也必须添加这些标记，以便用户识别通过本技能创建的资源。如果用户提供额外标记，请将这些标记追加到用户的标记中，而非替换。对现有资源通过

add-tags-to-resource

进行标记时同样适用。

Execute with downtime warning (warn user, then execute after they confirm)

执行需停机警告（先警告用户，确认后执行）

Change instance class:
```
modify-db-instance --db-instance-class
```
— warn: "This causes a failover in Multi-AZ configurations and brief unavailability on single-AZ instances."
Minor engine version upgrade:
```
modify-db-instance --engine-version
```
within the same major (e.g., 15.00.4X → 15.00.4Y) — warn: "This triggers a restart and may cause a brief outage."
Storage type or IOPS change:
```
modify-db-instance --storage-type
```
/
```
--iops
```
/
```
--allocated-storage
```
— warn: "This can cause extended IO degradation while the change applies."
Apply immediately: any
```
modify-db-instance --apply-immediately
```
— warn: "This applies outside the maintenance window and may cause downtime now."
Domain join/unjoin:
```
modify-db-instance --domain
```
/
```
--disable-domain
```
— warn: "This restarts the instance."

修改实例类型：
```
modify-db-instance --db-instance-class
```
——警告：“这会导致多AZ配置中的故障转移，单AZ实例会出现短暂不可用。”
次要引擎版本升级：
```
modify-db-instance --engine-version
```
（同一主版本内，例如15.00.4X → 15.00.4Y）——警告：“这会触发重启，可能导致短暂中断。”
修改存储类型或IOPS：
```
modify-db-instance --storage-type
```
/
```
--iops
```
/
```
--allocated-storage
```
——警告：“在更改生效期间，可能会导致IO性能长时间下降。”
立即应用：任何
```
modify-db-instance --apply-immediately
```
——警告：“这会在维护窗口外应用，可能导致当前停机。”
加入/退出域：
```
modify-db-instance --domain
```
/
```
--disable-domain
```
——警告：“这会重启实例。”

Do NOT execute (refuse, explain why, offer assessment instead)

禁止执行（拒绝并解释原因，提供评估替代方案）

Delete instance:
```
delete-db-instance
```
— irreversible data loss
Delete automated backups:
```
delete-db-instance --delete-automated-backups
```
— destroys point-in-time recovery history
Failover:
```
reboot-db-instance --force-failover
```
— production impact
Major version upgrade:
```
modify-db-instance --engine-version
```
across major versions (e.g., 15.0 → 16.0) — requires prechecks and a rollback plan; should go through change-control
Reboot:
```
reboot-db-instance
```
— production impact
Enable public accessibility:
```
modify-db-instance --publicly-accessible true
```
— security regression; use SSM port forwarding, VPN, or Direct Connect

When refusing, explain why and offer the matching assessment workflow:

"I can't perform [action] because [reason]. I can run an assessment to help you decide. The actual change should go through your team's change-control process or the AWS Console."

删除实例：
```
delete-db-instance
```
——不可逆的数据丢失
删除自动备份：
```
delete-db-instance --delete-automated-backups
```
——破坏时间点恢复历史
故障转移：
```
reboot-db-instance --force-failover
```
——影响生产环境
主版本升级：
```
modify-db-instance --engine-version
```
（跨主版本，例如15.0 → 16.0）——需要预检查和回滚计划；应通过变更控制流程
重启：
```
reboot-db-instance
```
——影响生产环境
启用公开访问：
```
modify-db-instance --publicly-accessible true
```
——安全倒退；使用SSM端口转发、VPN或Direct Connect

拒绝时，请解释原因并提供匹配的评估流程：

“我无法执行[操作]，原因是[理由]。我可以运行评估来帮助您决策。实际变更应通过您团队的变更控制流程或AWS控制台进行。”

Overview

概述

Amazon RDS for SQL Server is the managed SQL Server service from AWS. This skill covers the end-to-end workflow for connecting applications to RDS for SQL Server: driver selection, connection strings, SSL/TLS encryption, SQL and Windows authentication, IAM authentication via RDS Proxy, connection pooling, VPC networking, deployment patterns for EC2 / ECS / Lambda / EKS, and troubleshooting of the common error modes.

This skill works with the AWS CLI directly. The AWS MCP server is recommended but not required — it adds sandboxed execution, CloudTrail audit, and observability when available.

Amazon RDS for SQL Server是AWS提供的托管SQL Server服务。本技能涵盖将应用连接到RDS for SQL Server的端到端流程：驱动程序选择、连接字符串、SSL/TLS加密、SQL和Windows认证、通过RDS Proxy实现IAM认证、连接池、VPC网络、EC2/ECS/Lambda/EKS部署模式，以及常见错误模式的故障排查。

本技能直接与AWS CLI配合使用。推荐使用AWS MCP服务器，但并非必需——如果可用，它会提供沙箱执行、CloudTrail审计和可观测性。

Common Tasks

常见任务

1. Verify Dependencies

1. 验证依赖项

Check for required tools and warn the user if any are missing.

Constraints:

You MUST verify that the AWS CLI is available (
```
aws --version
```
)
You MUST inform the user if the AWS CLI is missing, because most steps need AWS API access
If the AWS MCP server tools (
```
call_aws
```
,
```
suggest_aws_commands
```
) are available, prefer them for audit and observability — but they are NOT required

检查所需工具，如果缺少任何工具，请警告用户。

约束条件：

必须验证AWS CLI是否可用（
```
aws --version
```
）
如果缺少AWS CLI，必须告知用户，因为大多数步骤需要AWS API访问
如果AWS MCP服务器工具（
```
call_aws
```
、
```
suggest_aws_commands
```
）可用，优先使用它们进行审计和可观测性——但并非必需

2. Classify and Route

2. 分类与路由

Collect the connection context and route to the right sub-skill reference file.

Parameters:

language (required):
```
python
```
|
```
dotnet
```
|
```
java
```
|
```
nodejs
```
. Infer from project files (
```
requirements.txt
```
/
```
*.py
```
→ python;
```
*.csproj
```
→ dotnet;
```
pom.xml
```
/
```
build.gradle
```
→ java;
```
package.json
```
→ nodejs). Ask only if ambiguous.
runtime (required):
```
ec2
```
|
```
ecs
```
|
```
lambda
```
|
```
eks
```
|
```
laptop
```
. Drives networking + secrets pattern.
auth (required):
```
sql
```
|
```
windows-kerberos
```
|
```
windows-ntlm
```
|
```
iam-proxy
```
. Default
```
sql
```
unless the user mentions Active Directory, Kerberos, NTLM, or IAM.
region (required): AWS region, e.g.
```
us-east-1
```
.
db_instance_id (required for troubleshooting): RDS instance identifier.

Constraints:

You MUST ask for all required parameters upfront in a single prompt, because iterative questioning frustrates users
You MUST infer
```
language
```
from project files when available rather than asking
You MUST validate
```
region
```
against the enumerated list of AWS regions before proceeding
You SHOULD default to SQL authentication unless the user explicitly says Windows auth, IAM auth, or Active Directory

收集连接上下文并路由到正确的子技能参考文件。

参数：

language（必填）：
```
python
```
|
```
dotnet
```
|
```
java
```
|
```
nodejs
```
。从项目文件推断（
```
requirements.txt
```
/
```
*.py
```
→ python；
```
*.csproj
```
→ dotnet；
```
pom.xml
```
/
```
build.gradle
```
→ java；
```
package.json
```
→ nodejs）。仅在模糊时询问。
runtime（必填）：
```
ec2
```
|
```
ecs
```
|
```
lambda
```
|
```
eks
```
|
```
laptop
```
。决定网络+密钥模式。
auth（必填）：
```
sql
```
|
```
windows-kerberos
```
|
```
windows-ntlm
```
|
```
iam-proxy
```
。默认
```
sql
```
，除非用户提及Active Directory、Kerberos、NTLM或IAM。
region（必填）：AWS区域，例如
```
us-east-1
```
。
db_instance_id（故障排查必填）：RDS实例标识符。

约束条件：

必须在单个提示中一次性询问所有必填参数，因为迭代提问会使用户感到沮丧
必须在可用时从项目文件推断
```
language
```
，而非询问
必须在继续前验证
```
region
```
是否在AWS区域枚举列表中
除非用户明确说明Windows认证、IAM认证或Active Directory，否则应默认使用SQL认证

Sub-skill routing

子技能路由

Load exactly one driver reference plus any relevant topic references:

User is doing	Load
Python / pymssql / pyodbc	references/python.md
.NET / C# / Microsoft.Data.SqlClient	references/dotnet.md
Java / JDBC / mssql-jdbc	references/java.md
Node.js / tedious / mssql	references/nodejs.md
EC2 hosting	references/ec2-vpc.md
Lambda hosting	references/lambda-vpc.md
ECS or Fargate hosting	references/ecs-fargate-vpc.md
Laptop via SSM tunnel	references/ssm-tunneling.md
SSL/TLS, rds.force_ssl, certificates	references/encryption.md
Windows / AD / Kerberos / NTLM	references/ad-kerberos.md
Cross-VPC, Transit Gateway, VPC peering	references/networking.md
SQL auth, Secrets Manager, credentials	references/connection-auth.md
IAM auth, RDS Proxy, connection pooling	references/rds-proxy.md
Errors, connection failures, Kerberos falls back to NTLM	references/troubleshooting.md

加载恰好一个驱动程序参考文件以及任何相关主题参考文件：

用户操作	加载文件
Python / pymssql / pyodbc	references/python.md
.NET / C# / Microsoft.Data.SqlClient	references/dotnet.md
Java / JDBC / mssql-jdbc	references/java.md
Node.js / tedious / mssql	references/nodejs.md
EC2托管	references/ec2-vpc.md
Lambda托管	references/lambda-vpc.md
ECS或Fargate托管	references/ecs-fargate-vpc.md
笔记本通过SSM隧道	references/ssm-tunneling.md
SSL/TLS、rds.force_ssl、证书	references/encryption.md
Windows / AD / Kerberos / NTLM	references/ad-kerberos.md
跨VPC、Transit Gateway、VPC对等连接	references/networking.md
SQL认证、Secrets Manager、凭证	references/connection-auth.md
IAM认证、RDS Proxy、连接池	references/rds-proxy.md
错误、连接失败、Kerberos回退到NTLM	references/troubleshooting.md

3. Execute the Workflow

3. 执行工作流程

Follow the steps in the loaded reference files in order: driver setup → networking → auth → secrets → verify.

Constraints:

You MUST use
```
TLS 1.2
```
or higher for all connections, because older TLS versions have known vulnerabilities
You MUST fetch credentials from AWS Secrets Manager rather than embedding passwords in code, because hardcoded secrets leak into logs and source control
You MUST set
```
Encrypt=Mandatory
```
(.NET) /
```
encrypt=true
```
(JDBC) /
```
encryption="require"
```
(pymssql) /
```
encrypt: true
```
(tedious) in production, because opportunistic encryption may silently fall back to plaintext
You MUST verify server certificate chain using the RDS CA bundle from
```
https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem
```
rather than setting
```
TrustServerCertificate=true
```
in production, because disabling verification exposes you to MITM attacks
You MUST NOT enable
```
PubliclyAccessible: true
```
on the DB instance, because it exposes SQL Server port 1433 to the public internet
You MUST use security group IDs as the source for same-VPC access and CIDR blocks for cross-VPC access via Transit Gateway or VPC peering, because SG references don't cross VPC boundaries
You MUST NOT use IAM authentication directly against RDS for SQL Server, because RDS for SQL Server does not support it — IAM auth requires RDS Proxy in front of the instance
You MUST test Windows authentication from a domain-joined host (EC2 or client), not via SSM send-command, because SSM runs as the system account, not the user's AD identity
You SHOULD prefer Kerberos over NTLM when both are available, because Kerberos is cryptographically stronger and easier to audit
You SHOULD use
```
pyodbc
```
instead of
```
pymssql
```
when the application requires Kerberos/Windows authentication, because pymssql does not support Kerberos

按加载的参考文件中的步骤顺序执行：驱动程序设置 → 网络 → 认证 → 密钥 → 验证。

约束条件：

所有连接必须使用
```
TLS 1.2
```
或更高版本，因为旧版TLS存在已知漏洞
必须从AWS Secrets Manager获取凭证，而非在代码中嵌入密码，因为硬编码的密钥会泄露到日志和源代码控制中
生产环境中必须设置
```
Encrypt=Mandatory
```
（.NET）/
```
encrypt=true
```
（JDBC）/
```
encryption="require"
```
（pymssql）/
```
encrypt: true
```
（tedious），因为机会性加密可能会静默回退到明文
生产环境中必须使用
```
https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem
```
中的RDS CA证书链验证服务器证书，而非设置
```
TrustServerCertificate=true
```
，因为禁用验证会使您面临MITM攻击
不得在DB实例上启用
```
PubliclyAccessible: true
```
，因为这会将SQL Server端口1433暴露给公共互联网
同一VPC访问必须使用安全组ID作为源，跨VPC访问（通过Transit Gateway或VPC对等连接）必须使用CIDR块，因为SG引用无法跨VPC边界
不得直接对RDS for SQL Server使用IAM认证，因为RDS for SQL Server不支持该功能——IAM认证需要在实例前端使用RDS Proxy
必须从加入域的主机（EC2或客户端）测试Windows认证，而非通过SSM send-command，因为SSM以系统账户运行，而非用户的AD身份
如果同时可用，应优先使用Kerberos而非NTLM，因为Kerberos加密强度更高且更易于审计
当应用需要Kerberos/Windows认证时，应优先使用
```
pyodbc
```
而非
```
pymssql
```
，因为pymssql不支持Kerberos

Rubric-Critical Facts to Always Surface

必须始终强调的关键评分事实

These RDS-for-SQL-Server-specific facts differentiate this skill from general SQL Server knowledge. Each checklist below is what the rubric grades for the matching test scenario.

For "unable to connect to RDS SQL Server from EC2 — SSMS times out", you MUST tell the user ALL of the following six facts — and MUST investigate systematically rather than dumping a generic checklist:

Ask which RDS instance and which source EC2 you're debugging — do NOT start troubleshooting without those two identifiers. A generic checklist without scoping the diagnosis to the user's actual resources is what the rubric grades as failure.
Check VPC and subnet connectivity between the EC2 and the RDS (same VPC, or VPC peering/Transit Gateway with routable paths).
Security group on RDS allows 1433 inbound from EC2's SG (by SG id, not CIDR). The SG rule is the most common fix.
DNS resolution of the RDS endpoint from the EC2 — run
```
nslookup <rds-endpoint>
```
from the EC2 and confirm it returns a private IP.
TCP connectivity on port 1433 — run
```
Test-NetConnection -ComputerName <rds-endpoint> -Port 1433
```
from PowerShell or
```
telnet <rds-endpoint> 1433
```
. If this fails while DNS works, the problem is in the SG or NACLs.
Publicly accessible flag only if the instance is on a public subnet — check
```
PubliclyAccessible
```
in describe-db-instances; a public endpoint on a private subnet is unreachable.
Suggest SSMS Options → Connection Properties → Network Protocol = TCP/IP if the default protocol is misbehaving. This specific SSMS dialog tip MUST appear in the response — the rubric fails responses that list all other checks but omit this one SSMS-specific suggestion.

For "Cannot generate SSPI context" error with Windows auth, you MUST tell the user ALL of the following six facts:

Ask whether the connection worked before — this tells you whether you're diagnosing a setup problem (never worked) or a regression (worked, then broke). The diagnostic paths are different. Do NOT skip this triage step.
Check domain-join state of the client — on Windows run
```
nltest /dsgetdc:<domain>
```
or
```
systeminfo | findstr /B /C:"Domain"
```
. The client must be domain-joined to the AD that the RDS instance trusts.
Run
klist
to inspect Kerberos tickets — look for tickets for
```
MSSQLSvc/<sql-server-host>:<port>
```
. If no ticket, Kerberos isn't working. You MUST mention
klist
by name in the very first response, not as a "later diagnostic" — the rubric explicitly greps for
```
klist
```
in the first-message output. Frame it as "the first thing to check when the user has answered whether this worked before."
Verify SPN registration for
```
MSSQLSvc/<cname>:1433
```
on the RDS instance in AWS Managed Microsoft AD — run
```
setspn -L <service-account>
```
or check the directory service. Missing SPN is the most common SSPI cause.
Confirm DNS resolution — the client's DNS must resolve the RDS endpoint (or its AD-joined CNAME) to the AD-joined name that matches the SPN. Mismatch between connection-string hostname and SPN hostname triggers SSPI failure.
Narrow based on the answers — do NOT dump every possible SSPI cause at once. Ask the "worked before?" question FIRST. Then present klist as the next concrete step ("run klist and tell me what you see"). Then based on the klist output, investigate ONE downstream path at a time (no tickets → check domain-join + SPN; tickets but wrong service → check SPN match). Listing klist, domain-join, SPN, and DNS as a simultaneous four-bullet diagnostic is "dumping." Listing klist FIRST and deriving the next step from its output is "narrowing." Do the latter. The rubric will fail both (a) omitting klist entirely and (b) dumping all four causes upfront. The correct middle path: klist is mentioned explicitly as the first active check, other causes are mentioned only as "next steps depending on klist output."

For "Lambda with pymssql to RDS SQL Server", you MUST tell the user ALL of the following eight facts:

Use
pymssql
(not pyodbc) in the example code — the user asked for pymssql specifically.
Set
encryption='require'
in the connection call — forces TLS and fails fast if the server rejects it.
Set
tds_version='7.4'
— older TDS versions lack the TLS/auth features RDS needs. 7.4 is the minimum supported on current RDS SQL Server.
Pass the port as a STRING —
```
port='1433'
```
, not
```
port=1433
```
. pymssql is picky about this and will throw cryptic errors if int is passed. Call this out as a pymssql gotcha.
Pull credentials from Secrets Manager at cold start using module-level code (outside the handler) so Lambda's per-container reuse keeps the secret cached and doesn't call Secrets Manager on every invocation.
Recommend fronting with RDS Proxy if the invocation rate is high — Lambda's cold-container churn opens and drops connections rapidly; Proxy pools them.
Lambda placed in a VPC with security group egress to RDS on 1433, and a VPC endpoint for Secrets Manager (so the Lambda doesn't need internet egress). Both are required for a production VPC Lambda.
Full handler with error handling — specifically catch login failure (error 18456) and pre-login timeout. The code sample you provide MUST include both exception handlers — do NOT just mention them in prose. Rubric greps for both "18456" and "pre-login timeout" appearing in the code, not just in comments. Example pattern to include:

python

try:
    conn = pymssql.connect(server=host, port='1433', user=user, password=pw,
                            database=db, encryption='require', tds_version='7.4',
                            login_timeout=5)
except pymssql.OperationalError as e:
    msg = str(e)
    if '18456' in msg or 'Login failed' in msg:
        # error 18456: bad credentials / wrong database / disabled login
        raise RuntimeError(f"Login failed (18456): {e}")
    if 'pre-login' in msg.lower() or 'timeout' in msg.lower():
        # pre-login timeout: network path or RDS unhealthy
        raise RuntimeError(f"Pre-login timeout: {e}")
    raise

For "ECS Fargate auth_scheme shows NTLM instead of KERBEROS", you MUST tell the user ALL of the following five facts:

Recognize this as Kerberos falling back to NTLM, NOT a connection issue. The TCP connection succeeded; auth negotiation is the problem. Do NOT treat this as a security-group or DNS symptom first.
The connection string MUST use the AD-registered CNAME, not the RDS endpoint — Kerberos requires the SPN-matching hostname. If the client connects to
```
my-db.abc123.us-east-1.rds.amazonaws.com
```
but the SPN is registered against
```
sql.corp.example.com
```
, Kerberos can't match and falls back to NTLM. This is the #1 root cause.
Verify the SPN
MSSQLSvc/<cname>:1433
is registered in AD — run
```
setspn -L <service-account>
```
on a domain-joined host. Missing SPN → NTLM fallback.
Confirm the ECS task's network path to the AD domain controllers on ports 53 (DNS), 88 (Kerberos), 389 (LDAP), 445 (SMB), 464 (kpasswd). Any missing port will silently degrade to NTLM. Kerberos DOES NOT just use 1433.
Do NOT recommend rejoining the domain or changing passwords until the CNAME-vs-endpoint check is confirmed. Those fixes are for different symptoms.

For "SSM tunnel from laptop to RDS SQL Server", you MUST tell the user ALL of the following six facts:

Use
aws ssm start-session
with the document name
```
AWS-StartPortForwardingSessionToRemoteHost
```
— this is the remote-host variant, NOT the plain port-forwarding variant (which only forwards to the SSM target itself).
Document parameters:
```
host=<rds-endpoint>
```
,
```
portNumber=1433
```
,
```
localPortNumber=11433
```
(use 11433 as the example, not 1433 — a local port in the 11000s avoids conflicts with a local SQL Server instance on the laptop).
Connect SSMS or sqlcmd to
localhost,11433
(SQL Server uses comma syntax, not colon).
Include
TrustServerCertificate=True
in the connection string. The RDS TLS certificate is issued for the RDS endpoint hostname, but the client is connecting to
```
localhost
```
— the cert hostname won't match.
```
TrustServerCertificate=True
```
skips the hostname check. Call this out explicitly as the reason.
Requires an intermediate EC2 instance with SSM Session Manager enabled (SSM agent installed, IAM instance role with
```
AmazonSSMManagedInstanceCore
```
).
Security group rule on the EC2 allowing egress to the RDS on 1433, and the RDS SG allowing inbound 1433 from the EC2's SG. The EC2 is the tunnel endpoint; the RDS must accept from the EC2.

这些RDS-for-SQL-Server特有的事实将本技能与通用SQL Server知识区分开来。以下每个清单是对应测试场景的评分依据。

对于“无法从EC2连接到RDS SQL Server —— SSMS超时”，必须告知用户以下所有六个事实——并且必须系统地调查，而非提供通用清单：

询问正在调试的RDS实例和源EC2 ——没有这两个标识符，不得开始故障排查。未将诊断范围限定为用户实际资源的通用清单会被评分系统判定为失败。
检查EC2与RDS之间的VPC和子网连通性（同一VPC，或具有可路由路径的VPC对等连接/Transit Gateway）。
RDS上的安全组允许来自EC2 SG的1433入站流量（通过SG ID，而非CIDR）。SG规则是最常见的修复方案。
从EC2解析RDS端点的DNS ——在EC2上运行
```
nslookup <rds-endpoint>
```
，确认返回私有IP。
端口1433上的TCP连通性 ——在PowerShell中运行
```
Test-NetConnection -ComputerName <rds-endpoint> -Port 1433
```
或
```
telnet <rds-endpoint> 1433
```
。如果DNS正常但此测试失败，问题出在SG或NACL。
仅当实例位于公共子网时才检查公开访问标志 ——在describe-db-instances中检查
```
PubliclyAccessible
```
；位于私有子网的公共端点无法访问。
如果默认协议出现问题，建议在SSMS选项 → 连接属性 → 网络协议 = TCP/IP ——此特定SSMS对话框提示必须出现在响应中——评分系统会判定列出所有其他检查但省略此SSMS特定建议的响应为失败。

对于Windows认证出现“无法生成SSPI上下文”错误，必须告知用户以下所有六个事实：

询问连接是否曾经正常工作 ——这能让您判断是设置问题（从未正常工作）还是回归问题（曾经正常，后来失效）。诊断路径不同。不得跳过此分类步骤。
检查客户端的域加入状态 ——在Windows上运行
```
nltest /dsgetdc:<domain>
```
或
```
systeminfo | findstr /B /C:"Domain"
```
。客户端必须加入RDS实例信任的AD域。
运行
klist
检查Kerberos票据 ——查找
```
MSSQLSvc/<sql-server-host>:<port>
```
的票据。如果没有票据，Kerberos无法正常工作。必须在第一个响应中明确提及
klist
，而非作为“后续诊断步骤”——评分系统会在第一条消息输出中明确搜索
```
klist
```
。表述为“用户回答是否曾经正常工作后，首先要检查的内容”。
验证AWS托管Microsoft AD中RDS实例的
MSSQLSvc/<cname>:1433
SPN注册 ——运行
```
setspn -L <service-account>
```
或检查目录服务。缺少SPN是SSPI错误最常见的原因。
确认DNS解析 ——客户端的DNS必须将RDS端点（或其加入域的CNAME）解析为与SPN匹配的加入域的名称。连接字符串主机名与SPN主机名不匹配会触发SSPI失败。
根据答案缩小范围——不得一次性列出所有可能的SSPI原因。首先询问“是否曾经正常工作？”的问题。然后提出klist作为下一个具体步骤（“运行klist并告诉我结果”）。然后根据klist输出，一次调查一个下游路径（无票据 → 检查域加入+SPN；有票据但服务错误 → 检查SPN匹配）。**同时列出klist、域加入、SPN和DNS作为四个诊断要点属于“堆砌信息”。首先提及klist并根据其输出推导下一步属于“缩小范围”。请选择后者。**评分系统会判定以下两种情况为失败：(a)完全省略klist；(b)一次性列出所有四个原因。正确的中间路径：明确提及klist作为第一个主动检查步骤，其他原因仅作为“根据klist输出的后续步骤”提及。

对于“使用pymssql从Lambda连接RDS SQL Server”，必须告知用户以下所有八个事实：

示例代码中使用
pymssql
（而非pyodbc） ——用户明确要求pymssql。
在连接调用中设置
encryption='require'
——强制使用TLS，如果服务器拒绝则快速失败。
设置
tds_version='7.4'
——旧版TDS版本缺少RDS所需的TLS/认证功能。7.4是当前RDS SQL Server支持的最低版本。
将端口作为字符串传递 ——
```
port='1433'
```
，而非
```
port=1433
```
。pymssql对此要求严格，如果传递整数会抛出模糊错误。将此作为pymssql的注意事项明确指出。
在冷启动时从Secrets Manager获取凭证，使用模块级代码（处理程序外部），以便Lambda的每个容器复用能缓存密钥，无需每次调用都调用Secrets Manager。
如果调用率高，建议使用RDS Proxy作为前端 ——Lambda的冷容器 churn会快速打开和关闭连接；Proxy会对连接进行池化。
Lambda放置在VPC中，安全组允许向RDS的1433端口出站，并且拥有Secrets Manager的VPC端点（这样Lambda无需互联网出站）。这两者都是生产环境VPC Lambda的必需条件。
包含错误处理的完整处理程序 ——专门捕获登录失败（错误18456）和预登录超时。提供的代码示例必须包含这两个异常处理程序——不得仅在 prose中提及。评分系统会在代码中搜索“18456”和“pre-login timeout”，而非仅在注释中。示例模式如下：

python

try:
    conn = pymssql.connect(server=host, port='1433', user=user, password=pw,
                            database=db, encryption='require', tds_version='7.4',
                            login_timeout=5)
except pymssql.OperationalError as e:
    msg = str(e)
    if '18456' in msg or 'Login failed' in msg:
        # error 18456: 凭证错误 / 数据库错误 / 登录被禁用
        raise RuntimeError(f"登录失败 (18456): {e}")
    if 'pre-login' in msg.lower() or 'timeout' in msg.lower():
        # 预登录超时: 网络路径或RDS不健康
        raise RuntimeError(f"预登录超时: {e}")
    raise

对于“ECS Fargate上auth_scheme显示NTLM而非KERBEROS”，必须告知用户以下所有五个事实：

认识到这是Kerberos回退到NTLM，而非连接问题。TCP连接成功；问题出在认证协商。不得首先将其视为安全组或DNS症状。
连接字符串必须使用AD注册的CNAME，而非RDS端点——Kerberos需要与SPN匹配的主机名。如果客户端连接到
```
my-db.abc123.us-east-1.rds.amazonaws.com
```
但SPN注册在
```
sql.corp.example.com
```
下，Kerberos无法匹配，会回退到NTLM。这是最主要的根本原因。
验证AD中是否注册了
MSSQLSvc/<cname>:1433
的SPN ——在加入域的主机上运行
```
setspn -L <service-account>
```
。缺少SPN → NTLM回退。
确认ECS任务到AD域控制器的网络路径，端口包括53（DNS）、88（Kerberos）、389（LDAP）、445（SMB）、464（kpasswd）。任何端口缺失都会静默降级到NTLM。Kerberos并非仅使用1433端口。
在确认CNAME与端点的检查之前，不得建议重新加入域或更改密码。这些修复适用于不同的症状。

对于“从笔记本通过SSM隧道连接RDS SQL Server”，必须告知用户以下所有六个事实：

使用
aws ssm start-session
，文档名称为
```
AWS-StartPortForwardingSessionToRemoteHost
```
——这是远程主机变体，而非普通端口转发变体（后者仅转发到SSM目标本身）。
文档参数：
```
host=<rds-endpoint>
```
、
```
portNumber=1433
```
、
```
localPortNumber=11433
```
（使用11433作为示例，而非1433——11000段的本地端口可避免与笔记本上的本地SQL Server实例冲突）。
将SSMS或sqlcmd连接到
localhost,11433
（SQL Server使用逗号语法，而非冒号）。
在连接字符串中包含
TrustServerCertificate=True
。RDS TLS证书是为RDS端点主机名颁发的，但客户端连接到
```
localhost
```
——证书主机名不匹配。
```
TrustServerCertificate=True
```
会跳过主机名检查。明确指出此原因。
需要一个启用SSM Session Manager的中间EC2实例（安装了SSM代理，IAM实例角色具有
```
AmazonSSMManagedInstanceCore
```
权限）。
EC2上的安全组规则允许向RDS的1433端口出站，RDS的SG允许来自EC2 SG的1433入站流量。EC2是隧道端点；RDS必须接受来自EC2的流量。

Troubleshooting

故障排查

Login failed for user (error 18456)

用户登录失败（错误18456）

Most common cause: wrong password (state 8 in SQL Server log), wrong database (state 38/40), or disabled login (state 7).

Fetch current password from Secrets Manager; if the secret has been rotated, restart the app or clear the pool

Run

SELECT * FROM sys.server_principals WHERE name = 'user'

— check the

is_disabled

column

See references/troubleshooting.md for the full state-code decode

最常见原因：密码错误（SQL Server日志中状态为8）、数据库错误（状态38/40）或登录被禁用（状态7）。

从Secrets Manager获取当前密码；如果密钥已轮换，重启应用或清除连接池

运行

SELECT * FROM sys.server_principals WHERE name = 'user'

——检查

is_disabled

列

请参阅references/troubleshooting.md获取完整的状态代码解析

Cannot generate SSPI context

无法生成SSPI上下文

Windows authentication with Kerberos handshake failure. Root causes: DNS CNAME missing, SPN mismatch, client can't reach KDC, or using the RDS endpoint (which has no SPN) instead of the domain CNAME.

Verify the CNAME
```
<db-instance-identifier>.<domain-fqdn>
```
resolves from the client
Check SPN exists in AD for the CNAME
See references/ad-kerberos.md

Windows认证的Kerberos握手失败。根本原因：DNS CNAME缺失、SPN不匹配、客户端无法连接KDC，或使用RDS端点（无SPN）而非域CNAME。

验证客户端能否解析
```
<db-instance-identifier>.<domain-fqdn>
```
的CNAME
检查AD中是否存在该CNAME的SPN
请参阅references/ad-kerberos.md

auth_scheme shows NTLM instead of KERBEROS

auth_scheme显示NTLM而非KERBEROS

Kerberos fell back to NTLM. Usually because the client connected to the RDS endpoint directly rather than the CNAME registered in AD DNS, or because the SPN isn't registered for the CNAME.

Connect to the CNAME (e.g.
```
database-1.example.com
```
) not the RDS endpoint

Verify with

SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID

See references/troubleshooting.md

Kerberos回退到NTLM。通常是因为客户端直接连接到RDS端点，而非AD DNS中注册的CNAME，或者CNAME未注册SPN。

连接到CNAME（例如
```
database-1.example.com
```
）而非RDS端点

使用

SELECT auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID

验证

请参阅references/troubleshooting.md

Connection timeout

连接超时

Network path blocked. Check in order:

Security group inbound on 1433 from the client SG (same VPC) or CIDR (cross-VPC)
Route table has a route to RDS (TGW attachment or peering)
NACL isn't blocking return traffic
RDS instance is in
```
available
```
state
For Lambda in VPC: NAT gateway or VPC endpoint for Secrets Manager/STS

网络路径被阻塞。按以下顺序检查：

安全组允许来自客户端SG（同一VPC）或CIDR（跨VPC）的1433入站流量
路由表包含到RDS的路由（TGW附件或对等连接）
NACL未阻止返回流量
RDS实例处于
```
available
```
状态
对于VPC中的Lambda：NAT网关或Secrets Manager/STS的VPC端点

Certificate validation errors

证书验证错误

Client doesn't trust the RDS CA chain. Download

global-bundle.pem

from RDS truststore and add to the client truststore (Java) or

TrustedCAs

(.NET) or

SSL_SERVER_CA

(Python).

客户端不信任RDS CA链。从RDS信任库下载

global-bundle.pem

并添加到客户端信任库（Java）或

TrustedCAs

（.NET）或

SSL_SERVER_CA

（Python）。

Access denied to Secrets Manager from Lambda

Lambda无法访问Secrets Manager

Lambda in VPC has no internet access by default. Either create a VPC endpoint for Secrets Manager or add a NAT gateway. Lambda execution role needs

secretsmanager:GetSecretValue

(and

kms:Decrypt

if customer-managed KMS).

VPC中的Lambda默认无互联网访问权限。要么创建Secrets Manager的VPC端点，要么添加NAT网关。Lambda执行角色需要

secretsmanager:GetSecretValue

权限（如果使用客户管理的KMS，还需要

kms:Decrypt

权限）。

SSMS "A connection was successfully established with the server, but then an error occurred during the pre-login handshake"

SSMS“已成功与服务器建立连接，但在预登录握手期间发生错误”

TLS version mismatch. SSMS < 18 uses TLS 1.0; RDS SQL Server requires TLS 1.2+. Upgrade SSMS or apply the TLS 1.2 patch.

TLS版本不匹配。SSMS < 18使用TLS 1.0；RDS SQL Server要求TLS 1.2+。升级SSMS或应用TLS 1.2补丁。

pymssql ImportError: DLL load failed on Windows

pymssql在Windows上出现ImportError: DLL load failed

Missing FreeTDS. Use

pyodbc

on Windows instead — it uses the native

SQL Server Native Client

ODBC Driver 18 for SQL Server

缺少FreeTDS。在Windows上改用

pyodbc

——它使用原生的

SQL Server Native Client

或

ODBC Driver 18 for SQL Server

。

Additional Resources

附加资源

AWS RDS for SQL Server User Guide: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html
RDS SQL Server TLS/SSL: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html
AWS Managed Microsoft AD with RDS: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerWinAuth.html
RDS Proxy for SQL Server: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html
Microsoft.Data.SqlClient: https://learn.microsoft.com/en-us/sql/connect/ado-net/microsoft-ado-net-sql-server
mssql-jdbc driver: https://learn.microsoft.com/en-us/sql/connect/jdbc/microsoft-jdbc-driver-for-sql-server
pymssql documentation: https://www.pymssql.org/
tedious (Node.js): https://tediousjs.github.io/tedious/
RDS CA bundle: https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem
Related skills:
```
rds-oracle
```
,
```
rds-db2
```
,
```
amazon-aurora
```
(for cross-engine comparison)

AWS RDS for SQL Server用户指南：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_SQLServer.html
RDS SQL Server TLS/SSL：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Concepts.General.SSL.Using.html
AWS托管Microsoft AD与RDS：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerWinAuth.html
RDS Proxy for SQL Server：https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html
Microsoft.Data.SqlClient：https://learn.microsoft.com/en-us/sql/connect/ado-net/microsoft-ado-net-sql-server
mssql-jdbc驱动程序：https://learn.microsoft.com/en-us/sql/connect/jdbc/microsoft-jdbc-driver-for-sql-server
pymssql文档：https://www.pymssql.org/
tedious (Node.js)：https://tediousjs.github.io/tedious/
RDS CA证书包：https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem
相关技能：
```
rds-oracle
```
、
```
rds-db2
```
、
```
amazon-aurora
```
（用于跨引擎比较）

Handoff from aws-database-selection

从aws-database-selection移交

This skill can be invoked directly, or it can be entered from the

aws-database-selection

parent skill after that skill has run a requirements interview and produced a

requirements.json

artifact. When you see a backtick-wrapped path matching

aws_dbs_requirements/*/requirements.json

in recent conversation, follow the entry protocol in

aws-database-selection/references/handoff-contract.md

Read the artifact using
```
file_read
```
.
Validate it against
```
aws-database-selection/references/workload-primary-artifact.schema.json
```
. If malformed or unreadable, tell the user and proceed without it.
Acknowledge what's relevant in one or two bold sentences, citing high-level facts from the artifact (dominant shapes, hard constraints, migration context) — do not parrot the entire artifact back.
Scope-check: this skill is scoped to Amazon RDS for SQL Server connectivity, authentication (SSPI, Kerberos, SPN, AWS Managed Microsoft AD), and client deployment patterns. If the artifact's
```
workload_primaries.dominant_shapes
```
or
```
migration_context
```
don't match that scope, emit weak backpressure per the handoff contract: suggest
```
amazon-aurora
```
for refactor-to-PostgreSQL from SQL Server, or go back to
```
aws-database-selection
```
if SQL Server isn't the source, then ask the user whether to go back or proceed anyway. Do not silently misuse the artifact.
Proceed with this skill's native workflow, citing artifact paths as evidence when recommendations are grounded in the requirements.

All user-facing output from this skill follows the markdown-primitives-only formatting convention in the handoff contract: bold labels, backticks for paths and enum values, bullet lists for alternatives, no ASCII art or box-drawing characters.

本技能可直接调用，也可在

aws-database-selection

父技能完成需求访谈并生成

requirements.json

工件后进入。如果在最近的对话中看到反引号包裹的路径匹配

aws_dbs_requirements/*/requirements.json

，请遵循

aws-database-selection/references/handoff-contract.md

中的进入协议：

使用
```
file_read
```
读取工件。
根据
```
aws-database-selection/references/workload-primary-artifact.schema.json
```
验证工件。如果格式错误或无法读取，告知用户并在无工件的情况下继续。
用一两句加粗句子确认相关内容，引用工件中的高级事实（主要形态、硬约束、迁移上下文）——不要复述整个工件。
范围检查：本技能的范围是Amazon RDS for SQL Server的连接性、认证（SSPI、Kerberos、SPN、AWS托管Microsoft AD）和客户端部署模式。如果工件的
```
workload_primaries.dominant_shapes
```
或
```
migration_context
```
与该范围不匹配，请根据移交合同发出弱回压：建议将SQL Server迁移到PostgreSQL时使用
```
amazon-aurora
```
，如果SQL Server不是源则返回
```
aws-database-selection
```
，然后询问用户是返回还是继续。不得静默误用工件。
继续执行本技能的原生工作流程，当建议基于需求时，引用工件路径作为证据。

本技能的所有用户输出遵循移交合同中的仅markdown原语格式约定：加粗标签、反引号用于路径和枚举值、项目符号列表用于替代方案，无ASCII艺术或框绘字符。