はじめに

このシリーズは、自分（フリーランスのインフラエンジニア）が AWS サーバレス + Terraform + GitHub Actions OIDC でポートフォリオサイト lab.iigtn.com を 0 から構築した記録です。

ただの「やってみた」ではなく、各ステップでの 設計判断・ハマりどころ・学び を残し、後から自分や他人が追えるようにしました。本記事はその序章。なぜ作ったのか、どういう方針で進めたのかを書きます。

想定読者:

AWS は触ったことがあるが、本格的なサーバレス + IaC 構築は未経験のエンジニア
Terraform を「コピペで動かしている」段階から、設計判断ができるようになりたい人
個人ポートフォリオを作りたいフリーランス・インフラエンジニア
採用担当として「実運用できる人」を見極める材料を探している人

この記事で分かること:

AWS サーバレスポートフォリオを構築する動機と設計思想
「壊れない構成」より「壊れたら気付ける構成」という方針
シリーズ全体で扱うハマりどころの先出し

環境

OS: Windows 11
AWS リージョン: ap-northeast-1（一部 us-east-1）
IaC: Terraform
CI/CD: GitHub Actions OIDC

このシリーズで作るもの

最終的にできたのは、こんなサイトです。

URL: https://lab.iigtn.com/
ホスティング: AWS S3 (非公開バケット) + CloudFront (CDN) + ACM (TLS 証明書)
API: API Gateway HTTP API + Lambda (Node.js 20) + DynamoDB
メール送信: SES（問い合わせ通知）
監視: CloudWatch Alarms + SNS + AWS Budgets
IaC: Terraform 100%
CI/CD: GitHub Actions OIDC（静的アクセスキーゼロ）

個人サイトとしては「やや過剰」なくらいですが、これは 採用評価のためのサンプル構成 として意図的に組んだものです。月額 200〜400 円程度で 5 年放置できる構成になっています。

なぜポートフォリオサイトを作るのか

フリーランスのインフラエンジニアとしての信用は、スキルセットの羅列より 「運用が止まっていない事実」 で証明されます。それを示すには 4 つの素材が必要だと考えました:

動いているサイト本体（外形監視で 200 を返している事実）
Terraform State と CloudWatch ログ（実際に運用している証拠）
設計判断の記録（なぜこの構成にしたか／何を捨てたか）
失敗ログ（壊れた時にどう対処したか）

本サイトはこの 4 つを 1 セットで持つように設計しました。

設計思想 4 本柱

構築前に 4 つの方針を立てました。これがすべての判断の基準になっています。

柱	意味
構造の透明性	全構成を Terraform で表現し、「なぜこの構成か」を口頭で説明できる状態に保つ
運用の継続性	月額数百円〜数千円で 5 年運用しても破綻しないコスト構造
拡張の自由度	後から認証・決済・SaaS 化を足しても破綻しない疎結合設計
評価軸への適合	IaC / CI/CD / セキュリティ / 可観測性の 4 点を採用担当が読み取れる

キーワードは「壊れない構成」より「壊れたら気付ける構成」

個人運用のインフラで一番怖いのは 「壊れているのに気付かない」 状態です。だから、可能な限り壊れない構成を目指すよりも、壊れた瞬間に通知が飛んでくる構成 を優先しました。

具体的には:

CloudWatch Synthetics or Alarms で外形監視
SNS topic + メール購読で即時通知
Lambda エラー率 / API 5xx / CloudFront 4xx 率すべてに閾値アラーム
AWS Budgets で月額予算超過アラート（攻撃や設定ミスの早期検知）

これらを最初から仕込み、サイト立ち上げと同時に「壊れたら気付ける」状態を確保しました。

このシリーズの構成（全 21 記事）

1 つの記事に詰め込みすぎず、構築の各フェーズを 1 記事ずつに分解しました。各記事は 3,500〜4,500 文字、最後に 用語集 を付けています。

序章 (本記事)
ChatGPT との 6 ラウンド設計レビュー
AWS マルチアカウント運用と IAM 設定
開発環境セットアップ
Terraform Bootstrap（鶏卵問題の解決）
Windows での provider TLS 干渉と回避
… 以下続く（全 21 記事）

最終回は 付録「構築で使ったコマンド早見表」。PowerShell / Git / AWS CLI / Terraform の頻出コマンドをまとめます。

この先のシリーズで扱うハマりどころ（先出し）

個人で AWS を触ると、必ずハマる「あるある」をいくつか先出ししておきます。本シリーズでは、これらを発生時系列で解説します。

Windows + Git Bash で terraform init 時に TLS bad record MAC が出てプロバイダがダウンロードできない
Squarespace で管理されているドメインで NS 委譲ができない
CloudFront アラーム (us-east-1) を作ろうとすると別 region の SNS が使えない
SES が sandbox から出ないと送信元 / 送信先の両方を verify する必要がある
IAM Role の description は ASCII / Latin-1 のみ（日本語不可）

これらは「知らないと半日溶ける」系の罠です。記事の中で、何が起きたのか・どう解決したのかを正直に書きます。

用語集

AWS (Amazon Web Services): Amazon が提供するクラウドコンピューティングサービス群。本シリーズではほぼすべてのインフラを AWS で構築する。
サーバレス (Serverless): 「サーバを自分で管理しない」アーキテクチャの総称。OS パッチ・容量管理・台数調整を AWS 側に任せる。Lambda / API Gateway / S3 / DynamoDB などが代表例。
S3 (Simple Storage Service): AWS のオブジェクトストレージ。HTML / CSS / 画像などのファイルを格納する。本サイトでは静的サイトファイルの保管に使用。
CloudFront: AWS の CDN（Content Delivery Network）。世界中の Edge ロケーションにファイルをキャッシュし、訪問者に最寄りの拠点から配信する。HTTPS 終端も担当。
ACM (AWS Certificate Manager): AWS の TLS 証明書管理サービス。パブリック証明書は無料。CloudFront にアタッチする証明書は仕様上 us-east-1 リージョンで発行する必要がある。
API Gateway: HTTP リクエストを受け付けて Lambda などのバックエンドに振り分けるマネージド API サービス。HTTP API と REST API の 2 種類があり、本シリーズでは安価な HTTP API を使用。
Lambda: AWS のサーバレス関数実行サービス。アクセスがない時は完全無料、リクエスト発生時のみ実行され課金される。
DynamoDB: AWS のフルマネージド NoSQL データベース（KVS）。スキーマレスで自動スケール。On-demand モードならアクセス薄い時はほぼ 0 円。
SES (Simple Email Service): AWS のメール送信サービス。新規アカウントは sandbox 状態（検証済アドレスにしか送信できない）から始まる。
CloudWatch: AWS の監視・ログ・メトリクス・アラームを統合する観測サービス。
SNS (Simple Notification Service): AWS のメッセージ通知ハブ。メール / SMS / Lambda などにイベントを配信できる。CloudWatch Alarm の通知先によく使う。
AWS Budgets: 月額予算を設定して超過時にメール通知する AWS 標準機能。攻撃や設定ミスによるコスト爆発の早期検知に必須。
IaC (Infrastructure as Code): インフラ構成をコードで記述・管理する手法。本シリーズでは Terraform を使用。
Terraform: HashiCorp が開発する IaC ツール。AWS だけでなく GCP / Azure などマルチクラウドに対応。
OIDC (OpenID Connect): 認証連携の業界標準プロトコル。GitHub Actions と AWS の間で短期トークン（JWT）をやり取りし、静的アクセスキーなしで AWS リソースにアクセスできる。
JWT (JSON Web Token): OIDC で発行される署名付きトークン。「誰が・どこから・どんな目的で」というクレーム（claim）を含む。
CDN (Content Delivery Network): 世界中の拠点（Edge）にコンテンツをキャッシュし、訪問者に最寄りから配信する仕組み。CloudFront はその代表例。
外形監視: サイトの URL を定期的に外側から叩いて応答を確認する監視方式。AWS では CloudWatch Synthetics で実装できる。
採用評価: 本シリーズでの中心的な目的。フリーランスとしての案件獲得・採用面接で「この人は実際に AWS を運用できる」と判断されるための材料を残すこと。

まとめ

フリーランス・インフラエンジニアとしての信用は「運用が止まっていない事実」で示す。
設計思想は「構造の透明性 / 運用の継続性 / 拡張の自由度 / 評価軸への適合」の 4 本柱。
個人運用では「壊れない構成」より「壊れたら気付ける構成」を優先する。
本シリーズではハマりどころも含めて時系列で記録していく。

参考リンク