AWS無料枠・ポートフォリオ
AWSポートフォリオでサーバーレス構成を選ぶ理由
個人開発ポートフォリオでS3、CloudFront、API Gateway、Lambda、DynamoDBを選ぶ理由を整理します。
AWSを使ったポートフォリオを作るとき、最初からEC2やRDSで本格的な構成を作る必要はありません。個人開発MVPでは、サーバーレス構成が現実的です。
結論
静的コンテンツ中心の学習サイトなら、S3 + CloudFrontを中心にし、必要な動的処理だけAPI Gateway + Lambda + DynamoDBで作る構成が合っています。
固定費を避けられる
個人開発で一番怖いのは、使っていないのに料金が発生し続ける構成です。EC2、RDS、NAT Gateway、ALBは学習価値がありますが、MVPでは固定費や停止忘れのリスクがあります。
サーバーレス中心にすると、アクセスが少ない段階では低コストに抑えやすくなります。
AWS資格の学習と直結する
S3、CloudFront、Lambda、API Gateway、DynamoDB、IAM、CloudWatchは、Cloud PractitionerでもSAAでも重要です。
この構成を自分で作ると、資格知識を単なる暗記ではなく、実装経験として説明できます。
面接で説明しやすい
ポートフォリオでは、作ったもの以上に「なぜその設計にしたか」を説明できることが重要です。
たとえば、S3を直接公開せずCloudFront OACを使った、問い合わせだけDynamoDBに保存した、GitHub ActionsはOIDCで最小権限にした、という説明は評価されやすいポイントです。
MVPに合っている
学習サイトは、用語集、比較記事、模擬問題、構成図、ブログのような静的コンテンツが中心です。これらはS3 + CloudFrontで配信できます。
問い合わせフォームだけはユーザー入力を保存する必要があるため、API Gateway + Lambda + DynamoDBで動的処理にします。
注意点
サーバーレスでも何も考えなくてよいわけではありません。CORS、IAM、ログ、DynamoDBキー設計、CloudFrontキャッシュ、課金監視は必要です。
公開後の確認を成果物に残す
公開後は、静的ページの配信、フォーム送信、Lambda の request ID、DynamoDB の保存結果、CloudWatch Logs のエラー分類を一連で確認します。失敗時にどの順序で切り分けるか、CI と実行ロールがどの権限を持つか、ログに個人情報を残さない理由を README に記録すると、構成図だけでは伝わりにくい運用判断もポートフォリオの成果として示せます。
構成ごとの責務を説明できるようにする
静的なフロントエンドは S3 に置き、利用者には CloudFront 経由で配信します。問い合わせや登録のような動的処理は API Gateway が HTTP の入口となり、Lambda が入力を検証して DynamoDB に保存します。CloudWatch は実行ログとメトリクスを確認する場所です。サービスを増やすことが目的ではなく、それぞれの責務を説明できる範囲で使うことがポートフォリオでは重要です。
S3 はファイル保管、CloudFront は配信、API Gateway は HTTP 境界、Lambda はイベントに応じた短い処理、DynamoDB はアクセスパターンに合わせたデータ保存を担います。AWS Lambda とは でイベント駆動の実行モデルを確認し、AWS Well-Architected Framework の観点を使って、セキュリティ、信頼性、運用、コストの判断理由を書き出します。
小規模でも、なぜそのサービスを選び、何をまだ採用していないかを説明できれば、単に構成図のサービス名を並べるより実装経験が伝わります。たとえば、まずは問い合わせAPIを1本作り、必要になった段階で通知や管理画面を増やす方針は、運用の複雑さを段階的に増やす判断です。
利用者リクエストを経路で追う
利用者がサイトへアクセスすると、DNS と CloudFront を経由して静的ファイルが返ります。HTML、JavaScript、CSS はキャッシュから配信される場合もあります。フォーム送信では、ブラウザが API Gateway の POST エンドポイントへ JSON を送り、Lambda が型・文字数・許可値を検証して DynamoDB に記録します。
静的配信と API 呼び出しの境界を明確にします。S3 を公開バケットとして直接配信するのではなく CloudFront を経由する構成なら、S3 側は配信元だけに読取りを許可する設計を検討できます。API Gateway は許可するメソッド、ルート、Origin、認証の有無を明示します。ブラウザの入力検証だけを信用せず、Lambda 側で同じルールを再検証します。
画面で失敗が起きたら、CloudFront の配信、CORS、API Gateway のルート、Lambda の例外、DynamoDB の権限を順に確認します。request ID、デプロイ時刻、リリースバージョンをログに残せば、リクエストがどこまで到達したかを追えます。
デプロイとOIDCの境界を分ける
フロントエンドはビルドした静的ファイルを S3 に配置し、必要な場合だけ CloudFront のキャッシュを無効化します。バックエンドはインフラ定義と Lambda コードをデプロイし、エンドポイント、環境変数、IAM ロールが期待どおりかを確認します。この二つを分けると、画面変更と API 変更の影響範囲を切り分けやすくなります。
GitHub Actions などの CI から AWS へ反映する場合は、長期的なアクセスキーをリポジトリに保管するより、OIDC を通じて実行時に限定ロールを引き受ける構成を検討します。信頼条件では、リポジトリ、ブランチ、環境を必要な範囲に絞ります。どのリポジトリからでも本番ロールを引き受けられる設定や、feature branch まで本番更新を許す設定は避けます。
CI のデプロイロールと Lambda 実行ロールは同じにしません。CI には変更を反映する権限、Lambda には問い合わせ保存など実行時に必要な最小権限だけを持たせます。境界を分けると、関数の問題と CI 設定の問題で影響範囲を限定できます。
最小権限と秘密情報の扱い
Lambda の実行ロールには、対象 DynamoDB テーブルへの PutItem など必要な操作だけを付与します。一覧表示がなければ Scan を安易に足さず、CloudFront から S3 を読む権限も対象バケット・プレフィックスに絞ります。AccessDenied が出たときは CloudWatch Logs のエラーと IAM の Action・Resource を照合し、必要な1操作を追加します。
動作確認のために AdministratorAccess を付け、そのまま残すのはよくある失敗です。何が本当に必要な権限か分からなくなり、コードや設定の問題が起きたときの影響も広がります。権限を増やす前に失敗した API 呼び出しを特定し、最小化したポリシーとして残します。
Secrets や API キーを静的サイトの JavaScript に埋め込むことも避けます。ブラウザへ配信したコードは誰でも確認できるため、秘密として保持できません。外部サービスの認証情報が必要な処理は Lambda 側に置き、参照できるロールと実行環境を限定します。
コストガードレールを公開前に置く
個人開発では、予算通知、請求ダッシュボード、CloudWatch Logs の保持設定、CloudFront と API のアクセス状況を公開前の確認項目に含めます。AWS Budgetsで個人開発の課金事故を防ぐ では、通知が必要になる場面と設定の考え方を確認できます。
料金や利用制限は、アカウント、リージョン、利用状況、提供条件で変わります。「無料枠内に必ず収まる」「このアクセス数までは固定で無料」とは断定せず、公開前と構成変更時に公式の料金ページとコンソール表示を確認します。ログ出力、データ転送、キャッシュ無効化、想定外の API 呼び出しは、実装量が少なくても見落としやすい対象です。
通知しきい値は、超過後に知らせるだけでなく、調査して停止・制限・設定変更を判断できる余地を持たせるために決めます。公開後も実際のアクセスがあった日の利用状況とログ量を確認し、想定との違いを記録します。
監視と障害対応の入口を作る
CloudWatch Logs には、Lambda の request ID、処理結果、エラー分類、処理時間を構造化して出力します。問い合わせ本文やメールアドレスを丸ごと残さず、調査に必要な識別子と状態を記録します。API Gateway の 4xx と 5xx、Lambda の例外、DynamoDB の権限エラーを分けて見られると、画面の送信失敗から原因を追いやすくなります。
アラームは障害の兆候を早く知るために使います。ただし入力ミスまで緊急通知にすると、重要な例外を見逃しやすくなります。入力不備は集計対象、Lambda の例外や継続的な 5xx は調査対象、といった運用の区別を決めます。具体的なログ調査の順序はLambdaのログをCloudWatchで確認する方法を参照してください。
障害を経験したら、原因だけでなく、どのログがあれば短く切り分けられたか、どの権限が広すぎたかを記録します。README や設計メモに障害時の調査手順も残すと、再現できるポートフォリオになります。
CLFとSAAの学習に結び付ける
Cloud Practitioner（CLF）では、各サービスの役割、責任共有モデル、料金の考え方、監視の基本を説明できることが土台です。S3、CloudFront、Lambda、DynamoDB、CloudWatch がどの課題を解くかを、構成図とリクエストフローに結び付けて理解します。
Solutions Architect Associate（SAA）では、可用性、セキュリティ、疎結合、コスト最適化を比較する判断が増えます。CloudFront を置く理由、S3 を非公開にする方法、API の認証境界、Lambda の失敗処理、DynamoDB のアクセスパターンを、自分で作った小さな機能で説明できるようにします。
よくある誤解と失敗例
「サーバーレスなら運用コストはゼロ」という誤解は危険です。OS の保守の一部は AWS に委ねられますが、権限、ログ、監視、コスト通知、障害時の判断は利用者側の責任です。「S3 を公開すれば速い」「CORS を * にすれば動く」という短絡も、公開範囲を広げる失敗につながります。
最初はAWS無料枠でポートフォリオを作る方法を参考に小さく構築し、問い合わせAPIを追加したらAPI Gateway + Lambda + DynamoDBで問い合わせAPIを作る流れのように、入力検証、実行ロール、ログ、重複送信への注意まで確認します。動いた状態で終わらせず、失敗時にどこを調べるかまで残すことが実装経験になります。
関連用語
次に読む記事
次に学ぶ内容
ブログ記事だけでなく、AWS用語集・サービス比較・模擬問題・構成図を組み合わせると、資格知識と実装イメージをつなげて理解できます。