前面几位已经把分层架构和安全组互相引用讲得很透彻了，我从一个基础设施即代码（IaC）的角度补充一套可直接落地的 Terraform 实践，这也是"易维护"最关键的一环。一、用 Terraform 管理安全组，告别控制台手点安全组规则写在 .tf 文件里，有版本记录、能 code review、能回滚。一个典型的三层安全组引用如下：sg-web 入方向放行 80/443（来源 0.0.0.0/0），22 端口只放行堡垒机 IP；sg-app 入方向 8080，source_security_group_id 直接引用 sg-web 的 ID；sg-db 入方向 3306，source_security_group_id 引用 sg-app 的 ID。这样 Web 层扩容时，app 和 db 的规则一行不用改——这正是前面几位说的"用安全组互相引用代替写死网段"在 IaC 里的自然写法。二、变量分层，环境隔离把网段、端口、可用区等抽成 variable，dev/test/prod 各一份 tfvars。同一套 .tf 代码 + 不同 tfvars = 不同环境，避免"生产环境手改了一台，测试环境不知道"的配置漂移。三、terraform plan 先看再 apply每次变更先跑 plan 看清楚会改哪些规则，确认没有误删或意外放开端口，再 apply。这比控制台"改完就生效、想回滚也记不清原来啥样"安全得多。四、状态文件管理terraform.tfstate 记录了当前基础设施的完整状态，团队协作时放到远端后端（如 OBS）并加锁，避免多人同时 apply 互相覆盖。五、排错时 IaC 的优势线上连不上时，先 terraform plan 看是否有 drift（云端被人手改过、与代码不一致），再查安全组入方向、网络 ACL、系统防火墙、服务监听地址。drift 是排错时最容易被忽略的问题，IaC 让它可见。小结：分层网络 + 安全组互相引用 + Terraform 管理 + plan 先看再 apply + 状态远端托管。前四步管"安全"，最后一步管"可维护"，五步做到位，安全和易维护就真正兼顾了。

前面几位已经把分层架构和安全组互相引用讲得很透彻了，我从一个基础设施即代码（IaC）的角度补充一套可直接落地的 Terraform 实践，这也是"易维护"最关键的一环。一、用 Terraform 管理安全组，告别控制台手点安全组规则写在 .tf 文件里，有版本记录、能 code review、能回滚。一个典型的三层安全组引用如下：sg-web 入方向放行 80/443（来源 0.0.0.0/0），22 端口只放行堡垒机 IP；sg-app 入方向 8080，source_security_group_id 直接引用 sg-web 的 ID；sg-db 入方向 3306，source_security_group_id 引用 sg-app 的 ID。这样 Web 层扩容时，app 和 db 的规则一行不用改——这正是前面几位说的"用安全组互相引用代替写死网段"在 IaC 里的自然写法。二、变量分层，环境隔离把网段、端口、可用区等抽成 variable，dev/test/prod 各一份 tfvars。同一套 .tf 代码 + 不同 tfvars = 不同环境，避免"生产环境手改了一台，测试环境不知道"的配置漂移。三、terraform plan 先看再 apply每次变更先跑 plan 看清楚会改哪些规则，确认没有误删或意外放开端口，再 apply。这比控制台"改完就生效、想回滚也记不清原来啥样"安全得多。临时放行的端口，plan review 时一眼就能看到，事后及时删掉。四、状态文件管理terraform.tfstate 记录了当前基础设施的完整状态，团队协作时放到远端后端（如 OBS）并加锁，避免多人同时 apply 互相覆盖。state 文件里可能含敏感信息，不要提交到代码仓库。五、排错时 IaC 的优势线上连不上时，先 terraform plan 看是否有 drift（云端被人手改过、与代码不一致），再查安全组入方向、网络 ACL、系统防火墙、服务监听地址。drift 是排错时最容易被忽略的问题，IaC 让它可见。小结：分层网络 + 安全组互相引用 + Terraform 管理 + plan 先看再 apply + 状态远端托管。前四步管"安全"，最后一步管"可维护"，五步做到位，安全和易维护就真正兼顾了。