模倣を捨てよ、環境非依存型テンプレートの極意：MappingsとConditionsが織りなすDRY原則の極限
インフラストラクチャ・アズ・コード（IaC）の黎明期を過ぎ、我々は今、数千・数万のリソースを単一のパイプラインで制御する時代を生きている。
開発、検証、本番。ステージごとに類似したインフラテンプレートをコピー＆ペーストし、環境変数の置換スクリプトに怯える日々を送るSREは、もはや絶滅すべきだ。
AWS CloudFormationにおいて、環境差異を吸収するために`Parameters`をただ並べ立てるのは、設計の敗北を意味する。デプロイのたびに人間の手でパラメータを入力させたり、CI/CDパイプライン側で複雑な分岐スクリプトを書かせたりするアプローチは、自動化の美徳に反する。
本稿では、`Mappings`（マッピング）と`Conditions`（条件付き評価）を極限まで組み合わせ、環境名（Environment）という単一の入力から、リソースのスペック、可用性、セキュリティ要件を完全に導出する「環境非依存型テンプレート」の設計パターンを、実戦的なコードとアーキテクチャの深層から解説する。
—
1. 内部アーキテクチャの理解：CloudFormationの評価順序（Evaluation Order）
高度なテンプレート設計を行う上で、CloudFormationの内部エンジンがどのように式を評価しているかを理解することは不可欠である。この順序を誤ると、意図しない循環依存や評価エラーに直面する。
CloudFormationのライフサイクルにおいて、式と関数は以下の順序で解決される。
1. Parameters の解決（外部入力）
2. Mappings のルックアップ（静的な多次元連想配列の参照）
3. Conditions の評価（Mappingsの結果やParametersを比較）
4. Resources / Outputs の生成と依存関係解決
このアーキテクチャから導き出される重要な知見がある：「`Conditions`の判定には`Mappings`の結果を利用できるが、その逆はできない」。
したがって、環境依存の静的ディクショナリはすべて`Mappings`に閉じ込め、動的なフラグ判定やリソースの有無は`Conditions`に委譲するという役割分担が、最も美しく破綻しない設計となる。
—
2. マジックナンバーの完全駆除：多次元Mappingsによる環境抽象化
多くの現場で見かけるアンチパターンは、インスタンスタイプやディスク容量をコード内に直書き（マジックナンバー）し、それをConditionsで力技で分岐させる手法だ。これでは環境が増えるたびにコードの修正が必要になる。
以下のMappings設計を見てほしい。ここでは、`Environment`（dev, stg, prod）と`Region`の軸を組み合わせ、さらにリソースの「サイジングプロファイル」を完全に抽象化している。
AWSTemplateFormatVersion: ‘2010-09-09’
Description: ‘Expert-level Environment-Agnostic Infrastructure Pattern’
Parameters:
EnvironmentType:
Type: String
Default: dev
AllowedValues:
- dev
- stg
- prod
Description: ‘Target deployment environment’
Mappings:
# 環境ごとのトポロジーとサイジングを完全に一元化
EnvironmentConfig:
dev:
InstanceType: t4g.micro
MinSize: 1
MaxSize: 2
MultiAZ: ‘false’
EnableDeletionProtection: ‘false’
BackupRetentionDays: 1
stg:
InstanceType: t4g.small
MinSize: 2
MaxSize: 4
MultiAZ: ‘true’
EnableDeletionProtection: ‘false’
BackupRetentionDays: 7
prod:
InstanceType: t4g.medium
MinSize: 2
MaxSize: 10
MultiAZ: ‘true’
EnableDeletionProtection: ‘true’
BackupRetentionDays: 30
# リージョンごとのAMIマッピング（例：Amazon Linux 2023 ARM64）
RegionMap:
us-east-1:
AMI: ami-0c7217cdde317cfec
ap-northeast-1:
AMI: ami-0d52744d65518c81e
このMappingsの優れている点は、「開発者が環境ごとのインフラの差異を意識する必要がない」という点だ。テンプレートの利用者は、単に `EnvironmentType` を指定するだけで、AWSが推奨するベストプラクティスに則ったサイジングと高可用性設定が自動的に適用される。
—
3. Conditionsの高度な組み合わせ：論理関数（Fn::And, Fn::Or, Fn::Not）の極意
Mappingsから引き出した値、あるいはパラメータを元に、リソースを構築するか否か、あるいはどのプロパティを適用するかを制御するのが `Conditions` である。
ここで、単に `EnvironmentType == ‘prod’` と比較するだけの素朴な条件分岐を行ってはならない。真のエキスパートは、「将来の拡張性に耐える論理的条件（Logical Expressions）」を構築する。
以下の例では、「本番環境であること」、または「マルチAZが無効な開発環境以外で、かつ特定のストレージ暗号化が強制される場合」といった複雑なビジネスロジックをConditionsで表現する。
Conditions:
# 1. 本番環境判定
IsProduction: !Equals [ !Ref EnvironmentType, ‘prod’ ]
# 2. 開発環境以外（stg および prod）の判定
IsNonDev: !Not [ !Equals [ !Ref EnvironmentType, ‘dev’ ] ]
# 3. 冗長構成（MultiAZ）の有効性判定（Mappingsの文字列をBoolean比較用に評価）
NeedsMultiAZ: !Equals
- !FindInMap [ EnvironmentConfig, !Ref EnvironmentType, MultiAZ ]
- ‘true’
# 4. 削除保護の適用条件：本番、またはステージングかつマルチAZの場合
ApplyDeletionProtection: !And
- !Condition IsNonDev
- !Equals
- !FindInMap [ EnvironmentConfig, !Ref EnvironmentType, EnableDeletionProtection ]
- ‘true’
🧠 深層知見：CloudFormationの文字列比較の罠
Mappingsから取得する値は、JSON/YAMLの仕様上、Boolean（`true`/`false`）であっても文字列（`’true’`/`’false’`）として扱われることが多い。
`!If` や `!Condition` においてこれをそのまま評価すると、期待通りに動作せずバグの温床となる。Mappings内ではあえてクォーテーションで囲んだ文字列として定義し、比較時にも文字列として厳格に扱うのが、無駄なデバッグ時間を削減するプロの知見である。
—
4. リソース定義の極限：!If関数による動的プロパティ生成とリソースの生死制御
ここまで準備したMappingsとConditionsを、実リソースの定義（`Resources`）にどのように流し込むか。
ここでは、RDSデータベースクラスターの構築を例に、環境に応じたスペック変更と、開発環境ではコスト削減のためにリードレプリカ（マルチAZ）を完全に省く（リソースの存在自体をコントロールする）手法を示す。
Resources:
# 共通のKMSキー（本番のみ強固なポリシー、開発はデフォルト等も可能）
StorageKey:
Type: AWS::KMS::Key
Properties:
Description: ‘Encryption key for database storage’
EnableKeyRotation: !Condition IsProduction
# データベースインスタンス
PrimaryDatabase:
Type: AWS::RDS::DBInstance
Properties:
DBInstanceIdentifier: !Sub ‘app-db-${EnvironmentType}’
DBInstanceClass: !FindInMap [ EnvironmentConfig, !Ref EnvironmentType, InstanceType ]
Engine: postgres
EngineVersion: ‘15.4’
# Mappingsから取得したバックアップ保持期間を適用
BackupRetentionPeriod: !FindInMap [ EnvironmentConfig, !Ref EnvironmentType, BackupRetentionDays ]
MultiAZ: !Condition NeedsMultiAZ
StorageEncrypted: true
KmsKeyId: !GetAtt StorageKey.Arn
# Conditionsによる削除保護の適用
DeletionPolicy: !If [ ApplyDeletionProtection, Delete, Snapshot ]
Tags:
- Key: Environment
Value: !Ref EnvironmentType
# 開発環境では不要だが、検証・本番では必要なリードレプリカをConditionで完全制御
ReadReplicaDatabase:
Condition: IsNonDev
Type: AWS::RDS::DBInstance
Properties:
DBInstanceIdentifier: !Sub ‘app-db-replica-${EnvironmentType}’
DBInstanceClass: !FindInMap [ EnvironmentConfig, !Ref EnvironmentType, InstanceType ]
Engine: postgres
# プライマリDBへの依存関係を明示
SourceDBInstanceIdentifier: !Ref PrimaryDatabase
StorageEncrypted: true
ここで注目すべきは `ReadReplicaDatabase` に付与されている `Condition: IsNonDev` である。
これにより、`dev` 環境のデプロイ時には、CloudFormationエンジンはそもそもこのリソースブロックを評価・作成しない。スタックのコストを極限まで最適化し、無駄なリソース作成によるAWS利用料の肥大化を防ぐことができる。
—
5. エキスパートの流儀：AWS CLI / API を駆使した完全自動化パイプライン
テンプレートがどれほど美しくとも、デプロイプロセスが手動であれば意味がない。環境非依存型テンプレートの真価を発揮させるため、CI/CDパイプライン（GitHub ActionsやAWS CodePipeline）から実行する際のAWS CLIコマンドのベストプラクティスを提示する。
環境変数を動的に注入し、変更セット（ChangeSet）を活用した安全かつ完全自動化されたデプロイメントスクリプトの断片を共有しよう。
!/usr/bin/env bash
set -euo pipefail
— Configuration —
STACK_NAME=”core-application-stack”
TEMPLATE_FILE=”infrastructure.yaml”
REGION=”ap-northeast-1″
ENVIRONMENT=”${1:-dev}” # 引数で環境を指定（デフォルトはdev）
echo “==> Validating CloudFormation Template…”
aws cloudformation validate-template \
–template-body “file://${TEMPLATE_FILE}” > /dev/null
echo “==> Generating ChangeSet for Environment: [${ENVIRONMENT}]…”
CHANGE_SET_name=”changeset-$(date +%s)”
ChangeSetを作成し、意図しないリソース削除（Replacement等）が発生していないかプレビューする
aws cloudformation create-change-set \
–stack-name “${STACK_NAME}” \
–template-body “file://${TEMPLATE_FILE}” \
–parameters ParameterKey=EnvironmentType,ParameterValue=”${ENVIRONMENT}” \
–capabilities CAPABILITY_IAM CAPABILITY_NAMED_IAM \
–change-set-name “${CHANGE_SET_name}” \
–region “${REGION}”
echo “==> Waiting for ChangeSet to be created…”
aws cloudformation wait change-set-create-complete \
–stack-name “${STACK_NAME}” \
–change-set-name “${CHANGE_SET_name}” \
–region “${REGION}”
変更内容のサマリーを取得してログに出力（監査・レビュー用）
aws cloudformation describe-change-set \
–stack-name “${STACK_NAME}” \
–change-set-name “${CHANGE_SET_name}” \
–region “${REGION}” \
–query “Changes[].ResourceChange.{Action:Action, ResourceType:ResourceType, LogicalResourceId:LogicalResourceId, Replacement:Replacement}” \
–output table
echo “==> Executing ChangeSet…”
aws cloudformation execute-change-set \
–stack-name “${STACK_NAME}” \
–change-set-name “${CHANGE_SET_name}” \
–region “${REGION}”
echo “==> Waiting for stack operation to complete…”
aws cloudformation wait stack-update-complete \
–stack-name “${STACK_NAME}” \
–region “${REGION}”
echo “==> Deployment successfully completed for [${ENVIRONMENT}].”
💡 現場で役立つハック：ChangeSetの Replacement 検出
上記の自動化スクリプトで特筆すべきは、`describe-change-set` の出力にある `Replacement` 属性の監視だ。
もしMappingsやConditionsの変更によって、既存のステートフルなリソース（RDSやDynamoDBなど）が `Replacement: True`（＝作り直し）と判定された場合、自動的にパイプラインを中断するガードレールをスクリプト側に組み込むことで、本番環境での致命的なデータ消失事故を未然に防ぐことができる。
—
6. まとめ：保守性の限界を突破するインフラストラクチャ設計へ
CloudFormationの `Mappings` と `Conditions` は、単なる条件分岐のツールではない。それらは、「環境差異というインフラストラクチャの複雑性をコードの内側で美しくカプセル化するための強力な抽象化レイヤー」である。
コピペで作られたスパゲッティのようなテンプレートや、環境ごとに散らばるバラバラの設定ファイルとは今日で別れを告げよう。
DRY原則を徹底し、単一のテンプレートであらゆるステージングを完璧に制御する。その境地に至ったとき、あなたのインフラストラクチャは真の意味で「コード」となり、ビジネスの加速を強力に支える基盤となる。