ナレッジ

これからAWSを利用して新たなサービスを構築する企業に向けて、「どのような体制でAWSを利用開始するか」という意思決定の整理を目的とする。ここで扱うのは単なる契約形態ではなく、責任・運用・知見の配置を含めた体制設計である。

セキュリティ対策を一度構築して終わりにせず、運用担当者が定められた入口から安全に更新できる状態を作る。AWSとTerraformによる責務分離の考え方を、実装パターンへ展開できる形で整理する。

AWSにおけるアクセス制御はIAM（API操作レベル）とSecurity Group（ネットワーク通信レベル）の2レイヤーで構成される。アクセス先のサービスによってどちらが効くかが異なる。それぞれの役割の違いと、Terraformで一括管理する際の共通設計パターンを解説する。

レガシー技術には物理的な上限という暗黙のガードレールがあったが、クラウドにはそれがない。ファイルストレージ、サーバー、データベース、ログという4つの領域を例に、レガシーとクラウドネイティブで設計の前提がどう変わるかを読み解く。

オンプレミスでは「内側は安全、外側は危険」という境界の直感が成り立っていた。AWSではこの直感がそのまま通用しない。一般インターネット・AWSグローバルネットワーク・VPCプライベートネットワークの3つを区別し、「API認証」と「ネットワーク制限」が別のレイヤーであることを整理する。

AWSのサービスを組み合わせるたびに設計をやり直すと、プロジェクトごとに作りがばらつく。ECSを中心とするWebサービスを運用し続けるという目的の単位でTerraformを組み替え、環境ごとの記述を「宣言と配線」に絞る設計の考え方と、それを支える規則・品質の担保・運用の循環を解説する。

テスト環境や限定公開ページのBASIC認証について、運用担当がSSM Parameter Storeを入口としてパスワード更新できる構成を整理する。

踏み台サーバを、監査や緊急対応にも耐えられる運用入口として設計する構成を整理する。更新の仕組みは、操作できる画面で確かめられる。

コストの異変に気づくのが月末の請求書では遅い。Cost Explorer・Lambda・EventBridge Schedulerを組み合わせ、毎朝のコストをSlackへ通知する構成を解説する。通知文面や月次スレッド集約といった「読まれる通知」の設計まで固定化し、設定数個で導入できる形に整理した。

Amazon ECSのBlue/Greenデプロイには、CodeDeployに切替を任せる方式と、ECS自身が切替を行うネイティブ方式がある。承認の止め方、構成要素、インフラ管理とデプロイの責務分離の違いを整理し、選び方の判断軸を示す。

ECSの環境変数とシークレットを、インフラ管理値・運用設定値・機密値の3系統に分ける。タスク定義の値の指定方式とTerraformのstateの性質から、誰がどの値を変え、変更がいつ反映されるかを整理する。

ECSタスクの異常停止やデプロイ失敗は、CloudWatchの標準メトリクスには現れない。EventBridge・CloudWatch Logs・Metric Filterの3サービスを直列に束ね、イベントをメトリクス化して監視可能にする構成パターンを解説する。

プロジェクトで使用するIAMロール・ポリシー・ユーザー・グループをTerraformで一括管理する設計パターンを解説する。マネージドポリシーとインラインポリシーの使い分け、AWSクォータを踏まえた設計判断を紹介する。

CloudFront・ALB・VPC Flow Logsを調査に使える状態にするログ分析基盤の設計を解説する。ログを送る側（配送）と受ける側（格納・参照）を分離し、スキーマはGlue Crawlerの自動推定に頼らずTerraformで明示定義する。その設計判断の理由を中心に整理する。

運用管理画面にサービス名やARNを書くと、構成が変わるたびに画面の修正が要る。Terraformがモジュールの出力から接続情報を組み立ててLambdaへ渡し、画面は情報の形と状態の語彙だけを知る構成にすると、サービスやリソースの増減に画面を直さずに追従できる。CDの進捗をデプロイ方式ごとの段階で見せる設計、権限の導き方、AIが開発しやすい構造としての位置づけを解説する。

CloudFront continuous deployment（CloudFrontの継続的デプロイ）のヘッダー振り分けを使い、AIやスクリプトに本番ドメインからStagingの公開前の版を確認させる構成を整理する。人の確認は認証付きの確認用配信に分け、ヘッダーで届く経路を秘密として扱わない前提と、返った版を突き合わせる理由、運用で注意する点を示す。

Security Groupを一括管理し、リソース間の通信許可をSecurity Group IDの参照で設計するパターンを解説する。IPアドレスに依存せず、公開する入口を必要最小限に絞るネットワークアクセス制御の実践を紹介する。

VPCの中にあるサーバやデータベースへ人が入る方法を、「何に接続するか」「入口の性質」「認証と絞り込み」の3つの軸で整理する。SSHか踏み台かの二択にせず、公開しなくても届く手段から検討する順序を示す。

運用操作をCloudWatchダッシュボードに載せると、実行者を記録できず、更新の単位もダッシュボードに従属する。この2つの境界を確認したうえで、AWS由来の設計システムCloudscapeで管理画面を再構成する設計判断を解説する。

ブラウザのポータルからVPNサーバーとデスクトップサーバーを起動・停止し、安全な経路でAWS上のデスクトップを利用する構成を解説する。スポットインスタンスと「使う時だけ起動する」運用で、常時稼働の数分の一のコストに抑える。各EC2の構成と、コスト・セキュリティの設計判断まで。