ファンズでSREをしているあらきです。弊社ではAWSをメインに使っていますが、当初から1アカウントの中に開発やテスト環境を作っていました。分割した方が安全なのはわかりつつもなかなか腰が重く実行に移せていませんでしたが思い切ってAWS Control Towerを使用して既存アカウントを分割しました。Terraformで管理はしていたものの、新しい構築はそれなりの時間と労力がかかりました。本番アカウントは当初からあるアカウントに残した状態で開発環境を移したお話をします。

分割する時にぶち当たる壁1

弊社はお金を取り扱っている関係でセキュリティ遵守は必須のため、RDSやs3に対して暗号化をしているのですが、最初に作られた当初からAWSマネージドの鍵を使用していたため、別の環境に移す際にs3の場合は一度Decryptした後に新しいアカウントのバケットに旧アカウントからのアクセスを許可した状態でs3 Syncさせました。この時に `--acl bucket-owner-full-control` オプションが無いとSync元のアクセス権限が引き継がれ、Sync先でアクセス権限がない400エラーが出てしまいます。

RDSにおいては一度スナップショットを撮り、そのスナップショットから一度復元DBを作成し、復元する際にKMSマネージドキーを外し、アカウント間共有の鍵を当てがって復元します。その復元DBからスナップショットを撮り、そちらをアカウント間で共有する機能があるのでそちらを使います。実は最初はmysql dumpを使用してやろうとしましたが、リストアが権限不足でできなかったので、AWSのRDSの機能の一つ、スナップショットを使った方がスムーズに移行ができました。

分割する際にぶち当たる壁2

弊社では以前のブログでも紹介しましたが、AppmeshをEKS環境で使用しておりますが、こちらの仕様が2021年4月に新しくなっておりました。こちらによると、新しく作るMeshにおいては必ずProxy認証が入るため、`AWSAppMeshEnvoyAccess`のIAM Policyが必要になりました。また、弊社ではElasticacheを使用しているのですが、AppmeshバックエンドからのSSL発信は通さないため、k8s Podに対してEnvoyが特定のプロトコルは無視するアノテーションを追加で入れる必要がありました。こちらはドキュメントに載っていますが、Kubernetesの具体例はなく、サポートの方に頼らざるを得ませんでした。

      annotations:
          appmesh.k8s.aws/egressIgnoredPorts: "6379"

既存アカウントをControl Towerに寄せる壁

主に以下に書かれている通り、キモなのはAWS Configの無効確認とSTSのエンドポイントアクセス許可です。また、CloudFormationを使用していない場合はStacksetの許可も必要なので併せて確認します。ここに書かれているメッセージ`Enable trusted access with AWS Organizations to use...`は管理側のアカウントのCloudFormationででました。

結論

分割は大変でしたがControl Towerを使うことにより、安全な環境下でアカウントを分割、かつ管理できるようになりました（まだ途中、最後に全部消すまでが移行ですね）。今年のre:InventではTerraformに対応した例も見かけたので今後は作成しやすくなると思います。（もう少し早く来てほしかった・・！）最初に作った時期と異なる時期に作成することになるので、スケジュールに余裕を持ってやった方が良いのは間違いありません。