AWS 服务器安全防护应从入口控制开始，再处理 Web 请求、DDoS 风险、源站保护和异常监控。
单独依赖某一个产品无法完成完整防护。
EC2 安全组负责控制端口和来源
CloudFront 负责降低源站暴露
AWS WAF 负责过滤 HTTP/HTTPS 请求
AWS Shield 负责 DDoS 基础防护
CloudWatch、WAF logs、CloudFront logs 和 GuardDuty 负责发现异常。
AWS 服务器安全防护的基本思路
先控制入口再配置 Web 防护
EC2 实例上线后，第一步不是安装更多安全软件，而是收紧网络入口。
Security Group 是 AWS 里最基础的网络边界，它控制关联资源的入站和出站流量，可以按协议、端口和来源设置规则。
安全组是有状态的，允许的入站请求对应的响应流量会自动放行。(AWS文档)
服务器只应开放业务需要的端口。
Web 服务通常开放 80 和 443；SSH、RDP、数据库、缓存、后台管理端口不应面向整个公网。
服务器开通阶段就应完成系统镜像、密钥对、安全组和公网访问规则配置，具体购买和基础开通流程可参考 亚马逊云服务器购买。
防护目标是限制暴露面
服务器安全不是关闭所有访问。
网站必须对外提供服务，但管理入口、数据库入口和内部接口应限制来源。
安全配置的目标是让正常用户访问 Web 服务，让管理人员通过受控入口运维，让数据库和内部服务只接受可信来源访问。
一个基础防护结构可以这样规划：
EC2 或 ALB 承载应用，CloudFront 作为网站入口，AWS WAF 绑定在 CloudFront 或 ALB 前端，数据库放在私有网络，S3 静态资源通过 CloudFront 分发。
文件权限和对象存储配置可参考 AWS S3 教程，CDN 源站、缓存、HTTPS 和费用配置可参考 AWS CloudFront 教程。
EC2 安全组配置
只开放必要端口
安全组规则应按服务用途配置，不应开放大范围端口。
Web 服务器可以开放 HTTP 和 HTTPS；管理端口只允许固定办公 IP、VPN 或堡垒机来源；数据库端口只允许应用服务器安全组访问。
| 服务 | 常见端口 | 推荐来源 |
| HTTP | 80 | 公网 |
| HTTPS | 443 | 公网 |
| SSH | 22 | 固定 IP / VPN |
| RDP | 3389 | 固定 IP / VPN |
| MySQL | 3306 | 应用服务器安全组 |
| PostgreSQL | 5432 | 应用服务器安全组 |
| Redis | 6379 | 内网安全组 |
AWS Config 的 restricted-ssh 规则也把 SSH 面向 0.0.0.0/0 或 ::/0 视为不合规状态。
管理端口长期暴露给全网，会增加暴力登录、凭证试探和自动化扫描风险。(AWS文档)
SSH 和 RDP 限制来源
Linux 服务器使用 SSH，Windows 服务器使用 RDP。
二者都是管理入口，不应与网站端口采用同一开放范围。
生产环境应使用密钥登录、限制来源 IP，并避免弱密码和共享密钥。
密钥文件不应上传到代码仓库、共享网盘或镜像中。
运维团队应使用受控入口管理实例，例如 VPN、堡垒机或临时授权规则。
管理入口越分散，审计和责任追踪越困难。
数据库端口不开放公网
MySQL、PostgreSQL、Redis、MongoDB、Elasticsearch 等服务不应直接暴露到公网。
应用服务器访问数据库时，可以用安全组引用安全组的方式授权，只允许应用层访问数据库层。
生产数据库建议优先使用私有网络和托管数据库方案。
RDS 的 VPC、安全组、自动备份、Multi-AZ 和 Read Replica 规划可参考 AWS RDS 教程。
数据库安全的核心不是端口能否连通，而是访问来源、账号权限、备份恢复和审计能力是否完整。
CloudFront 保护源站
网站流量先经过 CloudFront
CloudFront 可以减少源站负载，并阻止非 Web 流量直接到达源站。
AWS DDoS 弹性最佳实践文档说明，CloudFront 要求请求通过有效 IP 和完整 TCP 握手建立连接，并可自动关闭慢速读写攻击连接，例如 Slowloris 类请求。(AWS文档)
网站对外入口使用 CloudFront 后，静态资源和部分公开页面可以在边缘节点缓存，源站只处理必要回源请求。
这能降低 EC2、ALB 或 S3 的直接压力，也有利于后续接入 WAF。
限制用户直接访问源站
配置 CloudFront 后，源站仍然应减少直接暴露。
S3 源站应使用 Origin Access Control 让 CloudFront 访问私有 bucket；EC2 或 ALB 源站应限制不必要的公网入口；后台、数据库和内部 API 不应通过公开路径暴露。
源站保护的目的，是让用户通过 CloudFront 访问公开内容，而不是绕过 CDN 直接访问 EC2、ALB 或 S3。若源站完全公开，CloudFront 和 WAF 只能保护经过它们的流量，无法覆盖绕过路径。
AWS WAF 过滤 Web 请求
Web ACL 绑定 CloudFront 或 ALB
AWS WAF 通过 Web ACL 控制受保护资源的 HTTP/HTTPS 请求。
Web ACL 可以绑定 CloudFront、API Gateway、Application Load Balancer 等资源，并按规则对请求执行允许、阻断或计数动作。(AWS文档)
CloudFront 适合作为全球网站入口，ALB 适合作为区域应用入口，API Gateway 适合 API 服务入口。
WAF 规则上线前，建议先使用 Count 模式观察命中情况，再逐步切换到阻断，避免正常业务请求被误拦截。
使用 Managed Rules 建立基础防护
AWS Managed Rules 可用于防护常见应用漏洞和异常请求，包括常见恶意请求模式、SQL 注入类请求、脚本注入类请求、异常路径和请求大小异常。
AWS 官方说明，Managed Rules 是用于防护应用漏洞或不需要流量的托管规则服务，可添加到 Web ACL 中。(AWS文档)
Managed Rules 适合作为基础层，但不能替代业务规则。
登录、搜索、表单、支付、下载、后台路径的风险不同，应按业务路径调整规则动作、例外条件和观察周期。
Rate-based rule 限制高频请求
接口刷量、登录试探、搜索滥用、表单高频提交，可以用 rate-based rule 处理。AWS WAF 的 rate-based rule 会按聚合条件统计请求数量，并在请求速率超过阈值时执行限速或阻断；聚合条件可以包括 IP 地址、Header 等。(AWS文档)
高频规则不应只看单一 IP。
代理池、不同国家流量、特定路径异常、特定 User-Agent 异常都可能影响判断。稳定做法是先记录请求，再根据日志设置路径、IP、国家、Header 和请求频率规则。
AWS Shield 防御 DDoS
Shield Standard 提供基础防护
AWS Shield Standard 面向所有 AWS 客户提供基础 DDoS 防护，用于防御常见网络层和传输层 DDoS 攻击。
普通网站、企业官网和常规业务通常先使用 Shield Standard，并结合 CloudFront、Route 53、WAF 和安全组完成基础防护。(AWS文档)
Shield Standard 不是单独的配置入口，它是 AWS 基础防护能力的一部分。
真正影响防护效果的，是应用是否使用边缘服务、源站是否减少暴露、WAF 是否过滤异常 Web 请求、日志是否能支持排查。
Shield Advanced 适合高风险业务
Shield Advanced 面向更高风险业务，例如金融站点、游戏平台、下载站、大流量营销活动、容易被攻击的业务系统。
AWS Shield Advanced 采用订阅费用模式，并可能产生额外用量费用，成本明显高于基础防护。(Amazon Web Services, Inc.)
普通网站不应把 Shield Advanced 作为默认配置。
只有业务停机损失高、攻击风险明确、DDoS 响应要求高时，才需要评估 Shield Advanced。
长期使用 WAF、CloudFront、Shield Advanced 和日志服务时，付款方式、充值续费和账单核对应提前规划，可结合 AWS代付 处理持续账单。
监控、日志和异常发现
CloudWatch 监控资源异常
CloudWatch 应监控 CPU、NetworkIn、NetworkOut、磁盘、状态检查、ALB 请求数、5xx 错误率和延迟。
告警阈值应基于业务正常流量设置，不应照搬固定数值。网站高峰期、活动期、爬虫访问期和攻击期的指标表现不同，基线数据越清晰，告警越有效。
WAF logs 和 CloudFront logs 分析请求
WAF logs 用于查看哪些请求被允许、计数或阻断。CloudFront logs 用于分析访问来源、路径、状态码、请求量和缓存命中情况。
两类日志结合后，可以判断异常请求是否集中在特定路径、国家、IP、Header 或 User-Agent。
日志不是只在攻击后才使用。
规则调整、误拦截确认、缓存策略优化、流量来源分析，都需要依赖日志。
没有日志，WAF 规则只能凭感觉配置。
GuardDuty 发现潜在入侵行为
GuardDuty 可用于发现潜在安全异常。
AWS 文档说明，若 EC2 finding 中的活动不是授权行为，最佳实践是将该实例视为可能已被入侵，并按流程识别实例、调查恶意软件或异常行为并执行修复。(AWS文档)
发现疑似被入侵实例后，应先隔离实例，保留必要证据，再检查恶意进程、外连、异常账号、密钥泄露和计划任务。
恢复方式不应只依赖清理文件。更稳的做法是从可信镜像重建实例，轮换密钥和凭证，并从干净备份恢复业务数据。
AWS 安全防护费用怎么看
安全组本身不额外收费
Security Group 是基础网络控制能力，使用安全组本身不额外收费。它应作为所有 EC2、RDS、ALB 和相关 VPC 资源的基础配置。(AWS文档)
WAF、CloudFront 和日志会产生成本
AWS WAF 的费用与 Web ACL、规则数量和 Web 请求数量有关；AWS 官方定价说明，WAF 费用基于创建的 Web ACL、每个 Web ACL 添加的规则数量以及收到的 Web 请求数量。(Amazon Web Services, Inc.)
CloudFront 会产生流量、请求、缓存失效、边缘函数和日志相关费用。
安全成本不能只看 EC2 实例价格。
服务器、CDN、WAF、日志、数据传输和备份应一起纳入月度成本评估，长期预算可参考 亚马逊云服务器价格。
企业项目如果需要账号开通、安全组配置、CloudFront、WAF、账单核对和基础技术支持，可通过 AWS代理 协助处理。
具体服务范围、充值赠金和适用产品应按账号类型、充值金额和实际规则确认。
AWS 服务器安全配置检查
上线前检查网络入口
上线前应确认 Web 服务只开放必要端口，SSH 和 RDP 限制来源，数据库端口只允许应用服务器访问，Redis、Elasticsearch、管理后台和内部接口未暴露公网。安全组规则应保留用途说明，避免后期无法判断规则来源。
上线后检查源站和 WAF
网站应通过 CloudFront 访问公开内容，S3 应保持私有，源站应减少直接访问路径。
WAF 应启用基础规则，并对登录、搜索、表单、下载等高风险路径设置监控或限速规则。规则调整应基于日志，不应直接阻断未知流量。
长期运行检查日志、备份和账单
长期运行时，应持续检查 CloudWatch 告警、WAF logs、CloudFront logs、GuardDuty findings、实例备份、数据库备份和安全服务费用。
安全配置不是上线时的一次性动作，流量结构、业务路径、攻击方式和账单都会变化。
AWS 服务器防御网络攻击的配置顺序
AWS 服务器防护应按顺序执行。先收紧 EC2 安全组、管理端口、数据库端口和系统权限；再用 CloudFront 保护网站入口和静态资源；然后用 AWS WAF 过滤 Web 请求和高频访问；对高风险业务再评估 Shield Advanced；最后用 CloudWatch、WAF logs、CloudFront logs 和 GuardDuty 持续发现异常。
安全配置的核心是减少暴露面、限制访问来源、记录异常行为、保留恢复能力。只购买高配置服务器不能提高安全性。端口、源站、WAF、DDoS、防护费用和运维流程一起规划，才能降低网络攻击对 AWS 业务的影响。
