クラウドエンジニア転職のポートフォリオ例｜構成図・IaC・運用設計

クラウド転職のポートフォリオは、実務未経験者が学習内容を具体化する用途で有効です。ただし、商用環境の実務経験の代わりではなく、構成図、IaC、試験、監視、復旧、READMEを一つの設計として説明する資料です。

この記事では、AWSを例に7つの成果物、Terraformの見せ方、正常性の証跡、障害時の切り戻し、公開してはいけない情報、面接での5分説明まで掲載します。

✓この記事でわかること

• クラウド転職でポートフォリオは必要？
• 採用担当者へ見せる7つの成果物は？
• 面接で5分間にどう説明する？
• AWS構成図には何を描く？

このページはクラウドエンジニア転職完全ガイドの各論です。転職の進め方を最初から確認する場合はそちらへ。

クラウド転職でポートフォリオは必要？

実務経験が十分にある人は、職務経歴書で担当工程と成果物を説明できるため、ポートフォリオが必須とは限りません。一方、未経験者やクラウド実務が浅い人は、知識だけでは見えない「構成を考え、設定し、確認し、片付ける」過程を示せます。ただし、個人検証は顧客調整、本番変更、障害責任の経験を証明しません。

サーバー・ネットワークを含むポートフォリオ全体の考え方は、インフラエンジニア転職のポートフォリオ例で扱っています。本記事はクラウド構成とIaC、運用設計に焦点を当てます。

採用担当者へ見せる7つの成果物は？

成果物は、構成図やコードを単品で置かず、要件から運用まで追える7点セットにします。採用担当者や現場面接官が短時間で確認できる順に並べると、説明しやすくなります。

AWS構成図には何を描く？

構成図には、AWSアイコンだけでなく、利用者からアプリ・DBまでの通信方向、Public／Private subnet、Availability Zone、管理経路、ログ・監視、Terraform stateの保管先を描きます。次の図は、ALB、EC2、RDSを2つのAZへ配置し、CloudWatch、S3、GitHub Actions、Terraformとの関係を示した仮想例です。

図の通信フロー

1. 利用者はHTTPSでApplication Load Balancer（ALB）へ接続する。
2. ALBは、target groupで正常と判定されたアプリ用EC2へ転送する。
3. アプリ用EC2は、DB用Security Groupで許可されたポートだけを使ってRDSへ接続する。
4. EC2、ALB、RDSのメトリクスとログをCloudWatchで確認し、条件に応じて通知する。
5. Terraformのstateはアプリデータ用S3と分け、専用S3 backendで管理する。

構成図と一緒に書く設計判断

Terraformのディレクトリとコードはどう見せる？

コードは1ファイルへ詰め込まず、ネットワーク、コンピュート、DB、監視の責任範囲で分けます。次はREADMEからたどりやすい構成例です。実際のリポジトリには、使用したTerraform CLIと事業者のバージョン、実行環境も記載します。

cloud-portfolio/
├── README.md
├── docs/
│   ├── requirements.md
│   ├── architecture.png
│   ├── design-decisions.md
│   ├── operations.md
│   └── test-results.md
└── infra/
    ├── versions.tf
    ├── backend.tf
    ├── variables.tf
    ├── network.tf
    ├── security-groups.tf
    ├── alb.tf
    ├── compute.tf
    ├── rds.tf
    ├── monitoring.tf
    ├── outputs.tf
    └── terraform.tfvars.example

S3 backendの設定例

次は学習用の設定例です。bucketは事前に作成し、実在する一意の名前へ置き換えます。stateには機微情報が含まれることがあるため、公開リポジトリへcommitしません。

terraform {
  required_version = ">= 1.10.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }

  backend "s3" {
    bucket       = "replace-with-private-state-bucket"
    key          = "cloud-portfolio/dev/terraform.tfstate"
    region       = "ap-northeast-1"
    encrypt      = true
    use_lockfile = true
  }
}

provider "aws" {
  region = "ap-northeast-1"
}

HashiCorpのS3 backendはuse_lockfile = trueでS3 lockfileによるstate lockingを有効化できます。DynamoDBを使う従来のlocking設定は公式ドキュメントでdeprecatedとされています。S3 bucket側でもバージョンing、Block Public Access、暗号化、最小権限のIAMを設計し、state本体とlockfileに必要な権限を分けます。

出典：HashiCorp Developer「Backend Type: s3」

Security Groupの設定例

次の抜粋は、図のALB、アプリ、DB間のSecurity Group参照関係を示す例です。これだけで図全体を構築できる完全なコードではありません。実際のポートフォリオでは、VPC、subnet、route、ALB、EC2、RDS、監視を含む全コードと変数定義をそろえます。

resource "aws_security_group" "alb" {
  name        = "portfolio-alb-sg"
  description = "Security group for ALB"
  vpc_id      = aws_vpc.main.id
}

resource "aws_security_group" "app" {
  name        = "portfolio-app-sg"
  description = "Security group for application"
  vpc_id      = aws_vpc.main.id
}

resource "aws_security_group" "db" {
  name        = "portfolio-db-sg"
  description = "Security group for database"
  vpc_id      = aws_vpc.main.id
}

resource "aws_vpc_security_group_ingress_rule" "alb_https" {
  security_group_id = aws_security_group.alb.id
  description       = "HTTPS from internet"
  ip_protocol       = "tcp"
  from_port         = 443
  to_port           = 443
  cidr_ipv4         = "0.0.0.0/0"
}

resource "aws_vpc_security_group_egress_rule" "alb_to_app" {
  security_group_id            = aws_security_group.alb.id
  description                  = "Application traffic to EC2"
  ip_protocol                  = "tcp"
  from_port                    = 8080
  to_port                      = 8080
  referenced_security_group_id = aws_security_group.app.id
}

resource "aws_vpc_security_group_ingress_rule" "app_from_alb" {
  security_group_id            = aws_security_group.app.id
  description                  = "Application traffic from ALB"
  ip_protocol                  = "tcp"
  from_port                    = 8080
  to_port                      = 8080
  referenced_security_group_id = aws_security_group.alb.id
}

resource "aws_vpc_security_group_egress_rule" "app_to_db" {
  security_group_id            = aws_security_group.app.id
  description                  = "PostgreSQL traffic to RDS"
  ip_protocol                  = "tcp"
  from_port                    = 5432
  to_port                      = 5432
  referenced_security_group_id = aws_security_group.db.id
}

resource "aws_vpc_security_group_ingress_rule" "db_from_app" {
  security_group_id            = aws_security_group.db.id
  description                  = "PostgreSQL traffic from application"
  ip_protocol                  = "tcp"
  from_port                    = 5432
  to_port                      = 5432
  referenced_security_group_id = aws_security_group.app.id
}

Security Group本体とruleを分けることで、ALBとアプリの相互参照を本体のinline ruleへ書いた場合に起こり得るTerraformの依存サイクルを避けています。この例ではインターネットからDBへ直接到達できません。ただし、必要なDNS・HTTPS通信などのegress、IPv6、管理経路、VPC endpoint、ネットワークACLは別途追加・確認が必要です。「Security Groupを設定したから安全」と断定せず、通信方向と残る経路を構成図と試験表で確認します。

plan・apply・正常性の証跡はどう残す？

Terraformの証跡は、成功した画面だけでなく、どのcommitを、誰が、どのplanで確認し、適用後に何を試験したかまで残します。terraform planは変更案を作るコマンドであり、それだけでは変更を実行しません。

terraform init
terraform fmt -check
terraform validate
terraform plan -out=tfplan
terraform show -no-color tfplan > plan.txt

# applyはAWSリソースを変更し、費用が発生する可能性がある。
# 自分の検証アカウントでplanをレビューしてから実行する。
terraform apply tfplan

記事へ架空の成功結果を載せるのではなく、次の記録欄を用意し、自分の実行結果で埋めます。Account ID、ARN、IP、秘密情報は公開前にマスクしてください。

実行日時:
Git commit:
Terraform CLI / AWS provider:
実行者のIAM role:
planの追加・変更・削除件数:
意図しないreplace / destroyの有無:
レビュー者・指摘:
apply結果:
ALB target health:
HTTPS応答:
CloudWatch alarm状態:
削除結果:
未実施項目:

ALBのヘルスチェックは経路、interval、timeout、正常・異常判定回数などを設定します。AWS公式ドキュメントでは、全有効AZの全対象が同時にunhealthyになった場合、ALBはfail openとして全対象へ転送し得ると説明されています。「ヘルスチェックに失敗すれば必ず通信が止まる」と書かず、障害時の挙動まで確認します。

出典：HashiCorp Developer「terraform plan command reference」「terraform apply command reference」、AWS Documentation「Health checks for Application Load Balancer target groups」

監視・バックアップ・障害対応をどう設計する？

運用設計では、メトリクス名だけでなく、なぜ監視するか、どの条件で通知するか、通知後に誰が何を確認するかを決めます。RTOは復旧までに許容する時間、RPOはどの時点までデータを戻せればよいかを示す目標です。

仮想システムの運用要件例

次は学習用の仮想要件であり、本番環境へそのまま使う推奨値ではありません。

• サービス提供時間：平日の日中
• RTO：障害検知から60分以内に利用再開
• RPO：24時間以内のデータ損失に抑える
• 一次対応：アラーム受信後にALB、EC2、RDSの順で状態とログを確認
• 復旧できない場合：構成変更を止め、直前のplan、アプリログ、DB状態を添えて上位者へ連絡

CloudWatch alarmは、メトリクスまたは数式を一定期間の閾値と比較し、状態に応じてactionを実行できます。閾値は他社の例をコピーせず、自分の正常時データと運用要件から決めます。学習環境では、意図的にサービスを停止して検知から復旧までを記録しますが、本番環境で無断実施してはいけません。

Amazon RDSの自動バックアップは、設定した保持期間に従って保存され、その期間内の時点へ復元できます。復元試験では「バックアップがある」だけで終えず、別DBとして復元し、アプリが必要なデータを確認できるかまで記録します。DB削除時の自動バックアップ保持と、手動・最終スナップショットの扱いも分けます。

出典：AWS Documentation「Using Amazon CloudWatch alarms」「Introduction to backups」

失敗時の切り戻しはどう書く？

「Terraformでロールバックする」と一文で済ませず、インフラ設定、アプリ、データを分けます。Terraformにはあらゆる変更を一括で元へ戻す単一の切り戻しコマンドがあるわけではありません。

適用が途中で失敗した場合も、すぐに過去のstateファイルを上書きせず、実リソースとstateの差、失敗したリソース、依存関係、業務影響を確認します。削除や再作成を伴う操作は、自分の検証環境でもplanとバックアップを確認してから実行してください。

検証環境が用意できない場面での確認項目や切り戻しの考え方は、設計構築チャンネルの解説動画も参考になります。

READMEへ何を書き、何を公開しない？

READMEは面接官が最初に見る入口です。構成図、コード、試験、運用設計へ迷わず移動でき、再現条件と未実施項目が分かる順にします。

1. 目的：どの求人・工程を想定した検証か
2. 仮想要件：利用者、通信、可用性、RTO・RPO、費用上限
3. 構成図・通信フロー：境界、AZ、subnet、管理経路
4. 採用理由：代替案と選ばなかった理由
5. 前提バージョン：Terraform、provider、CLI、リージョン
6. 作成手順：init、plan、レビュー、apply
7. 試験結果：正常・異常、実施日時、未実施項目
8. 運用：監視、通知、バックアップ、復元、障害対応
9. 削除：destroy前確認、残存リソース、費用確認
10. 制約：個人検証で証明できない実務範囲

公開してはいけない情報

• AWS access key、secret、session token、秘密鍵
• terraform.tfstate、保存したplanファイル、機微情報を含むログ
• 実在顧客の名称、IP、構成、アカウントID、ARN
• 私用・業務用メールアドレスや通知先
• パスワード、DB接続文字列、API token

.gitignoreだけへ頼らず、commit履歴も確認します。誤って秘密情報を公開した場合は、ファイルを消すだけでなく、該当credentialを失効・再発行し、履歴からの削除と影響確認を行います。

悪い例を採用担当者が読める完成例へどう直す？

サービス名を増やすより、設計と確認のつながりを補います。次の表は、ポートフォリオの記載を改善する例です。

面接で5分間にどう説明する？

面接ではリポジトリを上から読み上げず、要件、判断、確認、失敗、実務との差の順に説明します。次の時間配分は一例です。

1. 0:00～0:40 目的と要件：想定利用者、RTO・RPO、予算、対象外を説明する。
2. 0:40～1:40 構成図：利用者からDBまでの通信とPublic／Private境界を説明する。
3. 1:40～2:30 Terraform：directory、state、planレビュー、適用権限を説明する。
4. 2:30～3:30 試験：正常系と、最も学びが大きかった異常系を一つずつ示す。
5. 3:30～4:20 運用：監視、通知、バックアップ、復元、費用管理を説明する。
6. 4:20～5:00 限界と次の学習：個人検証で証明できない実務と、応募求人で補う項目を話す。

質問には「触りました」ではなく、制約、選択、代替案、実行結果で答えます。Terraform経験の説明を深めたい場合は、Terraform経験を転職で示す方法も確認してください。作成前の学習順は、同日12時公開のクラウドエンジニア転職ロードマップで整理できます。

完成前に何をチェックする？

次の項目をすべて確認し、未実施は未実施と書きます。チェックが付かない項目を隠すより、理由と次の検証計画を示す方が説明の信頼性を保てます。

• 仮想要件と、個人検証であることを書いた
• AWS構成図へ通信方向、AZ、subnet、境界、監視を描いた
• サービスの採用理由と代替案を書いた
• Terraform CLI・事業者のバージョンを記録した
• stateとplanファイルを公開対象から除外した
• fmt、validate、plan、適用後の確認結果を実物で残した
• 正常系と異常系を最低1件ずつ実施した
• 監視条件、通知先、一次対応、完了条件を決めた
• バックアップからの復元を確認した
• インフラ設定とデータの切り戻しを分けた
• 削除後に残存リソースと費用を確認した
• 秘密情報、顧客情報、アカウント情報がないことを履歴まで確認した
• 5分で要件・判断・試験・限界を説明できる

ポートフォリオと実務経験をどう区別する？

ポートフォリオは、個人検証で設計と確認を再現した成果物です。職務経歴書では『検証』と明記し、商用環境での承認、停止影響、顧客調整、障害復旧を経験したようには書きません。

構成図とコードだけでは変更承認は出ない

実案件では、構成図とTerraformコードが正しくても、それだけで変更承認は得られません。変更対象、依存関係、利用者影響、試験項目、監視、切り戻し条件、作業者と承認者をそろえます。planの差分に意図しない交換があれば、適用を止めて原因を確認します。適用成功後も、ALBのターゲットのヘルス、アプリ応答、DB接続、ログ、アラームまで確認して初めて作業完了です。

ポートフォリオでは、この案件思考を小さく再現します。自分で作った仮想要件に対して、どの構成を選び、何をリスクとして残し、どう試験したかを書いてください。成功結果だけでなく、権限不足やヘルスチェック失敗の切り分けを残すと、操作手順ではなく判断過程を説明できます。ただし、個人検証を本番実務の経験として言い換えないことが前提です。

作ったポートフォリオを面接でどう説明するかはクラウドエンジニア転職の面接で扱っています。構成の選定理由を言葉にする段階です。

まとめ：AWS構成図・Terraform・運用設計を一式で示す

評価されるポートフォリオは、きれいな構成図だけでなく、要件、Terraform、plan、正常性確認、監視、バックアップ、障害時の切り戻しが対応しています。秘密情報を除き、5分で設計理由を説明できる状態にしてください。

まず既存の構成図へ通信方向と責任境界を書き足し、Terraformの実行記録テンプレートを自分の検証結果で埋めてください。最後に、個人検証で示せる範囲と示せない実務経験を分け、5分で説明できれば選考用の完成版です。

この記事の執筆・監修者

けんと＠設計構築チャンネル

ネットワーク設計構築エンジニア／インフラ転職コンパス編集者

30歳・IT未経験からSIerへ転職。ネットワークエンジニアとして、金融系・オフィス系ネットワークの設計・構築に携わり、PL・PMも経験。自身の未経験転職と現場経験をもとに、仕事内容・技術・キャリア・求人選びをわかりやすく解説しています。

YouTube登録者5,000人 Xフォロワー5,000人

執筆者プロフィール・編集方針