考虑到搭建大型电子商务网站时使用Terraform自动构建AWS环境，我将对整体情况做一些总结。
选择使用Terraform而不是CloudFormation的原因是因为Terraform在更改时能够显示参数差异，这一点非常好。（虽然一旦CloudFormation版本升级可能会解决这个问题…）
希望对使用Terraform构建AWS环境的人有所帮助。
※不过我认为还不是最优解…

自動建构的目标

・为了早日恢复故障
・为了适应系统重建和灾难恢复

建筑方针

使用Terraform来自动构建AWS基础设施部分的资源
※ 主要使用的AWS资源包括EC2、S3、RDS、EFS、DirectConnect、Route53等常见资源
由（没有Terraform经验的）多人进行编码

环境

・有生产环境、验证环境、连接测试环境、性能测试环境和开发环境。
・账户分为生产环境账户（本番账户）和其他账户（验证账户）。
・生产账户分为三个VPC（服务用、运营、CI）。
・验证账户分为两个VPC（服务用、运营）。

Terraform的使用要点1：积极利用模块。

使用HashiCorp提供的Terraform Registry模块创建AWS环境。
对于没有HashiCorp提供的模块的AWS资源，我们需要自己编写模块。

通过这个方法，编码团队只需要将参数嵌入到模块中，就可以使用它了。

有些资源，如RDS参数组等模块，是不能被使用的例外。

＜Terraform 注册表＞
https://registry.terraform.io/

Terraform的使用要点2：WorkSpace功能

如果使用 Workspace 功能，则在存在类似生产环境的验证环境时，只需更改变量即可使用相同的代码进行 AWS 构建，如果使用得当，编码量将减少。
本次使用 Workspace 构建了生产环境、验证环境、连接测试环境、性能测试环境和开发环境（部分）。
然而，如果使用时存在环境差异较大的情况，则相反地开发效率会降低（需要考虑更多事项）。
虽然现在无法重新开始，但推荐仅在相同环境下使用。

＜工作空间＞
https://qiita.com/gamisan9999/items/168ff29be70572de7602

学习目标

我希望试用一下AWSSpec。
目前的测试方法是将代码与详细设计文档进行对比，我想改进这一点。

运用

目前正在考虑完成后的运维设计。
理想情况是每周自动执行Terraform，但考虑到Terraform的限制，无法保持NACL和SG的可幂等性（使用provider: aws v1.39）。
（使用Terraform添加较小ID的NACL时，会导致重新创建较大ID的NACL，暂时处于完全断开状态。
可能是个bug，但目前看来符合规范。）

有一些AWS资源是不可自动化的，例如直连（Direct Connect）等需要批准的资源是不能自动化的。我们也在考虑绕过这些运营限制。