非機能要件チェックリスト

この章では、小〜中規模のWebシステム向けの非機能要件チェックリストについて学びます。これにより、可用性・性能・セキュリティ・運用など、システム設計時に押さえるべき観点が理解できます。

各項目には対応の優先度を設定しており、プロジェクトの規模やフェーズに応じてどこに力を入れるべきかを判断できるようにしています。

チェック項目は特定のベンダー・言語・フレームワークに限定せず、汎用的な観点として整理していますが、対策例（構成例・施策例）はAWSを中心に記述しています。他のクラウドサービスやオンプレミス環境で活用する場合は、同等の代替サービスに読み替えてご参照ください。

なお、あらゆる規模・領域を網羅するとチェックリストが冗長になり実用性が下がるため、超大規模システム（マルチリージョン展開・データレジデンシー対応・セキュリティ認証取得など）、スマートフォンアプリケーション、制御系・組込みシステムといった領域は本ドキュメントの対象外としています。

なお、このチェックリストの内容は TSV としても提供しています。Excel や Google スプレッドシートに取り込んで、対応状況や所感を記入していくとスムーズです。

1. 技術選定

技術選定は、システムの基盤を決める重要な意思決定です。目先のコストだけでなく、運用コスト、学習コスト、将来の拡張性まで含めた総合的な観点で判断する必要があります。

1.1 クラウドサービスの活用

概要

オンプレミスではなく、AWSなどのクラウドサービスの利用を優先して検討します。

理由・背景

物理的な機器やネットワークが不要となることで、それらの調達や維持・メンテナンスに係るコスト（経年劣化による故障 / 冷却 / 置き場所・在庫管理 など）が不要となり、本来注力するべき内容に集中できます。

実施基準

推奨。オンプレミスを使わなければならない特別な事情がなければ実施を推奨します。

構成例1: クラウドサービスの利用

オンプレミスの代わりに、AWS・Google Cloud・Microsoft Azureなどのクラウドサービスを利用します。インフラ構築がブラウザの管理画面やコマンド操作で完結するため、調達のリードタイムが数分に短縮されます。さらに故障時の機器交換やデータセンタの保守といった維持・メンテナンス作業もクラウド事業者側に任せられ、運用にかかる負担を大幅に軽減できます。

関連セクション: AWS：この講座で学べること

構成例2: PaaSの利用

HerokuやVercel、Render、AWS AmplifyのようなPaaS（Platform as a Service）も選択肢になります。クラウドと同様のメリットに加え、OSやミドルウェアの運用までを事業者側に任せられるため、アプリケーションコードのデプロイだけに集中できます。一方でランタイムやミドルウェアの選択肢が事業者の提供範囲に限定されるため、柔軟性の観点では制約があります。

出典

1.2 マネージドサービスの活用

概要

クラウド事業者などが提供するマネージドサービスを積極的に採用します。

理由・背景

運用作業をクラウド事業者側に任せられるため、その機能を専門に扱える人材を社内で確保せずとも一定の品質で運用でき、運用コストや操作ミスのリスクを抑えられます。

実施基準

推奨。目的に合うマネージドサービスが存在する場合は、特別な事情がなければ利用を推奨します。

構成例1: Amazon RDS / Auroraの採用

データベースをEC2上に自前で構築せず、Amazon RDSやAuroraを採用します。自動バックアップ、パッチ適用、レプリケーション構成などがマネージドで提供されるため、データベースメンテナンスの運用負荷を大幅に軽減できます。

関連セクション: RDS概要

構成例2: ストレージ管理にAmazon S3を採用

ファイルサーバを自前で構築・管理する代わりに、Amazon S3を採用します。自前構築では実現が難しい耐久性99.999999999%（イレブンナイン）のストレージを、運用の手間なく従量課金で利用できます。

関連セクション: S3概要

構成例3: 認証基盤にAmazon Cognitoを採用

ユーザ認証基盤を自前で実装する代わりに、Amazon Cognitoを採用します。トークン発行・MFA・SNSログイン連携などがマネージドで提供されるため、実装・運用の負荷を軽減しつつ、自前実装によるセキュリティ事故のリスクも抑えられます。

出典

1.3 サーバレスアーキテクチャの活用

概要

AWS Lambdaなどに代表されるサーバレスアーキテクチャの導入を検討します。

理由・背景

サーバやOSやミドルウェアを意識せずにアプリケーションを動かせるため、これらの管理が不要になります。

実施基準

推奨。要件に合うサーバレスサービスが存在する場合は、特別な事情がなければ実施を推奨します。

構成例1: Lambdaの利用

関数単位で処理を実行できるAWS Lambdaを採用します。実行された時間分だけ課金されるため、常時稼働するサーバと比べてコストを大幅に削減できます。API Gateway・EventBridge・SQS・Step Functionsなどと連携することで、APIサーバ・イベント駆動処理・非同期ワークフローも組み立てられます。

関連セクション: Lambda概要

構成例2: ECS / Fargateの利用

コンテナ化されたアプリケーションをサーバレスで動かす基盤としてECS / Fargateを採用します。EC2インスタンスの管理は不要で、コンテナの起動・停止・スケーリングをAWSに任せられます。Lambdaでは扱いにくい長時間処理や、既存のコンテナアプリケーションをそのままサーバレスで運用したい場面に向いています。

関連セクション: Amazon ECS / Fargate概要

出典

1.4 コンテナ技術の採用

概要

Dockerに代表されるコンテナ技術を採用します。

理由・背景

「開発環境では動くのに本番では動かない」といった環境差異による問題を根本的に解消できます。また、コンテナ単位でデプロイ・スケーリングできるため、リリースのスピードと運用効率の両方を高められます。

実施基準

推奨。大規模なWebアプリケーション開発を行う場合などは、特別な理由がない限り実施を推奨します。

構成例1: Dockerによるコンテナ化

アプリケーションをDockerfileで定義し、コンテナイメージとしてパッケージ化します。開発者全員が同じイメージを使うことで、環境差分による不具合を根本的に解消できます。

関連セクション: Dockerの基本操作

構成例2: Amazon ECS（Fargate）によるコンテナオーケストレーション

コンテナの実行基盤としてAmazon ECS（Fargate）を採用します。Fargateを利用すれば、EC2インスタンスの管理が不要になり、コンテナの起動・停止・スケーリングをAWSに任せることができます。

関連セクション: Amazon ECS / Fargate概要

出典

1.5 マイクロサービスの採用

概要

ドメインや機能単位でサービスを分割するマイクロサービスアーキテクチャの導入を検討します。

理由・背景

機能単位で独立してデプロイできるため、リリースの影響範囲を限定でき、チームごとに並行して開発を進められます。一方で、サービス間通信・分散トレーシング・データ整合性の管理といった分散システム特有のオーバーヘッドがあり、規模や体制が小さい段階で導入するとメリットを上回るコストが発生する点に注意が必要です。

実施基準

段階に応じて検討。当初から導入すると規模に見合わないオーバーエンジニアリングとなり、将来的に技術的負債となる可能性があるため、サービスの成長に合わせて段階的に分割するのが安全です。

構成例1: Kubernetesによる管理

分割したサービスをKubernetesクラスタ上のPodやDeploymentとして管理します。ローリングアップデート、自動スケーリング、ヘルスチェックなど、分散システムの運用に必要な機能が標準で提供されるため、複雑なマイクロサービス構成も統一的に運用できます。

構成例2: Amazon EKSの利用

OSSのKubernetesを自前で構築・運用する代わりに、マネージドKubernetesであるAmazon EKSを利用します。マスターノードの構築・運用をAWSに任せられるため、Kubernetes自体の運用負荷を抑えながら、サービスごとの独立したデプロイやスケーリングを実現できます。

出典

1.6 技術情報の入手・サポート

概要

トラブル発生時に頼れる技術情報へのアクセス性とサポート体制を評価したうえで技術を選定します。

理由・背景

開発・運用が詰まったときに、適切な技術情報の入手やサポートが受けられないと、事業継続が成り立ちません。特に、技術情報に特定ベンダーしかアクセスできない場合はベンダーロックインにつながり、マイナーなフレームワークでは情報やコミュニティが乏しくエンジニアの採用や引き継ぎの学習コストも高くなります。機能が停止した場合のサポートを受けられるかどうかも、事業継続のために重要な要素です。

実施基準

必須。公式ドキュメントの公開状況やコミュニティの活発さといった情報入手のしやすさは必ず確認します。追加のサポート契約や外部レビュー体制は、運用レベルに応じて段階的に検討します。

施策例1: 公式ドキュメントが公開されているサービスの選定

特定ベンダーしか公式ドキュメントにアクセスできないサービスは避け、誰でもドキュメントを参照できるサービスを選びます。AWSやGoogle Cloudのように、公式ドキュメントが無料で公開されているサービスが望ましいです。

施策例2: 技術コミュニティが活発なOSSの選定

オープンなコミュニティの場で情報が豊富に共有されている技術を選びます。マイナーなフレームワークはトラブル発生時に情報が見つからず、解決に膨大な時間がかかるリスクがあります。

施策例3: トラブル対応時のサポート体制の確認

採用する技術について、トラブル発生時の対応窓口・対応時間・エスカレーション体制を事前に確認します。導入当初から高度な有償サポートを契約する必要はありませんが、将来的に課金することで適切なサポートを受けられる選択肢があるかは把握しておきます。例えばAWSの場合、Basic（無料）からEnterpriseまで複数のサポートプランがあり、上位プランほど24時間365日対応や障害時の迅速なエスカレーションが受けられるようになります。

出典

1.7 サービス上限

概要

AWS Service Quotasなどを用いて、各サービスの利用上限について事前の確認と必要に応じた上限緩和申請を行います。

理由・背景

サービス側の制限により目的が達成できない、または稼働中のシステムが停止・エラーとなることを防ぐ必要があります。

実施基準

推奨。特別な事情がなければ実施を推奨します。

施策例1: AWS Service Quotasの事前確認と上限緩和申請

AWS Service Quotasダッシュボードで、利用予定のサービスのデフォルト上限を確認します。例えば、Lambda の同時実行数（デフォルト1,000）やEC2のインスタンス起動数など、上限に達する可能性がある項目は事前に上限緩和申請を行います。

出典

1.8 想定されるコスト

概要

事前のコスト把握と継続的なコスト管理を行います。

理由・背景

クラウドは従量課金のため、適切な管理を怠ると請求額が青天井になるリスクがあります。個人開発の場合であっても、過度な請求を避けることは重要です。

実施基準

必須。青天井になるリスクを制御し利益率を確保するため、必ず実施します。対応しない場合、致命的なリスクが発生する可能性があります。

施策例1: 事前の概算コスト把握

AWS Pricing Calculatorなどを利用して、構築前にインフラの概算コストを算出します。事業収益に見合うかを事前に判断し、コスト面で実現可能なアーキテクチャを選択します。AWS Pricing Calculatorの使い方はWhat is AWS Pricing Calculator?（AWS公式ドキュメント）に記載があります。

施策例2: AWS Budgetsによる予算管理とアラート設定

AWS Budgetsで月額の予算上限を設定し、閾値（80%、100%など）を超えた場合にメールやSlackで通知を受け取ります。予算超過に気づかないまま請求額が膨れ上がることを防ぎます。設定のベストプラクティスはBest practices for AWS Budgets（AWS公式ドキュメント）に記載があります。

施策例3: Cost Explorerによる定期的な内訳確認

Cost Explorerを使い、週次または月次でサービス別・タグ別のコスト内訳を確認します。想定外にコストが増加しているサービスや、不要になったリソース（停止し忘れたEC2インスタンスなど）を特定し、削除またはサイズ変更を行います。

施策例4: コスト最適化施策の活用

スポットインスタンス（最大90%割引）、Savings Plans（長期利用による割引）、リザーブドインスタンスなどの購入オプションを活用し、同じ構成でもコストを大幅に削減します。クラウドにおけるコスト最適化の包括的な指針はCost Optimization Pillar - AWS Well-Architected Framework（AWS公式ドキュメント）に記載があります。

施策例5: データのライフサイクル管理

S3ライフサイクルポリシーなどを設定し、データを自動的にアーカイブまたは削除します。例えば「作成から90日後にGlacierストレージクラスへ移行」「365日後に削除」のようなルールを定めることで、ストレージコストを継続的に最適化できます。

関連セクション: S3概要

出典

2. DevOps

DevOpsは、開発と運用のプロセスを統合し、自動化・効率化を通じて品質とリリーススピードを両立させる技術プラクティスの集まりです。ここでは、バージョン管理・IaC・CI/CDパイプライン・自動テスト・レビュー・環境分離といった、手作業を減らし継続的に改善するための仕組みを扱います。後続のセクションで扱う施策のいくつかは、ここで整備するDevOps基盤と組み合わせることで、より効果的に運用できます。

2.1 バージョン管理

概要

ソースコードの管理には、Gitなどのバージョン管理システムを導入します。

理由・背景

バージョン管理がないと、「いつ」「誰が」「何を」変更したかが追えず、問題発生時の原因特定や切り戻しが不可能になります。アプリケーション開発の領域と思われがちですが、IaC（Terraform / AWS CDKなど）のコードやコンテナイメージの定義（Dockerfile）、CI/CDパイプラインの定義など、インフラ領域でも同様に活用されており、現代的なチーム開発の基盤として不可欠です。

実施基準

必須。バージョン管理がないと、障害発生時に「最後にうまく動いていた状態」へ戻せず復旧不能になる、複数人が同じファイルを編集して片方の変更が消える、設定変更による不具合の原因を特定できないなど、開発・運用が成り立たなくなるリスクがあるため、必ず実施します。

構成例1: Git（GitHub / GitLab）の利用

ソースコードの変更履歴をGitで管理し、GitHubやGitLabでリモートリポジトリをホスティングします。すべての変更がコミットとして記録されるため、問題発生時に任意の時点の状態に戻すことができます。

関連セクション: Git／GitHub

構成例2: ブランチ戦略の策定

Git FlowやGitHub Flowなどのブランチ戦略を定め、開発ブランチ、リリースブランチ、ホットフィックスブランチの運用ルールを明確にします。チーム内でルールを統一することで、並行開発時のコンフリクトを最小化します。

関連セクション: GitHubで保護ブランチを設定しよう

出典

2.2 IaCの導入

概要

インフラ構成をコードで管理できるIaC（Infrastructure as Code）を導入します。

理由・背景

同じコードを使うことで、開発・ステージング・本番のいずれでも同一構成を再現でき、環境差分による不具合を防げます。また、インフラの変更履歴がGitに残るため、いつ・誰が・何を変えたかを追跡でき、レビューや承認といったガバナンスを開発プロセスと同じワークフローで回せます。

実施基準

推奨。特別な事情がなければ実施を推奨します。

構成例1: Terraformの利用

Terraformを利用して、AWS・Google Cloud・Azureなど複数のクラウドのリソースをコードで定義・管理します。HCL（HashiCorp Configuration Language）を用いた宣言型の記述で、最終的なインフラの「あるべき状態」を定義し、terraform applyの1コマンドで環境を構築できます。

関連セクション: Terraform：この講座で学べること

構成例2: AWS CDKの利用

AWS CDK（Cloud Development Kit）を利用して、TypeScriptやPythonなどのプログラミング言語でAWSリソースを定義します。ループ・条件分岐・クラス継承などを使えるため、動的で複雑な構成を効率的に記述できます。内部的にはCloudFormationテンプレートに変換されて実行されます。

構成例3: Ansibleによる構成管理

Ansibleを利用して、サーバ（OS）の内部設定を自動化します。OSのパッケージ導入、設定ファイルの配置、ユーザ管理など、TerraformやCDKでは扱えないサーバ内部の構成管理を担います。エージェントレスで動作するため、SSHで接続できれば対象サーバを管理できます。

出典

2.3 CI/CDパイプライン

概要

GitHub ActionsやAWS CodePipelineなどによるCI/CDパイプラインを構築します。

理由・背景

手動でのテスト実行やデプロイは時間がかかり、操作ミスも発生しやすくなります。CI/CDパイプラインを構築することで、リリース作業を効率化し、人的な作業ミスを軽減できます。また、静的解析や自動テストをパイプラインに組み込むことで品質向上が見込め、属人化していた手順も明文化されて標準化されます。

実施基準

推奨。特別な事情がなければ実施を推奨します。

構成例1: GitHub Actionsによる自動化

GitHub Actionsを利用し、Pull Request作成時にテストの自動実行、mainブランチへのマージ時にステージング環境への自動デプロイ、リリースタグの作成時に本番環境への自動デプロイといったパイプラインを構築します。

関連セクション: CI／CDパイプライン：この講座で学べること

構成例2: AWS CodePipelineによる自動化

AWS CodePipelineを利用し、CodeCommit（またはGitHub）→ CodeBuild（ビルド・テスト）→ CodeDeploy（デプロイ）の一連のフローを自動化します。AWSサービスとのネイティブ連携により、AWS環境へのデプロイがスムーズに行えます。

出典

2.4 自動テスト

概要

静的解析・ユニットテスト・E2Eテストなどの自動テストをCIに組み込み、デグレ（既存機能の破壊）や品質低下を防ぎます。

理由・背景

手動でのテストは、開発者ごとの環境差で結果が変わったり、リリースのたびに実施漏れが発生したりするリスクがあります。CIパイプラインに自動テストを組み込むことで、変更のたびに同じ条件でテストが自動実行され、デグレや品質低下を早期に検知できます。

実施基準

推奨。静的解析とユニットテストはCI構築と合わせて導入し、E2Eテストはメンテナンスコストが高いため重要なフローに絞って段階的に追加します。

構成例1: 静的解析の自動化

flake8などの静的解析ツールをCIパイプラインに組み込み、コーディング規約違反や文法上の問題を自動検出します。未使用のインポートや不適切なインデント、長すぎる行などを警告して、レビューの負担を軽減できます。

関連セクション: 静的解析と自動テストを自動化しよう

構成例2: ユニットテスト・結合テストの自動化

pytestなどのテストフレームワークを使い、関数やAPIの動作を検証する自動テストを作成します。CIパイプラインで毎回実行することで、デグレを即座に検知できます。

関連セクション: Pythonで自動テストをしよう

構成例3: E2Eテストの自動化

PlaywrightやCypressを使い、ログイン→商品検索→カート追加→注文確定のような主要なユースケースを自動テスト化します。毎回のデプロイ前に実行することで、画面操作レベルでの業務フロー全体が正常に動作することを確認できます。

出典

2.5 デプロイタイプの選択

概要

ローリング・Blue/Green・カナリア・シャドウなど、サービス特性に合わせた適切なデプロイタイプを選択します。

理由・背景

デプロイタイプによっては、新旧バージョンが一時的に混在したり、切り替え時にダウンタイムが発生したりする問題が生じます。サービスの特性（ダウンタイム許容度・ロールバック容易性・想定リソース消費など）に応じて、適切なデプロイタイプを選ぶ必要があります。

実施基準

推奨。特別な事情がなければ実施を推奨します。

構成例1: ローリングデプロイ

サーバやコンテナを1台ずつ順番に新バージョンに更新していく方式です。Amazon ECSやKubernetesのデフォルトのデプロイタイプとして広く利用されており、システムを止めずに更新できます。一時的に新旧バージョンが混在するため、互換性を保てる変更に適しています。

関連セクション: デプロイタイプ

構成例2: Blue/Greenデプロイメント

現行環境（Blue）とは別に新環境（Green）を構築し、新環境で動作確認後にトラフィックを一気に切り替えます。問題が発生した場合は旧環境に戻すだけで即座にロールバックできます。大規模な構成変更や、新旧バージョンの混在を許容できない場面に向いています。

関連セクション: Blue／Greenデプロイメントを構築しよう

構成例3: カナリアデプロイ

新バージョンを一部のユーザだけに段階的に公開し、問題がなければ全体へ展開していく方式です。利用者が多いサービスで万一の影響を最小化したい場面や、A/Bテストを行いたい場面に向いています。

構成例4: シャドウデプロイ

本番環境に流れるトラフィックをミラーリングして新環境にも送信し、ユーザに影響を与えずに動作を検証する方式です。本番と同等の負荷やデータ条件で検証できるため、従来のテスト環境では再現しづらい不具合の検知に有効です。

出典

2.6 承認フロー

概要

Pull RequestのレビューやCIの通過など、mainブランチへのマージ前に通すべき承認フローを整備します。

理由・背景

独断でのコード変更や、テスト・静的解析を通さないまま本番に反映される変更は、品質低下の最大要因です。マージ前にレビュー・CIなど複数のチェックを必ず通す承認フローを整備することで、バグの早期発見、知識の共有、コードの一貫性の維持が実現できます。

実施基準

必須。品質低下の最大要因を防ぐため、必ず実施します。対応しない場合、致命的なリスクが発生する可能性があります。

施策例1: Pull Requestでのレビュアー承認の必須化

GitHubやGitLabのリポジトリ設定で、Pull Request（Merge Request）のマージにはレビュアーの承認を必須にします。これにより、独断でのコード変更を防ぎ、複数人の目で品質を担保できます。

関連セクション: GitHubで保護ブランチを設定しよう

施策例2: CI（静的解析・自動テスト）の通過を必須化

保護ブランチのステータスチェック設定を有効にし、CIで実行される静的解析・自動テストがパスしないとマージできないようにします。テストが失敗したコードが本番に流れる事故を防げます。

施策例3: 直接Pushの禁止

mainブランチへの直接Pushやforce pushを禁止し、すべての変更が必ずPull Request経由で行われるようにします。承認フローを迂回する経路を塞ぐことで、フロー自体の実効性を担保できます。

出典

2.7 AIツールの活用

概要

コーディングアシスタント・コードレビュー・セキュリティ分析・インシデント対応など、AIツールを開発・運用の各フェーズで活用します。

理由・背景

AIツールの活用はエンジニアの生産性を大きく向上させます。コードの自動補完、テストコードの生成、コードレビュー、セキュリティ分析、障害対応の支援など、開発から運用までの多くの作業を効率化できるため、導入コスト以上の効果が見込めます。

実施基準

推奨。現在のベストプラクティスとして導入を推奨します。

構成例1: AIコーディングアシスタントの活用

Claude Code、Codex、GitHub Copilotなどのコーディングアシスタントを開発環境に導入します。コードの自動補完、関数の自動生成、テストコードの生成などにより、コーディング速度を大幅に向上させます。

構成例2: AIレビューの導入

Pull Request作成時にAIが自動でコードレビューを行う仕組みを導入します。プロジェクト規約に沿ったレビューを誰でも一定品質で受けられるため、人的レビューの負担を軽減しつつ、レビュー品質の底上げにもつながります。

構成例3: Security Agentの導入

AWS Security AgentのようなAIエージェントを活用し、インフラやアプリケーションのセキュリティリスクを統合的にレビュー・分析します。脆弱性の検出と修正提案、ペネトレーションテストの実行と結果の解釈などを自動化できます。

関連セクション: AWS Security AgentでAIによる統合セキュリティレビューを体験しよう

構成例4: DevOps Agentの導入

DevOps AgentのようなAIエージェントを活用し、運用中のインシデント検知・原因調査・対応支援を自動化します。ログやメトリクスを横断的に分析し、復旧手順の提案までを行うため、運用負荷を大きく削減できます。

関連セクション: DevOps Agent概要 ・ DevOps Agentでインシデント対応を自動化しよう

出典

3. セキュリティ

セキュリティは、システムの信頼性を支える最も重要な基盤です。本講座では、情報セキュリティの三要素「機密性」「完全性」「可用性」のうち、機密性と完全性を扱います（可用性は「可用性」セクションで扱います）。

3.1 アクセス制御

概要

情報への適切なアクセス制御の仕組みを導入します。

理由・背景

アクセス制御はセキュリティ対策の基本中の基本であり、初歩的な攻撃を防ぐための最低限の防御策です。適切なアクセス制御がなければ、不正アクセスによる情報漏洩リスクを排除できません。

実施基準

必須。データや機能への「入口」となる部分には必ずアクセス制御を設定します。一度の事故が致命的になるため、対応しない場合は致命的なリスクが発生する可能性があります。

構成例1: AWSリソースへのアクセス制御

AWSリソースへのアクセスは、IAMユーザやIAMロールで制御します。開発者ごとに個別のIAMユーザを作成し、所属チームや役割に応じてポリシーを管理します。複数アカウントを横断的に管理する場合はIAM Identity Centerによる一元管理も推奨されます。S3バケットのように個別のリソースに対しては、バケットポリシーなどリソースベースのポリシーも組み合わせて制御できます。

関連セクション: IAM概要

構成例2: アプリケーションへのアクセス制御

アプリケーション利用者に対しては、ログイン認証機能を実装し、ユーザの権限に応じてアクセスできる情報や操作を制限します。自前で実装する代わりに、Amazon CognitoやAuth0のようなID基盤サービスを利用することで、認証フロー・パスワードリセット・トークン管理を事業者側に任せられます。

構成例3: APIへのアクセス制御

完全に公開するAPIでなければ、適切な認証によるアクセス制御を行います。認証がないと、本来の利用者以外からも自由にAPIを呼び出され、機密情報の漏洩や不正な操作につながります。トークンや署名による認証、APIキーの発行、リクエスト元IPアドレスの制限、レートリミットなどの手法があり、これらを組み合わせて防御層を厚くします。

出典

3.2 最小権限の原則

概要

IAMポリシーや認可ロジックにおいて、最小権限の原則を厳守します。

理由・背景

権限が広すぎると、一つのミスがシステム全体の崩壊に繋がります。例えば本来はS3バケットへの読み取りだけで十分なLambda関数に、念のためと全操作権限を付与しているような状態では、コードの不具合や認証情報の漏洩時に、データの削除や書き換えまで被害が広がってしまいます。

実施基準

必須。一つのミスが全システムの崩壊に繋がるため、必ず実施します。対応しない場合、致命的なリスクが発生する可能性があります。

施策例1: 適切なアクセス権限の設定

ユーザやプログラムごとに、業務上必要な操作と対象リソースを洗い出し、最低限の権限のみを付与します。「念のため」と広めに付与せず、明示的に必要な権限だけを許可する方針にすることで、認証情報の漏洩や設定ミス時の被害範囲を大幅に縮小できます。

関連セクション: IAM概要

出典

3.3 多要素認証（MFA）

概要

重要なログインに対して**多要素認証（MFA）**を必須にします。

理由・背景

パスワードだけによる認証は、漏洩・推測・使い回しによる不正アクセスのリスクが高くなります。MFAをパスワードと組み合わせることで、片方の認証情報が漏洩しても不正アクセスを防げます。AWSアカウントやアプリケーションログイン、GitHubなどの開発ツールに至るまで横断的に徹底することが重要です。

実施基準

推奨。MFAの機能が利用できる場合は、取り扱う情報や操作の重要度に応じて導入を判断します。

構成例1: ワンタイムパスワード（TOTP）

Google AuthenticatorやAuthyのような認証アプリケーション、SMSやメールで一定時間有効な数字コードを発行し、パスワードと組み合わせて入力する方式です。導入コストが低く、最も一般的に利用されています。

構成例2: デバイス認証（プッシュ通知）

事前に登録したスマートフォンに「このログインを承認しますか？」というプッシュ通知が届き、タップで承認する方式です。コードの入力が不要で利便性が高く、AWS MFAアプリケーションやMicrosoft Authenticatorなどが代表例です。

構成例3: FIDO規格による認証

スマートフォンやPCに登録された公開鍵と、指紋・顔などの生体認証を組み合わせて本人確認を行う方式です。生体情報をサーバに送らず端末内で照合するため、サーバ側の漏洩リスクや、フィッシング攻撃にも強い堅牢な認証が実現できます。物理セキュリティキー（YubiKey等）や、スマートフォン・PC内蔵の生体センサーを認証要素として利用できます。

出典

3.4 ネットワーク分離

概要

サーバやデータを格納するネットワークを適切に分離し、アクセス制限を実施します。

理由・背景

データベースなどがインターネットに露出するのは致命的なリスクです。ネットワークを適切に分離することで、万が一外部からの侵入があっても被害の拡大を防止できます。

実施基準

必須。必ず実施します。対応しない場合、致命的なリスクが発生する可能性があります。

構成例1: VPCによるパブリック / プライベートサブネットの分離

VPCを作成し、インターネットからアクセスが必要なリソース（ALBなど）はパブリックサブネットに、データベースやアプリケーションサーバはプライベートサブネットに配置します。プライベートサブネットのリソースにはインターネットから直接アクセスできないため、攻撃対象面を最小化できます。

関連セクション: VPC概要

構成例2: Security Groupによる通信元の制限

Security Groupで、各リソースが受け付ける通信元を最小限に絞ります。例えば、データベースのSecurity Groupには「アプリケーションサーバのSecurity GroupからのPort 3306のみ許可」と設定し、それ以外の通信はすべて拒否します。

関連セクション: VPC概要

出典

3.5 暗号化

概要

TLS/SSLやKMSなどを用いて、通信と保存データの暗号化を行います。

理由・背景

通信経路が暗号化されていなければ、中間者攻撃によりデータが盗聴されるリスクがあります。保存データの暗号化は、万が一データが漏洩した場合の被害を最小化するための防御策です。

実施基準

必須。昨今のセキュリティ基準として必須要件のため、必ず実施します。対応しない場合、致命的なリスクが発生する可能性があります。

構成例1: 通信の暗号化

ユーザとサーバ間の通信はすべてHTTPS（TLS/SSL）で暗号化します。ACM（AWS Certificate Manager）で無料のSSL/TLS証明書を発行し、ALBやCloudFrontに設定することで、通信経路上のデータ盗聴を防ぎます。

関連セクション: ACM概要

構成例2: データベースの暗号化

RDSやAuroraなどに保存されるデータを暗号化します。データベース側の暗号化機能を有効化するだけで、保存データに加えてバックアップ・リードレプリカ・スナップショットまで自動的に暗号化されます。鍵管理にKMS（Key Management Service）のカスタマー管理キーを利用すると、鍵のローテーションやアクセス制御をより細かく管理できます。

構成例3: ストレージの暗号化

S3・EBS・EFSなどのストレージに保存するデータも暗号化します。S3ではバケット単位でデフォルト暗号化を有効化することで、書き込まれるすべてのオブジェクトが自動的に暗号化されるため、設定漏れによる平文保存を防げます。こちらも鍵管理にKMSのカスタマー管理キーを利用すると、鍵のローテーションやアクセス制御をより細かく管理できます。

出典

3.6 シークレット情報の管理

概要

認証情報・APIキー・接続情報などのシークレット情報を安全に管理する仕組みを導入します。

理由・背景

コードリポジトリに認証情報が含まれていると、コード流出時にシステム全体が乗っ取られるリスクがあります。GitHubなどのパブリックリポジトリにAWSのアクセスキーやデータベースのパスワードをコミットする事故は後を絶ちません。

実施基準

必須。システム全体が乗っ取られるリスクを避けるため、必ず実施します。対応しない場合、致命的なリスクが発生する可能性があります。

構成例1: Secrets Manager / Parameter Storeによる管理

APIキー、データベースパスワード、外部サービスの認証情報などは、AWS Secrets ManagerやSystems Manager Parameter Store（SecureString）に保存します。アプリケーションは実行時にこれらのサービスから値を取得するため、コードにシークレット情報を含める必要がありません。

構成例2: git-secretsによるコミット前チェック

git-secretsなどのツールを導入し、git commit実行時にAWSアクセスキーや秘密鍵のパターンを検出してコミットをブロックします。.gitignoreの設定と合わせて、シークレット情報がリポジトリに混入することを防ぎます。git-secretsの使い方はawslabs/git-secrets（GitHubリポジトリ）に記載があります。

構成例3: シークレット情報のローテーション

IAMアクセスキー・データベースパスワード・APIキーなどのシークレット情報には有効期限を設け、定期的にローテーションします。長期間有効な認証情報を残さないことで、万が一漏洩した場合の被害期間を最小化できます。AWSの場合はSwitch Role（IAMロールの引き受け）など一時的な認証情報を使う運用に切り替えると、ローテーションの手間自体を減らせます。

出典

3.7 DevSecOps

概要

SAST・SCA・DASTなどのセキュリティテストをCI/CDパイプラインに組み込み、デプロイ前にセキュリティ問題を検出します。

理由・背景

セキュリティの問題をリリース後に発見すると修正コストが大幅に増加します。CIパイプラインにセキュリティテストを組み込むことで、開発の早い段階で脆弱性を検出し、手戻りを抑えられます。

実施基準

段階に応じて検討。まずは基本的なCI/CDパイプラインの構築を優先し、その後SAST・SCA・DASTの順に段階的に導入するのが現実的です。

構成例1: SASTツールのCI組み込み

ソースコードを実行せずに、静的にセキュリティ問題を検出します。Snyk、Semgrep、CodeQLなどのSASTツールをCIパイプラインに組み込み、PRごとにスキャンを実行し、脆弱性が検出された場合はマージをブロックします。

関連セクション: SAST概要

構成例2: SCAツールのCI組み込み

利用しているライブラリやコンテナイメージの既知の脆弱性（CVE）を検出します。OSSの脆弱性スキャナ「Trivy」などをCIパイプラインに組み込み、コンテナイメージやIaCの設定を自動スキャンします。

関連セクション: CI／CDパイプラインにSCAを導入しよう

構成例3: DASTツールのCI組み込み

稼働中のアプリケーションに対して外部から擬似的な攻撃リクエストを送り、実環境でしか現れない脆弱性（認証バイパス・セッション管理の不備など）を検出します。OWASP ZAPやBurp Suiteなどを用いて、ステージング環境にデプロイされたアプリケーションに対して擬似攻撃を実行します。

出典

3.8 マルウェア対策

概要

サーバの稼働環境に応じたマルウェア対策を導入します。

理由・背景

万が一マルウェアが侵入した場合、検知の仕組みがなければ侵入に気づけず、被害が拡大し続けます。サーバ環境やワークロードの形態に応じて、適切な検知・防御の仕組みを導入する必要があります。

実施基準

推奨。特別な事情がなければ実施を推奨します。

構成例1: マルウェア対策ソフトの導入

EC2などのサーバを自前で運用する場合、ClamAVなどのマルウェア対策ソフトを導入し、定期的なスキャンとシグネチャの更新を自動化します。

構成例2: マネージドサービス・サーバレスアーキテクチャの活用

LambdaやFargate・RDS・S3などのマネージドサービスやサーバレスを採用することで、OSレベルのマルウェア対策をクラウド事業者側に委任できます。サーバ自体を持たない構成にすることで、対策の責任範囲を最小化できます。

構成例3: GuardDuty Malware Protectionの活用

AWS環境では、GuardDuty Malware Protectionを有効化することで、EC2インスタンスにアタッチされたEBSボリューム、コンテナワークロード、S3バケットへの新規アップロードオブジェクトを対象に、エージェントレスでマルウェアスキャンを実行できます。

出典

3.9 WAFの導入

概要

WAF（Web Application Firewall）を導入します。

理由・背景

アプリケーションコードだけで完全にWeb攻撃を防ぐことは困難です。WAFを導入することで、コードの修正漏れをカバーする防御層として機能します。

実施基準

推奨。特別な事情がなければ実施を推奨します。

構成例1: AWS WAFの導入

AWS WAFを導入し、AWSが提供するマネージドルールグループ（Core Rule Set、SQL Database Rule Setなど）を適用します。SQLインジェクション、XSS（クロスサイトスクリプティング）、パストラバーサルなどの一般的なWeb攻撃を、ルールベースで自動的にブロックします。

出典

3.10 脆弱性管理

概要

ECRスキャン・Amazon Inspector・SSM Patch Managerなどを活用し、運用中のシステムに対する継続的な脆弱性検出とパッチ適用を行います。

理由・背景

脆弱性は日々発見されるため、デプロイ時のチェックだけでは不十分です。運用中のシステムに対しても継続的なスキャンとパッチ適用の運用ルールを定めないと、放置された脆弱性が攻撃の入口になります。

実施基準

推奨。特別な事情がなければ実施を推奨します。

構成例1: ECRのイメージスキャン

Amazon ECR（Elastic Container Registry）のイメージスキャン機能を有効化し、レジストリにプッシュされたコンテナイメージに対して脆弱性スキャンを実行します。Enhanced Scanningを有効にすれば、Amazon Inspectorと連携してプッシュ後も継続的にスキャンされます。

構成例2: Amazon Inspectorによる継続的スキャン

Amazon Inspectorを有効化し、EC2インスタンスやLambda関数、コンテナイメージの脆弱性を継続的に検出します。新しい脆弱性（CVE）が公開された際にも、影響を受ける対象を自動的に検知できます。

関連セクション: Amazon Inspectorでコンピュートリソースの脆弱性を管理しよう

構成例3: SSM Patch Managerによるパッチ適用

SSM Patch Managerを利用して、検出された脆弱性に対するパッチを自動適用します。深刻度に応じた適用ルール（例: Critical/Highは72時間以内、Mediumは次回メンテナンスウィンドウで適用）を定めることで、運用判断のブレを防げます。

出典

4. 可用性

可用性は、システムが継続して利用可能で、アクセス増加や障害にも耐えられる状態を維持する能力です。ユーザにとって「いつでも快適に使える」ことは当たり前の期待であり、その期待を裏切ることはサービスの信頼喪失に直結します。

4.1 サービス指標の策定

概要

可用性100%というのは現実的に達成が困難であるため、事業要件に応じた指標を策定し、それに見合う設計を行います。

理由・背景

可用性100%を目指すと、コストや構成の複雑性が指数関数的に増大します。一方で指標が定まっていないと、「どのくらい止まったらNG」「どのくらい遅いとNG」の判断軸が組織内で揃わず、対策の優先順位もブレます。事業要件と利用者の期待に基づいて目標指標を策定し、それを達成できる範囲で必要十分な設計を行うことが重要です。

実施基準

推奨。サービスを設計する際に最初に整理しておくべき観点として、可能な限り実施を推奨します。

施策例1: SLAの設定

SLA（Service Level Agreement）とは、ユーザに対して約束するサービスの稼働率です（例: 99.9%）。契約上の保証としての性質があり、達成できない場合の返金や補償などが定められることもあります。事業要件と利用者の期待に基づいて設定します。

設定する目標値によって必要な設計は大きく変わります。例えば外部顧客向けのSaaSで99.9%（月あたり約43分のダウンタイム許容）を約束する場合はマルチAZ構成が必須になり、99.99%以上を目指すならマルチリージョン化まで検討することになります。

一方、社内向けの業務ツールで平日日中のみ使えれば問題ないようなサービスであれば、単一構成でシンプルに運用しコストを抑える判断もあり得ます。

施策例2: SRE指標の設定

SRE（Site Reliability Engineering）実践の中核となるSLO・SLI・エラーバジェットを設定し、サービスレベルの管理と、変更・安定化のトレードオフ判断の基準にします。

• SLO（Service Level Objective）: 内部目標としての稼働率。SLAより厳しめに設定
• SLI（Service Level Indicator）: 実際の稼働率を計測する指標
• エラーバジェット: SLOで許容されるダウンタイムの総量（例: SLO 99.9%なら月あたり約43分）。この範囲内であれば新機能リリースや変更を積極的に行い、超過した場合は変更を止めて安定化を優先するという運用ルールに活用できます

SLIを定期的に計測してSLOの達成状況を監視し、エラーバジェットを開発と運用のトレードオフ判断に活用します。

施策例3: 障害復旧指標の設定

障害時の復旧に関する指標として、RTO・RPOを設定します。

• RTO（Recovery Time Objective）: 復旧目標時間。「障害発生からどれくらいの時間でサービスを復旧させるか」
• RPO（Recovery Point Objective）: 復旧時点目標。「どの時点のデータまで復旧できるか」（データ消失をどこまで許容できるか）

これらの指標を定めることで、バックアップ・リストアやDR戦略の選択基準が明確になります。

施策例4: レスポンス・スループット目標の設定

サービスのUXに直結する性能目標を設定します。

• レスポンスタイム: ページの表示時間（例: 2秒以内）やAPI応答時間（例: 500ms以内）などの応答時間目標
• スループット: ピーク時に処理できるリクエスト数（例: 同時1,000ユーザ、1,000 req/s）

CloudWatch MetricsやX-Rayで実際のレスポンスタイムを計測し、目標値を超える箇所をボトルネックとして特定・改善します。

目標値によって最適な設計は大きく変わります。

例えばレスポンスタイム目標を100ms以内と厳しく設定する場合は、LambdaのProvisioned Concurrency（実行環境を事前に温めておくホットスタンバイ相当の機能）でコールドスタートを回避したり、CDNやキャッシュを積極的に活用したりする設計が必要になります。

逆に数秒以内で許容される場合は、Lambdaのオンデマンド実行など、コスト効率を優先した設計も選択できます。

出典

4.2 単一障害点の防止

概要

サーバ・データセンタ（AZなど）など、停止するとサービス全体が止まってしまう単一障害点を作らない構成にします。

理由・背景

可用性設計の出発点は「どこか1か所が停止してもサービス全体が止まらない」状態を作ることです。サーバ単位・データセンタ単位の単一障害点を放置すると、そこに障害が起きた瞬間にサービス全体が停止するため、1箇所が停止しても他の箇所でシステムを継続できる構成にすることが重要です。

実施基準

推奨。特別な事情がなければ実施を推奨します。

構成例1: サーバの複数台運用

サーバ（EC2インスタンスまたはECSタスク）を最低2台以上で運用し、ALB（Application Load Balancer）でリクエストを分散します。1台が障害で停止しても、残りのサーバでサービスを継続できます。データベースの場合は、RDSのリードレプリカやAuroraのWriter/Reader構成を利用することで、読み取り処理を複数インスタンスに分散できます。

関連セクション: ELB概要

構成例2: マルチAZ構成

複数のアベイラビリティゾーン（AZ）にリソースを分散配置します。RDSはMulti-AZ配置を有効化してプライマリ障害時に自動フェイルオーバーさせ、ALBとECSタスクも複数AZに分散配置することで、AZ単位の障害にも耐えられる構成にします。

関連セクション: 冗長化構成を組み立てよう

構成例3: 可用性が組み込まれたマネージドサービスの活用

S3・DynamoDB・LambdaなどのAWSマネージドサービスは、リージョン内で自動的に複数AZへ複製・冗長化されています。これらを利用すれば、自前でマルチAZ構成を組まなくてもサービスを利用するだけで高い可用性が確保されるため（例: S3の標準クラスは99.99%の可用性、DynamoDBは複数AZへ自動レプリケーション）、単一障害点を意識せずに設計できます。

構成例4: ヘルスチェックによる異常インスタンスの切り離し

ALBやコンテナオーケストレータ（ECS / EKS など）のヘルスチェックを設定し、/healthエンドポイントで各インスタンスの正常／異常を判定します。異常と判定されたインスタンスは振り分け対象から自動的に除外されるため、故障の影響がユーザに波及するのを防げます。

出典

4.3 オートスケーリング

概要

負荷に応じて自動的にリソースを増減させるオートスケーリングの仕組みを導入します。

理由・背景

サービスの成長に伴いアクセス数は増加します。負荷に追従できる仕組みがなければ、急激なアクセス増加に対応できずサービスがダウンしてしまいます。手動でのスケーリング対応では時間がかかるため、自動化された仕組みを組み込んでおくことが重要です。

実施基準

推奨。特別な事情がなければ実施を推奨します。

構成例1: EC2 / ECSのオートスケーリング

EC2 Auto Scaling や Application Auto Scaling（ECS）を設定し、CPU使用率やリクエスト数などのメトリクスに基づいてサーバ・タスク数を自動的に増減させます。ピーク時にはスケールアウトし、閑散時にはスケールインすることで、コストとパフォーマンスを両立させます。

関連セクション: オートスケーリング概要

構成例2: RDSのオートスケーリング

RDSはライターインスタンスを複数台に増やせないため、ライター側はインスタンスクラスを上げる垂直スケーリングで性能を確保します。読み取り処理はリードレプリカを追加して台数を増やす水平スケーリングで負荷を分散でき、AuroraではApplication Auto Scalingと組み合わせて読み取り負荷に応じたレプリカ数の自動調整も可能です。さらにAurora Serverless v2を採用すると、ライター側も負荷に応じてキャパシティ（ACU: Aurora Capacity Unit）が自動でスケールします。

関連セクション: RDS概要

構成例3: マネージドサービスの活用

Lambda・DynamoDB（On-Demandモード）・S3などのマネージドサービスは、利用者がスケーリング設定を意識しなくても、AWS側でリクエスト数や負荷に応じて自動的にキャパシティが調整されます。サービス採用そのものがオートスケーリング対応につながります。

出典

4.4 キャッシュの活用

概要

同じリクエストが繰り返される場合は、キャッシュを活用します。

理由・背景

同じリクエストや同じデータへの問い合わせが繰り返される場合、毎回サーバやデータベースで処理するのは非効率です。キャッシュを導入することで、サーバやデータベースへのアクセス自体を減らし、負荷の軽減とレスポンスの高速化を同時に実現できます。

実施基準

推奨。特別な事情がなければ実施を推奨します。

構成例1: CloudFront（CDN）による静的コンテンツのキャッシュ

画像、CSS、JavaScriptなどの静的ファイルをCloudFrontのエッジロケーションにキャッシュします。ユーザに近いエッジロケーションからコンテンツを配信することで、レスポンス時間を大幅に短縮できます。

関連セクション: CloudFront概要

構成例2: ElastiCache（Redis）によるクエリ結果のキャッシュ

頻繁にアクセスされるデータベースのクエリ結果や、セッション情報をElastiCache（Redis）にキャッシュします。データベースへの問い合わせ回数を削減し、応答速度をミリ秒単位に短縮できます。

出典

4.5 疎結合なシステム構成

概要

サービス間の連携を疎結合にすることで、障害発生時の影響が全体に波及するのを防ぎます。

理由・背景

コンポーネント同士が密結合だと、片方の障害や負荷が連鎖して全体に影響します（カスケード障害）。状態や処理の依存を切り離して疎結合に設計しておくことで、依存先に障害が発生しても可能な機能だけでもシステムを動作させられるようになり、システム全体の可用性を高められます。

実施基準

必須。可用性を支える基盤設計のため、必ず実施します。

構成例1: ステートレスなアプリケーション設計

サーバ側にセッション情報やユーザの状態を保持せず、リクエストごとに必要な情報を受け取って処理する設計にします。セッション情報はElastiCache（Redis）やDynamoDBなどの外部ストアに切り出すことで、どのサーバにリクエストが振り分けられても同じ情報にアクセスでき、Auto Scalingやロードバランサが本来の効果を発揮できます。

構成例2: 非同期処理によるサービス間の切り離し

時間のかかる処理（画像変換、PDFの生成、メール送信など）をSQSキューに投入し、バックグラウンドのワーカーが非同期で処理します。ユーザへのレスポンスは即座に返し、処理完了後に改めて通知する仕組みにすることで、リクエスト元と処理の実行を切り離せます。

関連セクション: SQS概要

構成例3: イベント駆動アーキテクチャ

EventBridgeなどを利用して、システム内で発生するイベント（注文完了、ユーザ登録など）をトリガーに後続処理を非同期実行します。サービス間が直接呼び出し合う必要がなくなり、片方の変更や障害がもう片方に直接波及しない疎結合なアーキテクチャを実現できます。

関連セクション: EventBridge概要

構成例4: タイムアウトとリトライ

外部APIや他サービスへの呼び出しには、適切なタイムアウトとリトライを設定します。応答が返ってこないまま長時間待ち続けると呼び出し元のリソースを消費し続けるため、タイムアウトで処理を打ち切ります。

また、一時的なネットワークエラーなどに対してはエクスポネンシャルバックオフでリトライすることで、依存先の一時的な障害が呼び出し元へ波及するのを防げます。

出典

4.6 バックアップとリストア

概要

データ消失に備えて、バックアップを取得し、それを復旧するリストア戦略を整備します。

理由・背景

データ消失は事業継続に関わる致命的な問題です。さらにバックアップを取得するだけでなく、リストア手順が確立されていなければ「バックアップは取っていたが、復元方法がわからない」という事態に陥ります。さらに、リージョン全体に影響する大規模障害（自然災害・大規模停電・AWS側の広域障害など）に対しても、復旧戦略を事前に設計しておく必要があります。

実施基準

状況に応じて検討。データやサービスの重要度、再生成の可否に応じて判断します。失うことが許されないデータを扱う場合や事業継続に直結するサービスでは、必ず実施します。

構成例1: 定期的なバックアップ取得

RDSの自動バックアップ機能やAWS Backupなどを利用して、日次でスナップショットを取得します。RDSの保持期間は最大35日まで指定でき（Backup retention period（Amazon RDS公式ドキュメント）に「between 0 and 35 days」と明記）、古いバックアップは自動的に削除されます。AWS Backupを利用すれば、RDS・EBS・S3など複数サービスのバックアップを一元管理できます。

関連セクション: RDS概要

構成例2: リストア方法の策定と定期的なリハーサル

バックアップからの復旧手順を文書化し、四半期に1回など定期的にリハーサル（リストア訓練）を実施します。「バックアップは取っていたが、復元方法がわからない」「手順書が古くて動かない」という事態を防ぐため、復旧にかかる時間（RTO）と復旧可能なデータの時点（RPO）が要件を満たすかを定期的に検証します。

構成例3: マルチリージョンへのデータ配置

リージョン全体に影響する障害（自然災害・大規模停電・AWS側の広域障害など）に備え、別リージョンにデータを継続的に複製しておきます。S3・Aurora・DynamoDBなどの主要なストレージ・データベースサービスにはリージョン間でデータを複製する仕組みが用意されているため、これらを活用することでリージョン障害時にも別リージョンから業務を継続できる構成にできます。

出典

4.7 DDoS対策

概要

大量のリクエストを集中させてサービスを停止に追い込むDDoS攻撃への対策を行います。

理由・背景

DDoS攻撃を受けると正常なリクエストが処理できなくなり、サービス停止につながります。攻撃を受けてからでは対処が難しいため、基本対策は事前に導入しておく必要があります。

実施基準

推奨。特別な事情がなければ実施を推奨します。

構成例1: AWS Shieldによる基本的なDDoS対策

AWS Shieldは、DDoS攻撃からAWSリソースを保護するマネージドサービスです。Standardは追加コストなしでL3/L4のDDoS攻撃を自動緩和し、すべてのAWSアカウントでデフォルト有効です。Advancedは有償サブスクリプションで、より大規模・高度な攻撃への対応や、専門家による支援、攻撃時のコスト保護など、Standardより手厚い保護を受けられます。詳細はHow AWS Shield and Shield Advanced work（AWS公式ドキュメント）に記載があります。

構成例2: アクセス制限

利用者やアクセス元が限定される場合は、接続元を制限することで攻撃そのものを減らせます。社内システムであれば社内IPアドレスやCIDR範囲に絞る、サービス間の通信であれば特定のVPC内に閉じる（VPCエンドポイントの利用やSecurity Groupでの制限）といった対策が有効です。攻撃者がそもそも到達できない構成にすることで、DDoSのリスクを大きく下げられます。

構成例3: レートリミット

AWS WAFのレートベースルールやAPI Gatewayのスロットリングなどを使って、一定時間内に同一IPから受け付けるリクエスト数の上限を設定します。正当な利用者のリクエストは通しつつ、短時間で大量の通信を仕掛けてくる攻撃トラフィックを自動的にブロックできます。

構成例4: ブラックリストの導入

問題があると報告されているIPアドレスやボットからのアクセスを、ブラックリストとして遮断します。AWSではWAFのマネージドルール（評判の悪いIPアドレスのリストやボット検知機能）などを活用することで、利用者がIPを個別管理する手間を省きつつ、既知の脅威からのアクセスを自動的にブロックできます。

出典

4.8 性能テスト

概要

システムに負荷がかかっても正常に動作・停止することを確認する**負荷試験（パフォーマンステスト）**を行います。

理由・背景

事前に性能のボトルネックを特定し対策を講じることで、リリース後のレスポンス劣化や障害を防げます。特に大規模なプロモーションやサービスの成長期など、負荷が一時的に跳ね上がる場面で効果を発揮します。

また、高負荷時に処理が正常に動作するだけでなく、スケールインやデプロイのタイミングで処理を正常に終了できることも重要で、途中で強制終了されるとデータ不整合や処理漏れにつながります。

実施基準

状況に応じて検討。常時必須ではないものの、システムが大規模になってきたタイミングなど、負荷が予測される場面で実施を検討します。

施策例1: 負荷試験の実施

想定されるピークトラフィック（例: 同時1,000ユーザ）を再現し、レスポンスタイムの劣化やエラー率が上昇するポイントを特定して、ボトルネックを事前に解消します。

ツールとしてはk6やJMeterなどがあり、シナリオを書いてサーバに疑似的な負荷をかけることで、実際にユーザからアクセスされる前に性能特性を把握できます。

出典

5. オブザーバビリティ

オブザーバビリティ（可観測性, Observability）は、システムの状態を外部から観測・把握し、問題を迅速に検知・対応するための仕組みです。ログ・メトリクス・トレースの3つの柱で構成されることが一般的です。

5.1 アプリケーションログの取得

概要

各サービスが出力するアプリケーションログを、集約基盤に送信して一元的に保存・検索できるようにします。

理由・背景

アプリケーションログがないと、障害発生時に「何が起きたか」「どこで失敗したか」を追う手がかりが残らず、原因究明・影響範囲の特定・再発防止のいずれも打てなくなります。ユーザから「動かない」と言われても、開発者側では何ひとつ状況を把握できない状態になってしまいます。

特にコンテナやサーバレス環境では実行環境が起動・停止を繰り返すため、ローカルに保存されたログはすぐに消失してしまい、外部の集約基盤に送信していないと後から見返すこと自体ができません。

実施基準

必須。ログがなければ障害発生時に原因究明ができず、対応も再発防止も打てないため、必ず実施します。対応しない場合、致命的なリスクが発生する可能性があります。

構成例1: CloudWatch Logsへのログ集約

ECSタスクやLambda関数のログをCloudWatch Logsに集約します。ロググループとログストリームで整理し、CloudWatch Logs Insightsでクエリを実行することで、横断的なログ検索と分析が行えます。

構成例2: 構造化ログ（JSON形式）での出力

ログをJSON形式で構造化して出力します。フィールド名で直接フィルタや集計ができるため、非構造化ログのように正規表現を組み立てる必要がなくなり、調査時間を大幅に短縮できます。

非構造化ログの例:

2024-01-15 10:30:45 ERROR Failed to process order #12345 for user john_doe

構造化ログ（JSON）の例:

{
  "timestamp": "2024-01-15T10:30:45Z",
  "level": "ERROR",
  "message": "Failed to process order",
  "orderId": "12345",
  "userId": "john_doe"
}

CloudWatch Logs Insightsで filter level = "ERROR" | stats count() by userId のようなクエリで、ユーザ単位のエラー集計などが容易になります。

出典

5.2 アクセスログの取得

概要

システムに流れ込むリクエストや通信の記録を、アクセスログとして保存します。

理由・背景

アクセスログを残しておくことで、どのIPアドレスから、どのパスに、どの程度のリクエストが来たかを後から追えます。障害調査時のリクエスト再現、不正アクセスの特定、パフォーマンス分析など、幅広い場面で活用できます。

実施基準

推奨。障害調査・監査対応・不正アクセス調査など幅広い場面で必要になるため、可能な限り実施を推奨します。

構成例1: ALB/CloudFrontアクセスログのS3保存

ALBやCloudFrontなどのアクセスログをS3バケットに集約し、長期保存します。監査対応やフォレンジック調査に備え、保存期間のルール（例: 1年間保持）を定めます。

構成例2: VPC Flow Logsによるネットワークトラフィックの記録

VPC Flow Logsを有効化し、VPC内のネットワークインタフェース間のトラフィック情報（送信元・宛先IP、ポート、プロトコル、許可・拒否など）を記録します。不審な通信の検知や、セキュリティグループ設定のトラブルシュートに活用できます。

構成例3: WAFアクセスログの保存

AWS WAFのログをS3やCloudWatch Logsに配信し、リクエストごとにマッチしたルールと判定結果（Allow / Block / Count）を記録します。ALB/CloudFrontのアクセスログには含まれないWAFの評価内容が残るため、Blockされたリクエストの詳細調査や、不正アクセスの傾向分析に活用できます。

出典

5.3 監査ログの取得

概要

クラウド環境やシステムに対して、「誰が」「いつ」「何を」操作したかを記録する監査ログを取得します。

理由・背景

不正アクセスや設定変更ミスが起きた際に、「誰が何をしたか」を追えないと原因究明も再発防止もできません。監査ログを取得しておくことで事後の追跡が可能になり、コンプライアンス対応の観点でも必須となる場面が多いです。

実施基準

必須。事態収束と監査対応のため、必ず実施します。対応しない場合、致命的なリスクが発生する可能性があります。

構成例1: CloudTrailによるAPI操作履歴の保存

CloudTrailを有効化し、AWSアカウント内で行われたすべての操作（誰が、いつ、何をしたか）の履歴を保存します。不正な操作や設定変更があった場合の追跡に必須です。

構成例2: AWS Configによるリソース構成変更履歴の記録

AWS Configを有効化し、AWSリソースの構成情報がどのように変化したかを継続的に記録します。「いつ・どのリソースが・どう変更されたか」を後から確認でき、不正な設定変更や意図しない構成ドリフトの検出、コンプライアンス監査への対応に活用できます。

出典

5.4 セキュリティイベントの集約

概要

複数のセキュリティサービスの検知結果を1か所に集約して、対応漏れが起きないように監視できる仕組みを整えます。

理由・背景

GuardDuty・Inspector・IAM Access Analyzer・Configなど、AWSのセキュリティ関連サービスはそれぞれが個別にfindings（検知結果）を出します。バラバラに確認していると対応漏れが発生するため、一元的に集約して監視・対応する仕組みを整えることが重要です。

実施基準

推奨。現在のベストプラクティスとして導入を推奨します。

構成例1: Security Hubによるセキュリティ発見事項の集約

Security Hubを有効化し、GuardDuty・Inspector・IAM Access Analyzerなどのfindingsを1つの画面で集約します。CIS AWS Foundations Benchmarkなどの標準に対する準拠状況も一元的に確認でき、対応漏れを防げます。

構成例2: Security Lakeによるセキュリティログの長期保存・分析

Security Lakeを利用して、CloudTrail・VPC Flow Logsなどのセキュリティ関連ログを統一的なフォーマットでS3に集約します。Amazon AthenaやサードパーティのSIEMツールから横断的に分析できるようになります。

関連セクション: Security Lake概要

出典

5.5 メトリクス監視

概要

システムの状態を数値として継続的に把握するためのメトリクス監視を導入します。

理由・背景

「重い」「繋がらない」といった問題が発生した際に、メトリクスがなければ原因の特定ができません。CPU使用率やメモリ使用率などの基本的なメトリクスを常時監視することで、異常の早期検知と迅速な対応が可能になります。

実施基準

推奨。現在のベストプラクティスとして導入を推奨します。

構成例1: CloudWatch Metricsの活用

AWSの標準機能であるCloudWatch Metricsで、EC2のCPU使用率、RDSの接続数、ALBのリクエスト数やレスポンスタイムなどの基本メトリクスを収集・可視化します。追加設定なしでAWSリソースの主要メトリクスが自動取得されるため、まず最初に導入する監視基盤として活用できます。

構成例2: PrometheusとGrafanaによる監視

OSSの時系列データベースPrometheusでメトリクスを収集・保存し、Grafanaでダッシュボードとして可視化します。豊富なExporterを利用してミドルウェアやアプリケーションのメトリクスを柔軟に取得でき、コンテナ・VM・オンプレを問わず広く採用されているOSSの定番構成です。AWSではマネージドサービス（Amazon Managed Service for Prometheus / Amazon Managed Grafana）も利用できます。

構成例3: SaaS型監視サービスの利用

DatadogやNew Relicといった商用SaaS型の監視サービスを導入します。メトリクス・ログ・トレースが1つのプラットフォームで統合されており、複雑なアプリケーション監視や、AWSと他クラウド／オンプレを横断した監視が求められる場面で強力です。

出典

5.6 アラート通知

概要

異常検知時に自動的に担当者へ通知を届けるアラート通知を設定します。

理由・背景

ユーザからのクレームで障害に気づく状態は避けるべきです。監視メトリクスに閾値を設定し、異常を検知した時点で自動的に通知を送ることで、障害の影響を最小化できます。

実施基準

推奨。現在のベストプラクティスとして導入を推奨します。

構成例1: CloudWatch Alarmsによるメトリクス閾値の検知

CloudWatch Alarmsでメトリクスの閾値（例: CPU使用率80%超過、5xxエラー率1%超過）を設定し、異常を検知した際にSNS経由でSlackチャンネルやメール、PagerDutyなどへ通知を送信します。オンコール担当者がリアルタイムで障害に気づける体制を構築します。

関連セクション: SNS概要

構成例2: エラーログの監視と通知

CloudWatch Logsのメトリクスフィルタやサブスクリプションフィルタで、アプリケーションログ中の ERROR や Exception などの特定パターンを検知し、Lambda経由またはSNSで通知を送信します。メトリクス（数値）からは見えないアプリケーションレベルの問題を早期に発見できます。

構成例3: 外部監視サービスによる外形監視

Datadog SyntheticsやNew Relic Syntheticsなどの外部監視サービスを利用して、定期的にWebサイトのエンドポイントにアクセスし、レスポンスコードやレスポンスタイムを監視します。AWS外のインフラから監視するため、ユーザと同じ視点でサービスの稼働状態を確認でき、内部のメトリクスが正常でもネットワーク経路やDNSの問題でアクセスできないといった、内部監視では検知できない障害も発見できます。

出典

5.7 障害検知時の自動復旧

概要

障害を検知した際に、人手を介さずシステムを自動的に復旧させる仕組みを組み込みます。

理由・背景

人手で対応するとMTTR（平均復旧時間）が長くなり、その間サービスが低下・停止した状態が続きます。よく起きる障害パターンについて検知後の復旧アクションを自動化することで、影響時間を最小化できます。特に夜間・休日など人手を割きにくい時間帯や、大量発生する定型的なインシデントで効果が大きくなります。

実施基準

段階に応じて検討。基本的な自動復旧はオートスケーリングやヘルスチェックで実現できるものの、より高度な復旧処理を自動化する段階で導入を検討します。

構成例1: CloudWatch AlarmsとLambdaによる復旧ロジック

CloudWatch Alarmsで異常を検知した際に、SNS経由でLambdaを実行し、あらかじめ定義した復旧ロジック（例: プロセス再起動、キャッシュクリア、フェイルオーバなど）を実行します。よく起きる障害パターンに対して自動対応することで、MTTRを短縮できます。

構成例2: DevOps Agentによる障害対応の自動化

AIベースのDevOps Agentを導入し、障害発生時のログ・メトリクス・トレース情報を元に、原因分析から復旧アクションまでを自動的に実行します。定型的な障害だけでなく、事前定義していないパターンに対しても柔軟に対応できます。

関連セクション: DevOps Agent概要 ・ DevOps Agentでインシデント対応を自動化しよう

出典

5.8 分散トレーシング

概要

複数サービスをまたぐリクエストの流れを可視化する分散トレーシングを導入します。

理由・背景

複数のサービスにまたがるリクエストでは、どのサービスがボトルネックになっているかを特定することが困難です。分散トレーシングにより、リクエストの全体的な流れを可視化し、遅延の原因を特定できます。

実施基準

段階に応じて検討。シンプルな構成では必須ではないものの、複雑なアーキテクチャでボトルネックを特定する段階で導入を検討します。

構成例1: AWS X-Rayによる分散トレーシング

AWSが提供するマネージドの分散トレーシングサービスであるAWS X-Rayを有効化し、リクエストがAPI Gateway → Lambda → DynamoDBと流れる過程の処理時間を可視化します。各コンポーネントの所要時間がサービスマップ上で確認でき、レスポンス遅延のボトルネックを即座に特定できます。AWSサービスとの統合が強力で、Lambda / API Gateway / ECS などで最小限の設定で計装できます。

構成例2: OpenTelemetryによる計装とバックエンドの選択

CNCFの標準規格であるOpenTelemetryのSDKやCollectorで計装し、トレースデータをX-Ray・Jaeger・Grafana Tempo・Datadog・New Relicなど任意のバックエンドに送信します。ベンダー中立の計装なのでバックエンドを後から切り替えられ、マルチクラウド環境や将来の構成変更を見据えた採用に適しています。

出典

6. まとめ

この章では、小〜中規模のWebシステム向けの非機能要件チェックリストについて学びました。

• 非機能要件は、機能そのものではなく可用性・性能・セキュリティ・運用など「どのような品質で提供するか」を定めた要件である
• 技術選定（プログラミング言語・DB・クラウド・IaC・CI/CD）は、要件と組織の力量に応じてトレードオフを踏まえて決める
• 可用性は、SLO／SLA、マルチAZ・マルチリージョン、DR、バックアップとリカバリの観点で設計する
• 性能・拡張性は、レスポンスタイム目標、キャッシュ、オートスケーリング、負荷試験の観点で設計する
• 運用・保守性は、監視・ログ・アラート・オンコール体制の観点で組み立てる
• セキュリティは、認証・認可、暗号化、脆弱性管理、監査ログの観点で多層防御を組む
• 各項目に対応の優先度を設定しているため、プロジェクトの規模やフェーズに応じてどこに力を入れるかを判断できる