AWSリソースをLambda+Googleスプレッドシートで一括管理

こんにちは。

 

昨年からアルバイトとしてギークフィードでエンジニアをしている鈴木です。PHPやHTML+JSを使ってWEBシステム開発などをしています。

 

弊社ではWEBシステム開発にAWSを利用してから数年が経過し、複数のアカウント・サービスに渡ってAWSリソースが乱立しました。

その結果、誰がどのリソースを管理しているのか把握しにくくなっているという問題に直面しました。

そこで、社内で利用しているAWSリソースをGoogleスプレッドシート上で自動的にリストアップするLambda関数を作成し、管理者が編集・記録できるようにしました。

Lambda関数はPythonで書き、boto3とgspreadの2つのライブラリを主に利用しました。

 

この記事では主に、

  • STS AsuumeRoleを利用した複数AWSアカウントへのアクセス
  • Lambdaでgspreadを使用する際の注意点

について紹介します。

boto3やgspreadの基本的な利用方法については割愛します。

僕自身のPython歴に関しては、研究室で実験データの処理に使っている(100行未満)程度の初心者なので、Python・Lambdaの勉強に丁度良い内容だと思います。

 

作成したプログラムについて

先程紹介した通り、AWSリソースの乱立によって管理者の把握が困難となってしまい、一度手作業でリソースをスプレッドシートにリストアップしました。

マネジメントコンソールではサービスごとにインスタンスやリソースの一覧表示は可能なのですが、複数サービス・複数アカウントのリソースをまとめて表示する方法はなく、手作業でリストアップしていくのは相当の労力が必要とされます。

そこで、Lambdaとgspreadを利用しリソースをまとめてリストアップします。

 

目標イメージ

こちらは、手作業でまとめた際のスプレッドシートです。シートの左側にリソースの基本的な情報をまとめ、右側に管理者や使用用途などを記録し管理していきます。

毎日自動で更新が行われ、リソースが増えたら下に追加していきます。

管理者や使用用途などの情報は手動で追記していくため、更新の際は、左側の情報のみを更新します。

 

完成したスプレッドシート

このように、複数アカウントのEC2・Lightsail・IAMなどの情報を一つのGoogleスプレッドシート上にまとめてリストアップすることができました。

また、コストに関しても3アカウントの情報をシートごとにまとめるようにしました。どのアカウントがどのくらい稼働しどのくらい費用がかかっているか簡単に確認することができます。

今後はこのスプレッドシートを活用して、リソースの管理をおこなっていきます。

 

プログラムの概略

現状弊社では3つのAWSアカウントを運用しているのですが、将来的にアカウントは増・減・統合の可能性があるため、Lambda関数はアカウントごとに分散させず、一つのLambda関数で完結させることにしました。

その結果、上の図のように、アカウントAのLambda関数からSTS AssumeRoleを用いて3アカウント分のリソース情報を取得し、取得した情報をもとにスプレッドシートを更新するようにしました。

 

ソースコード

get関数とupdate関数が大部分を占めるため、一部省略しています。

ハンドラー関数では主に

  1. AssumeRoleを用いてアカウントごとにリソース情報を取得
  2. スプレッドシートへの認証処理
  3. シートごとに更新

という処理が行われます。

 

リソース情報の取得

アカウントの名前とRoleArnはeventパラメータで渡しています。配列data_listとcost_listに取得したデータを追加していきます。
boto3関数の返り値の構造はサービスによって異なるので、サービスごとにget関数を定義しています。

 

assume_role()関数によって一時認証情報(credeentials)を発行し、データの取得を行います。むやみにassumeRoleの発行を繰り返さないように、アカウントごとにまとめてget関数を呼び出しています。

 

スプレッドシートへの認証処理

gspreadの公式ドキュメントを参考に認証用jsonキーファイルを取得します。

取得したjsonファイルはapp.pyと同じレイヤーにアップロードしました。
from_json_keyfile_name()よりgspreadの認証情報を発行し、スプレッドシートを展開します。

 

シートごとに更新

今回、シートをサービスごとにわけてリソースをリストアップしたため、更新用のupdate関数はシートごとに定義しました。
update関数については、リソース情報が収集されたdata_list配列と、worksheet()によって得たシートを渡しています。
gspreadの操作方法については後述します。

STS AsuumeRoleを利用した複数AWSアカウントへのアクセス

STS AssumeRoleを用いて特定のアカウントへのアクセスを許可しておけば、アクセスキーとシークレットアクセスキーを用いずにセキュアに外部アカウントへのアクセスが可能となります。
AssumeRoleを用いて一時認証情報を発行するには以下のようにアカウント双方でロールを作成する必要があります。

アカウントA側のロール

このように、アカウントA側ではAssumeRoleへのフルアクセスを与える必要があります。
また、アカウントAでLambdaが実行されるため、LambdaとCloudWatchへのフルアクセスも与えています。

アカウントA・アカウントB・アカウントC側のロール

アクセスされるアカウント側には「クロスアカウントアクセスのロール」を与える必要があります。

今回のプログラムでは、全てのリソースへのアクセスにAssumeRoleを用いているため、自アカウント(アカウントA)にもクロスアカウントアクセスのロールを与えています。

クロスアカウントアクセスのロールは、ロール作成時にエンティティの種類を「別のAWSアカウント」にすることで作成できます。アカウントIDにはアカウントAのIDを入力します。

今回、このロールにはEC2・Lightsail・IAM・Costへのリードオンリーアクセスを与えました。このように、双方のアカウントに適切なロールを与えることで、assume_role()関数より一時認証情報を発行することができます。

Lambdaでgspreadを使用する際の注意点

EC2シートのupdate関数は上のようになっています。
Lambdaでgspreadを自動運用する際にはいくつか注意する点があります。

基本的な操作の説明

update関数では、スプレッドシートの「リソースID/ARN」の列から既に登録されているID/ARNを取得(10行目)し、更新範囲(11行目で取得)に対し

  • 既にID/ARNが存在されていれば情報を更新
  • ID/ARNがまだ存在していなければ追加

という風に処理することでスプレッドシートを更新しています。

APIのリクエスト制限

当初は、リソース情報1行分ごとにループしてfind()関数で既存/新規を判定→update()/append()という風なプログラムにしていました。
しかし、find()/update()/append()を多用していたところ

というエラーが発生してしまいました。

 

“Usage Limits | Sheets API | Google Developers”によると、GoogleスプレッドシートのAPIには

  • プロジェクトに対し500リクエスト/100秒の上限
  • ユーザーに対し100リクエスト/100秒の上限

という制限があるため、1行分ごとに更新場所の判定(find()など)とデータの更新(update()かappend())をループで処理すると、登録するデータ×2回のリクエストが発生してしまいエラーとなってしまいます。
なので、極力range()とupdate_cells()を使うことで、一括にデータの更新をする必要があります。
プログラムによっては、time.sleep()などを使って100秒間当たりのリクエスト回数を減らすという手もありますが、Lambda関数では時間制限があるためおすすめできません。

終わりに

今回、Lambdaとgspreadを組み合わせることで、AWSリソースの各情報をGoogleスプレッドシートにリストアップすることができました。
運用しているアカウント・リソースが増え、管理者も分散してしまうと、AWSマネジメントコンソール以外の方法でリソースを記録・確認していく必要があると思います。
そのような時、Lambdaを利用すれば比較簡単にリストアップの自動化ができるとわかりました。

この記事が気に入ったら
いいね ! しよう

Twitter で
The following two tabs change content below.

【採用情報】一緒に働く仲間を募集しています

採用情報
ページトップへ