我太懂这种“为了加个响应头就得搭个后端服务器”的无奈了——完全没必要为这点小事长期维护一台实例，给你分享几个更轻量的AWS原生方案，都是不用跑常驻服务器的：

方案一：用ALB的Lambda集成直接添加HSTS头 #

AWS ALB现在支持把Lambda函数作为目标，你可以写一个超简单的Lambda函数（Python/Node.js都行），在返回301重定向响应的时候直接带上HSTS头，完全不需要后端服务器：

• 先创建一个Lambda函数，逻辑很简单：返回状态码301，Location头指向新域名，同时在响应头里加上Strict-Transport-Security: max-age=31536000; includeSubDomains（根据安全团队要求调整max-age和参数）
• 然后在旧域名的ALB监听器规则里，把目标改成这个Lambda函数，代替原来的重定向规则
• 这样用户请求旧域名时，ALB会触发Lambda函数，直接返回带HSTS头的301响应，全程无后端服务器

举个Python版Lambda的极简示例：

def lambda_handler(event, context):
    return {
        'statusCode': 301,
        'headers': {
            'Location': 'https://新域名.com' + event['path'],
            'Strict-Transport-Security': 'max-age=31536000; includeSubDomains'
        },
        'body': ''
    }

这个函数连额外依赖都不需要，直接部署就能用，成本几乎可以忽略（Lambda的免费额度完全够旧域名的访问量）。

方案二：如果旧域名用了CloudFront，用Lambda@Edge处理 #

如果你的旧域名已经配置了CloudFront分发，那用Lambda@Edge更方便：

• 创建一个Viewer Response阶段的Lambda@Edge函数，在返回给用户的响应里添加HSTS头，同时配置CloudFront的重定向行为（或者在Lambda里直接返回301）
• 好处是CloudFront全球边缘节点会缓存这个响应逻辑，延迟更低，而且同样是无服务器架构

方案三：用Route 53 + S3静态网站（仅限静态重定向场景） #

如果旧域名的重定向是全站级别的（不需要复杂的路径匹配），还可以用S3静态网站托管：

• 把旧域名绑定到一个S3桶，开启静态网站重定向，目标设置为新域名
• 然后在CloudFront前面套一层，用Lambda@Edge给S3返回的重定向响应加上HSTS头
• 这个方案比Lambda集成更“彻底无服务器”，但缺点是对路径复杂的重定向支持有限

额外提醒 #

不管用哪个方案，HSTS头的参数要符合安全团队的要求：

• 必须包含max-age，建议至少设置为31536000（即1年）
• 如果需要覆盖所有子域名，加上includeSubDomains参数
• 如果要申请HSTS预加载列表，加上preload（但要注意一旦加入预加载，后续取消会非常麻烦，需谨慎操作）

相比你之前想的维护后端服务器，这些无服务器方案不仅省成本，还不用操心服务器的补丁、扩容、监控这些琐事，完全是一劳永逸的解决办法。

备注：内容来源于stack exchange，提问作者zip_000