Transit-Gaweway

自分がAWSを触ったのは、大学院時代に友達と簡単なWebサービスをデプロイするときに使ったのが初めてでした。1通り基本的なことを学ぶために、udemyの教材を使って基本的なリソースをマネジメントコンソールから作って削除していました。 そういった個人的な開発をする中ではなかなかAWSアカウントを複数作ることはなく、1つのAWSアカウントの中にサーバーやデータベースを作ることが多いです。 しかし、現職に入社してIDaaS経由でAWSの権限をもらったときに大量のアカウントが表示されていてびっくりしました。今ではとても理に適った管理方法だなと思うので、その感想をつらつら書きます。 参考 AWSのマルチアカウント戦略ってなに？なぜ必要？【社内勉強会スライド】 https://dev.classmethod.jp/articles/why-aws-multi-accounts/ メリット 権限が分離されている安心感がすごい 現職ではサービスの環境をDevelopment、Staging、Productionの3種類にわけていて、アプリケーションをEKSで動かしています。 1つのAWSアカウント内でこれをやろうとすると、環境ごとのVPC、IAM Role、EKSクラスタを作ったりする必要があり、ちゃんと分離できているのかが不安になります。 しかし、環境ごとにAWSアカウントを作成するとこんな感じになります。 お互いが絶対に干渉しないので、内部の設定ミスによる事故を防いだり、外部からの攻撃の影響範囲を制限することにつながります。 工夫が必要な点 初期に必要なAWSリソースをCloudFormationで作成 Terraformを使って各AWSアカウントのリソースを管理したいところですが、初期の状態ではTerraformを実行するためのIAM Roleもないわけです。それをアカウントごとに作成するのは大変なので、CloudFormationを使って最低限必要なリソースを全てのアカウントに対して作成します。 AWS Organizationを使ってAWSアカウントをOrganization Unit単位でグルーピングしておけば、より細かいリソース作成が可能になります。 Transit Gatewayを使ってAWSアカウントをまたがった通信を行う 各サービスにおいてEKSクラスタを共有させたいが、DBやStorageは別アカウントで持たせたいということもあると思います。実現する方法の1つとして、Transit Gatewayを用いる方法が挙げられます。 この記事をとても参考にさせてもらいました🙏 Transit Gatewayを利用してVPC間で通信してみた https://dev.classmethod.jp/articles/transit-gateway-vpc/ まとめ 現職でプロダクトの開発に携わりながら、こういったインフラを扱うSREのタスクもやらせてもらっていて、学んだことを残していこうと思います💪