AWS

GitHub Actions OIDCで実現する鍵レス本番デプロイ：漏えい事故を減らす実装プレイブック CI/CD の事故は、ビルドが失敗することより「漏えいしても気づけない鍵」が残り続けることのほうが深刻です。特に AWS_ACCESS_KEY_ID のような長期シークレットを GitHub Secrets に保存し続ける運用は、便利ですがリスクが高いです。 本記事では、GitHub Actions の OIDC（OpenID Connect）連携を使って、長期鍵を使わずに AWS へデプロイする実践手順をまとめます。単なる設定紹介ではなく、最小権限・ブランチ制限・監査ログ設計まで含めて、明日から本番投入できる形で説明します。 1. まず何が危険なのか：長期シークレット運用の限界 従来構成では、次のような問題が起きます。 Secret が漏れても検知が遅い（CIログ、誤コミット、権限の広いメンバー） ローテーションが後回しになる 1つの鍵で複数環境へアクセスできてしまう 「誰のどの workflow 実行が何をしたか」が追いにくい OIDC 連携では、GitHub が発行する短命トークンを信頼し、AWS 側で一時認証情報を払い出します。つまり、保管する鍵そのものを減らすのが最大の価値です。 2. 全体アーキテクチャ 基本フローは以下です。 GitHub Actions ジョブが OIDC トークンを取得 AWS IAM の OIDC プロバイダとロール信頼ポリシーで検証 条件に一致したジョブだけ AssumeRoleWithWebIdentity 一時クレデンシャルで S3/CloudFront/ECR/ECS へデプロイ ポイントは「GitHub 側の workflow 制御」だけでなく、AWS 側で repo・branch・workflow を強制することです。 3. AWS 側の初期設定（OIDC Provider + IAM Role） 3.1 OIDC Provider を作成 CLI 例（すでに存在する場合はスキップ）: 1 2 3 4 aws iam create-open-id-connect-provider \ --url https://token.actions.githubusercontent.com \ --client-id-list sts.amazonaws.com \ --thumbprint-list 6938fd4d98bab03faadb97b34396831e3780aea1 3.2 信頼ポリシーを厳密化する 以下のように sub と aud を必ず絞ります。 ...

AWS Lambda SnapStartがPythonに対応！コールドスタート解消へ はじめに AWS Lambdaを本番環境で利用している、あるいは利用を検討しているPythonデベロッパーの皆さん。「サーバーレスは便利だけど、あの"最初の"リクエストだけ遅いのが気になる…」と感じたことはありませんか？ API Gatewayと連携させたLambda関数が、しばらくアクセスがないとタイムアウトギリギリになったり、ユーザーに不快な待ち時間を与えてしまったり。この現象は「コールドスタート」と呼ばれ、多くのサーバーレス開発者を悩ませてきた根深い課題です。 これまで、この問題を解決するにはProvisioned Concurrency（プロビジョニングされた同時実行）という有料オプションを利用するのが一般的でしたが、コストとのトレードオフに頭を悩ませるケースも少なくありませんでした。 しかし、2023年末のre:Invent 2023で、ついにこの状況を打開する待望の機能がPythonランタイムにもたらされました。それがAWS Lambda SnapStartです。 これまでJavaランタイムでのみ利用可能だったこの機能がPythonに対応したことで、私たちのサーバーレスアプリケーション開発は新たなステージに進むことになります。本記事では、プロの技術ブロガーとして、Lambda SnapStart for Pythonの仕組みから具体的な使い方、そして現場で活かすための実践的なTipsまで、徹底的に深掘りしていきます。この記事を読み終える頃には、あなたもSnapStartを使いこなし、コールドスタートの悩みから解放されているはずです。 なぜLambda SnapStartが重要なのか？ - コールドスタート問題の再確認 SnapStartの詳細に入る前に、なぜこの機能がこれほどまでに待望されていたのか、その背景にある「コールドスタート問題」を改めて整理しましょう。 Lambdaの実行モデルとライフサイクル AWS Lambdaは、リクエストに応じてコンテナ（実行環境）を起動し、コードを実行するアーキテクチャです。この実行環境は、常に起動しているわけではありません。一定時間リクエストがないと、AWSはコスト効率化のために実行環境を破棄します。 次にリクエストが来たとき、Lambdaは以下のステップを踏んで応答します。 実行環境の確保: 新しい実行環境（マイクロVM）をプロビジョニングします。 コードのダウンロード: S3などから関数のコード（デプロイパッケージ）をダウンロードし、展開します。 ランタイムの初期化: Pythonのランタイム（インタプリタ）を起動します。 関数の初期化 (Initフェーズ): ハンドラ関数の外で定義されたグローバルなコードを実行します。ライブラリのインポート、DBコネクションプールの作成、機械学習モデルのロードなど、比較的時間のかかる処理がここに含まれます。 関数の実行 (Invokeフェーズ): 実際にハンドラ関数を実行し、リクエストを処理します。 このうち、ステップ1から4までを含む最初の呼び出しをコールドスタートと呼びます。一度起動した実行環境は再利用されるため、2回目以降の呼び出し（ウォームスタート）ではステップ5のInvokeフェーズのみが実行され、非常に高速に応答できます。 graph TD subgraph "Cold Start" A[Request] --> B(Allocate MicroVM) B --> C(Download Code) C --> D(Initialize Runtime) D --> E(Run Init Code) E --> F(Run Handler) end F --> G[Response] subgraph "Warm Start" H[Subsequent Request] --> I{Environment Ready?} I -- Yes --> J(Run Handler) I -- No --> B J --> K[Response] end コールドスタートが引き起こす問題 コールドスタートによる遅延は、数十ミリ秒から、場合によっては10秒以上にも及ぶことがあります。特に以下のようなケースで顕著になります。 ...