CodeBuild での SSM パラメータ取得方法の比較とベストプラクティス

AWS CodeBuild で SSM パラメータストアから値を取得する際、以下の2つの方法があります。

1. スクリプト内で SSM パラメータを直接取得する
2. 環境変数に事前に設定して利用する

この記事では、この2つの方法を比較し、それぞれのメリット・デメリットや、環境変数を使う方法がベストプラクティスとなる理由を解説します。

---

1. スクリプト内で直接 SSM パラメータを取得する

メリット

• 柔軟性

  • パラメータ名を動的に生成できるため、特定の条件に応じたパラメータ取得が可能

• シンプル

  • 必要なときにパラメータを取得するため、スクリプトがシンプルになる場合がある

デメリット

• 処理速度の遅延

  • get_parameter の呼び出しごとに SSM API を利用するため、ネットワーク通信が発生する
    • 通常、1回の呼び出しに 50～300ミリ秒程度 かかる
    • 繰り返し取得が必要な場合は、累積で処理時間が増加する

• オーバーヘッド

  • boto3 クライアントの初期化や認証処理のオーバーヘッドが発生する

• 並列実行でのボトルネック

  • 同時に多数のプロセスが SSM API を呼び出すと、API レート制限やリソース競合が発生する可能性がある

2. 環境変数に事前設定して利用する

メリット

• 高速

  • 環境変数の参照はローカルメモリ上で行われるため、ほぼオーバーヘッドがない
  • SSM API を呼び出す際のネットワーク通信や認証の遅延が解消される

• スクリプトのシンプル化

  • スクリプトから SSM に関するロジックを排除でき、コードの可読性が向上する

• レート制限の回避

  • 事前に環境変数を設定することで、SSM API 呼び出し回数を削減できる

• 再利用性

  • 同じ環境変数を複数のスクリプトやプロセスで利用可能

デメリット

• 動的なパラメータ取得には不向き
  • パラメータ名を動的に生成したい場合や、実行中に異なる値を取得したい場合には対応が難しい
• セキュリティ上のリスク
  • 環境変数をそのままログに出力してしまうと、パラメータが漏洩するリスクがある 

項目	スクリプト内で取得	環境変数を利用
速度	数十～数百ミリ秒/回	ほぼゼロ
柔軟性	高い	中程度（静的パラメータ向き）
スクリプトの可読性	SSM	ロジックが増える
セキュリティ	シークレット値を直接扱う場合注意	環境変数の管理が必要
レート制限の影響	高い	低い
並列実行での効率性	競合が発生しやすい	安定している

結論: ベストプラクティス

基本的には以下の理由で環境変数を利用する方法を推奨する。

1. 速度が速い: 環境変数参照はローカル操作のため、ほぼ遅延が発生しない
2. 安定性が高い: 大量の並列プロセスが動作しても、SSM API レート制限の影響を受けない
3. 可読性が高い: スクリプト内で SSM API 呼び出しの処理を省略できるため、ロジックがシンプルになる

ただし、動的なパラメータ取得や複雑な条件が必要な場合は、スクリプト内で直接 SSM API を呼び出す方法が適している。