2026-04-25 · 構築日誌 #01

序章 — フリーランスのインフラエンジニアが AWS でポートフォリオを作る理由

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

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

このシリーズで作るもの

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

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

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

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

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

本サイトはこの 4 つを 1 セットで持つように設計しました。コードは GitHub に置き（現在は private、追って public 化検討）、構築解説書は /learn.html として公開しています。

設計思想 4 本柱

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

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

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

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

具体的には:

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

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

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

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

想定読者

このシリーズは、こんな人を想定しています:

逆に、AWS や Terraform の基本コマンドは知っている前提で書きます。「terraform init って何？」というレベルの説明は省きますが、各記事の最後に 用語集 を付けるので、知らない単語が出てきたらそこで補完してください。

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

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

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

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

次の記事

次の記事では、構築前に ChatGPT と 6 ラウンドの設計レビュー をして設計書を v1 → v5 に磨き込んだ過程を書きます。「凝った構成より運用が回る構成」という考え方が、レビューでどう変わっていったかが見えるはずです。

📚 用語集

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 を運用できる」と判断されるための材料を残すこと。