「アーキテクチャ図を見ながらコードレビューをしているが、図とコードが噛み合わず確認に時間がかかる」
AWSの構成管理にTerraformを使うチームが増えた今、こうした悩みを持つエンジニアは少なくありません。アーキテクチャ図はシステムの全体像を把握するために欠かせない資料ですが、Terraformのコードと対応付けて読む習慣がないと、設計意図の読み違いや変更ミスにつながります。
この記事では、AWSアーキテクチャ図のサンプルを3パターン（VPC基本構成・マルチAZ冗長設計・3層Web構成）掲載し、それぞれに対応するTerraformのresourceブロックを紐付けながら解説します。AWS環境でのLinuxサーバー構築・運用に関心のある方を想定環境として、EC2を中心とした一般的なWebシステムを扱います。
この記事のポイント
・アーキテクチャ図の各構成要素がTerraformのどのresourceに対応するかを整理
・VPC基本構成・マルチAZ・3層WebのサンプルをHCLコードとセットで解説
・図からコードを読む際の「AZ境界」「サブネット分離」の見方を具体的に説明
・設計ミスを事前に防ぐためのアーキテクチャ図チェックポイントも掲載
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
アーキテクチャ図とTerraformコードをセットで読む理由
AWSのアーキテクチャ図（構成図）は、VPC・サブネット・EC2・ALB・RDSといったリソースの配置関係を視覚化したものです。一方、Terraformはresourceブロックでその配置関係をコードとして宣言します。この2つを別々に理解しようとすると、次のような問題が起きます。・図には「マルチAZ」と書かれているのに、コード上では
availability_zone = "ap-northeast-1a"の1か所しかない・「プライベートサブネット」と「パブリックサブネット」の違いが、Terraformのresource定義だけではわかりにくい
・図のリソース名とTerraformのリソース名が対応しておらず、変更対象の特定に時間がかかる
図とコードをセットで読む習慣をつけると、「この
aws_subnetのブロックがアーキテクチャ図のどの箱に相当するか」がすぐにわかるようになります。コードレビューや障害対応の速度が上がります。アーキテクチャ図の基本構成要素と記号の読み方
AWSの公式アーキテクチャ図では、各リソースに対応するアイコンが定義されています。Terraform設計時に意識すべき主な対応関係は次のとおりです。・VPC（太い実線の外枠）：Terraformの
aws_vpcリソースに対応。CIDRブロックを指定します・サブネット（VPC内の区画）：
aws_subnetリソースに対応。パブリック・プライベートの区別はルートテーブルの設定で決まります・インターネットゲートウェイ（IGW）：
aws_internet_gatewayリソースに対応。パブリックサブネットのインターネット接続に必須・NAT Gateway：
aws_nat_gatewayリソースに対応。プライベートサブネットから外部APIへアクセスする際に使用・ALB（Application Load Balancer）：
aws_lbリソースに対応。load_balancer_type = "application"で定義・EC2インスタンス：
aws_instanceリソースに対応。AMI IDとインスタンスタイプを指定・RDS：
aws_db_instanceまたはaws_rds_clusterに対応。マルチAZ構成はmulti_az = trueで有効化アーキテクチャ図上で「AZ-a」「AZ-c」のように複数のAZにまたがって描かれているリソースは、Terraformでも複数の
aws_subnetリソースを定義し、それぞれのAZを指定する必要があります。サンプル1：VPC基本構成（パブリック・プライベートサブネット分離）
最初のサンプルは、VPC内にパブリックサブネットとプライベートサブネットを設ける基本構成です。EC2をプライベートサブネットに置き、ALBをパブリックサブネットに置くことで、EC2への直接アクセスを遮断します。構成概要：
・VPC CIDR: 10.0.0.0/16
・パブリックサブネット（10.0.1.0/24）：ALBを配置
・プライベートサブネット（10.0.2.0/24）：EC2（Webサーバー）を配置
・インターネットゲートウェイ：パブリックサブネット用
・NAT Gateway：プライベートサブネットからの外向き通信用
以下のTerraform HCLがこのアーキテクチャ図に対応します（出力例は環境により異なります）。
# VPC定義 resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" tags = { Name = "main-vpc" } } # パブリックサブネット（ALB用） resource "aws_subnet" "public" { vpc_id = aws_vpc.main.id cidr_block = "10.0.1.0/24" availability_zone = "ap-northeast-1a" map_public_ip_on_launch = true tags = { Name = "public-subnet" } } # プライベートサブネット（EC2用） resource "aws_subnet" "private" { vpc_id = aws_vpc.main.id cidr_block = "10.0.2.0/24" availability_zone = "ap-northeast-1a" tags = { Name = "private-subnet" } } # インターネットゲートウェイ resource "aws_internet_gateway" "main" { vpc_id = aws_vpc.main.id tags = { Name = "main-igw" } } # NAT Gateway（パブリックサブネットに配置） resource "aws_eip" "nat" { domain = "vpc" } resource "aws_nat_gateway" "main" { allocation_id = aws_eip.nat.id subnet_id = aws_subnet.public.id tags = { Name = "main-nat" } }
aws_vpc→aws_subnet→aws_internet_gateway/aws_nat_gateway」の定義順序と対応しています。AWSでのLinuxサーバー構築をこれから始める方は、Amazon LinuxでのAWSサーバー構築入門も参考にしてください。
サンプル2：マルチAZ冗長Webシステム構成
2つ目のサンプルは、単一AZ構成に複数AZへの分散を加えた冗長設計です。AZ障害が発生しても片側のサブネットとインスタンスで処理を継続できる構成が目標です。構成概要：
・AZ-a：パブリックサブネット（10.0.1.0/24）＋プライベートサブネット（10.0.2.0/24）
・AZ-c：パブリックサブネット（10.0.3.0/24）＋プライベートサブネット（10.0.4.0/24）
・ALB：2つのパブリックサブネットにまたがって配置
・EC2：各AZのプライベートサブネットに1台ずつ配置
・NAT Gateway：各AZに1台ずつ（AZ障害時にNAT自体が単一障害点にならないため）
# AZ-cのサブネット追加定義（AZ-aはサンプル1を流用） resource "aws_subnet" "public_c" { vpc_id = aws_vpc.main.id cidr_block = "10.0.3.0/24" availability_zone = "ap-northeast-1c" map_public_ip_on_launch = true tags = { Name = "public-subnet-c" } } resource "aws_subnet" "private_c" { vpc_id = aws_vpc.main.id cidr_block = "10.0.4.0/24" availability_zone = "ap-northeast-1c" tags = { Name = "private-subnet-c" } } # ALB（2つのパブリックサブネットにまたがる） resource "aws_lb" "web" { name = "web-alb" internal = false load_balancer_type = "application" subnets = [aws_subnet.public.id, aws_subnet.public_c.id] tags = { Name = "web-alb" } }
aws_subnetリソースを2ブロック定義し、availability_zoneだけを変えるパターンが基本です。ALBのsubnets引数に両方のサブネットIDを渡すことで、図の「AZをまたぐ配置」を表現します。マルチAZ冗長設計の詳細な設計ポイントについては、AWSマルチAZ冗長設計の実践でより深く解説しています。
サンプル3：RDSを含む3層Webシステム構成
3つ目のサンプルは、ALB→EC2（Webサーバー）→RDSの3層構成です。RDSはDBサブネットグループを使ってマルチAZに配置し、プライベートサブネットに閉じた設計にします。構成概要：
・Tier 1（パブリックサブネット）：ALBを配置
・Tier 2（プライベートサブネット）：EC2（アプリサーバー）を配置
・Tier 3（DBサブネット）：RDS Multi-AZを配置
# DBサブネット（AZ-aとAZ-c） resource "aws_subnet" "db_a" { vpc_id = aws_vpc.main.id cidr_block = "10.0.10.0/24" availability_zone = "ap-northeast-1a" tags = { Name = "db-subnet-a" } } resource "aws_subnet" "db_c" { vpc_id = aws_vpc.main.id cidr_block = "10.0.11.0/24" availability_zone = "ap-northeast-1c" tags = { Name = "db-subnet-c" } } # DBサブネットグループ resource "aws_db_subnet_group" "main" { name = "main-db-subnet-group" subnet_ids = [aws_subnet.db_a.id, aws_subnet.db_c.id] } # RDS（マルチAZ有効） resource "aws_db_instance" "main" { identifier = "main-db" engine = "mysql" engine_version = "8.0" instance_class = "db.t3.micro" allocated_storage = 20 db_subnet_group_name = aws_db_subnet_group.main.name multi_az = true skip_final_snapshot = true tags = { Name = "main-db" } }
multi_az = trueに対応します。図の「プライマリ＋スタンバイ」の表現は1つのaws_db_instanceリソースで実現できます。Terraformリソースとアーキテクチャ図の対応早見表
| アーキテクチャ図の要素 | Terraformリソース | 設定のポイント |
|---|---|---|
| VPC（外枠） | aws_vpc |
cidr_block でアドレス空間を定義 |
| パブリックサブネット | aws_subnet |
ルートテーブルにIGWへのルートがある |
| プライベートサブネット | aws_subnet |
ルートテーブルにNAT Gatewayへのルートがある |
| インターネットゲートウェイ | aws_internet_gateway |
VPCに1つアタッチ |
| NAT Gateway | aws_nat_gateway |
Elastic IPが必要（aws_eip） |
| ALB | aws_lb |
load_balancer_type = "application" |
| EC2インスタンス | aws_instance |
ami・instance_type・subnet_id を指定 |
| RDS マルチAZ | aws_db_instance |
multi_az = true で冗長化を有効化 |
| セキュリティグループ | aws_security_group |
ingress と egress でポートを制御 |
| ルートテーブル | aws_route_table |
サブネットとの関連付けがパブリック/プライベートの実体 |
設計ミスをアーキテクチャ図で事前に防ぐポイント
1. 単一AZ構成になっていないか確認する
アーキテクチャ図を書いた後、全てのリソースが1つのAZに収まっていないか確認します。ALBは複数AZのサブネットを指定しないと本来のフェイルオーバー機能が働きません。図で「AZの境界線を何本引いているか」を数えることが有効な確認方法です。2. プライベートサブネットからの外向き通信経路を確認する
プライベートサブネットのEC2がyumやapt、外部APIへ接続するためには、NAT Gatewayを経由するルートが必要です。アーキテクチャ図でNAT Gatewayと矢印の向きを確認し、対応するTerraformのaws_route_tableにdestination_cidr_block = "0.0.0.0/0"のルートが定義されているかを確認します。3. RDSのDBサブネットグループを見落とさない
RDSをマルチAZ構成にするには、DBサブネットグループに複数AZのサブネットを登録する必要があります。アーキテクチャ図でRDSアイコンが1か所に見えていても、実際にはaws_db_subnet_groupのsubnet_idsに2つ以上のAZのサブネットIDを渡す必要があります。図の視覚表現とリソース定義の対応を意識してください。本記事のまとめ
AWSアーキテクチャ図のサンプルとTerraformコードの対応関係をまとめます。| 確認ポイント | アーキテクチャ図での確認方法 | Terraformでの確認箇所 |
|---|---|---|
| マルチAZ構成か | AZ境界線が複数本あるか | aws_subnet の availability_zone が複数あるか |
| パブリック/プライベートの分離 | IGW/NAT矢印の向きと経路 | aws_route_table の destination と gateway_id |
| RDSの冗長化 | プライマリとスタンバイが別AZか | aws_db_instance の multi_az = true |
| ALBの複数AZ対応 | ALBが2つ以上のAZに配置されているか | aws_lb の subnets に複数IDが渡されているか |
＞＞ AWSでのLinuxサーバー構築セミナーの詳細はこちら
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
- 前のページへ：AWSタグ命名規則でマルチアカウント環境を整理するVPC設計の実践｜チーム運用を統一する
- この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます