Marico's space
作为「30 天 AWS Terraform 挑战」的第 28 天，我终于把一块硬骨头啃了下来——用 Terraform 在 AWS 上完整部署了一套生产级的三层架构。
这个项目带给我的最大收获，不是学会了敲多少行代码，而是真正理解了什么叫「像系统设计师一样思考」：可扩展性、安全性、可靠性，这三者之间的取舍与平衡，才是云工程的真功夫。
三层架构（3-Tier Architecture）是现代云系统的基石模式，核心理念是把系统拆成三个职责清晰的层：
这样分层的好处很直接：
我在 AWS 上搭建的架构大致是这样的：
第一步是搭建一个自定义的虚拟私有云（VPC，Virtual Private Cloud），这是所有安全隔离的基础：
这样一来，外部流量只能到达负载均衡器，后端服务完全藏在私有网络里，攻击面大幅缩减。
生产环境最怕单点故障。我的做法是把资源分布在 2 个可用区（AZ，Availability Zone），计算和网络组件都做了跨 AZ 冗余。
结果就是：即使一个 AZ 整体宕机，应用依然可以在另一个 AZ 继续服务。
Web 层我只部署了一个组件：Application Load Balancer（ALB，应用负载均衡器）。它是整个系统的唯一公网入口，所有用户请求都从这里进来，再被路由到后端的应用服务器。
业务逻辑跑在私有子网的 EC2 实例上，由 Auto Scaling Groups（ASG，自动伸缩组）统一管理：
数据库层使用的是 Amazon RDS（Relational Database Service，关系型数据库服务），支持的引擎包括 MySQL 和 PostgreSQL。
RDS 实例被放在私有子网组里，只能从应用层访问，公网完全不可达——这是数据库安全的基本线。
整个基础设施是用 Terraform 搭建的，采用的是模块化思路：每个功能组件独立成模块，然后在主配置里调用。
这次创建了以下 Terraform 模块：
模块化的好处：代码可以在不同环境（测试、预发、生产）复用，结构清晰，出了问题也容易定位，部署速度也更快——写一次，到处跑。
实施过程中遇到的实际问题：
这些都是教科书不会告诉你的东西，只有亲自踩过，才知道边界在哪里。
Terraform 写代码不难，真正难的是设计一个经得住生产环境考验的系统。部署只是最后一步，前面的架构设计才是核心竞争力。
数据库永远不要暴露在公网。各层之间严格隔离，安全组规则遵循最小权限原则，宁可多检查，也不要大开后门。
Terraform 模块把一个复杂的分布式系统拆成了可独立管理的小组件。掌握了这个思路，你面对的系统规模可以比原来大很多倍。
把东西弄坏，再把它修好，这个过程能教给你的远比任何教程都多。
第 28 天，感觉自己真正从「会写 Terraform 代码」跨到了「能设计真实云架构」的门槛上。
现代云系统的标准答案：可扩展、安全、容错、自动化——这四点全部做到，才是真正的生产级系统。
挑战还剩两天，接下来会把最后的优化和高级模式走完，给这次旅程画一个完整的句号。
原文链接：Scaling Cloud Proficiency: Building a Production-Ready 3-Tier Architecture with Terraform