shibomb

AWS CDK×Pythonで「手作業ゼロ」を実現！Webアプリ基盤をコードで自動構築

AWSのコンソール画面を一つひとつクリックしてインフラを構築する作業、時間もかかるし、ちょっとした設定ミスで動かなくなったりしませんか？開発環境と本番環境でなぜか設定が違う…なんてトラブルに頭を抱えた経験のある方も少なくないはずです。もし、普段あなたが使っているPythonのようなプログラミング言語で、インフラの構成をコードとして管理し、ボタン一つで正確に再現できるとしたらどうでしょう。この記事では、そんな夢のような クラウド自動化 を実現する AWS CDK を紹介します。手作業によるインフラ構築から卒業し、IaC (Infrastructure as Code) の世界へ踏み出すための最初の一歩を、一緒に歩んでいきましょう。

プログラミングでインフラを操る！IaC（Infrastructure as Code）の基本と重要性

サーバー、データベース、ネットワークといった「インフラ」を、コードを使って定義・管理する手法を IaC (Infrastructure as Code) と呼びます。従来、インフラ構築はGUIのコンソール画面を操作したり、コマンドを一つひとつ実行したりする手作業が中心でした。しかし、この方法にはいくつかの課題がありました。

手作業による構築は、手順が複雑になるほど人的ミスが起こりやすくなります。また、「前回どうやってこの環境を作ったんだっけ？」と手順書を探し回ったり、開発環境と本番環境の微妙な差異が原因で「自分のPCでは動いたのに！」という問題が発生しがちです。変更履歴を追うのも難しく、誰がいつ何を変更したのか分からなくなることも珍しくありません。

IaCは、これらの課題を解決します。インフラの構成をコードで記述することで、以下のような大きなメリットが生まれます。

  1. 自動化による効率化: コードを実行するだけで、何度でも同じインフラを自動で構築できます。これにより、デプロイ自動化 の基盤が整います。
  2. 再現性の確保: 誰が実行しても全く同じ構成の環境を正確に再現できます。これにより、環境差異による問題を根本からなくせます。
  3. バージョン管理とレビュー: コードなのでGitなどのバージョン管理システムで変更履歴を管理できます。インフラの変更をプルリクエストとしてチームでレビューすることで、品質と透明性が向上します。

IaCは、インフラ管理をソフトウェア開発のプラクティスに近づける考え方であり、現代のクラウドネイティブな開発において、もはや欠かせない要素となっています。

AWS CDKとは？Python開発者に嬉しいクラウドインフラ自動化ツール

数あるIaCツールの中でも、今回主役となるのが AWS CDK (Cloud Development Kit) です。これは、AWSが公式に提供するオープンソースのフレームワークで、TypeScript、Python、Java、C#、Goといった汎用プログラミング言語を使ってAWSのインフラを定義できるのが最大の特徴です。

Python開発者にとって、AWS CDKは特に魅力的な選択肢です。なぜなら、新しい独自言語 (DSL) を学ぶ必要がなく、使い慣れたPythonの文法やツール（エディタの補完機能、デバッガ、ライブラリなど）をそのまま活用して Python インフラ コードを書けるからです。

CDKの強力な点は、Constructs (コンストラクト) と呼ばれる抽象化されたコンポーネントにあります。例えば、「インターネットからアクセスできるコンテナアプリケーション環境」を構築したい場合、通常はVPC、サブネット、インターネットゲートウェイ、ルートテーブル、ALB、ECSクラスター、タスク定義…など、非常に多くのAWSリソースを個別に設定する必要があります。しかしCDKでは、これらの定型的な構成をひとまとめにした高レベルなコンストラクトが用意されており、わずか数行のコードで実現できてしまいます。

CDKで書かれたコードは、cdk deploy コマンドを実行すると、最終的にAWSの標準的なIaCサービスである「CloudFormation」のテンプレート (JSON/YAML形式) に変換（合成）されてから、AWS上にリソースが展開されます。つまり、開発者はPythonで快適に開発しつつ、実行時には実績と信頼性のあるCloudFormationの仕組みを利用できる、という「良いとこ取り」が可能なのです。

AWS CDKの導入から最初のスタック構築まで：Pythonで手を動かしてみよう

百聞は一見にしかず。さっそくAWS CDKを導入し、Pythonで簡単なインフラを構築してみましょう。ここでは、シンプルなS3バケットを作成する手順を解説します。

前提条件

作業を始める前に、以下の環境が準備されていることを確認してください。

  • AWSアカウントと、リソースを作成できる権限を持つIAMユーザー
  • AWS CLIがインストールされ、aws configure で認証情報が設定済みであること
  • Node.jsとnpm (CDKのコマンドラインツール aws-cdk のインストールに必要)
  • Python 3.9以上

セットアップとプロジェクト初期化

  1. CDK CLIのインストール: まずはターミナルで、CDKのコマンドラインツールをnpmを使ってグローバルにインストールします。

    npm install -g aws-cdk

  2. プロジェクト作成: 次に、プロジェクト用のディレクトリを作成し、その中でCDKプロジェクトを初期化します。--language python を指定するのがポイントです。

    mkdir my-cdk-project
cd my-cdk-project
cdk init app --language python

    これにより、Python用のCDKプロジェクトの雛形が自動生成されます。同時にPythonの仮想環境 (.venv) も作成されるので、有効化しておきましょう。

  3. 依存ライブラリのインストール: 仮想環境を有効化し、必要なPythonライブラリをインストールします。

    # macOS / Linux
source .venv/bin/activate
# Windows
# .venv\Scripts\activate.bat

pip install -r requirements.txt

S3バケットを作成するコードを記述する

プロジェクトの雛形の中にある my_cdk_project/my_cdk_project_stack.py ファイルを開き、編集します。このファイルが、インフラ構成を定義する本体です。今回は、ファイルをバージョン管理でき、スタック削除時に自動で中身も削除されるS3バケットを作成してみます。

from aws_cdk import (
    Stack,
    aws_s3 as s3,
    RemovalPolicy # RemovalPolicy をインポート
)
from constructs import Construct

class MyCdkProjectStack(Stack):
    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        # S3バケットを作成するコンストラクト
        s3.Bucket(self, "MyFirstCdkBucket",
            versioned=True,  # バージョニングを有効にする
            # スタック削除時にバケットも削除するポリシー
            # 本番環境では不用意な削除を防ぐため RETAIN が推奨されます
            removal_policy=RemovalPolicy.DESTROY,
            # スタック削除時にバケット内のオブジェクトも自動削除する
            auto_delete_objects=True
        )

インフラをデプロイする

コードが書けたら、いよいよAWS上にデプロイします。ターミナルで以下のコマンドを順に実行してください。

  1. ブートストラップ (初回のみ): CDKがデプロイに必要な情報を保存するためのS3バケット等をAWSアカウント内に作成します。これはアカウントとリージョンの組み合わせごとに一度だけ行えばOKです。

    cdk bootstrap

  2. 差分確認 (任意): これからデプロイされる内容と、現在のAWS環境との差分を確認できます。安全のために実行する癖をつけると良いでしょう。

    cdk diff

  3. デプロイ: 実際にAWS上にリソースを作成します。途中でIAMポリシーの変更に関する確認が表示されたら y を入力して進めてください。

    cdk deploy

    数分後、デプロイが完了するとAWSコンソール上にもS3バケットが作成されているのが確認できるはずです。

  4. クリーンアップ: 確認が終わったら、以下のコマンドで作成したリソースを綺麗に削除できます。

    cdk destroy

これで、PythonコードからAWSインフラを管理する第一歩を踏み出せました！

実践！Python製WebアプリケーションのインフラをCDKで構築・デプロイ

S3バケットだけでは物足りないですよね。次は、より実践的な例として、コンテナ化されたPythonのWebアプリケーション (FlaskやFastAPIなど) を動かすためのインフラを構築してみましょう。構成は、VPC (ネットワーク)、ECS on Fargate (コンテナ実行環境)、ALB (ロードバランサー) を組み合わせた一般的なものです。

これを手作業で作るのは大変ですが、CDKの高レベルなコンストラクト ApplicationLoadBalancedFargateService を使うと驚くほど簡単です。このコンストラクトは、ALB、ECSサービス、タスク定義、ターゲットグループ、セキュリティグループなど、必要なリソース一式をまとめて作成してくれます。

from aws_cdk import (
    Stack,
    aws_ec2 as ec2,
    aws_ecs as ecs,
    aws_ecs_patterns as ecs_patterns # 高レベルなパターンコンストラクト
)
from constructs import Construct

class WebAppStack(Stack):
    def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
        super().__init__(scope, construct_id, **kwargs)

        # 1. VPCの作成
        # max_azs=2 は、2つのアベイラビリティゾーンにまたがるネットワークを自動で作る設定
        vpc = ec2.Vpc(self, "MyWebAppVpc", max_azs=2)

        # 2. ECSクラスターの作成
        cluster = ecs.Cluster(self, "MyWebAppCluster", vpc=vpc)

        # 3. ALB + Fargateサービスの作成
        # これだけでロードバランサーとコンテナサービスが構築される
        ecs_patterns.ApplicationLoadBalancedFargateService(self, "MyWebAppService",
            cluster=cluster,
            cpu=256,                 # タスクに割り当てるCPUユニット
            memory_limit_mib=512,    # タスクに割り当てるメモリ (MiB)
            desired_count=1,         # 実行するタスクの数
            task_image_options=ecs_patterns.ApplicationLoadBalancedTaskImageOptions(
                # ECRにプッシュ済みの自分のDockerイメージを指定する
                image=ecs.ContainerImage.from_registry("123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-web-app:latest")
            )
        )

このわずかなコードを cdk deploy するだけで、外部からアクセス可能なコンテナアプリケーション基盤が自動で構築されます。Dockerイメージの指定部分は、事前にAWS ECR (Elastic Container Registry) にプッシュしておいた自分のアプリケーションイメージに書き換えてください。CDKがいかに強力で、インフラ構築の複雑さを隠蔽してくれるかが分かる好例です。

チーム開発で活かすCDK：環境分離とベストプラクティス

CDKは個人開発だけでなく、チームでの開発効率を飛躍的に向上させます。ここでは、チームでCDKを運用する上で重要となる「環境の分離」と、コードの保守性を高めるためのプラクティスをいくつか紹介します。

環境ごとの設定を分離する

開発 (dev)、ステージング (stg)、本番 (prod) など、環境ごとにリソースのスペックや設定を変えたいケースは頻繁にあります。CDKでは、cdk.json ファイルの context を利用して、これをスマートに管理するのが一般的です。

例えば、cdk.json に環境ごとの設定を定義します。

{
  "app": "python3 app.py",
  "context": {
    "dev": {
      "instance_count": 1,
      "log_level": "DEBUG"
    },
    "prod": {
      "instance_count": 3,
      "log_level": "INFO"
    }
  }
}

デプロイ時に -c オプションでどの環境を使うか指定します。

cdk deploy -c target_env=dev MyWebAppStack

そして、Pythonコード側では self.node.try_get_context() を使って値を取得し、設定を切り替えます。

# ... Stackクラス内 ...
target_env = self.node.try_get_context("target_env")
if not target_env:
    raise ValueError("Context variable 'target_env' must be specified.")

env_config = self.node.try_get_context(target_env)
instance_count = env_config["instance_count"]

# この instance_count を desired_count に渡すなどして利用
ecs_patterns.ApplicationLoadBalancedFargateService(self, "MyWebAppService",
    # ...
    desired_count=instance_count,
    # ...
)

これにより、単一のコードベースで複数の環境を安全に管理できます。

その他のベストプラクティス

  • コンストラクトの再利用: アプリケーションで繰り返し使うインフラのパターン（例: 特定のタグが付いたS3バケットと、それを配信するCloudFrontディストリビューションのセット）は、独自のコンストラクトクラスとして実装しましょう。これにより、コードの再利用性が高まり、DRY (Don’t Repeat Yourself) の原則を守れます。
  • スタックの分割: 一つの巨大なスタックに全てのリソースを詰め込むのではなく、責務（ネットワーク、データベース、アプリケーションなど）に応じてスタックを分割します。スタックが小さいと、デプロイ時間が短縮され、変更の影響範囲も限定的になります。
  • 適切なタグ付け: AWSリソースには、コスト管理や識別のために必ずタグを付けましょう。CDKでは Tags.of(scope).add("key", "value") を使って簡単にタグを追加できます。

CDKと他のIaCツールの比較：あなたのプロジェクトに最適な選択肢は？

最後に、AWS CDKと他の代表的なIaCツールを比較し、どのような場合にどのツールが適しているかを考えてみましょう。

項目AWS CDKTerraformAWS CloudFormation
言語TypeScript, PythonなどHCL (独自言語)YAML / JSON
抽象度高い (高レベルConstructs)中〜高低い (リソース直書き)
クラウドAWS特化マルチクラウド対応AWS特化
状態管理CloudFormationスタックtfstateファイルCloudFormationスタック
開発体験IDEの補完などが効きやすい専用のCLIとエコシステムAWSコンソールとの連携
  • AWS CloudFormation: CDKの土台となっているサービスです。YAML/JSONで記述するため学習は容易ですが、記述量が多くなりがちで、ループ処理のような動的な構成は苦手です。シンプルで静的な構成や、既存の資産を活用する場合には依然として有効です。
  • Terraform (by HashiCorp): マルチクラウド対応が最大の特徴です。AWS、Google Cloud、Azureなど、複数のクラウドを一つのツールで管理したい場合に第一の選択肢となります。HCLという独自の宣言的言語を使いますが、エコシステムが非常に成熟しています。
  • AWS CDK: AWSに特化する代わりに、汎用プログラミング言語の力を最大限に活かせるのが強みです。アプリケーション開発者がインフラを管理する場合や、複雑で動的なインフラ構成を効率的に記述したい場合に最適です。特にチームのスキルセットがPythonやTypeScriptに偏っているなら、学習コストを低く抑えられます。

結論として、AWS環境のみを利用し、チームがPythonなどの対応言語に習熟しているならば、AWS CDKは非常に生産性の高い選択肢です。もし将来的にマルチクラウド展開の可能性があるなら、Terraformを検討するのが良いでしょう。

インフラをコードで管理することは、現代のクラウド開発における必須スキルです。ぜひこの記事をきっかけに、AWS CDKを使った快適なインフラ管理の世界に飛び込んでみてください！

#aws-cdk #python #infrastructure-as-code #cloud-automation

関連記事

インフラ脱却！AWS LambdaでPython製Web APIを動かす具体例とコツ

負債を生まない！クリーンアーキテクチャとDDDで「設計されたシステム」をPythonで作る

PythonとFastAPIでスケーラブルWeb API！設計からAWSデプロイまで