你好，我是ZOZO的@wadason。
这篇文章是ZOZO Advent Calendar 2022日历第5卷的第8天的文章。

我将总结2022年有关Terraform实施的政策，并写下我的感受。内容不会太深入。

引起因素

去年，我們在剛入職且還不太熟悉的時候，制定了將公司的Cloud Formation遷移到Terraform的長期計劃。起初，這個決定只是輕率地做出的，但是在進行這項艱巨的任務時，我差點被絕大量的Cloud Formation堆棧打敗。然而，由於持續改進Terraform相關技術，現在我們認為這不僅僅是一個單純的遷移工作，而是一個具有一定意義的良好實踐。

解决方法

从Cloud Formation到Terraform的迁移步骤的改进

我起初考虑使用terraformer或cf2tf。虽然这些工具都很有吸引力，但我决定不使用它们。
由于AWS服务的覆盖不够，无论如何都需要进行迁移工作。

首先，我们整理了步骤。
我们发现在Cloud Formation的PhysicalResourceId和Terraform的import命令的第二个参数经常是相同的。当然也有例外情况，但我们认为通过逐步积累经验可以提高效率。
我们创建了一个能够根据Cloud Formation提供的信息，并与Terraform计划中的内容进行对比，自动生成import命令的电子表格。

$ aws cloudformation describe-stack-resources --stack-name ${STACKNAME} | jq -r ".StackResources[] | [.StackName, .ResourceType,.LogicalResourceId,.PhysicalResourceId] |@csv"  > ${STACKNAME}.csv

Terraform的输入项是模块名(module.hoge)、资源类型（aws_iam_role等等）和资源名。
我认为有些效率提升。没有成功的一点是，Terraform中资源细分得比S3等Cloud Formation更详细，这种方法并不奏效。

我认为由于目前情况多以目视确认和手动输入为主，所以编写脚本能进一步提高效率是很好的。

Terragrunt的安装

在执行迁移过程中，我们面临着一个问题：状态机过于庞大，导致CI/CD速度变慢。因此，我们决定使用terragrunt，将状态机分开为Cloud Formation堆叠。虽然我们仍会共享后端S3存储桶，但我们可以通过细粒度的状态机分离来安心地进行迁移工作。

我认为一旦稍微冷静一点，就可以考虑将细分得太过的state进行统一。我觉得状态太多了太拥挤了，而且Terraform和Provider的版本管理也很复杂，给运营带来了很大的负担。

其他

工具的引入

我们团队考虑并实施了进行安全扫描的tfsec以及从代码中估算成本的infracost的引入。这给予了我们重新审视现状的机会。

Lambda的维护

Lambda实现的方式因为执行者的不同而经常有所不同。因此我们统一了相同的管理方法。
我们使用Terraform来管理Lambda的资源，并通过将函数放置在符合相同命名规则的存储库中来降低管理成本。由于缺乏CI/CD的实施以及分散在各种存储库中，所以这一举措非常必要。

最后

找到空闲时间，享受并实施活动。我计划以后详细发布相关内容！