情報システム部でAWS周りの運用保守をしている「ねぎ」です、こんにちは!
この記事は弥生 Advent Calendar 2022の4日目エントリーです。
今回の記事では、
AWSアカウントが増えてきて各アカウントの構成がどうなっているかがわからない!
他のアカウントはどのような構成でサービスが稼働しているんだろう?
など、このAWSアカウントでは、ある程度どういうAWSサービスを利用しているのかが把握できる
そんなAWS構成図の自動描画に関する仕組みを紹介したいと思います。
構成図描画の比較
みなさんはAWSの構成図どうされていますでしょうか? 「aws構成図 ツール」などで検索してみると色々なものが出てくるかと思います。
弥生では75 AWSアカウント (2022年11月現在) の数になっていて、なんとか自動で作成してくれるものがないかと模索しておりました。
検討したツールの中で最終的に比較したのは、以下2つでした。
Perspective AWS でのワークロード検出 | 実装 | AWS ソリューション
Cloudmapper GitHub - duo-labs/cloudmapper: CloudMapper helps you analyze your Amazon Web Services (AWS) environments.
Perspectiveは描画をしてくれるリソースは非常に多いのですが、マルチアカウントかつデフォルトの構成で利用する場合には金額が大きくなりそうな点があり、 最終的にCloudmapperを利用することにしました。
全体構成
CloudmapperでAWSリソースを自動描画するために、ECS + Fargateの構成を使って各コンテナと取得するAWSアカウントのリソースを紐づけることで、AWSアカウントの増加にも対応出来るようにしました。
その他、詳細は後述していきますが、Cloudmapperで自動描画するための全体構成としては以下となりました。
各リソースの使い方と詳細は後述します。
Code系
ここでは全体構成の中の以下のCode系とECR部分について、何をやっているかお話します。
Code系のリソースとECRを組み合わせた一般的な使い方をしています。
構成図を自動描画するための各AWSアカウント名をハイパーリンクで表示するだけのHTMLファイルとWebサーバーのDockerファイルを用意し、AWSアカウントが増えたら、HTMLファイルを修正しています。 HTMLファイルがCodeCommitで修正されると、CodePipelineが動き、CodeBuildが呼ばれます。 CodeBuildで修正されたHTMLファイルを含めた新しいDockerイメージを生成し、ECRへとプッシュする自動化を行っています。
ECS / Fargate / ECR
CodeCommitで管理されているWebページ用のDockerイメージと、CloudmapperのDockerイメージをECSのFargateを使って稼働させています。
1つのコンテナで、1つのAWSアカウントに関するリソース情報を収集しています。 1つのタスクで、5つまでのコンテナを起動しているので、75アカウント / 5コンテナ = 15タスク稼働させて全アカウントの構成図を自動描画しています。
EventBridge / Lambda
コスト節約のため、平日9時から17時までの閲覧として社内周知しており、それ以外の時間は各タスクを停止させています。 その際に使用しているのが、EventBridgeとLambdaです。
EventBridgeにて、起動する日時、停止する日時をスケジュールして、LambdaでECS + Fargateのタスク起動、停止を実施しています。
その他のリソース
これまでに紹介しなかった残りのリソースについてお話していきます。
まずAWS Secrets ManagerとECS + Fargateの各コンテナとの関連ですが、各AWSアカウントのリソース情報収集の際に、IAMのアクセスキー、シークレットキーが必要になります。 コンテナの環境変数にべた書きするわけにもいかないので、AWS Secrets Managerにキーを保存して、コンテナの環境変数にセットしています。
次にECS + Fargateの各コンテナから、NAT Gatewayを介して各AWSアカウントへリソース情報を収集する部分になります。 CloudmapperのDockerイメージを稼働させている各コンテナから、各AWSアカウントのIAM権限を利用してAWSリソース情報収集を行います。 当然、セキュリティリスクを考慮してIAMの権限を絞り、NAT GatewayのIPからのみ収集が可能になるようにしています。
最後にクライアントPCからのアクセスですが、ALBを作成して、各コンテナの数と同じだけALBのターゲットグループを用意して、描画を行った結果にアクセス出来るようにしています。
工夫した点
一番はセキュリティです。 Cloudmapperから各AWSアカウントのリソース情報を取得する際に、IAMのアクセスキー、シークレットキーが必要になっています。 そのためIAMのポリシー権限を絞るのはもちろん、必要なIPからのみ取得出来るようなポリシーとしています。 またコンテナで使用するアクセスキー、シークレットキーは、SecretsManager上で管理し、もちろんKMSキーによる暗号化も行っています。 最後に本構成図を閲覧する部分にもセキュリティグループによって制限を掛けています。
次にコストです。 アカウント数が増加傾向にあるため、どうしてもこの自動描画の仕組みも課金額が伸びてしまう傾向にあります。 それをなるべく抑えるために、平日日中帯のみの稼働としたことによって、75アカウントの自動描画であっても月額約6万円程度 (140円/1$換算) に収まっています。
以上のようなことを対応した上で、自動描画を行っているAWSアカウントのリソース情報を自動描画してみました。
こんな感じで描画されました。 どうでしょうか?ちょっと見にくいですかねw
ただなんとなくこういう構成で動いてるんだろうな、ということが把握できるかと思います。
ECSのタスクがいっぱい起動しているんだな
同じNICから通信経路が伸びているな
ELBもあるな
サブネット構成もなんとなくわかるな
といったことが把握していただけるのではないでしょうか。
一部のリソースは自動描画出来ないところもありますが、ある程度把握各AWSアカウントのサービス構成を把握するには役立つと思っています。
あとがき
構成図自動描画いかがでしたでしょうか? 弥生ではこちらの仕組みを導入後、サービス稼働前のアーキテクチャーレビューや、不要になったリソース削除の抜け漏れ確認、などに活用しています。
どのサービスもクラウドサービスの活用が前提になってきている中で、サービスのリリースまでにスピード感が求められているかと思います。 構成図をきっちりドキュメントとして残していく、メンテナンスしていくことも重要だと思います。 一方でスピードを求められる中では、ある程度の構成図をこういった仕組みで自動化してリリースをしていくことも必要だと感じています。
今後も快適なクラウドサービスの活用へ向けて、色々な自動化を検討していきたいと思います。