インフラエンジニアの皆さん、こんにちは。
手作業でAWSコンソールをポチポチと操作してインフラを構築する時代は、もう過去のものです。もし今、あなたが本番環境の設定変更で冷や汗をかいたり、「前回どうやって設定したっけ？」とドキュメントを探し回っているなら、この記事がその悪夢を終わらせます。
今回は、「GitHub Actions × CloudFormation」による、自動化された堅牢なインフラデプロイ基盤の作り方を伝授します。これをマスターすれば、あなたのインフラは「コード」として資産化され、誰が触っても壊れない、美しく再現性のあるものへと進化します。
—
1. なぜ「CI/CD」でインフラを構築すべきなのか？
インフラのCI/CD（継続的インテーション・継続的デリバリー）は、単なる自動化ではありません。最大のメリットは「冪等性（べきとうせい）」の担保と「心理的安全性」の確保です。
- 冪等性: 何度実行しても常に同じ結果が得られること。手作業による「設定ミス」や「変更漏れ」を物理的に排除します。
- レビュープロセス: インフラ構築がプルリクエスト（PR）ベースになることで、変更内容がチーム全員の目に触れます。「誰が何を変えたか」がGitHub上に全て残るため、事故が起きる確率が激減します。
—
2. OIDCによる「セキュアな認証」が最強の理由
AWSの認証で「アクセスキーとシークレットキー」をGitHubのSecretsに保存するのは、もうやめましょう。漏洩のリスクが高すぎます。
現在、業界のベストプラクティスはOIDC（OpenID Connect）です。
GitHub Actionsが一時的な認証情報をAWSから直接取得するため、永続的なクレデンシャルを管理する必要がありません。
設定手順の要点:
1. AWS IAMでプロバイダ作成: `https://token.actions.githubusercontent.com` を信頼されたエンティティとして追加。
2. ロールの作成: GitHubリポジトリを指定し、必要な権限（CloudFormationの実行権限）を持つIAMロールを作成します。
—
3. 実践：GitHub Actionsワークフローの構築
それでは、実際にパイプラインを構築しましょう。`.github/workflows/deploy.yml` を作成します。
name: Deploy Infrastructure
on:
push:
branches: [ main ] # mainブランチへのマージでデプロイ実行
pull_request:
types: [ opened, synchronize ] # PR作成時にもチェック
permissions:
id-token: write # OIDC認証に必須
contents: read
jobs:
lint-and-validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
# 1. cfn-lintでコードの静的解析（構文ミスを事前に検知）
- name: Run cfn-lint
run: cfn-lint template.yaml
deploy:
needs: lint-and-validate
if: github.event_name == ‘push’
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
# 2. AWS認証（OIDCを使用）
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
aws-region: ap-northeast-1
# 3. CloudFormationスタックのデプロイ
- name: Deploy CloudFormation
run: |
aws cloudformation deploy \
–template-file template.yaml \
–stack-name my-web-service-stack \
–capabilities CAPABILITY_IAM
—
4. 精度を高める「HelloWorld」的デプロイのコツ
最初は、巨大なインフラを一気に作ろうとせず、「S3バケットを1つ作るだけ」といった最小構成でパイプラインを回してください。
1. template.yamlを作成:
Resources:
MyBucket:
Type: AWS::S3::Bucket
Properties:
BucketName: my-unique-demo-bucket-2024
2. `cfn-lint`を使い倒す:
ローカル環境に `pip install cfn-lint` を入れ、コミット前に `cfn-lint template.yaml` を実行する癖をつけてください。これだけで、AWSに投げてから「エラー」で弾かれる時間を大幅に短縮できます。
—
最後に：エンジニアとしての心構え
このパイプラインを導入した瞬間から、あなたのインフラは「生き物」になります。
「動けばいい」ではなく、「どうすれば再利用可能か」「どうすれば事故が起きないか」を考えながらコードを書く。その積み重ねが、あなたを一流のSREへと引き上げます。
最初は難しく感じるかもしれませんが、一度このフローを経験すれば、もう二度と「手動デプロイ」には戻れません。
さあ、今日からインフラをコードの中に閉じ込めて、より創造的な開発ライフを送りましょう！何か詰まったら、いつでも聞いてくださいね。応援しています。