はじめに

本記事では、FastAPIやPythonアプリをAWS ECS Fargate上にデプロイする際の環境変数の管理方法についてまとめています。

個人の備忘録程度の走り書きとなっておりますが、温かい目で見守っていただければ幸いです。

ローカルと本番環境での環境変数の扱いを切り替えることで、安全かつ効率的な運用を目指します。

書こうと思ったきっかけ

受講しているITスクールのハッカソンの開発の一環で、開発環境と本番環境で異なる環境変数の管理が必要となったため、混乱を避けるためにも設定方法を記事として記録しておくことにしました。

内容

環境ごとの`.env`利用有無

環境	`.env` 読み込み	備考
ローカル	読み込む	`.env` に値を記載
本番（Fargate）	読み込まない	Secrets Managerやタスク定義から注入

方法①：マネジメントコンソールから設定する手順

ECS → タスク定義 → 対象のタスク定義を選択 → 新しいリビジョンを作成
[コンテナの定義] → 編集 → 環境変数セクションへ移動

以下を追加：

名前	値（例）
`ENV`	`production`
`DATABASE_URL`	`mysql+pymysql://user:password@host:3306/dbname`

保存してリビジョンを作成
新しいリビジョンでサービスを更新（またはタスクを再起動）

なぜ `ENV=production` が必要？

"name": "ENV", "value": "production" をタスク定義の環境変数に追加する理由は、アプリケーション側で「本番環境かどうか」を判定するためです。

if os.getenv("ENV") != "production":
    load_dotenv()

このように、ENV が production であれば .env ファイルを読み込まないようにしています。

.env を読み込んでしまうと、ECSに設定した環境変数よりも .env の値が優先される可能性がある
.env が存在しない状態で load_dotenv() を呼ぶとエラーになる場合がある（意図しない挙動）
ローカルと本番の動作切り替えを簡単に行える

つまり「ENV=production」は、本番環境で.envを無効化するためのスイッチのような役割を果たしており、セキュリティや安定運用のために重要です。

方法②：JSONのタスク定義で書く場合

{
  "containerDefinitions": [
    {
      "name": "your-container-name",
      "image": "your-image",
      "environment": [
        {
          "name": "ENV",
          "value": "production"
        },
        {
          "name": "DATABASE_URL",
          "value": "mysql+pymysql://user:password@host:3306/dbname"
        }
      ]
    }
  ]
}

セキュリティ面の注意

DATABASE_URL にはパスワードなどの機密情報が含まれるため、本番環境では Secrets Manager や SSM パラメータストアを使って管理するのがベストプラクティスです。

ECSのタスク定義では secrets セクションを利用することで、Secrets Manager に格納された情報を直接環境変数として注入することができます。

まとめ

ローカルでは .env に記載した環境変数を使用
本番では Secrets Manager やタスク定義で注入し、.env は使わない
ENV=production によって本番と開発の切り替えを制御
安全で柔軟な環境変数管理のため、AWSリソースと連携した設計を行う