
IaCツールのTerraformを使用してプロジェクトを進めている場合、作成したリソースの情報を参照して別のリソースを作成したい場面に遭遇します。このような時に役立つのがterraform_remote_state
データソースです。
この記事ではterraform_remote_stateの基本と、使い方について解説します。
Terraformを使用したインフラ構築をより効率的に進めるために必要な知識となるため、一緒に学んでいきましょう。
terraform_remote_stateとは
terraform_remote_stateは、Terraformのデータソースの1つであり、リモートバックエンドに保存されたtfstate
ファイルのoutput値を取得するために使用します。
このデータソースは、異なるTerraformプロジェクト間や環境でリソース情報を共有する際に便利な機能です。
The terraform_remote_state Data Source
terraform_remote_stateのメリット
このセクションでは、terraform_remote_stateを使用することでどのようなメリットがあるのかを解説します。
プロジェクト間でtfstateの情報を共有できる
terraform_remote_stateを利用すると、Terraformの異なるプロジェクト間でtfstate
の情報を共有し、リソースのIDや設定情報を参照できます。
VPC、EC2、RDSなどのリソースを、それぞれ異なるTerraformプロジェクトとして構築、管理する場合でも、各リソースのIDや設定情報をプロジェクト間で共有し参照することが可能です。
こうすることで、別のプロジェクトで作成したVPCのIDを参照し、その中にEC2を構築するといったことができます。
検証環境、本番環境などでstate情報を参照できる
検証環境や本番環境など、環境ごとにtfstate
ファイルを分けていた場合にも有効です。
検証環境で構築するリソースを本番環境のVPCに関連付ける場合でも、本番環境のVPC情報を検証環境から参照できるため、環境ごとの設定を適切に共有できます。
tfstateに関しては、以下の記事で解説しています。
tfstateファイルについての基礎 コアやプロバイダ、tfstateファイルの役割について理解しよう
terraform_remote_stateデータソースを使用する条件
terraform_remote_stateのデータソースを使用するには、次のような条件があります。
outputブロックで値を出力していること
terraform_remote_stateデータソースで値を使用するには、作成したリソースの情報をoutputブロックで出力する必要があります。
outputブロックで値を出力していない場合はエラーになるため注意が必要です。
root moduleでoutputした値のみ取得できる
公式ドキュメントにも記載されていますが、terraform_remote_stateはroot moduleのoutputに定義された値のみ取得できます。
moduleを使用してリソースを作成している場合、module内のoutputs.tf
で値を定義するだけではterraform_remote_stateから参照することはできません。
必ずroot moduleのoutputs.tf
で、module内のoutputを出力するように設定する必要があります。
以下に、moduleを使用したディレクトリ構成の例を示します。
/terraform-project
│── main.tf # moduleの呼び出し側(root module)
│── outputs.tf # ここでoutputを定義する必要がある
│── variables.tf
│── terraform.tfstate
│
└── modules
├── app
│ ├── main.tf # module appのリソース定義
│ ├── outputs.tf # modele app内でのみ有効
│ ├── variables.tf
│ └── terraform.tfstate
│
├── db
│ ├── main.tf # module dbのリソース定義
│ ├── outputs.tf # module db内でのみ有効
│ ├── variables.tf
│ └── terraform.tfstate
│
└── network
├── main.tf # module networkのリソース定義
├── outputs.tf # module network内でのみ有効
├── variables.tf
└── terraform.tfstate
この構成では、modules/app/outputs.tf
にoutputを定義しても、その値はterraform_remote_stateから直接参照することはできません。
そのため、root moduleのoutputs.tf
に、module内のoutputを渡してあげるためのoutputを定義する必要があります。
moduleについては、次の記事で解説しています。
【Terraformハンズオン】Terraformでモジュールを作成してみよう
terraform_remote_stateハンズオン
ここからは、VPCとEC2の構築するハンズオンを行います。
本番環境と検証環境でディレクトリを分け、本番環境で作成したVPCの値を検証環境で使用します。
前提条件
このセクションでは、リモートバックエンドを使用してリソースを構築します。
リモートバックエンドを使った環境構築は、以下の記事で解説していますので参照ください。
Terraform AWS S3リモートバックエンドを用いてtfstateを管理してみよう
ディレクトリ構成
ディレクトリ構成は次のように構成しています。
├── prod # 本番環境
│ ├── versions.tf
│ ├── outputs.tf # vpcとsubnetの値を出力
│ └── vpc.tf # vpcとsubnetを作成
└── stg # 検証環境
├── versions.tf
└── ec2.tf # prodのremote_stateを取得する
prodディレクトリ
使用するTerraformのバージョン、AWSプロバイダの情報などはversions.tf
を作成します。
# versions.tf
terraform {
required_version = ">= 1.0.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.67.0"
}
}
backend "s3" {
bucket = "test-terraform" # 任意の作成済みバケットを指定
key = "prod/vpc/terraform.tfstate" # バケット内のパスを指定 remote_stateで使用するパスになる
region = "ap-northeast-1"
}
}
provider "aws" {
region = "ap-northeast-1"
}
vpc.tf
を作成し、VPCとsubnetを作成します。
# vpc.tf
# ------------------------------
# VPC
# ------------------------------
resource "aws_vpc" "common_vpc" {
cidr_block = "10.0.0.0/16"
enable_dns_support = true
enable_dns_hostnames = true
}
resource "aws_subnet" "public_a" {
vpc_id = aws_vpc.common_vpc.id
cidr_block = "10.0.1.0/24"
availability_zone = "ap-northeast-1a"
map_public_ip_on_launch = true
}
outputs.tf
を作成し、VPC、subnetの情報を出力します。
# outputs.tf
output "common_vpc_id" {
value = aws_vpc.common_vpc.id
}
output "public_subnet_a_id" {
value = aws_subnet.public_a.id
}
この状態でinitを実行し、プロジェクトを初期化します。
terraform init
init完了後、applyを実行します。
terraform apply
apply後にoutputs.tf
に記載した値がターミナルに出力されます。
Outputs:
common_vpc_id = "vpc-068411b1c46d248c4"
public_subnet_a_id = "subnet-022ef95ad62531d5d"
詳しくは後述しますが、remote_stateではoutputで出力されたkeyを指定して、値を使用します。
stgディレクトリ
続いてstgディレクトリもprodと同様、versions.tf
を作成します。
# versions.tf
terraform {
required_version = ">= 1.0.0"
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.67.0"
}
}
backend "s3" {
bucket = "test-terraform"
key = "stg/ec2/terraform.tfstate"
region = "ap-northeast-1"
}
}
provider "aws" {
region = "ap-northeast-1"
}
ec2.tf
では、terraform_remote_state
ブロックを作成してprodのtfstateの情報を取得します。
# ec2.tf
# ------------------------------
# AMI
# ------------------------------
data "aws_ami" "amazonlinux2_latest" {
owners = ["amazon"]
most_recent = true
filter {
name = "name"
values = ["amzn2-ami-hvm-2.0.*.0-x86_64-gp2"]
}
}
# ------------------------------
# reference remote state
# ------------------------------
data "terraform_remote_state" "common" {
backend = "s3"
config = {
bucket = "test-terraform"
key = "prod/vpc/terraform.tfstate" # ここでprodのbackend設定を読み込む
region = "ap-northeast-1"
}
}
# ------------------------------
# EC2
# ------------------------------
resource "aws_instance" "ec2" {
ami = data.aws_ami.amazonlinux2_latest.id
instance_type = "t2.micro"
# ここでremote_stateの値を使用する
subnet_id = data.terraform_remote_state.common.outputs.public_subnet_a_id
terraform_remote_stateの基本的な構文は次のようになります。
# 構文
data.terraform_remote_state.<NAME>.outputs.<RESOURCE NAME>
# 具体例 prod環境のpublic_subnet_a_idの値を取得
subnet_id = data.terraform_remote_state.common.outputs.public_subnet_a_id
<NAME>
はdata "terraform_remote_state" "common"
のcommon
の部分を指定し、<RESOURCE NAME>
はoutputで出力したkeyを指定します。
ファイルの作成が完了したら、prodの時と同様、initを実行し、applyします。
terraform init
terraform apply
まとめ
この記事では、Terraformのデータソースの1つであるterraform_remote_stateについて解説しました。
terraform_remote_stateを利用することで、Terraformの異なるプロジェクト間でtfstate
の情報を共有し、リソースのIDや設定情報を参照できます。
大きいプロジェクトなどではerraform_remote_stateを使用して構築する場面もあるため、この記事を参考に手を動かしていただき、terraform_remote_stateの理解を深めていただければと思います。
参考記事
The terraform_remote_state Data Source
tfstateファイルについての基礎 コアやプロバイダ、tfstateファイルの役割について理解しよう
【Terraformハンズオン】Terraformでモジュールを作成してみよう
【番外編】USBも知らなかった私が独学でプログラミングを勉強してGAFAに入社するまでの話

プログラミング塾に半年通えば、一人前になれると思っているあなた。それ、勘違いですよ。「なぜ間違いなの?」「正しい勉強法とは何なの?」ITを学び始める全ての人に知って欲しい。そう思って書きました。是非読んでみてください。
「フリーランスエンジニア」
近年やっと世間に浸透した言葉だ。ひと昔まえ、終身雇用は当たり前で、大企業に就職することは一種のステータスだった。しかし、そんな時代も終わり「優秀な人材は転職する」ことが当たり前の時代となる。フリーランスエンジニアに高価値が付く現在、ネットを見ると「未経験でも年収400万以上」などと書いてある。これに釣られて、多くの人がフリーランスになろうとITの世界に入ってきている。私もその中の1人だ。数年前、USBも知らない状態からITの世界に没入し、そこから約2年間、毎日勉学を行なった。他人の何十倍も努力した。そして、企業研修やIT塾で数多くの受講生の指導経験も得た。そこで私は、伸びるエンジニアとそうでないエンジニアをたくさん見てきた。そして、稼げるエンジニア、稼げないエンジニアを見てきた。
「成功する人とそうでない人の違いは何か?」
私が出した答えは、「量産型エンジニアか否か」である。今のエンジニア市場には、量産型エンジニアが溢れている!!ここでの量産型エンジニアの定義は以下の通りである。
比較的簡単に学習可能なWebフレームワーク(WordPress, Rails)やPython等の知識はあるが、ITの基本概念を理解していないため、単調な作業しかこなすことができないエンジニアのこと。
多くの人がフリーランスエンジニアを目指す時代に中途半端な知識や技術力でこの世界に飛び込むと返って過酷な労働条件で働くことになる。そこで、エンジニアを目指すあなたがどう学習していくべきかを私の経験を交えて書こうと思った。続きはこちらから、、、、
エンベーダー編集部
エンベーダーは、ITスクールRareTECHのインフラ学習教材として誕生しました。 「遊びながらインフラエンジニアへ」をコンセプトに、インフラへの学習ハードルを下げるツールとして運営されています。

関連記事

2024.09.22
【Terraformハンズオン】非同期呼び出しのLambda関数をデプロイしてみよう
こちらの記事では、Lambda関数の「非同期呼び出し」に焦点を絞って解説し、Terraformを使ったハンズオンを行います。
- AWS
- Terraform
- ハンズオン

2024.09.28
Trivyで実現するTerraformのセキュリティ強化 IaC脆弱性スキャンの方法
インフラのコード化による効率化が進みましたが、一方でコードに潜むセキュリティリスクも拡大しています。これらのリスクを管理するためには、適切なセキュリティスキャンを導入し、脆弱性を早期に発見することが重要です。
- サイバーセキュリティ
- インフラエンジニア
- Terraform

2024.09.28
【Terraformハンズオン】Lambda関数にレイヤーを追加してみよう
この記事では、Lambda関数の中でも「レイヤー」について解説し、記事後半ではIaCツールのTerraformを使ってハンズオン形式でレイヤーの作成方法と利用方法を学びます。
- AWS
- ハンズオン
- Terraform

2024.08.24
【Terraformハンズオン】NatGatewayを使ってプライベートな通信を実現してみよう
AWSを扱う実際の現場では、NAT Gatewayを使うことでより安全なインターネット通信を実現することができます。ぜひ一緒に理解を深めながら、Terraformでの実装方法を学んでいきましょう。
- AWS
- Terraform