Vukodlok/aws-cloud-engineering-capstone
GitHub: Vukodlok/aws-cloud-engineering-capstone
一个遵循 AWS Well-Architected Framework 的云工程作品集项目，使用 Terraform 在 AWS 上自动化构建安全、模块化且可复现的云基础设施。
Stars: 1 | Forks: 0
# AWS 云工程作品集项目
使用 Terraform、GitHub Actions 和 AWS CloudWatch 遵循 AWS Well-Architected Framework 构建的安全、自动化且可复现的 AWS 基础设施。
## 项目概览
| 类别 | 实现 |
|---|---|
| 云服务提供商 | Amazon Web Services (AWS) |
| 基础设施即代码 | Terraform |
| 计算 | Amazon EC2 |
| 网络 | Amazon VPC、公有/私有 Subnet、Route Table |
| 存储 | 启用服务端加密的 Amazon S3 |
| 监控 | Amazon CloudWatch、CloudWatch Logs、CloudWatch Alarms |
| 通知 | Amazon SNS |
| CI/CD | GitHub Actions |
| 架构原则 | AWS Well-Architected Framework |
| 安全重点 | 最小权限、网络隔离、加密 |
## 项目概述
本项目展示了在 Amazon Web Services (AWS) 上，使用 Terraform 作为基础设施即代码 来设计并实现一个安全、自动化、模块化且可复现的云基础设施。该解决方案通过自动化基础设施部署、实施运维监控，以及通过 GitHub Actions CI/CD 工作流验证基础设施更改，解决了常见的云工程挑战。
该架构配置了 AWS 网络、计算、监控和存储资源，同时强调了自动化、安全性、可维护性和可重复性。在整个开发过程中，设计决策以 AWS Well-Architected Framework 为指导，并在必要时进行了调整，以适应 AWS Academy 沙箱环境的限制，同时不损害架构的最佳实践。
本仓库包含项目的完整 Terraform 源代码、技术文档、架构图、屏幕截图以及实现细节。
# 解决方案架构
cd aws-cloud-engineering-capstone
```
2. 导航到目标环境：
```
cd terraform/environments/prod
```
3. 初始化 Terraform：
```
terraform init
```
4. 验证 Terraform 配置：
```
terraform validate
```
5. 查看计划的基础设施变更：
```
terraform plan
```
6. 部署基础设施：
```
terraform apply
```
7. 验证已部署的资源：
```
terraform output
terraform state list
```
## CI/CD 验证工作流
该仓库包含一个 GitHub Actions 工作流，可自动验证 Terraform 配置的更改。
该工作流执行：
- Terraform 格式化检查
- Terraform 初始化
- Terraform 配置验证
这确保了基础设施变更在部署前得到审查，并降低了配置错误进入部署阶段的风险。
由于本项目是使用 AWS Academy 沙箱环境开发的，因此部署执行仍然是使用临时 AWS 凭证的受控手动过程。在生产环境中，此工作流将使用安全的 AWS 身份验证方法（例如 OpenID Connect (OIDC) 联合身份验证）进行扩展，以实现无需长期凭证的自动化 Terraform 部署。
## 架构决策
本项目使用 AWS Well-Architected Framework 原则进行设计，重点关注安全性、运维卓越和可重复的基础设施部署。
在开发过程中做出了以下架构决策。
### 使用 Terraform 的基础设施即代码
选择 Terraform 作为基础设施预配工具，是因为它能够实现一致、可重复且版本控制的 AWS 部署。
此方法的好处包括：
- 减少手动配置错误
- 可复用的基础设施模块
- 跨环境的一致部署
- 通过版本控制实现可审计的基础设施变更
Terraform 配置使用可复用的模块进行组织，涵盖了网络、计算、监控和存储。
### 模块化 Terraform 设计
本项目使用模块化的 Terraform 结构，按职责分离基础设施组件。
已实现的模块包括：
- `network` - VPC、subnet、route table 和 Internet Gateway
- `compute` - EC2 实例和安全组配置
- `monitoring` - CloudWatch 日志、告警和 SNS 通知
- `storage` - S3 bucket 配置和加密
此结构提高了可维护性，并允许未来扩展到其他环境，例如开发和测试 环境。
### 网络隔离
该架构在 Amazon VPC 内使用独立的公有和私有 subnet。
该设计遵循纵深防御 原则：
- 公有 subnet 中的资源可以通过 Internet Gateway 与外部服务通信。
- 私有 subnet 中的资源保持与直接入站互联网访问的隔离。
- 安全组强制执行受控的网络通信。
在生产环境中，私有工作负载通常会跨越多个可用区，以提高弹性和可用性。
### EC2 安全设计
EC2 实例设计遵循最小权限安全原则。
实施内容包括：
- 没有不必要的入站访问规则
- 显式的出站 HTTPS 访问
- 通过 Terraform 管理的安全组规则
- 通过代码而非手动配置部署的基础设施
最初的设计包括 IAM 角色和 AWS Systems Manager Session Manager，以提供无需 SSH 密钥或暴露入站端口即可实现的安全管理访问。
由于 AWS Academy 沙箱的权限限制，在部署期间无法完全实现 IAM 角色的创建。推荐的生产架构保留了此设计，使用 IAM 角色和临时的 AWS 托管凭证。
### NAT Gateway 决策
最终实现中有意排除了 NAT Gateway。
在生产环境中，NAT Gateway 将为私有资源提供受控的出站互联网访问，同时保持入站隔离。这将支持以下活动：
- 操作系统更新
- 软件包安装
- 外部 API 通信
考虑到 AWS Academy 沙箱环境和项目范围，额外的成本和资源需求对于本次实现是不必要的。
### CI/CD 工具选择
最初的设计考虑了 AWS 原生的 CI/CD，包括 CodePipeline、CodeBuild 和 CodeDeploy。
最终的实现使用了 GitHub Actions，因为它更贴近常见的行业工作流，即直接从源代码控制存储和验证基础设施代码。
GitHub Actions 提供：
- 自动化的 Terraform 验证
- 版本控制的工作流
- 与 Pull Request 集成
- 清晰的基础设施变更审计记录
对于生产部署，GitHub Actions 将通过 AWS OIDC 身份验证进行扩展，以实现安全的自动化 Terraform 执行。
### 存储安全
Amazon S3 被实现为项目的存储解决方案。
该 bucket 使用 AES-256 进行服务端加密，以保护静态数据，同时保持与 AWS 沙箱环境的兼容性。
生产环境可能会使用额外的控制措施，例如：
- 客户托管的 KMS 密钥
- Bucket 策略
- 对象版本控制
- 生命周期策略
- 访问日志记录
## 项目证明
以下屏幕截图提供了已部署 AWS 资源和自动化工作流的证明。屏幕截图按仓库内的架构组件进行组织。
## 网络
网络层通过专用的 VPC、subnet 隔离和受控的路由，奠定了 AWS 环境的基础。
包含的资源：
- Amazon VPC
- 公有 subnet
- 私有 subnet
- Route table 配置
证明：
- [查看网络截图](screenshots/networking/)
## 计算与安全
计算层展示了具有受控网络访问权限的 AWS 计算资源部署。
包含的资源：
- Amazon EC2 实例
- 安全组配置
- 入站和出站流量规则
证明：
- [查看计算截图](screenshots/compute/)
## 监控与告警
监控架构通过 AWS CloudWatch 提供运维可见性，并通过 Amazon SNS 提供自动化通知。
包含的资源：
- CloudWatch 告警
- SNS 通知主题
- SNS 电子邮件订阅
证明：
- [查看监控截图](screenshots/monitoring/)
## 存储
存储层展示了使用 Amazon S3 的安全对象存储。
包含的资源：
- S3 bucket 部署
- 服务端加密配置
证明：
- [查看存储截图](screenshots/storage/)
## 基础设施自动化
基础设施验证通过 GitHub Actions 执行，以确保部署前 Terraform 配置的质量。
包含的工作流检查：
- Terraform 格式验证
- Terraform 初始化
- Terraform 验证
证明：
- [查看自动化截图](screenshots/automation/)
## 局限性与未来改进
本项目是在 AWS Academy 沙箱环境中开发的。虽然沙箱提供了使用 Terraform 设计和部署 AWS 基础设施的能力，但由于账户权限、资源生命周期限制和项目范围，一些生产级功能受到了限制。
以下改进代表了生产实施的推荐后续。
### 自动化的 AWS 身份验证
最初的设计包括使用安全的 AWS 身份验证，通过 GitHub Actions 自动执行 Terraform 部署。
由于 AWS Academy 沙箱的限制，配置 OpenID Connect (OIDC) 联合身份验证所需的 IAM 管理权限不可用。
未来的实现：
- 配置 GitHub Actions 与 AWS IAM 的 OIDC 身份验证
- 消除对长期 AWS 凭证的依赖
- 允许安全的自动化 Terraform plan 和 apply 工作流
- 通过源代码控制维护可审计的基础设施变更
### IAM 角色集成
最初的架构包括用于安全 EC2 管理的 IAM 角色和 AWS Systems Manager Session Manager。
生产设计将包括：
- 通过 EC2 实例配置文件附加的 IAM 角色
- AWS Systems Manager Session Manager 访问权限
- 临时的 AWS 托管凭证
- 移除基于 SSH 密钥的管理
IAM 实现已记录在架构设计中，但由于沙箱权限限制而无法部署。
### 高可用架构
当前的实现使用了简化的单可用区 设计，以保持在项目范围和沙箱限制之内。
生产架构将扩展以包括：
- 多个可用区
- 冗余的公有和私有 subnet
- 跨实例的负载均衡
- 提高的容错能力
### NAT Gateway 实现
由于沙箱成本考量和项目范围，最终部署中排除了 NAT Gateway。
生产实施将包括：
- 部署在公有 subnet 中的 NAT Gateway
- 私有 subnet route 配置
- 针对私有工作负载的受控出站互联网访问
这将允许私有资源检索更新并与外部服务通信，而无需将它们暴露给入站互联网流量。
### 额外的安全控制
未来的安全改进可能包括：
- AWS Key Management Service (KMS) 客户托管的加密密钥
- AWS CloudTrail 审计
- AWS Config 合规性监控
- 遵循最小权限原则的增强型 IAM 策略
- 额外的网络安全控制
### 多环境部署
Terraform 结构旨在支持多个环境：
- 开发
- 测试
- 生产
当前的实现侧重于将生产环境作为演示部署。未来的扩展将使用独立的变量配置，在其他环境中部署相同的基础设施模式。
## 测试与验证
在开发过程中，使用 Terraform 验证工作流和 AWS 资源验证对基础设施变更进行了验证。
执行了以下验证步骤：
### Terraform 配置验证
使用内置验证命令测试了 Terraform 配置：
```
terraform fmt
terraform validate
terraform plan
```
这些检查验证了：
- Terraform 语法的正确性
- Provider 配置
- 模块引用
- 资源依赖解析
- 部署前计划的基础设施变更
### 基础设施部署验证
在 Terraform 成功部署后，通过 Terraform 状态管理和 AWS 管理控制台 对 AWS 资源进行了验证。
验证包括：
- 确认 Terraform 成功创建了 AWS 资源
- 查看 Terraform 输出
- 在 AWS Console 中验证资源配置
- 捕获部署证明的屏幕截图
Terraform 验证命令示例：
```
terraform state list
terraform output
```
### GitHub Actions 验证
该仓库包含一个自动化的 Terraform 验证工作流。
该工作流执行：
- Terraform 格式化检查
- Terraform 初始化
- Terraform 验证
这确保了在变更合并到主分支之前的基础设施代码质量。
### 部署限制
AWS Academy 沙箱环境引入了临时的资源生命周期和受限的 IAM 权限。
由于这些限制：
- Terraform 部署执行是使用临时的沙箱凭证手动执行的
- 通过 GitHub Actions 进行的自动化 AWS 部署被记录为未来的生产增强功能
- IAM 角色部署已设计，但未在最终的沙箱部署中启用
这些限制被记录为架构决策，而不是被视为部署失败。
## 应用的工程原则
在本项目的设计和实施过程中，几个核心的云工程原则指导了架构决策：
### 简单性与目标驱动架构
该架构旨在满足业务需求，同时避免不必要的复杂性。添加资源是基于运维需求，而不是简单地整合额外的服务。
### 最小化互联网暴露
除非有明确的业务需求，否则服务不应暴露于公共互联网。该架构使用网络隔离、私有资源和安全组来减少不必要的暴露，并遵循纵深防御原则。
### 关注点分离
专业的基础设施项目将职责分离为可维护的组件。Terraform 模块按功能进行组织，包括网络、计算、监控和存储，允许独立开发、测试和维护各个组件。
### 为扩展而设计
Terraform 结构旨在支持未来的增长，而无需进行重大的重新设计。特定于环境的配置、可复用的模块和变量驱动的部署允许随着需求的发展添加额外的环境和资源。
### 在实现之前定义接口
Terraform 模块的设计首先确定了所需的输入和预期的输出。这种方法创造了可预测的模块行为，并提高了跨不同环境的复用性。
### 复用经过验证的解决方案
基础设施组件被设计为可复用的，而不是为每个环境重新构建。Terraform 模块和配置模式允许一致的部署，同时减少重复和配置错误。
## 经验教训
本项目提供了在设计、部署和排查基于 AWS 基础设施即代码 原则方面的实践经验。
获得的主要经验教训包括：
- 云架构必须考虑到平台限制、权限边界和运维需求。
- 即使云环境是临时的或经常需要重新创建，基础设施即代码 也能实现可重复的部署。
- Git 历史记录提供了整个开发过程中工程决策、故障排除步骤和架构变更的审计轨迹。
- 安全性和运维卓越需要有意识的设计决策，而不是依赖默认配置。
- 云工程需要在理想的生产架构与可用资源、项目范围和业务需求之间取得平衡。
在 AWS Academy 沙箱限制内工作，强调了设计可复现、有文档记录且适应性强的基础设施的重要性。
## 项目资源
本仓库中提供了其他项目文档和资源：
- [最终项目论文](documentation/aws-cloud-engineering-capstone-project-final-report.pdf)
- [项目提案](documentation/aws-cloud-engineering-capstone-project-proposal.pdf)
- [架构图](diagrams/)
- [部署证明](screenshots/)
## 作者
**Mark Robuck**
云工程作品集项目
本项目展示了对以下内容的实践经验：
- Amazon Web Services (AWS)
- Terraform 基础设施即代码
- CloudWatch 监控与告警
- GitHub Actions CI/CD 工作流
- 云安全最佳实践
- AWS Well-Architected Framework 原则
与我联系：
- [LinkedIn](https://www.linkedin.com/in/mark-robuck/)
- [个人作品集网站](https://mrmarkrobuck.wordpress.com/)
标签：AWS, DPI, ECS, Terraform, 漏洞利用检测, 运维