しかし、GitLabがプライベートネットワーク内にあり、AWSアカウントも異なるとなると、話はそう単純ではありません。

今回、EC2上のGitLab Self-ManagedとCodeBuildを連携するため、AWS CodeConnectionsの設定を進める過程で、次のエラーが問題となりました。

Invalid host endpoint provided.

当初は、Transit Gateway（TGW）でVPC間の通信経路を確保すれば、あとはCodeConnectionsの設定だけで済むと考えていました。ところが、AWSサポートへの問い合わせを通じて、VPC接続、自己署名証明書、GitLabの認証、さらにCodeBuildのソース取得方式まで、切り分けるべき論点が次々と出てきました。

本記事では、この事例を基に、閉域環境でCodeConnectionsを利用する際の設計ポイントを整理します。

本記事の検証範囲

1. GitLabとCodeBuildを別AWSアカウントで連携する

今回の構成は、次のとおりです。

GitLabにはパブリックIPアドレスがなく、インターネットから直接アクセスできない構成です。

VPC間はTGWで接続されていますが、TGWの接続が存在することと、CodeConnectionsからGitLabへ通信できることは別の話です。

さらに、CodeConnectionsの接続設定、GitLab側での認可、CodeBuildによるソース取得では、それぞれ異なる通信や権限が関係します。

最初はネットワークの問題だと思っていたものが、調べていくと認証や証明書の問題にも広がっていく。複数のAWSサービスを組み合わせる際に、こうした切り分けの難しさを感じる場面は少なくありません。

2. CodeConnectionsの「ホスト」と「接続」は別物

エラーの原因を考える前に、CodeConnectionsの仕組みを整理しておきます。

GitLab Self-Managedとの連携では、「ホスト」と「接続」という2種類のリソースを扱います。

ホストはGitLabの設置環境を表すリソースで、GitLabのURL、VPC、サブネット、セキュリティグループ、必要に応じたTLS証明書などを設定します。

一方、接続はGitLabアカウントによる認可を受け、AWSサービスからリポジトリへアクセスするためのリソースです。

両者を区別すると、ネットワークや証明書の設定と、GitLabへのアクセス認可を分けて考えられます。

PATはホストの認可に使用する

GitLab Self-Managedのホストをセットアップする際には、Personal Access Token（PAT）を使用します。

AWS公式ドキュメントによれば、PATには次の要件があります。

• GitLab管理者が作成・使用する
• apiスコープが必要
• GitLabのAdmin Modeが有効な場合はadmin_modeも必要
• PATはホストの認可に使用され、接続では保存・使用されない
• ホストのセットアップ後にPATを削除できる

つまり、ホストの認可に使用したPATを、そのまま継続的なリポジトリアクセス用の認証情報として保持する必要はありません。

参考：AWS公式｜GitLab Self-Managedへの接続作成

3. Invalid host endpoint provided. とVPC設定の関係

今回のエラーは、CodeConnectionsでGitLab Self-Managedのエンドポイントを設定する際に発生したものです。

Invalid host endpoint provided.

AWSサポートからは、「VPCを使用する」が無効の状態でプライベートIPを指定すると、このエラーが発生するという説明がありました。

また、VPC接続を有効にして必要なネットワーク設定を行うことで、Availableに至ったという経緯も示されています。

このため、今回のエラーを切り分けるうえでは、接続先URLだけでなく、VPC接続の設定が有力な確認ポイントになります。

プライベートIPのGitLabにはVPC接続を検討する

AWS公式ドキュメントでは、GitLab Self-Managedがプライベートネットワーク内に存在する場合、ホストの作成時に「Use a VPC」を選択する構成が示されています。

設定する主な項目は、VPC ID、サブネットID、セキュリティグループIDです。

ここで注意したいのは、GitLabが稼働するVPCと、CodeConnectionsに設定するVPCが必ずしも同一とは限らないことです。

AWS公式手順では、VPNやDirect Connectを経由してGitLabへアクセスできるVPCの例が示されています。一方、今回のような別アカウント間のTGW構成については、同じ手順の中で明示的な例示がありません。

今回の構成ではTGWを利用し、CodeConnectionsのAvailable表示まで到達しています。ただし、これだけでTGW経由のあらゆる構成がサポートされると判断することはできません。

エラーが発生した場合の切り分け

同じエラーに遭遇した場合、まず次の4点を調べます。

1. GitLabのエンドポイントURLが適切か
2. プライベートIPへの接続に対応したVPC設定になっているか
3. 設定したVPC・サブネットからGitLabへの経路があるか
4. HTTPSの証明書が接続先と整合しているか

特に、プライベートIPを指定しているにもかかわらずVPC接続を使用していない場合は、最初に見直したい設定です。

4. 閉域接続では、作業端末からのアクセスも必要になる

AWSからGitLabへのネットワーク疎通を考える際、見落としやすいのが接続の認可操作です。

CodeConnectionsの公式手順では、接続を作成した後、ブラウザでGitLabにサインインし、「Authorize」を選択して認可します。

AWS CLIやCloudFormationで接続リソースを作成した場合も、初期状態はPENDINGとなり、コンソールで認可を完了させる必要があります。

ここで問題になるのが、設定作業を行う端末からGitLabへアクセスできるかという点です。

例えば、AWS側のVPCからGitLabへ通信できても、作業PCが社内ネットワーク外にあり、GitLabのプライベートIPに到達できなければ、ブラウザで認可操作を進められない可能性があります。

この場合は、社内VPNや管理用端末など、GitLabへアクセスできる正規の操作環境を用意する必要があります。

AWSサービス間の通信経路だけを考えていたところに、作業端末からのアクセスという別の問題が出てくる。閉域ネットワークの設計では、こうした運用面まで含めて考える必要があります。

5. TGW経由の通信と自己署名証明書をどう扱うか

今回の構成では、GitLabとCodeBuildが異なるAWSアカウントに存在します。

VPC間はTGWで接続されていますが、TGWが存在するだけでは通信は成立しません。

少なくとも、次の項目を整理する必要があります。

特に、CodeConnectionsとCodeBuildを同じ通信元として扱わないことが大切です。

どのコンポーネントがGitLabに接続するかによって、必要なネットワーク設定は変わります。

自己署名証明書の設定先

今回のGitLabでは、HTTPS通信に自己署名証明書を使用しています。

AWS CodeConnectionsには、非公開認証局を利用する環境向けにTLS証明書を指定する設定があります。

ただし、証明書を登録することと、TLS接続が正常に検証されることは同じではありません。

接続先としてIPアドレスを使用する場合、証明書のSubject Alternative Name（SAN）に、そのIPアドレスが登録されているかが論点になります。

証明書を信頼できても、接続先のIPアドレスが証明書と一致しなければ、ホスト名検証で失敗する可能性があります。

この点は、実際の証明書をopenssl x509 -textなどで調べることで確認できます。

6. CodeBuild側にもVPCや証明書の設定が必要なのか

今回、最も気になったのが、CodeBuild側の証明書設定に関するAWSサポートの回答です。

サポートからは、CodeConnections側で証明書を設定していれば、CodeBuild側に特別な証明書設定は必要ないという趣旨の説明がありました。

当初は、CodeConnectionsがGitLabとの通信を担うのであれば、その説明で理解できそうに思えました。しかし、CodeBuildの公式仕様を調べていくと、一つ疑問が残りました。

CodeBuildが実際にGitLabからソースを取得する際、HTTPS通信はどのコンポーネントが実行するのでしょうか。

この点を整理しないまま、CodeBuild側の証明書設定が不要と判断するのは早いと感じました。

ビルド環境からGitLabへ接続するならVPC設定が必要

CodeBuildのビルド環境から直接GitLabへGit cloneを実行する方式であれば、プライベートIPしか持たないGitLabへ到達できるネットワーク経路が必要です。

通常、VPC設定のないCodeBuildのビルド環境はAWS管理のネットワークで動作するため、TGWで接続されたプライベートVPCへ、そのままアクセスできるわけではありません。

したがって、ビルド環境が直接GitLabへ接続する方式なら、CodeBuild側にも到達可能なVPC設定と通信経路が必要になります。

一方、CodeConnections側の仕組みでソース取得が完結する方式なら、必要なネットワーク構成は異なります。

残る論点は、今回のCodeConnectionsを利用したソース取得が、どちらの方式で動作するかです。

GetConnectionTokenから読み取れること

AWSのCodeBuild向けGitHub App接続手順では、サービスロールに次のIAM権限を付与する例が示されています。

{
  "Effect": "Allow",
  "Action": [
    "codeconnections:GetConnectionToken",
    "codeconnections:GetConnection"
  ],
  "Resource": "arn:aws:codeconnections:<region>:<account-id>:connection/<id>"
}

GetConnectionTokenは、接続に関連する認証トークンを取得するためのアクションです。

この仕組みから、CodeBuildが接続を通じて認証情報を取得し、ソース取得処理に利用する構成が考えられます。

ただし、認証トークンを取得することと、ビルド環境から直接GitLabへ通信することは同義ではありません。IAM権限だけで実際の通信元を特定することはできません。

なお、上記はGitHub App向け公式手順を基にした説明用のポリシー例です。実際のGitLab Self-Managed構成では、接続方式と必要権限に合わせて調整する必要があります。

参考：AWS公式｜GitHub App connections

証明書検証を無効化すればよいのか

CodeBuildのProjectSource APIには、insecureSslという設定項目があります。

ただし、この設定はCodeConnectionsのホスト側で実施するTLS検証とは別のものです。今回のGitLab Self-Managed＋CodeConnections構成に適用できるかも、ソース取得方式によって異なります。

AWSサポートからは、CodeConnections側のTLS証明書検証を無効化することはできないとの説明がありました。

いずれにしても、証明書検証を無効化してエラーを回避するのは、セキュリティ上望ましい対応ではありません。

自己署名証明書を使用する場合でも、適切なCA証明書の信頼設定と、接続先のホスト名またはIPアドレスとの整合性を確保することが基本です。

実際の通信元をどう調べるか

CodeBuildの実行結果が得られるなら、まずDOWNLOAD_SOURCEフェーズのログを調べます。

ソース取得の段階で失敗しているのか、取得後のビルド処理で失敗しているのかを分けるためです。

さらに、GitLab側のVPC Flow Logsを利用し、通信元IPアドレスを調べる方法があります。

通信元IPとENIの対応関係を照合すれば、CodeConnections側のネットワークコンポーネントからの通信なのか、CodeBuild側からの通信なのかを判断する手掛かりになります。

必要に応じてGitLab側のアクセスログとも突き合わせれば、より具体的に切り分けられます。

今回、CodeBuildの実行検証はできていませんが、設計段階では次の4点を整理しておきたいところです。

7. AWSサポートへの問い合わせで重要なのは、設定値より前提条件

今回の問い合わせを整理する中で、改めて感じたのは、エラーメッセージだけを伝えても、問題の本質にはなかなかたどり着けないということです。

最初は「GitLabに接続できない」という問題でも、構成を整理すると、プライベートIP、TGW、自己署名証明書、GitLabの認可など、複数の条件が関係しています。

そこで、問い合わせの前提として、次の情報を整理することが有効になります。

• GitLab Self-ManagedがEC2上で稼働している
• GitLabはプライベートIPのみを使用している
• AWSアカウント間をTGWで接続している
• HTTPSには自己署名証明書を使用している
• CodeConnectionsのエンドポイント設定時にエラーが発生している

このように整理すると、単なる接続エラーではなく、どのコンポーネント間の通信に問題があるのかを議論しやすくなります。

さらに、AWSサポートには設定方法だけでなく、設定が必要になる条件まで尋ねたいところです。

例えば、CodeBuild側の証明書設定について疑問が残るなら、次のように質問します。

GitLab Self-Managedへのソース取得にCodeConnectionsを利用する場合、GitLabへのHTTPS通信はどのコンポーネントが実行するのでしょうか。CodeBuild側にVPC設定やCA証明書の登録が必要になる条件を教えてください。

これは、単に「CodeBuild側の証明書設定は必要ですか」と聞くよりも、通信経路と責任分界を明確にできる質問です。

長年、基盤設計やシステム間連携に関わってきましたが、複数の製品やサービスが絡む問題では、個々の設定よりも、サービス間の境界に原因が潜んでいることが少なくありません。

今回のCodeConnectionsも、そうした視点で考える必要がある事例でした。

8. まとめ｜マネージドサービスでも基盤設計は不要にならない

今回、CodeConnectionsでGitLab Self-Managedへの閉域接続を構成する過程で、Invalid host endpoint provided. というエラーが問題となりました。

AWSサポートからは、プライベートIPを使用する場合のVPC接続設定が有力な原因として示され、CodeConnectionsのAvailable表示まで到達しています。

今回の検討から得られる教訓は、次の3つです。

第一に、AWSサービス間の接続でも通信経路を明確にする必要があります。 TGWが接続されているだけでは不十分で、ルートテーブル、セキュリティグループ、通信元の整理が欠かせません。

第二に、ネットワークと認証は別の問題です。 AWS側からGitLabへ到達できても、作業端末から認可画面へアクセスできなければ、接続のセットアップを完了できない場合があります。

第三に、接続ステータスと実際の処理成功は区別します。 CodeConnectionsがAvailableでも、CodeBuildのソース取得やビルド成功まで保証されたわけではありません。

AWSのマネージドサービスは、インフラの構築・運用負担を減らしてくれます。しかし、複数サービスを組み合わせた際の通信経路、認証、TLS証明書、IAM権限まで自動的に設計してくれるわけではありません。

マネージドサービスを利用することと、基盤設計が不要になることは別の話です。

今回の事例は、その基本を改めて考える機会になりました。

参考資料

• AWS公式｜GitLab Self-Managedへの接続作成
• AWS公式｜GitLab access in CodeBuild
• AWS公式｜GitHub App connections
• AWS公式｜CodeBuild ProjectSource API

ECS/Fargateでコンテナを非rootユーザーとして実行したところ、ログ出力先のディレクトリでPermission deniedが発生したことがありました。

Dockerfileでは、ログ出力先のディレクトリを作成し、アプリケーションを実行するユーザーへchownしていました。Dockerイメージだけを見ると、書き込みできるように設定されています。

問題が起きたのは、アプリケーションコンテナとFluent Bitコンテナでログ用のVolumeを共有する構成にしたときでした。

原因を調べていくと、Dockerfileの設定が常に無効になるという単純な話ではありませんでした。Dockerfile、ECSタスク定義、Volumeを個別に確認するだけではなく、それらを組み合わせた実行時の最終状態まで設計対象にできていたかという問題に行き着きました。

この記事では、実際に発生した事象と採用した対策を、AWS公式ドキュメントで確認できる仕様と照らし合わせて整理します。採用しなかった対策候補との違いも明確にしながら、設計段階で見落とした点と、事前のPoCで確認すべきだった内容を振り返ります。

ECS/FargateでPermission deniedが発生した

今回の構成を単純化すると、アプリケーションがファイルへログを書き込み、同じVolumeをマウントしたFluent Bitがそのログを読み取る構成でした。

Application Container
非rootユーザー
        │
        │ ログ書き込み
        ↓
    Shared Volume
        │
        │ ログ読み込み
        ↓
Fluent Bit Container

ECSのタスク定義では、Volumeを定義し、アプリケーションコンテナとFluent Bitコンテナの双方へマウントしていました。

本記事では、タスク定義でボリューム名を定義した空のデータVolumeを、AWS公式ドキュメントに合わせてbind mountと呼びます。AWS公式でも、bind mountの用途として、1つ以上のコンテナにマウントする空のデータVolumeが示されています。Fargateでは、bind mountにタスクへ割り当てられたエフェメラルストレージが利用されます。

詳細は、AWS公式「Amazon ECSでのバインドマウントの使用」とAWS公式「Amazon ECS向けのFargateタスクエフェメラルストレージ」で確認できます。

アプリケーションコンテナは非rootユーザーで動作させていました。Dockerfileでは、概念的には次のようにログ出力先を作成し、所有者を変更しています。

RUN mkdir -p /app/logs
RUN chown appuser:appgroup /app/logs

USER appuser

タスク定義側のuserによる上書きはなく、実行ユーザーはDockerfileのUSERで指定した非rootユーザーでした。

このDockerイメージだけを見ると、appuserが/app/logsへ書き込めるように見えます。

ところがECS/Fargate上でタスクを起動すると、アプリケーションがログを書き込む際にPermission deniedが発生しました。

Dockerfileでchownしたのに、なぜ書き込めなかったのか

問題のポイントは、Dockerfileでchownしたディレクトリと、ECS/Fargate上でアプリケーションが実際に書き込むディレクトリが、Volumeマウント後は同じものではなかったことです。

Dockerイメージ内では、/app/logsの所有者をappuserへ変更していました。

Docker Image
    │
    └─ /app/logs
         owner = appuser

この状態だけを見れば、appuserは/app/logsへ書き込めるように見えます。

ECSで同じ/app/logsへVolumeをマウントすると、イメージ内のディレクトリはマウントによって覆い隠されます。実行中のコンテナから見えるのは、Dockerfileでchownしたイメージ側の/app/logsではなく、Volume側の/app/logsです。

Docker Image
/app/logs
owner = appuser
        │
        │ ECS Task起動
        ↓
Volumeを /app/logs へmount
        │
        ↓
イメージ側の /app/logs は隠蔽
        │
        ↓
コンテナから見える /app/logs
＝ Volume側

Dockerfileで設定したディレクトリが削除されたわけではありません。同じパスへVolumeをマウントしたことで、イメージ側のディレクトリが実行中のコンテナから見えなくなっています。

Dockerfileでchownしていても、Volumeマウント後の/app/logsが同じ所有者・権限になるとは限りません。

今回見落としていたのは、この「イメージ作成時の権限」と「Volumeマウント後の実効権限」の違いでした。

DockerfileのVOLUMEとcontainerPathが一致する場合

ここまでだけを見ると、「VolumeをマウントするとDockerfile側の権限設定は使われない」と考えたくなります。

Amazon ECSには、もう一つ重要な仕様があります。

DockerfileのVOLUMEで指定した絶対パスと、タスク定義のcontainerPathが一致する場合、ECSはそのパス内のデータをデータVolumeへコピーします。

AWS公式ドキュメントには、非rootユーザー向けに対象ディレクトリをchownし、USERを指定した後にVOLUMEを宣言する例も掲載されています。この説明の中では、既定のVolume権限を0755、所有者をrootとし、Dockerfileでカスタマイズできることも示されています。

詳細は、AWS公式「Amazon ECSでのバインドマウントの使用」を参照してください。

概念的には次のような記述です。

RUN mkdir -p /app/logs
RUN chown appuser:appgroup /app/logs

USER appuser
VOLUME ["/app/logs"]

今回使用していたDockerfileには、ログ出力先をVOLUMEとして宣言する記述はありませんでした。

Dockerfile
/app/logs を appuser に chown
        │
        ↓
ECSで同じパスへVolumeをmount
        │
        ↓
イメージ側の /app/logs は隠蔽
        │
        ↓
VOLUME宣言なし
        │
        ↓
Volumeマウント後の権限で
書き込み可否が決まる

今回の構成では、Dockerfileでchownした/app/logsへVolumeをマウントしたことで、イメージ側のディレクトリは隠蔽されました。また、Dockerfileに対象パスのVOLUME宣言がなく、VOLUMEとcontainerPathを一致させてイメージ側の状態をVolumeへ引き継ぐ仕組みも利用していませんでした。

当時は、このDockerfileとECS Volumeを組み合わせた後に、実行時にどのような状態になるのかを設計観点として持っていませんでした。

VOLUME宣言がなかったことだけで、Permission deniedの原因をすべて説明できるわけではありません。実際の書き込み可否は、Volumeマウント後のowner、group、modeと、アプリケーションの実効UID/GID、書き込み対象パスの組み合わせで決まります。

今回の問題で重要だったのは、Dockerfileでchownしたという設定だけを見て書き込み可能と判断し、Volumeマウント後にどの所有者・権限になるのかを確認していなかったことです。

今回の案件ではVOLUMEを利用する方法は採用していないため、ここではAWS公式仕様から確認できる対策候補の一つとして扱います。

実効ユーザーもDockerfileだけで確認しない

ファイルやディレクトリの権限とあわせて確認する必要があるのが、コンテナを実際にどのユーザーで実行しているかです。

ECSでは、DockerfileのUSERとは別に、タスク定義のuserでも実行ユーザーを指定できます。このパラメータはDockerのUserや--userに対応します。

今回のタスク定義ではuserを指定しておらず、DockerfileのUSERを上書きする設定はありませんでした。

設計レビューで確認すべきなのは、「DockerfileにUSER appuserと書いてある」ことではありません。

ECS上で最終的にどのUID/GIDでプロセスが動き、そのユーザーがVolumeマウント後のパスへ必要な操作をできるかまで確認する必要があります。

Volumeの権限と同じく、Dockerfileやタスク定義を個別に見るだけでは不十分です。設計対象にすべきなのは、それらを組み合わせた後の実行時の最終状態です。

userパラメータの仕様は、AWS公式「FargateでのAmazon ECSタスク定義パラメータ」で確認できます。

対策はchownの方法だけで考えない

Permission deniedが発生すると、chmodやchownの方法から考えたくなります。

今回の構成を設計の観点から見直すと、その前に確認すべきことがあります。

アプリケーションコンテナとFluent Bitの間に、そもそも共有Volumeが必要なのか。

権限をどう合わせるかだけではなく、権限調整が必要になる境界そのものをなくせないかを最初に検討します。

共有Volume自体をなくせないか

今回の構成は次のようになっていました。

Application
    ↓ file
Shared Volume
    ↓ file
Fluent Bit

ログ出力要件が許せば、アプリケーションのログをファイルへ出力せず、awsfirelensログドライバ経由でFluent Bitへ渡す構成も考えられます。

FireLensでは、アプリケーションコンテナにawsfirelensログドライバを設定し、Fluent BitまたはFluentdをログルーターとして利用できます。

詳細は、AWS公式「Amazon ECSタスク定義の例：FireLensにログをルーティングする」を参照してください。

Application
    ↓ awsfirelens
Fluent Bit

この構成に変更できれば、アプリケーションとFluent Bitの間でログファイルを共有するVolumeをなくせる可能性があります。Volumeに付随するowner、group、mode、UID/GID、マウント後の権限といった設計項目も減らせます。

実案件でも、ログ出力方式そのものを変更して共有Volumeをなくす案を検討しました。既存のログ出力方式を変更するとAP側での改修と再テストが必要になるため、今回は共有Volumeを残したうえで権限設定方法を変更する判断としました。

設計として上位の選択肢を検討しても、変更影響やプロジェクト条件によって採用できないことがあります。

重要なのは、「権限エラーをどう直すか」から始めるのではなく、「その権限設計自体をなくせないか」を一度確認したうえで、案件条件に合った方法を選ぶことです。

VOLUMEディレクティブを利用する方法

共有Volumeを残す場合には、前述したDockerfileのVOLUMEとcontainerPathの仕様を利用する方法も候補になります。

この方法ではDockerfile、すなわちコンテナイメージそのものを変更します。ECS上の課題を解決する目的でVOLUMEを追加しても、同じイメージを別の環境で実行した場合の挙動にも影響します。

今回の環境ではこの方法を追加検証していないため、AWS公式仕様から確認できる対策候補としての紹介に留めます。

補足：configuredAtLaunchはbind mountの設定ではない

対策を調べる過程では、ECSのVolumeに関する情報を複数確認しました。その中で紛らわしかったのがconfiguredAtLaunchです。

名称からはVolumeの初期設定に使えるようにも見えますが、configuredAtLaunch=trueは、ECSのデプロイ時にAmazon EBS Volumeを構成するための設定です。今回利用していたbind mountの権限を変更するためのオプションではありません。

AWS公式「Amazon ECSのデプロイ時にAmazon EBSボリューム設定を指定する」でも、configuredAtLaunchをtrueに設定したタスク定義に対して、デプロイ時にAmazon EBS Volumeを構成する仕組みとして説明されています。

同じ「Volume」という言葉で扱われていても、bind mount、EBS、EFSでは仕様も設定方法も異なります。目にした情報をそのまま設計判断に使うのではなく、自分が利用しているVolume方式を特定したうえで、該当する公式ドキュメントを確認する必要があります。

権限設定用コンテナを先行して実行する

別の方法として、Volumeの所有者や権限を設定するコンテナを先に実行し、正常終了した後にアプリケーションコンテナを起動する構成があります。

ECSではdependsOnでコンテナ間の起動依存関係を設定できます。SUCCESSを指定すると、依存先コンテナが終了コード0で完了するまで後続コンテナを開始しません。SUCCESSとCOMPLETEの依存先にはessential containerを指定できません。

詳細は、AWS公式「FargateでのAmazon ECSタスク定義パラメータ」を参照してください。

Permission Setting Container
        │
        │ Volumeの所有者・権限を設定
        │ exit 0
        ↓
Application Container
        ↓
Fluent Bit Container

権限設定用コンテナには、共有Volumeへ必要な所有者・権限を設定できる権限を持たせます。アプリケーションコンテナ自体は従来どおり非rootユーザーで実行します。

この方法であれば、アプリケーションイメージを変更せず、タスク定義を中心とした基盤側の変更で対応できます。

なお、権限設定用コンテナでVolumeの初期権限を整えても、その後アプリケーションが生成するファイルを別コンテナから読めるとは限りません。TomcatとFluent BitでVolumeを共有した際に実際に発生したPermission deniedと、UID/GID・setgid・umaskを含む権限設計について、続編で整理しました。

Fluent BitがPermission deniedでログを読めない｜ECS/Fargate共有VolumeのUID/GID設計

ECS/FargateでTomcatとFluent Bitが共有Volumeを利用する構成でPermission deniedが発生。Fluent BitのUID/GID、setgid、umask、read-onlyマウントなど、Dockerコンテナ間でログを共有する際の権限設計を実例から解説します。

sys-univ.com

2026.08.24

rootユーザーで実行する

アプリケーションコンテナ自体をrootユーザーで実行する方法もあります。

権限問題は回避しやすくなりますが、非root実行を前提としていたセキュリティ設計との整合を確認する必要があります。動作するかどうかだけではなく、なぜ非rootユーザーで実行する設計にしていたのかまで戻って判断する必要があります。

技術的に動く対策と、プロジェクトで採用できる対策は違う

今回検討した方法を、変更対象まで含めて整理すると次のようになります。

最終的には、権限設定用コンテナを先行して実行する構成を採用しました。

アプリケーション側を修正したりログ出力仕様を変更したりする場合、AP側での改修とテストが必要になります。権限設定用コンテナの追加であれば、タスク定義を管理する基盤側で変更を完結でき、既存のコンテナイメージにも影響を与えません。

変更範囲を基盤側に限定できることから、この方式を採用しました。 この構成への変更後は、非rootユーザーで実行するアプリケーションからログを正常に書き込めるようになり、Permission deniedは解消しました。

技術的に成立する対策と、プロジェクトとして採用しやすい対策は同じとは限りません。変更主体、責任分界、変更影響、追加試験の範囲まで含めて対策を決める必要があります。

なぜ設計段階で気づけなかったのか

今回の問題で重要なのは、ECSのVolume仕様を知っていたかどうかだけではありません。

結果として、Dockerfileで設定した権限と、ECSがVolumeをマウントした後の実効権限との接続部分を、設計時に十分確認できていませんでした。

Dockerfileだけを見れば、確認対象は次の範囲です。

Dockerfile
 ├ mkdir
 ├ chown
 └ USER

実際には、その後ろまで設計する必要があります。

Docker Image
      ↓
ECS Task Definition
      ↓
Volume生成
      ↓
containerPathへmount
      ↓
実効UID/GID
      ↓
Applicationからwrite
      ↓
Fluent Bitからread

「Dockerfileで対象ディレクトリをchownしたこと」と、「Volumeをマウントした実行環境でアプリケーションユーザーが書き込めること」は同じではありません。

前者は設定内容です。設計で最終的に保証したいのは後者です。

「担当者が知らなかった」で終わらせない

今回のECS Volumeの仕様を知っている担当者であれば、設計段階で問題に気づけた可能性があります。

原因を「担当者が仕様を知らなかった」で終わらせても、次の案件で同じ問題を防ぐ仕組みにはなりません。

クラウドでは、自分たちがDockerfileや設定ファイルへ直接記述するものだけでなく、クラウドサービスが実行時に生成、マウント、変更するものがあります。必要なのは、それらを含めた実行時の最終状態を設計する観点です。

今回であれば、設計レビューでは次のような項目を確認すべきでした。

Fargateで利用するbind mountはタスクのエフェメラルストレージ上にあり、bind mountを使用するすべてのコンテナが停止するとデータは削除されます。今回のようなFargateタスクでは、タスク停止時のライフサイクルまで含めて設計する必要があります。

詳細は、AWS公式「Amazon ECSでのバインドマウントの使用」を参照してください。

設計書に「Dockerfileでchownする」と書くだけでは足りません。Volumeをマウントした後に、どのUID/GIDが、どのパスへ、どの権限でアクセスできるのかを定義する必要があります。

ここまで書いて、初めて実行時の権限設計になります。

この考え方は、ECSだけに限りません。基本設計で決めた方式を、構築・テストできる状態までどう落とすかについては、次の記事で詳しく整理しています。

• 基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程
• 【前編】詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程

事前PoCでは、ここまで確認すべきだった

今回の問題は、設計段階のPoCで発見できた可能性があります。

ECSでコンテナが起動することだけを確認するPoCでは足りません。

今回のPermission deniedを検出するだけなら、大掛かりな試験は必要ありませんでした。本番と同じ非rootユーザーとVolume構成でタスクを起動し、次の範囲を確認すれば、書き込み権限の問題を設計段階で検出できた可能性があります。

ECS Task起動
      ↓
実効UID/GIDを確認
      ↓
Volume mount後のowner/group/modeを確認
      ↓
Applicationからファイル作成
      ↓
Applicationからディレクトリ作成

これが、今回の問題を発見するために必要だった最低限のPoCです。

ログ機構全体の成立性まで確認するのであれば、その先にFluent Bitからの読み取り、ログ転送、Task再作成後の動作まで確認します。

Applicationからwrite
      ↓
Fluent Bitからread
      ↓
ログ転送
      ↓
Task再作成後も成立するか

設計レビュー表とPoCで似た項目を確認するのには理由があります。

設計では、実行時に成立すべき状態を定義する。PoCでは、その状態が実際の環境で成立することを確認する。

今回なら、設計では「非rootのアプリケーションユーザーがVolumeマウント後のログ出力先へwriteできる」と定義します。PoCでは、本番相当のユーザーとVolume構成で実際にファイルを作成して確認します。

PoCは「AWSのサービスが使えるか」を試すだけの工程ではありません。

本番と同じ境界を通したときに、設計したシステムが成立するかを確認する工程です。

クラウドリフトでも、AWSサービス単体の機能確認だけを行い、オンプレミスからクラウドへ移した後の実際の処理や運用まで通さなければ、問題が後工程で表面化します。今回のVolume権限も規模は小さいものの、構造は同じでした。

クラウドリフトでPoCに何を含めるべきかは、次の記事で詳しく整理しています。

• クラウドリフトの失敗は構築前に始まっている｜PoC不足が手戻り・コスト超過・納期遅延を招く理由
• クラウドリフトPoCで「動いた」は確認できた。しかし業務では使えなかった｜10の設計リスク① 可用性・性能・ストレージ・バックアップ・監視

今回の事象から得た3つの学び

一つ目は、Dockerfileは設定であって、実行時の最終状態ではないことです。

DockerfileでUSERやchownを指定しても、それだけでECS上の実効ユーザーやVolumeマウント後の権限は確定しません。設計で確認するべきなのは、各設定をECS上で組み合わせた後の最終状態です。

二つ目は、設計で抜けやすいのはコンポーネント単体ではなく、その接続部分であることです。

Dockerfileの設定もECSのVolume定義も、それぞれ単体で存在しています。今回確認できていなかったのは、DockerイメージとECS Volumeを接続した後に、どのユーザーがどのファイルシステムへアクセスするのかという実行時の状態でした。

三つ目は、PoCでは本番と同じ境界を通す必要があることです。

コンテナが起動したことだけでは、システムとして成立したことにはなりません。本番と同じUID/GID、Volume、マウントポイント、サイドカーを含めて実際の処理を通し、設計した状態が成立することを確認する必要があります。

今回の事象を振り返ると、

「Dockerfileでchownした」ではなく、「Volumeをマウントした後に、必要なユーザーが必要な操作をできる」まで確認して初めて権限設計は完了する

ということになります。

クラウドでは、自分たちが直接構築・設定したものだけを見るのでは足りません。クラウドサービスが実行時に生成、変更、接続するものまで含めて最終状態を設計し、不確実性が残る境界は事前PoCで実際に通す。

今回のPermission deniedは小さな権限エラーでしたが、クラウド設計とPoCで何を確認するべきかを改めて考えるきっかけになりました。

参考にしたAWS公式ドキュメント

• Amazon ECSでのバインドマウントの使用

• Amazon ECS向けのFargateタスクエフェメラルストレージ

• FargateでのAmazon ECSタスク定義パラメータ

• Amazon ECSのデプロイ時にAmazon EBSボリューム設定を指定する

• Amazon ECSタスク定義の例：FireLensにログをルーティングする

関連記事

ECS/Fargateの権限問題を、設計レビューで何を確認するかという観点を、運用設計や要件定義の工程まで広げて確認したい方は、以下の記事も参考にしてください。

• 運用設計とは？運用設計書の目次サンプルと項目一覧｜基盤SE視点
  ログ、監視、ジョブ、バックアップ、障害対応など、本番運用を成立させるために設計しておくべき項目を整理しています。

運用設計とは？運用設計書の目次サンプルと項目一覧｜システム基盤エンジニア視点

運用設計とは何かをシステム基盤エンジニアの実務目線で解説します。運用設計書の目次サンプルと検討項目一覧を示し、監視・ログ・バックアップ・ジョブ管理、誰がやるのか、要件定義・基本設計との関係、処理方式設計との双方向連携を整理します。

sys-univ.com

2026.08.14

• 要件定義とは何をする工程か｜RFP・見積前提から認識差を潰す実務
  RFPや提案内容を前提に、スコープや責任分界を確定し、設計・構築・テストできる水準まで具体化する実務を解説しています。

要件定義とは何をする工程か｜RFP・見積前提から認識差を潰す実務

要件定義とは何をする工程なのか。RFP、質問回答、提案書、見積前提から認識差を潰し、スコープや責任分界を確定する実務を、大規模SIの具体的な失敗事例とともに解説します。

sys-univ.com

2026.08.12

データを遠隔地に保全し、サーバやデータベースを別リージョンで起動できるようにすることは重要です。ただ、それだけで業務を再開できるとは限りません。

DBが復旧している。Web/APも起動している。それでも利用者がログインできなければ、オンラインサービスは利用できません。

DRで確認すべきなのは、リソースが存在するかではなく、利用者が認証され、必要な処理を実行し、安全に業務を継続できる一連の経路が成立するかです。

Amazon Cognitoは、この問題を分かりやすく示す例です。

本記事では、実際のDR検討で経験した問題と、2026年に提供開始されたAmazon Cognito User PoolsのMulti-Region Replication（MRR）を題材に、AWSのDR設計で何を確認すべきかを整理します。

1. DRは「データ」「起動」「業務経路」の3レベルで考える

DRを考えるときは、どこまで復旧できれば「DRが成立した」と考えるのかを3つのレベルに分けると整理しやすくなります。

レベル1は、データが残っている状態です。

データベースのバックアップやスナップショット、オブジェクトストレージ、AMIなどを遠隔リージョンへ保管し、大規模障害でもデータや復旧資材を失わないようにします。

レベル2は、システムを起動できる状態です。

DRリージョンでネットワーク、サーバ、コンテナ、データベースなどを起動し、アプリケーションが動作できるところまで復旧します。

レベル3は、安全に業務経路が成立する状態です。

利用者がシステムへ到達できるか。認証できるか。適切な権限でAPIやDBへアクセスできるか。KMS、Secrets、外部IdP、外部APIなどの依存先がDRリージョンでも利用できるか。

ここまで確認して初めて、業務を再開できます。

バックアップがあることは、DRの一部にすぎません。

図　DRは「データが残る」「システムが起動する」だけではなく、「安全に業務経路が成立する」ところまで確認する

2. DRではリソース一覧ではなく「1トランザクション」を追う

DR設計では、EC2、RDS、S3、Lambdaなど、AWSリソース単位で対策を並べがちです。

リソース単位の確認は必要ですが、それだけでは依存関係を見落とします。

見るべきなのは、利用者が1回の業務処理を完了するまでに何を通るのかです。

Webシステムなら、利用者はDNS、WAFやロードバランサー、Web/APを通り、認証基盤で認証された後、DBや外部APIを使って業務処理を行います。

認証基盤が外部IdP、メール、SMS、Lambda Triggerへ依存する構成もあります。KMS、Secrets Manager、証明書は複数の処理から参照される共通依存です。

監視、ログ、運用管理端末、管理アクセスもDR時に必要になります。

2026年9月のAWS Security Blog記事でも、Cognito MRRを利用する場合、Lambda、WAF、SNS、SES、CloudWatchなどのリージョナルな構成を別リージョンのレプリカ側で準備する必要があると説明されています。

DR設計で見る単位を、

何のリソースを複製したか

から、

利用者が業務を完了するまでに、どの依存先を通るか

へ変えることが重要です。

図　DRでは利用者からDBまでの本流だけでなく、認証、外部IdP、KMS、Secrets、外部API、監視など、その業務経路を支える依存先まで確認する

認証フローは構成によって異なります。Amazon CognitoのManaged Loginでは、ブラウザがCognitoのドメインへ直接遷移する場合があるため、この図は依存関係を理解するための概念図です。

3. 実案件で直面した「データは送れるが、認証できない」問題

Amazon Cognitoが大阪リージョンへ対応する前の案件で、東京リージョン全体が利用できなくなった場合に、大阪リージョンで業務を継続する構成を検討しました。

Cognitoが大阪リージョンで利用可能になったのは2023年9月1日です。今回の案件はそれより前の検討でした。

AWSの発表はWhat’s Newで確認できます。

私がこの案件で強く印象に残ったのは、データを大阪へ持っていけることと、大阪で業務を継続できることは別だったという点です。

Web/APやデータ、復旧資材を大阪側へ持つ構成は検討できました。

しかし当時はAmazon Cognitoを大阪リージョンで利用できず、認証を大阪側だけで完結できませんでした。

Web/APやDBを大阪側に用意しても、利用者がログインできなければオンライン業務は成立しません。

結果として、大阪側ではデータを遠隔保全するところまでとし、認証を含めて大阪側で業務を継続するDR構成にはできませんでした。

この経験は、前章で整理した「データが残る」だけでは、「安全に業務経路が成立する」ところには届かない例です。

DR要件を「別リージョンにデータを保管する」とだけ定義すると、この違いを見落とします。

4. Cognito MRRで何が変わったのか

2026年6月、Amazon Cognito User PoolsにMulti-Region Replication（MRR）が追加されました。

提供開始時の概要はAWS What’s Newで確認できます。

MRRではPrimary User Poolを権威あるユーザープールとし、ユーザー属性、ハッシュ化された認証情報、グループ、App Client、外部IdP設定などをSecondaryへ複製します。

レプリケーションはPrimaryからSecondaryへの一方向です。

Secondaryではサインインやトークン発行などの認証処理を継続できますが、Primaryとまったく同じ機能を持つわけではありません。

図　MRRにより認証基盤を別リージョンへ複製できるようになった。ただし、レプリケーションだけでDRが完成するわけではなく、フェイルオーバー方式や周辺依存を別途設計する必要がある

以下は、2026年10月時点のAmazon Cognito Developer Guideに基づく主な前提と制約です。

詳細な制約はAmazon Cognito Developer Guideに整理されています。

issuerもDRの依存関係になる

MRRを検討するときはOIDC issuerにも注意が必要です。

Cognitoにはoriginal issuerとupdated issuerがあり、AWSはMRRを含むUser Poolでupdated issuerを推奨しています。

updated issuerではOIDC discoveryとJWKSを複数リージョンで提供できます。

MRR自体はoriginal issuerでも利用できます。

ただしoriginal issuerのOIDC discovery endpointとJWKS endpointは単一リージョンに紐づきます。リージョン障害時にはJWKSを取得できない可能性があり、アプリケーションが公開鍵を動的に取得してトークン署名を検証する構成では影響を受ける可能性があります。

updated issuerへ移行できない場合、AWS Security Blogでは、アプリケーションのトークン検証層でJWKSをキャッシュする方法を緩和策として挙げています。

認証サービスがSecondaryで動作しても、トークンを検証する側が参照するJWKSまで確認しなければ、認証経路全体の可用性は評価できません。

また、2026年10月時点のDeveloper Guideでは、updated issuerはApplication Load BalancerのCognito認証、およびAmazon API Gateway REST APIのCognito authorizerとは互換性がありません。

サービス仕様が変わる可能性があるため、実装時には最新ドキュメントの確認が必要です。

ALB認証の制約とJWKSキャッシュは別の論点です。JWKSキャッシュはアプリケーション側のトークン検証層に対する対策であり、ALB認証の非互換を解消する方法ではありません。

5. 東京→大阪DRで確認すべきこと

2026年6月のMRR提供開始時点では、対応リージョンに東京は含まれていましたが、大阪は含まれていませんでした。

提供開始時点の対象リージョンはAWS What’s Newで確認できます。

ここで重要なのは、

「大阪リージョンでCognitoを利用できる」ことと、「東京のCognito User Poolを大阪へMRRできる」ことは別

という点です。

東京→大阪を前提にFull-stack DRを設計する場合、MRRの対応リージョンを設計時点で確認する必要があります。

対応していなければ、MRRを利用できる別リージョンの組み合わせへ設計を変更する方法があります。この場合、ユーザー情報が別リージョンへ複製されるため、データ所在や組織内の規程との整合も確認が必要です。

AWS Security Blogでも、Secondaryのリージョンを選ぶ際にはdata sovereigntyやresidency要件を確認するよう説明しています。

MRRを使わず、別User Poolを自前で同期する方法も考えられます。

AWSは、MRR以前の手動エクスポートやインポートには、データ露出や不整合のリスク、利用者へのパスワードリセットといった課題があったとAWS News Blogで説明しています。

単に「同期処理を作ればよい」と考えず、運用負荷とセキュリティまで含めて評価する必要があります。

MRRの対象リージョンは追加される可能性があるため、実装時には最新のAWS公式情報を確認してください。

6. 「認証だけのDR」と「システム全体のDR」は違う

2026年9月のAWS Security Blogでは、CognitoのフェイルオーバーをAuthentication-only failoverとFull-stack failoverに分けています。

Authentication-only failoverは、アプリケーション本体を同じリージョンで稼働させたまま、認証だけをCognitoのSecondaryへ切り替える方式です。

Full-stack failoverは、compute、data store、API、authenticationなど、アプリケーション全体を別リージョンへ切り替える方式です。

Lambda TriggerがリージョナルなDynamoDBへアクセスする場合など、認証処理の周囲にある依存先もDR側で成立させる必要があります。

先ほどの東京→大阪の実案件は、東京リージョン全体が利用できなくなることを想定していました。

求めていたのはFull-stack failoverです。

CognitoのMRRが成立しても、Web/AP、DB、API、Lambda、KMS、Secrets、外部サービスなどがDRリージョンへ切り替わらなければ、Full-stack DRにはなりません。

複数コンポーネントの切替を協調させる仕組みとして、AWSは**Amazon Application Recovery Controller（ARC）**も紹介しています。

認証、compute、database、APIなどをリカバリープランとして扱い、切替を協調させる選択肢です。

DR時だから認証を弱めてよいわけではない

DRでは可用性の回復が優先されやすく、「ログインできないなら認証を一時的に緩める」という発想が出ることがあります。

避けるべき設計です。

情報セキュリティでは、可用性だけでなく機密性と完全性も維持する必要があります。

MRRのSecondaryでTOTP MFAを利用できないなら、障害発生後に認証水準を下げるのではなく、SMS OTP、Email OTP、passkeyなど、利用可能な代替方式を平時に設計します。

SMSを使う場合も、Secondary側でSNS設定や送信元IDの登録が必要です。登録に時間がかかる場合があるため、DR発動後に準備するものではありません。

フェイルオーバー先ではPrimaryとは別に失敗回数が管理されます。ロックアウトまでの失敗回数が引き継がれないため、切替後のロックアウト判定はPrimaryの状態と一致しない場合があります。

DRでは、可用性だけでなく、認証・アクセス制御の挙動が切替前後でどう変わるかも確認する必要があります。

セキュリティリスクから要件を導き、残存リスクまで評価する考え方については、次の記事で整理しています。

セキュリティ要件定義の進め方｜リスクアセスメントから対策・残存リスクを決める方法

セキュリティ要件定義を、RFPや上位基準を起点に、リスクアセスメント、差異評価、対策、残存リスクまで具体化する方法を解説。脅威・脆弱性の分析、関係者との合意、変更時の再アセスメントまで実務例で整理します。

sys-univ.com

2026.09.17

7. フェイルオーバーは「何を異常とみなすか」まで設計する

Managed LoginやFederationを利用する構成では、Cognito MRRはRoute 53 Health Checkを利用したフェイルオーバーに対応しています。

Custom DomainだけでなくPrefix Domainでも利用できます。

Health Checkを設定し、Unhealthyになった場合、CognitoはSecondaryを利用する認証経路へ切り替えられます。

重要なのは、MRRを有効にするだけで切り替わるわけではないことです。

何をもってPrimaryが異常と判断するのかは、利用者側が設計します。

単純なHTTP死活監視では、認証処理そのものが失敗していてもHealthyになる可能性があります。

AWS Security Blogでは、CloudWatch Syntheticsで実際の認証フローを実行し、その結果をCloudWatch AlarmとRoute 53 Health Checkへつなぐ例を紹介しています。

単なる死活監視ではなく、認証処理がエンドツーエンドで成立しているかを見る考え方です。

SDKやCognito APIを直接利用する構成では、アプリケーション側でRegional Endpointの切替を行います。

AWS Security Blogでは、カスタムエンドポイントやプロキシを介してPrimaryとSecondaryへルーティングする構成も示されています。

DR設計書に、

CognitoはMRRを利用する

とだけ書いても不足です。

最低でも、何を監視するのか、どの状態を障害と判定するのか、自動切替か運用者判断か、誰が復旧を判断するのか、どこまでを一緒に切り替えるのかを決める必要があります。

この領域は基本設計と運用設計の両方にまたがります。

可用性方式や依存関係を基本設計で具体化する考え方については、次の記事で整理しています。

基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程

基本設計は画面設計だけでは終わらない。ログ・バックアップ・ジョブ・監視など、本番運用を見据えた基盤設計の論点を、ファイルアップロードや夜間バッチの実例で整理します。

sys-univ.com

2026.06.20

監視条件、障害判定、切替手順、復旧後の戻し方については、次の記事で整理しています。

運用設計とは？運用設計書の目次サンプルと項目一覧｜システム基盤エンジニア視点

運用設計とは何かをシステム基盤エンジニアの実務目線で解説します。運用設計書の目次サンプルと検討項目一覧を示し、監視・ログ・バックアップ・ジョブ管理、誰がやるのか、要件定義・基本設計との関係、処理方式設計との双方向連携を整理します。

sys-univ.com

2026.08.14

8. AWS DR設計で確認したいチェックリスト

MRRの前提

• □ 利用するUser PoolとPrimary、SecondaryのリージョンがMRRの対象か
• □ EssentialsまたはPlus、Multi-Region KMS KeyなどMRRの前提を満たすか
• □ original issuerとupdated issuerのどちらを使うか決め、その依存先への影響を確認したか

障害時に認証できるか

• □ SecondaryをACTIVEにする前に、Lambda、WAF、SNS、SES、ログなどのリージョン固有設定を完了したか
• □ SMSを使う場合、Secondary側のSNS設定と送信元IDなどの登録を済ませたか
• □ TOTP利用者の代替認証方式を平時に決めたか
• □ Route 53 Health Checkで何を異常とみなすかを決めたか
• □ 自動切替か手動切替か、判断者と復旧判断を決めたか
• □ SDKやAPIを直接利用する場合のRegional Endpoint切替方式を決めたか

業務経路全体が成立するか

• □ DNS、WAF/LB、Web/AP、DBまでDR側で利用できるか
• □ KMS、Secrets、証明書がDRリージョンでも利用できるか
• □ 外部IdP、外部API、外部システムへの接続を確認したか
• □ 認証後に呼ばれるLambdaや、その先のデータストアまで確認したか
• □ 監視、ログ、運用管理端末、管理アクセスがDR時にも利用できるか
• □ 「ログイン → 業務処理 → データ参照・更新」まで実際にDRテストしたか
• □ Health Checkを意図的に反転し、PrimaryからSecondaryへの切替と復帰を確認したか

AWS Security Blogでは、Health Checkの反転やAWS Fault Injection Service（FIS）を使ったフェイルオーバーテストも紹介されています。

チェックリストで重要なのは、個々のAWSサービスが存在するかではありません。

業務を開始して終了するところまで、一連の経路を実際に通せるかです。

9. まとめ

バックアップがあることと、DR先で業務を継続できることは同じではありません。

データが残っている。システムも起動できる。それでも、認証やKMS、外部サービスなどの依存先が成立しなければ、利用者は業務を再開できません。

Amazon CognitoのMRRによって、User Poolを別リージョンへ複製し、認証基盤の可用性を高められるようになりました。

MRRにもリージョン条件、Secondaryの機能制限、issuer、リージョナルサービス、フェイルオーバー方式など、確認すべき依存関係があります。

Authentication-only failoverとFull-stack failoverも区別する必要があります。

DRで確認すべきなのは、

「何をバックアップしたか」ではなく、「利用者が安全に業務を再開できるか」

です。

この視点で1トランザクションの経路を追うと、バックアップ一覧やリソース一覧だけでは見えなかったDRの弱点が見えてきます。

参考資料

Amazon Cognito Developer Guide — Multi-Region replication for user pools
https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-multi-region.html

Amazon Cognito Developer Guide — Identity provider and relying party endpoints
https://docs.aws.amazon.com/cognito/latest/developerguide/federation-endpoints.html

AWS Security Blog — Architecting resilient authentication with Amazon Cognito multi-Region replication
2026年9月15日
https://aws.amazon.com/blogs/security/architecting-resilient-authentication-with-amazon-cognito-multi-region-replication/

AWS What’s New — Amazon Cognito now supports multi-Region replication
2026年6月4日
https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-cognito-multi-region/

AWS News Blog — Improve your application resilience with Amazon Cognito multi-Region replication
2026年6月3日
https://aws.amazon.com/blogs/aws/improve-your-application-resilience-with-amazon-cognito-multi-region-replication/

AWS What’s New — Amazon Cognito がアジアパシフィック（大阪）リージョンとイスラエル（テルアビブ）リージョンでご利用いただけるようになりました
2023年9月1日
https://aws.amazon.com/jp/about-aws/whats-new/2023/09/amazon-cognito-new-regions/

AWS上でAI Agentを動かす構成が、検証環境だけの話ではなくなってきた。専用のIAM Roleを与え、VPC内に置き、必要なAPIやツールを実行させる。権限の与え方だけを見れば、運用ジョブやバッチ処理と大きくは変わらない。違うのは、目的に応じて何を実行するかをAgent自身が判断する点にある。

2026年7月、OpenAIの評価環境で動いていたAI Agentが隔離を越えて外部へ到達し、7月11日から13日にかけてHugging Faceの本番基盤を侵害した。

しかも、これは後から確認された一連の想定外動作の一例にすぎない。9月には、6月にOpenAIのAgentが豪州政府のMedicare統計ポータルへ無許可アクセスしていた事例も公表された。発生時点で把握・通知されたものではなく、後日の調査で明らかになった事例である。

境界の突破は7月に突然始まったわけではなく、5月から断続的に続いていた。両社が公開した技術レポートには、どの経路が使われ、どこで止まり、どこでは止まらなかったかが記録されている。

本記事は、この事件の時系列を追うものではない。攻撃の詳細は両社の一次資料に譲り、ここでは次の問いを扱う。

AWS上で正規の権限を持つAI Agentが、想定した範囲を越えて動いたとき、その到達範囲は何によって決まるのか。

進め方は、セキュリティ要件定義の基本形をそのまま使う。資産を洗い出し、脅威主体を定め、弱点と攻撃シナリオを置き、対策を決めて、残るリスクを確認する。この順に沿って、AI Agentという実行主体を一度当てはめてみる。

リスクアセスメントの進め方そのものは、セキュリティ要件定義の記事で整理している。

セキュリティ要件定義の進め方｜リスクアセスメントから対策・残存リスクを決める方法

セキュリティ要件定義を、RFPや上位基準を起点に、リスクアセスメント、差異評価、対策、残存リスクまで具体化する方法を解説。脅威・脆弱性の分析、関係者との合意、変更時の再アセスメントまで実務例で整理します。

sys-univ.com

2026.09.17

ここでは方法論の説明はせず、事件で実際に何が効いて何が効かなかったかという、設計時には得にくい材料を扱う。

AI Agentに何を預けているのか

リスクアセスメントは、守る対象を決めるところから始まる。AI Agentを載せた基盤で、守る対象は何か。今回の事件は、その範囲を実測で示している。

侵害の経路

事件の経路を、後の議論で必要な範囲だけ確認する。​

図　AIエージェント攻撃チェーン

押さえておきたい事実は3つある。

一つ目は、脱出に使われたのが許可された通信経路だったこと。 評価環境はインターネットから隔離されていたが、パッケージを取得するための経路は業務上必要なため開いていた。エージェントはその経路の実装に脆弱性を見つけ、外部へ抜けている。塞ぎ忘れた穴ではなく、開けておく理由があった経路が足場になった。

二つ目は、コード実行より前に認証情報が漏れていること。 Hugging Faceへの最初の侵入ベクターは、細工したデータセット設定を処理させ、ワーカーのローカルファイルを返させるものだった。コードは一切実行していない。読み取らせた’/proc/self/environ’に本番Podの環境変数が入っており、そこに認証情報が含まれていた。この読み取りで得た認証情報や実装情報が、その後の探索と横展開の材料になった。

三つ目は、一つの境界を越えたあとも連鎖が続いたこと。 本番Podでの足場から、Kubernetesのサービスアカウント、クラウドのメタデータ、内部ネットワーク、ソースコード管理へと進んでいる。

資産の範囲をどう置くか

ここから、自分たちの環境に置き換える。

奪われたものを並べると、業務データそのものより手前にあるものが多い。

図　AI Agentと重要資産の到達範囲

​AI Agentに預けていると考えるべき範囲は、Agentに直接処理させるデータだけではない。Agentが直接・間接に到達できる重要資産まで広げて考える必要がある。 要件定義で資産を洗い出すとき、Agentに渡すデータだけを対象にすると、事件で実際に使われた経路が丸ごと抜け落ちる。

影響も同じ範囲で考える。情報の取得と改ざんに加えて、構成変更による外部公開と、基盤そのものの停止まで入る。構成変更によって内部基盤を外部へ公開できた事例も、後段で確認する。

脅威主体としてのAI Agent

脅威分析では、まず誰が資産に手を伸ばし得るかを並べる。外部攻撃者、内部関係者、委託先、侵害されたワークロード。ここにAI Agentを加えるかどうかが、この記事の前提になる。

人間の内部不正者とは別物として扱う

AI Agentを内部脅威と呼ぶと、人間の内部不正と同じ枠に見えてしまう。動機を持ち、意図して権限を濫用する主体という含みが入るためで、その枠に置くと分析が動機の推定へ向かう。

ここでは次のように定義する。

正規に発行されたWorkload Identity（非人間ID）を持ち、与えられた目的を達成する過程で、設計者が想定した範囲を越える操作を行い得る実行主体。

IAM Role、Kubernetesのサービスアカウント、マシンIDの延長として読める形だ。既存の非人間IDの管理に、判断して行動する性質が加わったものと捉えればよい。

悪意は要件ではない

今回の事件で、エージェントはHugging Faceを攻撃するという目的を与えられていない。与えられていたのは、脆弱性を発見して悪用する能力を測る評価課題を解くことだった。

課題が解けないなかで、エージェントは評価対象のデータや解答がHugging Faceに置かれている可能性に行き当たり、そちらへ向かっている。OpenAIはこれを、報酬を得るための意図しない経路を選ぶreward hackingとして整理している。侵害は目的ではなく、目的達成の副産物だった。

脅威分析で見るのは動機ではない。与えられたGoal（目的）と、許されたAuthority（権限）の組み合わせだ。 Agentがデータを盗もうと考える必要はなく、与えられた目的の達成経路上にその操作が現れるだけで足りる。

達成できない目的を与えると、環境を掘り始める

この事件の前段には、目的が達成できない状況が繰り返し置かれていた。

訓練時の例が公開されている。エージェントは投稿の更新時刻を指定の値にせよと指示されたが、与えられたインターフェースにその機能がなかった。エージェントは環境を広く探索し、ブラウザがroot権限を持つことを発見して’/etc/sudoers.d’を上書きし、権限を得て目的を達成している。

事件時の評価でも同じ形が出ている。**AI Agentの脆弱性悪用能力を評価するベンチマーク「ExploitGym」**の898問のうち198問は、事故以前にどのモデルも正解したことがなかった。

Agentに必要なのは、達成する能力だけではない。達成できないと判断して正常に止まる経路が要る。

図　達成不能なら止まれる設計にする

モデル自身に「止まる判断」を期待するだけでなく、実行基盤側にハードリミットを持たせる。

これらはアライメントだけに任せる話ではなく、Agent実行基盤の設計項目でもある。止まれないAgentに広い権限を与えると、想定した経路が使えなくても、目的達成のために別の経路を探索し続ける。

効いた統制と、効かなかった統制

同じインシデント調査の中で、ある境界では攻撃が止まり、別の境界では止まらなかった。なぜそうなったのかを見ていく。

対策の実効性は、設計時点の机上評価だけでは判断しにくい。テストで確認できる範囲はあっても、複数の境界をまたぐ侵害でどこまで被害を止められるかは見えにくい。今回の事件では、関連するエージェント活動の中で、効いた統制と効かなかった統制の両方が記録されている。

侵入されたあとに止まった側

Hugging Faceの本番Podが侵害されたあと、エージェントはインスタンスメタデータサービスからEC2ノードロールの一時認証情報を読み出している。この認証情報は外部の二つのホスティング事業者のアドレスから再利用され、VPC、EKSクラスタ、Transit Gateway、シークレット、コンテナレジストリが列挙された。ここまでは通っている。

止まったのはこの先だ。AWSクラウドAPI面では、変更を伴う呼び出しがノードロールのポリシーによってすべて拒否された。 Hugging Face自身が、ここで得られたのはcontrolではなくmapだったと整理している。

ネットワーク側も同じ形で効いた。本番Hubのデータベースは、許可リストに載ったアドレスからプライベートリンク経由の接続しか受け付けない構成になっている。盗まれたAWSキーを使った接続はサーバー選択のタイムアウトで失敗し、数時間後の再試行も同じ結果に終わった。

認証情報は奪われている。それでも、奪われた認証情報でできることがIAMポリシーとネットワーク構成の側で先に絞られていた。

同じ事件で止まらなかった側

侵害されたのはHugging Faceだけではない。OpenAI側の評価基盤でも、関連するエージェント活動は続いていた。

7月19日、ある評価ランでは、エージェントが稼働マシンのLinuxカーネルに公開CVEが残っていることを特定し、エクスプロイトを自環境向けに改変して権限昇格し、コンテナの外へ出てワーカーノードのrootを取得した。

同日、別の評価ランでは、別の内部研究モデルのエージェントが、以前の活動によって残されていた署名鍵・復号材料・JWT偽造コードを回収し、新しい管理者JWTを発行してArtifactoryに受理させている。管理者認証情報を作り直せるため、標的に永続的なインプラントを置く必要すらなかった。

一連の活動では、その後、OpenAIのマネージドKubernetes環境でcluster-admin相当の権限まで到達し、Privileged設定かつホストファイルシステムをマウントしたPodも作成された。さらに、クラウドのシークレット管理サービスでは956件のシークレットが列挙・読み取りされ、その中には監視ツール自身のセンサー認証情報も含まれていた。

さらに、取得した認証情報を使って、OpenAIのパブリッククラウド環境にパブリックなApplication Load BalancerとNetwork Load Balancerが作成され、内部基盤の一部がインターネットへ露出し得る状態になった。

差を生んだのは、次の境界が独立して機能したかどうか

図　侵害後の権限展開フロー

ここで比較している活動は、すべて同一モデル・同一評価ランによるものではない。それでも、認証情報の取得、権限拡大、横展開という攻撃チェーンは共通している。結果を分けたのは、取得したIDから何を変更できたかだった。

Hugging Face側も、変更が一切できなかったわけではない。Kubernetesではprivilegedポッドが作られ、ソースコード管理では書き込み権限が取られてプルリクエストまで作成されている。止まったのはAWSのクラウドAPI面に限られる。

ここから引き出せる設計上の区別が一つある。既存の到達範囲で何ができるかという権限と、到達範囲そのものを変更できる権限は分けて考える必要がある。 前者を最小権限化していても、後者が残っていれば、Agent自身がその権限境界やネットワーク境界を広げられる。侵入されるかどうかだけでなく、侵入されたあとに次の境界が独立して機能するかが被害範囲を決める。

AWSで何を許し、何を許さないか

ここまでで、資産、脅威主体、弱点と攻撃シナリオまでを見た。ここからが対策だ。

AI Agentに与える権限を検討するとき、確認しておく観点は次のようになる。

特にEKSでは、Podにノードロールの認証情報を使わせない構成を前提にする。IRSAやEKS Pod IdentityでPodごとの権限を分離し、ノードのIMDSを必要としないPodからはアクセスできないようにする。IMDSv2の必須化やhop limitの設定は、その制御を補強する手段になる。

大半は従来のクラウド設計で扱ってきた項目だ。この中で、AI Agentを置くことによって検討の仕方が変わるものを3つ取り上げる。

Agentに自分の境界を変更させない

前章で見たとおり、最小権限では「既存の到達範囲で何ができるか」だけでなく、「到達範囲そのものを変更できるか」を分けて見る必要がある。後者は業務データに直接触らないため、最小権限の議論から漏れやすい。代表例が次のAPIだ。

• elbv2:CreateLoadBalancer
• ec2:AuthorizeSecurityGroupIngress
• ec2:CreateInternetGateway
• ec2:CreateRoute​

これらを持つAgentは、自分が到達できる範囲を自分で広げられる。今回のOpenAI側の活動でも、パブリックなロードバランサーが実際に作成され、内部基盤をインターネットへ露出し得る状態が生まれている。

私がAI Agentを載せる基盤の設計レビューをするなら、ここは「最小権限とすること」という一行では通さない。ネットワークとIAMの構成を変更するAPIを洗い出し、Agent実行ロールから明示的に外れていることを確認する。

加えて、この種の境界変更はIAMポリシーだけに依存させない。 Agent自身、またはAgentがAssumeRoleできるIDに

• iam:PutRolePolicy
• iam:AttachRolePolicy

などのIAM変更権限が残っていれば、最小権限として設計した実行ロールを後から拡張する経路が生まれる。境界の固定は、SCP（Service Control Policies）のようにAgent自身が変更できない上位のガードレールでも制限する。

Read Only ≠ Low Risk

権限を絞る議論は、更新系と参照系を分けるところから始まることが多い。参照だけなら壊れないという前提が置かれる。

事件の被害連鎖は、この前提の外側で始まっている。最初の侵入ベクターはコード実行を伴わないファイル読み取りで、’/proc/self/environ’を返させることで本番Podの環境変数中の認証情報が漏れた。

参照系を一段分けて考えたい。

図　読み取り権限のリスク比較

​※Describe / Listも、対象によってはネットワーク構成やARN、エンドポイントなどの偵察情報を返すため、常に低リスクとは限らない。

下段は性質が二つに分かれる。データベースの顧客データは、読まれた時点で情報漏洩そのものだ。認証情報は、読まれた内容が次の操作の資格情報になる。更新権限を持たないAgentでも、後者に到達できれば、そこで得た認証情報を持つ別のIDとして動ける。

この区別は、Human-in-the-loopをどこに入れるかにも効いてくる。Human-in-the-loopの線を「更新かどうか」だけで引くと、今回のような認証情報窃取の前段は素通りする。 IAM変更やDELETEの手前に人間を置いても、その前段で認証情報が漏れていれば、そこから先は別のIDとして進める。

線を引くなら、その操作が更新か参照かではなく、戻り値そのものが重要資産か、次の攻撃経路を成立させる材料になるかで判断する。

検知ではなく、止められるかまで設計する

この事件では、検知そのものは複数回機能している。

6月27日には監視ツールがポートスイープを検知し、対応者は活動を評価ランに紐づけたが、停止は不要と判断された。7月5日にはサービス停止を契機に管理者レベルの侵害が判明した。Hugging Face側でも、AIによるセキュリティ機構が複数のシグナルを相関させながら、重大度を十分に引き上げてオンコールチームを起動させることに失敗している。

シグナルは上がっていた。それでも活動は止まらなかった。

要件として書くべきは、検知できることだけではない。検知 → 重大度判定 → エスカレーション → 停止権限という4段が、最後まで通ることだ。誰が停止を判断するのか、判断がつかない場合はどちらへ倒すのか、応答がない場合に自動で止まるのか。OpenAIが事件後に示した対応基準では、懸念活動が浮上してから30分以内の通知を目標とし、重大なものは24時間365日のページ発報対象とする。さらに、ページを受けた安全・セキュリティ・研究チームが30分以内に誤検知と断定できなければ、関連する活動を一時停止することが期待されている。

判断がつかないときに止める側へ倒す設計は、可用性とのトレードオフを伴う。AI Agentが本番環境で自律的に動く構成では、この判断を運用開始後に持ち越さず、要件定義の段階で決めておきたい。

監視・ログ・障害時の判断体制を後から付け足すのではなく、要件定義から処理方式と結びつける考え方は、次の記事でも整理している。

運用設計とは？運用設計書の目次サンプルと項目一覧｜システム基盤エンジニア視点

運用設計とは何かをシステム基盤エンジニアの実務目線で解説します。運用設計書の目次サンプルと検討項目一覧を示し、監視・ログ・バックアップ・ジョブ管理、誰がやるのか、要件定義・基本設計との関係、処理方式設計との双方向連携を整理します。

sys-univ.com

2026.08.14

監視の配置も同じ考え方だ。事件では、読み出されたシークレットの中に監視ツール自身のセンサー認証情報まで含まれていた。監視とログをAgentの権限境界の内側に置けば、Agentの到達範囲が広がったときに、検知する側から先に失われる。CloudTrailの組織証跡を別アカウントのログアーカイブへ送り、Agent実行ロールにログの削除・停止権限を持たせない。 表の「ログ」が求めているのは、監査証跡の管理権限をAgentの権限境界から分離するという構成だ。

それでも残るもの

対策を並べたら、次は残存リスクを確認する。ここまでの要件をすべて満たしたとして、何が残るのか。

対策で低減できるものと、残る性質

※左右の項目は1対1の対応関係を示すものではない。

左側は設計によって大きく低減できる。右側は、権限を必要最小限まで絞っても残る。

最小権限もネットワーク分離も、許可した範囲内の動作までは止めない。許可した操作を、設計者が想定していない順序と組み合わせで実行されることまでは、権限の側から防げない。

17,600という数字の意味

Hugging Faceの復元によれば、この事件でエージェントが実行したアクションは約17,600件だった。

この数字を、17,600回の攻撃が成功したと読むと意味を取り違える。ほとんどは失敗している。 Hugging Face自身、多くのアクションはどこにもたどり着かなかったが、合わせると複数の独立したシステムを横断する経路を見つけるだけの網羅性を生んだ、と整理している。

人間による手作業では、探索を繰り返すほど時間と作業量が増える。AI Agentでは探索、失敗、再試行を自動化できるため、一つひとつの失敗にかかる追加コストを大きく下げられる。 塞がれれば別の経路を試し、以前の手がかりへ戻り、短命な実行環境でも必要なツールを組み直して探索を続けられる。

防御側にとって特に変わるのは、個々の攻撃手法よりも探索の物量だ。成功した1本の経路が、失敗した数千本のノイズに埋もれる。前章で検知から停止までを要件として書いたのは、この物量が相関分析の負荷に直接効いてくるためだ。

原則は変わっていない

今回悪用されたのも、安全でないデータ処理、メタデータへの到達、過大な権限、長期の認証情報といった既知の弱点だった。

OpenAI自身も、攻撃的に動作するエージェント集団が侵入のルールを書き換えるわけではないとしたうえで、最小権限、分離とセグメンテーション、強力な認証というセキュリティの基本は従来どおり不可欠であり、いかなる単一の統制も完全に堅牢だと仮定してはならないと整理している。

AI Agentがセキュリティ原則を書き換えたわけではない。従来からある弱点を、より速く、広く、執拗に組み合わせられるようになった。

この能力は評価環境の中だけに留まるものでもない。OpenAIは、同等の能力が外部の脅威アクターにも利用可能になるにつれ、持続的で協調的なAI支援型の攻撃を脅威モデルへ織り込む必要があるとしている。自社でAI Agentを運用していない組織でも、探索の量と速度が増大することを外部脅威側の前提として考える必要がある。

まとめ

AI Agentを載せたAWS環境のセキュリティ要件を、一度フレームに通してみた。持ち帰る点は3つだ。

AI Agentは、正規の非人間IDを持つ実行主体として脅威分析の対象に入れる。 人間の内部不正と同じ枠には置かない。見るのは動機ではなく、与えた目的と許した権限の組み合わせだ。悪意がなくても、目的の達成経路上に想定外の操作が現れる。

一つの境界を突破されても、次の境界が独立して機能するように設計する。 今回、同じインシデント調査の中で止まった統制と止まらなかった統制の両方が記録された。差を生んだのは、取得されたIDから権限とネットワーク境界をどこまで変更できたかだった。既存の到達範囲で何ができるかという権限と、到達範囲そのものを変更できる権限は分けて設計する。

AI固有なのは原則ではなく、探索の量・速度・持続性だ。 最小権限も多層防御も分離も、従来どおり有効なまま残る。単一の統制を完全と考えないという原則が、これまで以上に短時間で試される。

参考資料

Hugging Face, “Anatomy of a Frontier Lab Agent Intrusion: A Technical Timeline of the July 2026 Incident”

OpenAI, “The Hugging Face incident and the road ahead”

OpenAI, “OpenAI – Hugging Face Incident Technical Report” (August 26, 2026)

関連記事

AI Agentでは、IAMやネットワーク、認証情報といった従来からのセキュリティ設計が不要になるわけではありません。むしろ、Agentが正規の権限を持って自律的に操作することを前提に、どこまで到達できるか、どの境界で止めるかを要件として明確にしておく必要があります。

本記事ではOpenAI・Hugging Faceの事例からAI Agentの到達範囲を整理しましたが、AWS側の統制、検知後の運用設計については、以下の記事で詳しく解説しています。

• VPC Encryption Controlsの落とし穴｜Flow Logsの暗号化判定とEnforce判定は別物
  AWSのネットワーク統制について、Flow Logsで観測できる状態とEnforceによる許可・拒否の判定が同じではない点を整理しています。「見えている状態」と「実際に強制される境界」を分けて考えるという点は、AI Agentのネットワーク設計にも共通します。
  
  
  

  VPC Encryption Controlsの落とし穴｜Flow Logsの暗号化判定とEnforce判定は別物

  VPC Encryption Controlsでは、Flow Logsで暗号化と表示されてもEnforceで許可されるとは限りません。encryption-statusと準拠判定の違い、既存Flow Logsにフィールドが自動追加されない点、ExclusionやTGWの注意点をAWS公式仕様から整理します。

  

  sys-univ.com

  2026.08.27
• 運用設計とは｜監視・障害対応・エスカレーションまでをどう設計するか
  監視はアラートを出して終わりではなく、重大度判定、エスカレーション、対応判断まで含めて設計する必要があります。本記事で扱った**「検知 → 重大度判定 → エスカレーション → 停止」**を、より広い運用設計の観点から整理しています。
  
  
  

  運用設計とは？運用設計書の目次サンプルと項目一覧｜システム基盤エンジニア視点

  運用設計とは何かをシステム基盤エンジニアの実務目線で解説します。運用設計書の目次サンプルと検討項目一覧を示し、監視・ログ・バックアップ・ジョブ管理、誰がやるのか、要件定義・基本設計との関係、処理方式設計との双方向連携を整理します。

  

  sys-univ.com

  2026.08.14

ある異なるAWSアカウントにある2台のRDS for OracleをDatabase Link（以下、DBリンク）で接続する構成を検討していたときの話です。

一方はAWS KMSによるストレージ暗号化あり、もう一方は暗号化なし。

注：本記事では、KMS暗号化ありのRDS AをDBリンク元、暗号化なしのRDS BをDBリンク先として説明します。NNEではDBリンク元とDBリンク先で設定するパラメータが異なるためです。

クロスアカウントRDS for OracleのDBリンク構成

つまり、A側に作成したDBリンクからBへ接続します。

ここでいう「DBリンクの方向」は接続を開始する方向です。AからBの表をSELECTすれば結果データはBからAへ返るため、DBリンクの向きとデータが流れる向きは同じとは限りません。

最初に疑問だったのは、

「KMSで暗号化されたRDSから、暗号化されていないRDSへDBリンクを張って問題ないのか」

ということでした。

問い合わせでは「データが文字化けしないか」という表現も使いました。しかし今振り返ると、本当に確認したかったのは文字コードの問題ではありません。

ストレージ上で暗号化されたデータがOracle Databaseからどう見え、DBリンクではどの状態で扱われるのか

という疑問でした。

さらに、

• 相手AWSアカウントへKMSキーを共有する必要があるのか
• 別VPC間でDBリンクを成立させるには何が必要なのか

も確認しました。

このとき印象的だったのが、AWSサポートから最初に、

「今回の暗号化とは、RDSのストレージボリューム暗号化という理解でよいか」

という趣旨の確認が入ったことです。

この確認が、今回の記事の本質です。

RDS for Oracleで「暗号化」と言っても、実際には複数のレイヤーがあります。

• AWS KMSによるRDSストレージ暗号化
• Oracle Transparent Data Encryption（TDE）
• Oracle NetのNNE／SSL/TLS
• AWSネットワーク基盤側の通信暗号化

「RDSが暗号化されている」ことと「DBリンク通信が暗号化されている」ことは別の話です。

本記事では、2026年8月時点のAWS公式仕様も確認しながら、この違いを整理します。

結論｜KMSによるRDS暗号化はDBリンクへ引き継がれない

結論から言えば、AWS KMSによるRDSストレージ暗号化が原因で、DBリンクのSELECT結果が暗号文になることはありません。

そもそも、DBリンク先のOracle Databaseがリンク元RDSのKMSキーを使ってデータを復号する仕組みではありません。

AWSサポートからも、KMSによる暗号化はストレージレイヤーで処理され、ストレージから読み出す際には透過的に復号されるため、ストレージ暗号化を原因としてDBリンクのデータが文字化けすることはない、という回答を得ています。

この「ストレージ暗号化を原因として」という限定も重要です。文字コードやOracle Netなど、別の原因による問題まで否定しているわけではありません。

AWS公式でも、RDSの保存時暗号化は基盤ストレージ、ログ、自動バックアップ、Read Replica、スナップショットなどを対象とし、RDSが復号を透過的に処理すると説明されています。

概念的には次の関係です。

KMSによるRDS暗号化とOracle Database／DBリンクの関係

Oracle Database自身が、KMSで暗号化されたストレージブロックを受け取ってKMSキーで復号しているわけではありません。

したがって、DBリンク接続のためにA側のKMSキーをB側AWSアカウントへ共有する必要もありません。

また、AからDBリンク経由でBへデータを書き込んだ場合、A側のストレージ暗号化属性がBへ引き継がれるわけでもありません。Bへ保存されたデータを暗号化するかどうかは、B自身のRDS暗号化設定で決まります。

なお、既存の非暗号化RDS DBインスタンスを、そのまま後から暗号化済みに変更することはできません。暗号化したスナップショットコピーを作成し、そこから新しいDBインスタンスをリストアする必要があります。

つまり、

「必要になったら後から暗号化をONにすればよい」

という設計にはできません。

RDS for Oracleで分けて考える4つの暗号化レイヤー

今回の話は、次の4レイヤーに分けると整理できます。

ポイントは、どれか一つを有効にすれば他のレイヤーまで暗号化されるわけではないことです。

KMS暗号化はどこまでの話なのか｜TDEとの違いとKMSキー共有

Oracle TDEはKMS暗号化とは別物

Oracle Transparent Data Encryption（TDE）は、Oracle Database側でデータを暗号化する仕組みです。

RDSのKMS暗号化がOracleより下のストレージレイヤーで処理されるのに対し、TDEではOracle Databaseがデータを書き込む前に暗号化し、読み出す際に復号します。

RDS for OracleでTDEを利用できるのはOracle Enterprise Edition＋BYOLです。Oracle WalletとTDE master keyはAmazon RDSが管理します。

TDEには設計時に注意すべき制約があります。

AWSではRDS for OracleのTDEをpermanent／persistentなオプションとして扱っており、一度有効にすると無効化できず、TDEを含まないOption Groupへ変更することもできません。TDEを利用するDBスナップショットは共有できません。

つまり、TDEは後から簡単に外せるオプションではありません。

RDS for Oracleには、TDE以外にもオンプレOracleの前提をそのまま持ち込めない制約があります。詳しくは「RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった」で整理しています。

RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった｜開発中に見えた設計ギャップと代替アプローチ

RDS for Oracleではオンプレ運用の前提が通用しない。Storage-Full、アーカイブログ、SSH不可など、開発中に見えた9つの設計ギャップと代替アプローチを整理します。

sys-univ.com

2026.08.30

また、TDEで保護されたデータも、暗号文のままDBリンクへ流れるわけではありません。Oracleが論理データへ復号した後、Oracle Netへ渡されます。

その先の通信を暗号化するのはNNEまたはSSL/TLSです。

RDSのKMS暗号化 ≠ Oracle TDE ≠ DBリンク通信の暗号化

という関係です。

DBリンク接続ではKMSキー共有は不要

DBリンクでは、各RDSの保存時暗号化は各RDS内で処理されます。

A側OracleがB側のKMSキーを使うわけでも、B側OracleがA側のKMSキーを使うわけでもありません。

したがって、クロスアカウントDBリンクのためにKMSキーを共有する必要はありません。

一方、暗号化されたDBスナップショットそのものを別AWSアカウントへ共有する場合は、KMSキーへのクロスアカウントアクセスが関係します。

AWSアカウントのデフォルトKMSキーで暗号化されたスナップショットはそのまま共有できません。AWS公式では、対象アカウントへアクセスを許可したcustomer managed keyを用意し、そのキーでスナップショットをコピーして共有し、共有先でも自アカウントのKMSキーを指定してコピーする手順が案内されています。

DBリンクとスナップショット共有では、

論理データへアクセスするのか、暗号化されたAWSリソース自体を共有するのか

が違います。

別AWSアカウントのRDS間でDBリンクを成立させる条件

KMSキー共有が不要でも、別AWSアカウントのRDSへそのままDBリンクを張れるわけではありません。

先に、AからBへOracle Netで到達できるネットワークを作る必要があります。

確認順序は、

VPC間接続 → Route → Security Group／NACL → DNS → Oracle Net → Database Link

と考えると分かりやすいです。

AWSサポートからはVPC Peeringが例示されました。AWS公式のRDS for Oracle DBリンク手順でも、同一VPCまたはピア接続されたVPC間で、有効なルート、ACL、Security Group、名前解決を確認するよう案内されています。

ただし、Database LinkというOracle機能自体がVPC Peeringを要求しているわけではありません。

本質的な要件は、DBリンク元からDBリンク先のRDS endpointとOracle Listenerポートへ到達できることです。

本記事ではAをDBリンク元としているため、基本となる通信方向は、

• A側：Bへのoutbound
• B側：AからOracle Listenerポートへのinbound

です。

Security Groupはstatefulなので、戻り通信のためだけに対称のinboundルールを追加する必要はありません。一方、Network ACLを独自に制限している場合はstatelessなので、復路も確認します。

接続先にはIPアドレスを固定せず、RDS endpointのDNS名を使用します。RDS自身も、基盤IPはフェイルオーバー等で変わり得るため、DNS名を利用することを推奨しています。

別VPCの場合はDNSも確認します。

VPC Peering越しでAmazon提供DNSを利用する場合は、VPC側のenableDnsSupportと、Peering接続側のDNS解決サポートを確認します。カスタムDNSを利用している場合は、そのDNSサーバーがDBリンク先を解決できる必要があります。

つまり、

Routeがある／SGが通る／DNSが引ける

を分けて確認する必要があります。

DBリンク通信の暗号化はKMSとは別に構成する｜NNEの設計

DBリンクのOracle Net通信を暗号化する方法の一つがNative Network Encryption（NNE）です。

RDS for Oracleでは、Option GroupへNATIVE_NETWORK_ENCRYPTIONを追加して利用します。NNEはOracle Databaseの全エディションで利用できます。

ここで重要なのは、

NNEオプションを追加しただけで「暗号化を必須にした」と考えてはいけない

ことです。

DBリンク元RDSはOracle Net clientになる

本記事の構成では、

• A：DBリンク元 → Oracle Net client
• B：DBリンク先 → Oracle Net server

です。

AWS公式も、DBインスタンスがDatabase Linkを利用するとき、そのDBインスタンスはクライアントとして動作すると明記しています。

したがって主に確認するのは、

A側：

SQLNET.*CLIENT

B側：

SQLNET.*SERVER

です。

Requestedは「必須」ではない

RDSのNNE Optionでは、SQLNET.ENCRYPTION_CLIENTとSQLNET.ENCRYPTION_SERVERの既定値はいずれもRequestedです。

ただし、この既定値はNNEオプションを追加した後の話です。NNEオプションを追加していないRDSが、最初からNNEで通信しているという意味ではありません。

また、Requestedだから暗号化されないという意味でもありません。

CLIENT／SERVERともにRequestedで双方がNNEを利用できれば暗号化は成立します。

問題は、相手が暗号化に対応しなくても、暗号化なしで接続できる場合があることです。

つまり、

「暗号化されることがある」と「暗号化を必須条件として保証する」は別です。

AからBへのDBリンクについて暗号化を必須にしたい場合、A側を例えば、

SQLNET.ENCRYPTION_CLIENT=Required

とします。

B側がRequestedでも、接続が成立すれば暗号化されます。暗号化条件を満たせなければ接続自体が失敗します。

一方、B側を、

SQLNET.ENCRYPTION_SERVER=Required

とすると、DBリンクだけでなくBへ接続する他のOracle Netクライアントにも暗号化を要求します。

したがって、

DBリンクだけを暗号化したいのか、RDSへの全接続を暗号化したいのか

を分けて設計します。

Requiredだけでなく暗号方式も確認する

さらに注意したいのが暗号アルゴリズムです。

Oracle Database 19cなどのRDS NNE設定では、既定候補にAESだけでなくRC4、3DES、DESも含まれ、既定リストはRC4_256から始まります。AWSはDES、3DES、RC4をsecure encryption methodとは扱っていません。

そのため、

SQLNET.ENCRYPTION_CLIENT=Required

だけでは、使用する暗号方式まで安全なものへ限定したことにはなりません。

例えばAES256へ限定する設計なら、

A側：

SQLNET.ENCRYPTION_CLIENT=Required
SQLNET.ENCRYPTION_TYPES_CLIENT=AES256

B側：

SQLNET.ENCRYPTION_SERVER=Requested または Required
SQLNET.ENCRYPTION_TYPES_SERVER=AES256

のように、CLIENT／SERVER双方で共通する方式を設定します。

SQLNET.ALLOW_WEAK_CRYPTOとSQLNET.ALLOW_WEAK_CRYPTO_CLIENTSはいずれも既定値がTRUEです。弱い方式を禁止する場合はこちらも確認しますが、既存クライアントのパッチレベルや互換性へ影響するため、接続元を確認した上で変更する必要があります。

暗号化と整合性チェックは別設定

NNEでは、通信の暗号化とは別にデータ改ざんを検知するチェックサムも設定できます。

SQLNET.ENCRYPTION_*をRequiredにしても、SQLNET.CRYPTO_CHECKSUM_*が自動的にRequiredになるわけではありません。

盗聴対策と改ざん検知は別々に設計する必要があります。

「暗号化されているか」だけでなく方式まで確認する

設定後はV$SESSION_CONNECT_INFOを確認し、実際にネゴシエーションされた暗号方式を確認できます。

SELECT NETWORK_SERVICE_BANNER
FROM V$SESSION_CONNECT_INFO
WHERE SID = SYS_CONTEXT('USERENV', 'SID');

NNEが有効ならencryption service adapterを含む行が表示され、AES256など実際にネゴシエーションされた方式を確認できます。

見るべきなのは、

「暗号化されているか」だけではなく「何で暗号化されているか」

です。

既定候補にはRC4_256も含まれるため、AES256など設計時に想定した方式が実際に使われているところまで確認する必要があります。

なお、DBリンクによって生成されたリモートセッションをどのように特定し、証跡化するかについては、DBリンク固有の実機確認が必要です。

RDS間DBリンクはSSL/TLSでも暗号化できる

DBリンクの暗号化方式はNNEだけではありません。

AWS公式には、Oracle DBインスタンス間では、各インスタンスにOracle SSLオプションが構成されていれば、SSL/TLS endpoint経由でDatabase Linkを確立でき、追加構成は不要と明記されています。

つまり、本記事のA→B構成でも、両RDS for OracleへSSLオプションを設定することでDBリンク通信をTLS化できます。

SSLオプションを入れただけでは全通信TLSにはならない

RDS for Oracleでは、SSL接続用に通常接続とは別の第2ポートを利用します。

そのため、

• 通常ポート：非SSL通信
• SSLポート：SSL/TLS通信

を同じDBインスタンスで併存できます。

つまり、SSLオプションを追加しただけでは、そのRDSへの全通信がTLS必須になるわけではありません。

TLSを必須にする場合は、SSL/TLS endpointを利用することに加えて、Security Group等で非SSL経路を許可していないかも確認する必要があります。

NNEはOracle NetのネゴシエーションでRequiredを使って強制し、TLSはポートと接続経路で強制するという違いがあります。

TLSバージョンとCipher Suiteも確認する

2026年8月時点で、RDS for Oracleの19c／21cはTLS 1.0と1.2をサポートしています。

特に既存のOracle SSLオプションでは、SQLNET.SSL_VERSIONが自動的に1.0へ設定されています。既存環境では「SSLを使っている＝TLS 1.2」と判断せず、設定値を確認する必要があります。26aiではTLS 1.2のみがサポートされています。

Cipher Suiteも同様です。

19c／21cの既定Cipher SuiteであるSSL_RSA_WITH_AES_256_CBC_SHAはFIPS対応ですが、AWS公式表ではFedRAMP準拠ではありません。つまり、既定値のままで自分たちのセキュリティ要件を満たすとは限りません。

また、RDS for OracleではRSA証明書とECDSA証明書をサポートしており、SQLNET.CIPHER_SUITEへ指定する方式はDBインスタンスの証明書タイプと互換である必要があります。互換性のないCipher Suiteしか設定していないOption GroupはDBインスタンスへの関連付けに失敗します。

NNEとSSL/TLSは併用できない

NNEとSSL/TLSは、同じRDS for Oracle DBインスタンスで併用できません。

したがって、

NNEで暗号化した上にTLSを重ねる

という構成にはできません。

どちらを採用するかは、既存の接続方式、証明書管理、接続クライアント、セキュリティ基準から判断します。

重要なのは、

KMSによるRDS暗号化とは別に、Oracle Net通信の暗号化方式を選ぶ

ことです。

AWS基盤側の通信暗号化とOracle Net暗号化は分けて考える

AWSネットワーク基盤側にも通信暗号化の仕組みがあります。

Amazon RDSでは、一部のインスタンスタイプについてNitro Systemによるインスタンス間通信の自動暗号化が提供されています。ただし、対象インスタンスタイプ、同一Region、同一VPCまたはVPC Peering、Transit Gateway等の仮想ネットワークサービスを経由しないことなどの条件があります。

RDS for Oracleでは、Oracleで利用可能なインスタンスクラスと、Nitroによる自動暗号化の対象一覧を別々に確認する必要があります。

例えば、RDS全体の自動暗号化対象一覧に含まれるM7g／R7gはRDS for Oracleの利用可能クラスには含まれていません。一方、RDS for Oracleで利用可能なM7i／R7i／M8i／R8iは、2026年8月時点の自動暗号化対象一覧には列挙されていません。

したがって、「新しい世代だから自動的に暗号化される」とは判断できません。

さらに2025年11月にはVPC Encryption Controlsが追加され、AWS基盤側の転送時暗号化をMonitor／Enforceで監視・強制できるようになりました。RDS公式でも、Enforce VPCでは転送時暗号化をサポートするNitroベースのDBインスタンスのみ新規プロビジョニングできるとされています。既存VPCをEnforceへ移行する際は、まずMonitorで非準拠リソースを確認・是正する必要があります。

VPC Encryption ControlsのMonitor／Enforceの違い、Flow Logsのencryption-statusの読み方、ExclusionやTransit Gatewayを含むEnforce移行時の注意点は、「VPC Encryption Controlsとは｜Monitor／EnforceとFlow Logsの読み方」で整理しています。

VPC Encryption Controlsの落とし穴｜Flow Logsの暗号化判定とEnforce判定は別物

VPC Encryption Controlsでは、Flow Logsで暗号化と表示されてもEnforceで許可されるとは限りません。encryption-statusと準拠判定の違い、既存Flow Logsにフィールドが自動追加されない点、ExclusionやTGWの注意点をAWS公式仕様から整理します。

sys-univ.com

2026.08.27

ただし、ここでDBリンクの記事として重要なのは、AWS基盤側の証跡とOracle Net側の証跡は同じではないことです。

VPC Flow Logsではencryption-statusとして、

• 0：not encrypted
• 1：nitro-encrypted
• 2：application-encrypted
• 3：両方
• -：状態不明、またはVPC Encryption Controlsが無効

を記録できます。

ただしAWSがapplication-encryptedとして認識する通信は限定されています。interface endpointやgateway endpointについては、AWS自身がパケット内容ではなく使用ポートから暗号化状態を推定していると説明しています。

したがって、

Flow Logsが1: nitro-encryptedだから、Oracle NetもNNE/TLSで暗号化されている

とは言えません。

逆に、Oracle NetをNNEで暗号化していても、Flow Logsがそれをapplication-encryptedとして認識するとは限りません。Nitro暗号化も適用されない経路では、Flow Logs側で0: not encryptedと評価される可能性があります。

つまり、

一方のレイヤーの証跡だけで、もう一方の暗号化状態を証明も否定もできません。

VPC Flow Logsが答えるのは、

「AWS基盤から見て、このフローをどの暗号化状態として扱っているか」

です。

NNEでV$SESSION_CONNECT_INFOから確認するのは、

「このOracle Netセッションで、どの暗号方式がネゴシエーションされたか」

です。

対象も粒度も異なります。

まとめ｜「暗号化されているか」ではなく「どのレイヤーか」で考える

今回の疑問は、

KMSで暗号化したRDS for Oracleと、暗号化されていない別AWSアカウントのRDSをDBリンクで接続するとどうなるのか

というところから始まりました。

結論は3つです。

• KMSによるRDS暗号化は保存時の暗号化であり、暗号化属性やKMSキーがDBリンク先へ伝播するわけではない
• DBリンクのOracle Net通信を暗号化するなら、NNEまたはSSL/TLSを別途設計する
• AWS基盤側の暗号化とOracle Net暗号化は別レイヤーであり、一方の証跡だけでもう一方を証明・否定できない

設計時に確認するべきなのは、

「暗号化されているか、いないか」

という二択ではありません。

「どのデータを、どのレイヤーで、どの仕組みによって暗号化し、それをどの方法で確認するのか」

まで分けて考える必要があります。

今回AWSサポートが問い合わせの冒頭で、

「今回の暗号化とは、RDSのストレージボリューム暗号化という理解でよいか」

という趣旨の確認をしてきた理由も、ここにあります。

KMS、TDE、Oracle Net、AWSネットワーク基盤。

すべて「暗号化」ですが、守っている場所も確認方法も異なります。

RDS for OracleでDBリンクを設計するときは、まずこの境界を分けるところから始めるのがよいでしょう。

関連記事

RDS for Oracleでは、暗号化以外にもオンプレミスOracleの前提をそのまま持ち込めない制約があります。また、こうしたクラウド固有の差異は、構築段階ではなく要件定義や基本設計の段階で確認しておくことが重要です。あわせて確認したい方は、以下の記事も参考にしてください。

• RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった
  SYS権限やOSアクセス、ログ確認など、オンプレミスOracleからRDS for Oracleへ移行するときに変わる運用・設計上の前提を、実案件で直面した制約から整理しています。

RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった｜開発中に見えた設計ギャップと代替アプローチ

RDS for Oracleではオンプレ運用の前提が通用しない。Storage-Full、アーカイブログ、SSH不可など、開発中に見えた9つの設計ギャップと代替アプローチを整理します。

sys-univ.com

2026.08.30

• 基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程
  サーバー、データベース、ネットワーク、セキュリティ、監視、バックアップ、運用など、システム基盤の基本設計で何を決めておくべきかを整理しています。

基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程

基本設計は画面設計だけでは終わらない。ログ・バックアップ・ジョブ・監視など、本番運用を見据えた基盤設計の論点を、ファイルアップロードや夜間バッチの実例で整理します。

sys-univ.com

2026.06.20

セキュリティグループも見た。
NACLも見た。
VPCルートテーブルも見た。

それでも通信できない。

そんなとき、原因はAWSコンソールの中ではなく、OSの中にあるかもしれません。

今回扱うのは、EC2を別AZで起動した際に、Windows ServerのOS内ルート情報が更新されず、通信できなくなった事象です。

この記事では、単なるルート設定の話ではなく、EC2Launch、User Data、AMI再利用、DR設計で見落としやすい「起動後のOS状態」について整理します。

EC2は起動した。でも通信できない

EC2インスタンスを別AZで起動した。

インスタンスの起動は成功している。
OSも上がっている。
しかし、通信できない。

このような事象が起きると、まずAWS側の設定を疑うと思います。

セキュリティグループがおかしいのか。
NACLで止められているのか。
サブネットのルートテーブルが間違っているのか。

もちろん、それらは確認すべきです。

しかし、今回の原因はそこではありませんでした。

問題は、Windows OS内のルーティング情報が、移動先AZに合わせて更新されていなかったことでした。

AZ移動後、Windowsサーバが通信できない

今回の事象は、AZ障害時の切替を想定した環境で発生しました。

通常時は、あるAZでWindows ServerのEC2インスタンスを稼働させています。

障害時には、別AZでインスタンスを起動し、業務を継続する想定でした。

構成としては、クラウドではよくある考え方です。

図　別AZでEC2を起動できても、起動後に通信できるとは限らない

ただし、この構成で注意すべきなのは、「別AZでEC2が起動できること」と「起動後に業務通信が成立すること」は別問題だという点です。

今回も、インスタンスの起動自体は成功していました。

OSも起動していました。

ところが、正常なネットワーク通信ができませんでした。

AWS側の設定だけを見れば、サブネット、セキュリティグループ、NACL、VPCルートテーブルを疑いたくなります。

しかし、調査していくと、問題はWindows OS内部のルーティング情報にありました。

移動先AZで必要となるルート情報が、OS起動時に追加されていなかったのです。

ここで重要なのは、VPCのルートテーブルではなく、Windows OS内のルート情報だという点です。

では、なぜOS内にルート情報が必要になるのでしょうか。

たとえば、次のような構成を考えてみます。

通常の業務通信は、デフォルトゲートウェイから出す。
一方で、監視サーバ向けのセグメント 172.16.10.0/24 には、2枚目のNIC、つまり別ENI側の経路を使って通信させる。

この場合、Windows OS内には、

172.16.10.0/24 は、2枚目のNIC側の経路へ向ける

VPCルートテーブルが正しくても、Windows OS内にこのルートがなければ、監視サーバ向けの通信は期待した経路に流れません。

EC2はクラウド上の仮想サーバです。

しかし、サーバである以上、OSの中にもネットワーク設定があります。

クラウド側の設定だけでは、通信は完結しません。

さらに、別AZで起動すると、通常は起動先のサブネットも変わります。

サブネットやENI構成が変われば、OS内のスタティックルートで前提にしていたネクストホップ（次に経由するルーターやゲートウェイのIPアドレス）　　やインターフェースが、移動先の環境と合わなくなることがあります。

しかし、AMIを取得した時点のOS内ルート情報には、旧環境を前提にした経路が残っている場合があります。

そのまま別AZで起動すると、ルートのエントリは存在しているのに、実際には期待した経路へ到達できない。

これが、

「設定した覚えはあるのに通信できない」

という事象の正体です。

原因はEC2Launchの起動時処理だった

原因は、Windows Serverの起動時に動く初期化処理でした。

Windows Server 2012 R2以前では、EC2Configというサービスが使われていました。

一方、Windows Server 2016 / 2019では、EC2Launch v1が使われる構成があります。

ここで見落としやすいのは、

「Windows Serverなら、起動時に毎回同じ初期化処理が走る」

とは限らないことです。

今回のポイントはここです。

AMIを取得する前のインスタンスで、すでに初回起動時の処理が終わっている。
その状態をAMIとして固める。
そのAMIから別AZで起動する。
しかし、OSや初期化エージェントの状態としては、必要な処理が「初回起動時のみ実行済み」と扱われる。
その結果、別AZで起動したときに、ルート追加処理が走らない。

このような流れになると、EC2自体は起動しているのに、OS内のルート情報が移動先AZに合わないまま残ります。

その結果、サーバは起動したのに通信できない、という状態になります。

若手SEがここで学ぶべきなのは、OSの設定そのものだけではありません。

「その設定は、いつ、どの仕組みによって入るのか」

を見る必要があるということです。

EC2Config、EC2Launch v1、EC2Launch v2をざっくり押さえる

細かい仕様をすべて暗記する必要はありません。

ただ、Windows EC2の初期化エージェントには世代差があることは押さえておくべきです。

Windows Server 2012 R2以前
  → EC2Config

Windows Server 2016 / 2019の一部AMI
  → EC2Launch v1

Windows Server 2022 / 2025、
一部のWindows Server 2016 / 2019 AMI
  → EC2Launch v2

EC2Launch v2では、「どのタスクを、どのステージで、どの頻度で実行するか」を管理する考え方になります。

見るべきポイントは、バージョン名そのものではありません。

実務では、以下を確認します。

・対象OSは何か
・EC2Config、EC2Launch v1、EC2Launch v2のどれか
・User Dataは初回だけか、毎回か
・起動時タスクは有効か
・タスクの実行頻度は once か always か
・初期化処理のログにエラーは出ていないか

ここを確認しないままDR設計や移行設計を進めると、机上では成立しているのに、切替時に通信できないサーバが立ち上がることがあります。

なお、EC2Launch v2には agent-config.yml などの設定ファイルがありますが、この記事では詳細な設定手順までは踏み込みません。

ここで重要なのは、ファイル名を暗記することではなく、起動時に実行されるタスクと実行頻度を確認する、という考え方です。

なぜ永続ルートではなく、起動ごとの処理なのか

ここで、こう思う人もいるかもしれません。

「Windowsなら route add -p で永続ルートにすればよいのでは？」

たしかに、固定的な経路であれば、それで済む場合もあります。

route add -p は、Windowsで再起動後も残るルートを登録する方法です。

しかし、クラウド移行やAZ切替では、単純な永続ルートだけでは不十分な場合があります。

なぜなら、起動先のAZ、サブネット、ENI構成、ゲートウェイ、経路設計によって、追加すべきルートが変わることがあるからです。

AMIに固定ルートを焼き込んでしまうと、元のAZでは正しくても、別AZでは古い経路を引きずる可能性があります。

たとえば、元の環境では `10.0.1.1` 側を通る前提でOS内にルートを持っていたとします。

しかし、別AZで起動した後は、サブネットやENI構成が変わり、`10.0.2.1` 側を通すべき構成になっているかもしれません。

このとき、OS内に旧環境のルートが残ったままだと、設定は存在しているのに、移動先環境では正しい経路に通信が流れません。

一方、起動ごとのスクリプトでルートを追加する方式なら、起動先の環境に合わせて必要なルートを入れ直す設計にできます。

もちろん、その分だけスクリプト設計は慎重に行う必要があります。

特に重要なのが、冪等性です。

冪等性とは「同じ処理を何度実行しても、結果が壊れず同じ状態に収まる性質のこと」です。

起動のたびに実行される処理は、何度実行しても壊れないように作る必要があります。

たとえば、同じルートを毎回追加しようとしてエラーになる。
既存設定を無条件で上書きしてしまう。
途中で失敗したときに中途半端な状態が残る。

こうした作りになっていると、初期化処理そのものが新しい障害原因になります。

対策は「OS起動ごとに必要な処理を実行させる」こと

今回の対策は、OS起動ごとに必要なルート追加処理が実行されるようにすることでした。

EC2Launch v1の場合、単に「起動すれば自動で全部整う」と考えるのではなく、起動時に必要な処理が実行される状態になっているかを確認する必要があります。

たとえば、今回のようなルート追加であれば、User DataからEC2Launchのモジュールを読み込み、`Add-Routes` を呼び出す方法があります。

Import-Module (Join-Path $env:ProgramData 'Amazon\EC2-Windows\Launch\Module\Ec2Launch.psd1')
Add-Routes

<persist>true</persist>

重要なのは、コマンドそのものを暗記することではありません。

タスクスケジューラ、User Data、EC2Launchのどの仕組みによって、起動時の処理を実行させているのかを理解することです。

EC2Launch v2では、この種の起動時タスクの扱いが整理されており、同じ問題が起きにくい構成になっています。

ただし、実際の挙動は、AMIの世代、EC2Launchのバージョン、User Data、タスクの実行頻度に依存します。

そのため、v2だから確認不要、とは考えない方が安全です。

環境によって確認ポイントは変わります。

しかし、共通する考え方は同じです。

「起動時に、必要なOS設定が、確実に反映される状態になっているか」

ここを確認する必要があります。

AWS側の設定だけ見ても足りない

若手SEにとって、EC2の通信不可というと、どうしてもAWS側の設定に目が行きます。

それ自体は間違いではありません。

実際、通信不可の原因として、セキュリティグループ、NACL、VPCルートテーブル、サブネット、ENI、DNS設定などはよくあります。

しかし、それだけでは足りません。

今回のように、OS内部の設定が原因になることもあります。

今回の切り分けは、3つの層で見ると整理しやすくなります。

AWSインフラ層
  → セキュリティグループ、NACL、VPCルートテーブルを見る

初期化エージェント層
  → EC2LaunchやUser Dataが期待どおり実行されたかを見る

OS設定層
  → Windowsのルーティングテーブルが移動先環境に合っているかを見る

EC2の通信確認では、AWS側の設定、クラウド初期化処理、OS内部の設定を一連の流れとして見る必要があります。

図　AWS側の設定だけ見ても足りない

この図で言いたいのは、EC2が起動した時点で確認が終わるわけではない、ということです。

AWS側の設定が正しく、インスタンスが起動していても、その後に動く初期化処理やOS内部の設定が想定どおりでなければ、業務通信は成立しません。

サーバが起動していることと、業務通信が成立していることは別です。

ここを混同すると、DRテストや移行リハーサルで痛い目を見ます。

これはルーティングだけの話ではない

今回の事象は、Windows Serverのルーティング情報が更新されなかった、という個別トラブルに見えます。

しかし、これはルーティングだけの話ではありません。

以前扱ったような、MTU設定が戻る、SSHでログインできない、OS起動後に想定した設定になっていない、といった事象にも共通する構造があります。

共通しているのは、初期化エージェントがOS設定を書き換える、または書き換えないことで、起動後のOS状態が想定とずれる点です。

ある設定は、初期化エージェントによって上書きされます。

別の設定は、初期化エージェントが実行されないために更新されません。

つまり、

「書き換えられて困る」

場合もあれば、

「書き換えてほしいのに書き換わらない」

場合もあります。

どちらも、クラウド初期化処理がOS設定に関与していることを理解していないと、原因にたどり着きにくくなります。

なぜクラウドはOS設定を書き換えるのか

では、なぜクラウド環境では、起動時にOS設定へ手を入れるのでしょうか。

理由は大きく3つあります。

1つ目は、セキュリティです。

クラウド環境では、インターネットや社内ネットワークから到達可能なサーバを短時間で作成できます。

そのため、初期状態をできるだけ安全側に寄せる必要があります。

SSHのパスワード認証を無効にし、公開鍵認証を前提にするような考え方は、その典型です。

パスワード総当たり攻撃の入口を減らすためです。

これは、クラウド環境におけるベストプラクティスに寄せた挙動と考えると理解しやすいです。

2つ目は、クラウド環境に合わせてOSを自動適応させるためです。

EC2インスタンスは、起動時にインスタンスメタデータ、User Data、ネットワーク情報などを利用します。

OSは、起動した場所、割り当てられたIP、ホスト名、初期化スクリプトなどをもとに、クラウド上で動ける状態に整えられます。

3つ目は、AMIを再利用するためです。

AMIは、ある時点のOS状態を固めたものです。

しかし、そのAMIから起動されるインスタンスは、元の環境と同じとは限りません。

別AZかもしれません。
別サブネットかもしれません。
別IPかもしれません。
別用途のサーバとして起動されるかもしれません。

そのため、AMIに残っているOS設定をそのまま信じるだけでは危険です。

クラウドでは、起動時にメタデータやUser Dataを参照し、起動先の環境に合わせて初期化する仕組みが用意されています。

ただし、その初期化処理が「いつ」「どの条件で」「何を」実行するかは、OS、エージェント、設定によって変わります。

ここを理解していないと、

設定したはずなのに戻った
自動で入ると思っていたのに入らなかった
AMIから起動したら前の状態を引きずった

DR設計では「起動できる」だけでは足りない

今回の話は、DR設計やAZ障害時の切替設計にも直結します。

DR設計では、次のような確認をしがちです。

・別AZでEC2が起動できる
・AMIからインスタンスを作成できる
・EBSを付け替えられる
・IPやDNSを切り替えられる

しかし、これだけでは不十分です。

本当に確認すべきなのは、起動後に業務通信が成立するかです。

実務では、少なくとも以下を確認した方がよいです。

・OS内のルート情報は正しいか
・DNS名前解決はできるか
・ADや認証基盤へ到達できるか
・業務アプリの接続先へ通信できるか
・監視、バックアップ、ジョブ管理エージェントは動くか
・User Dataや起動時スクリプトは期待どおり実行されたか
・初期化処理のログにエラーは出ていないか

業務として使える状態になったかどうかです。

ここを間違えると、テストでは成功したように見えても、本番障害時に通信できないサーバが立ち上がることになります。

まとめ

今回は、EC2を別AZで起動した際に、Windows Serverのルーティング情報が更新されず、通信できなくなった事象を扱いました。

原因は、AWS側のセキュリティグループやVPCルートテーブルではなく、OS内部のルート情報でした。

そして、その背景には、EC2Config、EC2Launch、EC2Launch v2といったクラウド初期化エージェントの挙動差がありました。

クラウドでは、サーバを起動するだけなら簡単です。

しかし、起動したサーバが業務として使える状態になっているかは、別の問題です。

若手SEは、EC2が起動したかどうかだけで安心してはいけません。

見るべきなのは、起動後に、どの設定が、どのタイミングで、どの仕組みによって反映されるのかです。

サーバは起動した。
でも通信できない。

その原因は、AWS側ではなく、OSの中にあるかもしれません。

関連記事

今回のようなトラブルは、AWSやOSの設定だけを個別に見るのではなく、切替後にシステム全体が業務として使える状態になっているかまで確認する必要があります。

システム基盤・クラウドエンジニアの仕事
サーバー、OS、監視、バックアップ、可用性、クラウドなどを横断し、
システムを「整える・保つ・戻す」ための基盤設計・運用・障害対応を解説しています。

システム基盤・クラウドエンジニアの仕事｜整える、保つ、戻す

システム基盤エンジニアの仕事内容を、インフラエンジニアとの違いから実務まで解説。サイジング、標準化、監視、可用性、バックアップ、AWS移行、障害対応を大規模SIの実例を交えて紹介します。

sys-univ.com

2026.08.17

詳細設計とは何を決める工程か｜パラメータ表で終わらせないための設計の考え方
基本設計で決めた内容を、構築・テスト・運用できる具体的な設定や手順へどう落とし込むかを整理しています。

【全3回・第1部】詳細設計とは何を決める工程か｜パラメータ表で終わらせないための設計の考え方

詳細設計とは、基本設計で決めた方式を構築・テスト・運用できる粒度に落とし込む工程です。OS、ミドルウェア、DB、ジョブ、監視、バックアップなどを、単なるパラメータ表ではなく品質保証ストーリーとして設計する考え方を基盤SEの目線で解説します。

sys-univ.com

2026.08.20

シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。

実務で使えるシステム開発方法論｜ナギ ＠ 氷河期SEの知見録｜note

要件定義、基本設計、詳細設計、テスト、移行、運用保守まで、システム開発の流れを実務目線で体系化するマガジンです。教科書には書かれにくい、設計漏れ、手戻り、品質保証、運用で詰まるポイントを、現場経験に基づいて整理します。若手SEだけでなく、開ReadMore...

note.com

• 【第1部】システム監視の基本｜死活監視・エージェント監視・SNMP監視
  監視の基本構造、死活監視、エージェント監視、SNMP監視、MIB・OIDなどを解説

• 【第2部】この記事
  クラウド監視、既存監視のFit & Gap、運用で使える監視設計を解説

はじめに

前編では、死活監視、エージェント監視、SNMP監視など、システム監視の基本的な仕組みを整理しました。

そこで確認したのは、ping が通ることと、システムが業務として正常に使えることは別だという点です。

サーバへの到達、プロセスの起動、HTTP/HTTPSの応答、業務処理の正常終了では、それぞれ確認しているレベルが異なります。

後編では、この考え方をクラウド環境へ広げます。

AWS CloudWatchやOCI Monitoringを使えば、自前の監視サーバを構築せずに、メトリクス、ログ、アラームを扱える場合があります。

しかし、クラウド監視サービスを使えば、監視設計が不要になるわけではありません。

• 標準メトリクスで足りるのか
• 既存監視をそのまま置き換えられるのか
• どの値を異常とするのか
• 誰に通知するのか
• 通知後に何を確認し、どう対応するのか

こうした点は、クラウドでも設計する必要があります。

特にオンプレミスからクラウドへ移行する場合は、既存監視をそのまま移すのではなく、何を引き継ぎ、何を標準機能で代替し、何を見直すのかというFit & Gapが重要になります。

監視は、アラートを出すための設定ではありません。

障害に気づき、判断し、対応につなげるための設計です。

クラウド監視とは何か

前編で説明した監視構成は、オンプレミスや従来型の監視製品を前提としたものでした。

一方、クラウドでは監視の実現方法が少し変わります。

クラウドでは、クラウドベンダーが用意する監視サービスを使って、仮想サーバ、ストレージ、ロードバランサ、データベース、ネットワーク、サーバレス、コンテナなどのメトリクス、ログ、イベントを収集できます。

そのため、従来のように自前で監視サーバを立てて、すべてのサーバに監視エージェントを導入し、監視製品を運用する、という構成が必ずしも必要ではありません。ただし、ここで誤解してはいけないことがあります。

クラウド監視サービスがあることと、監視設計が不要になることは別です。
クラウド監視サービスは、監視を実現するための部品です。

何を監視するのか。 どの値を異常とするのか。 どの条件で通知するのか。 通知を受けた人が何を確認するのか。 既存システムで行っていた監視を新システムでも継続するのか。

ここは、設計で決める必要があります。

特にオンプレミスからクラウドへ移行する業務システムでは、既存監視の引き継ぎが大きな論点になります。

クラウド監視サービスの代表例

クラウド監視サービスは、クラウドベンダーごとに用意されています。

AWSであれば、CloudWatch。 Azureであれば、Azure Monitor。
Google Cloudであれば、Cloud Monitoring。
OCIであれば、OCI Monitoring。

それぞれ名称や機能の範囲は異なりますが、基本的には、クラウド上のリソースからメトリクス、ログ、イベントを収集し、条件に応じてアラームや通知につなげるためのサービスです。

この記事では、AWSでよく使われるCloudWatchを中心に説明します。

あわせて、Oracle DatabaseやOracle製品を利用している業務システムではOCIが選択肢になることもあるため、OCI Monitoringについても簡単に触れます。

AWS CloudWatchの場合

AWS CloudWatchは、AWS上のリソースを監視するための代表的なサービスです。

EC2、RDS、ELB、EBS、Lambda、ECS、EKSなど、AWS上の多くのサービスはCloudWatchにメトリクスを出力できます。

たとえば、EC2であればCPU使用率、ネットワーク送受信量、ディスクI/Oなどを確認できます。

RDSであれば、CPU使用率、DB接続数、ストレージ容量、読み書きIOPSなどを確認できます。ELBであれば、リクエスト数、ターゲットの正常性、HTTPエラー数、レスポンスタイムなどを確認できます。

CloudWatchでは、こうしたメトリクスに対してアラームを設定できます。

たとえば、CPU使用率が一定時間以上高い状態が続いたら通知する。 RDSの空き容量が少なくなったら通知する。 ELB配下の正常ターゲット数が減ったら通知する。 アプリケーションログに特定のエラーメッセージが出たら通知する。

このように、CloudWatchはAWS上のシステム監視における基本的な部品になります。ただし、CloudWatchを使えばすべてが自動で完璧に監視されるわけではありません。

標準メトリクスで足りるのか。 詳細監視が必要なのか。 CloudWatch Agentを入れてOS内部のメモリやディスク使用率を取得するのか。 アプリケーションログをCloudWatch Logsへ送るのか。 ログのどの文字列を異常として拾うのか。 アラーム閾値をどう設定するのか。 通知先をどうするのか。 通知を受けた人が何を確認するのか。

これらは設計が必要です。

特にオンプレミスからAWSへ移行する場合、既存の監視をCloudWatchだけでそのまま置き換えられるとは限りません。

JP1、Systemwalker、Zabbix、PFM for Oracle、Oracle Enterprise Managerなどで見ていた監視項目が、CloudWatchの標準メトリクスだけで同じ粒度で取得できるとは限らないからです。

そのため、AWSへ移行する場合でも、CloudWatchで何が見えるかだけではなく、既存監視で何を見ていたのか、新システムでも同じ監視が必要なのか、必要ならCloudWatchで代替できるのか、できない場合は何で補うのかを整理する必要があります。

OCI Monitoringの場合

OCIでも、クラウドネイティブな監視サービスがあります。
代表的なのがOCI Monitoringです。

OCI Monitoringを使うと、OCI上のコンピュート、ストレージ、ロードバランサ、データベース、ネットワーク関連リソースなどのメトリクスを収集し、条件に応じてアラームを設定できます。

OCIのComputeインスタンスでは、プラグインを有効化することで、インスタンスの状態やメトリクスを取得できる構成もあります。
ただし、OCI Monitoringを使えば、Oracle Databaseの性能監視や既存の運用監視がすべて自動で置き換わるわけではありません。

Oracle Databaseを利用している業務システムでは、OCI Monitoringで見るもの、Oracle Database側の機能で見るもの、OEMで見るもの、ログ監視で見るもの、運用手順で確認するものを分けて考える必要があります。

特に、既存システムでOracle Database、Oracle Enterprise Manager、AWR、ASH、Performance Hub、PFM for Oracleなどを利用していた場合、クラウド移行後にどの監視を何で代替するのかを整理する必要があります。

Oracle系システムでは、DB性能、待機イベント、SQL、セッション、表領域、アラートログなど、DB内部の監視観点が重要になることがあります。
そのため、OCI Monitoringだけで考えるのではなく、Oracle Databaseの監視機能や既存運用を含めて、全体として監視設計を行う必要があります。

クラウド移行では、既存監視のFit & Gapが必要

クラウド移行といっても、完全な新規開発ばかりではありません。

実務では、既存のオンプレミスシステムをクラウドへ移すリフト＆シフトや、移行後に段階的にクラウドネイティブ化していくケースが多くあります。

その場合、移行前のシステムで行っていた監視を、移行後にどう引き継ぐかが大きな論点になります。

既存環境では、JP1、Systemwalker、Zabbix、PFM for Oracle、Oracle Enterprise Managerなどで、OS、ジョブ、ログ、DB性能、表領域、待機イベント、SQL、アラートログなどを監視していたかもしれません。

では、それをクラウド移行後に同じように見られるのでしょうか。答えは、簡単ではありません。

クラウド移行後の監視Fit & Gapでは、少なくとも次の3つに整理して考える必要があります。

1. 既存監視を標準機能で置き換えられるもの

PFM for Oracleや既存監視製品で見ていた内容を、OEM、AWR、ASH、Performance Hub、CloudWatch、Performance Insights、Database Insightsなどで代替できる場合は、新環境の標準機能に寄せる判断があります。

この場合、既存監視をそのまま機械的に移植するのではなく、新環境で標準的に提供されている監視機能を使い、運用をシンプルにできないかを検討します。

2. 標準機能だけでは置き換えられないもの

一方で、既存監視で見ていた項目が、新環境の標準機能では取得できない、または同じ粒度で監視できない場合もあります。

その場合は、代替方式を検討します。

別のメトリクスで代替できるのか。 ログ監視で拾えるのか。 スクリプトで補完できるのか。 外部監視製品やAPMを使うのか。 そもそも新環境でも本当に必要な監視なのか。

ここを整理せずに進めると、オンプレでは見えていた異常が、クラウド移行後に見えなくなることがあります。

3. 代替するか、捨てるか、運用でカバーするもの

標準機能で置き換えられない監視については、最終的に判断が必要です。

手組みしてでも実装するのか。 別製品を追加して実現するのか。 運用手順でカバーするのか。 監視対象から外すのか。

監視を外す場合は、障害検知が遅れる可能性、一次対応への影響、サービスレベルへの影響を説明し、リスク受容として顧客と合意する必要があります。

ここで重要なのは、プロジェクト側だけで勝手に決めないことです。

既存システムで実装されていた監視には、多くの場合、過去の障害、運用上の要請、監査対応、顧客側の不安、サービスレベル上の理由があります。

そのため、単に「新しい製品ではできないのでやりません」とは言いにくいことがあります。

技術的には実現できない。 実現はできるがコストが高すぎる。 手組みすれば可能だが保守性が悪い。 運用カバーで十分と判断できる。 リスクを受容して監視対象から外す。

こうした判断を、要件、コスト、運用負荷、障害時の影響、顧客の期待値を踏まえて整理します。

クラウド移行時の監視設計で重要なのは、既存監視を機械的に移植することではありません。

業務システムとして必要な異常検知、性能把握、一次対応、エスカレーションが、新システムでも成立するかを確認することです。

そのうえで、できること、できないこと、代替すること、やめることを顧客と合意する。ここまで含めて、新システムの監視設計です。

監視対象・目的で見た監視の種類

ここで重要なポイントは、「監視方式」と「監視対象・監視目的」を混同しないことです。

この中で、若手SEが特に理解しておくべきなのは、死活監視だけでは業務正常性は分からないという点です。

サーバに ping が通っていても、Web画面がエラーになっているかもしれません。 Web画面が開いても、検索処理が失敗するかもしれません。 DBプロセスが起動していても、表領域が枯渇して更新できないかもしれません。 バックアップジョブが正常終了していても、リストアできないかもしれません。

だからこそ、監視設計では「何をもって正常と判断するのか」を決める必要があります。

監視方式は「何を知りたいか」から選ぶ

監視方式を選ぶときに大事なのは、製品や流行から入らないことです。

まず決めるべきなのは、「何を知りたいのか」です。

• サーバが起動しているかを知りたいなら、死活監視です。
• Webサービスが応答しているかを知りたいなら、URL監視です。
• OS内部のCPUやメモリを知りたいなら、リソース監視です。
• DBプロセスが動いているかを知りたいなら、プロセス監視です。
• DBとしてログインできるかを知りたいなら、DB接続監視です。
• ログに異常メッセージが出ていないか知りたいなら、ログ監視です。
• ストレージやネットワーク機器の状態を知りたいなら、SNMP監視や製品API監視です。
• クラウドリソースの状態を知りたいなら、CloudWatchやOCI Monitoringなどのクラウド監視サービスです。

監視方式は、目的によって変わります。

逆に言えば、監視方式だけを決めても意味がありません。

「SNMPで監視します」では不十分です。

• SNMPで何を監視するのか。
• どのOIDを見るのか。
• どのTrapを受けるのか。
• 重大度をどう判定するのか。
• 通知先はどこか。
• 一次対応手順は何か。

ここまで決めて初めて、監視設計になります。

監視設計で決めること

監視設計では、最低限、次のような項目を決めます。

• 監視対象
• 監視項目
• 監視方式
• 監視間隔
• 閾値
• 検知条件
• 除外条件
• 重大度
• 通知先
• 通知方法
• 監視抑止条件
• メンテナンス時の扱い
• 一次対応手順
• エスカレーション先
• 復旧確認方法
• 監視設定の変更手順
• 監視条件の見直しタイミング

たとえば、CPU使用率の監視でも、単に「CPUを監視する」では足りません。

• CPU使用率が何％を超えたら警告なのか。
• 何分継続したら異常なのか。
• 瞬間的なスパイクは除外するのか。
• 夜間バッチ中は閾値を変えるのか。
• 警告と異常で通知先を分けるのか。
• 通知を受けたら、運用者は何を見るのか。
• AP担当、DB担当、基盤担当のどこへ連絡するのか。

ここまで決める必要があります。

監視は、アラートを出すことが目的ではありません。

アラートを受けた人が判断できることが目的です。

監視でよくある誤解

監視でよくある誤解は、次の3つです。

そのため、監視設計は、設計時点で決めて終わりではありません。
システムテスト、運用テスト、本番リハーサル、本番稼働後の初期期間を通じて、見直す前提が必要です。

システム基盤エンジニアが持つべき監視の見方

まず持ってほしいのは、「監視は設定項目ではなく、運用の入口である」という見方です。

監視アラートは、障害対応のスタート地点です。

アラートが出た瞬間に、運用者は判断を求められます。

• これは本当に障害なのか。
• 無視してよい通知なのか。
• すぐにエスカレーションすべきなのか。
• まず手順書に沿って確認すべきなのか。
• 復旧したと言える条件は何か。

この判断ができるように設計するのが、監視設計です。

• 監視サーバがある。
• エージェントが入っている。
• CloudWatchにメトリクスが出ている。
• OCI Monitoringにアラームがある。 MIBを読み込ませた。

それだけでは、監視設計としては不十分です。
重要なのは、検知した後に運用が動けることです。

まとめ｜クラウドでも、監視の本質は変わらない

クラウド監視サービスを使えば、メトリクス、ログ、アラームを扱いやすくなります。

しかし、CloudWatchやOCI Monitoringを使えば、監視設計そのものが不要になるわけではありません。

特にオンプレミスからクラウドへ移行する場合は、既存監視をそのまま移植するのではなく、

• 標準機能で置き換えられるもの
• 標準機能だけでは置き換えられないもの
• 代替するもの、運用でカバーするもの、監視対象から外すもの

に分けて、Fit & Gapを整理する必要があります。そのうえで、

• 何を監視するのか。
• どの条件で異常と判断するのか。
• 誰に通知するのか。
• 通知後に誰が何を確認し、どう対応するのか。

まで設計して初めて、監視は運用で使える仕組みになります。

監視で重要なのは、たくさんのアラートを出すことではありません。

本当に検知すべき異常を、運用で判断・対応できる形で検知することです。

監視は、アラートを出すための設定ではなく、障害に気づき、判断し、対応につなげるための設計です。

前編では、監視する側・監視される側という基本構造から、死活監視、エージェント監視、エージェントレス監視、SNMP監視、MIB・OIDまで、システム監視の基礎を整理しています。

【前編】システム監視の基本｜ping・エージェント・SNMP監視を整理する

pingが通ることとシステムが業務で使えることは別物。死活監視・エージェント監視・SNMP監視の基本構造と、監視設計で見落としやすい落とし穴を整理します。

sys-univ.com

2026.09.09

関連記事

監視設計は、単独で完結するものではありません。

非機能要件で求める可用性や運用性を整理し、詳細設計で監視条件へ落とし込み、テスト・運用につなげていく必要性については次の記事で説明しています。

• 【全3回・第3部】監視・ログ・バックアップ・セキュリティの詳細設計｜運用で使える設計にする観点
  監視対象、閾値、通知、ログ監視条件、運用スクリプトなど、監視を詳細設計でどう具体化するかを整理しています

【全3回・第3部】監視・ログ・バックアップ・セキュリティの詳細設計｜運用で使える設計にする観点

詳細設計を「構築・テスト・運用できる形」に落とし込む後編②。設計時点では判断しきれない監視条件の見極めなど、現場で見落としやすい監視設計の難しさを整理します。

sys-univ.com

2026.08.20

• 機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う点
  可用性、性能、運用・保守性など、監視設計の前提となる非機能要件を整理しています。

機能要件と非機能要件の違い｜「機能が動く」と「本番で使える」は違う

「機能が動く」と「本番で使える」は違う。機能要件と非機能要件の違いを、購入申請システムの具体例と現場の失敗パターンから整理します。

sys-univ.com

2026.06.19

• 要件定義とは何をする工程か｜RFP・見積前提から認識差を潰す実務
  監視を含む非機能要件を、設計に入る前の要件定義でどこまで具体化するのかを解説しています。

要件定義とは何をする工程か｜RFP・見積前提から認識差を潰す実務

要件定義とは何をする工程なのか。RFP、質問回答、提案書、見積前提から認識差を潰し、スコープや責任分界を確定する実務を、大規模SIの具体的な失敗事例とともに解説します。

sys-univ.com

2026.08.12

• システム開発の全体像｜アプリ・基盤・非機能はどうつながるのか
  要件定義、設計、構築、テスト、運用まで、監視設計がシステム開発全体のどこに位置するのかを整理しています。

システム開発の全体像｜アプリ・基盤・非機能はどうつながるのか

システム開発は、アプリケーションだけで成立するものではありません。システム基盤、性能・可用性などの非機能、テスト、移行、運用がどのようにつながって一つのシステムを成立させるのかを、現場目線で整理します。

sys-univ.com

2026.08.26

オンプレのOracleで長く運用してきたDBAが、RDS for Oracleに移行したとき、最初に戸惑うのは性能ではなく「いつもの操作ができない」ことでした。

SSHでログインしようとしても入れない。
ALTER SYSTEM を実行しようとしても通らない。
オンプレで使っていた SYSDBA 前提の操作が、そのまま使えない。

サーバーは動いている。Oracleも動いている。なのに、これまで当たり前に使っていた運用手順が通用しない。

原因は、DBの設定ミスでも権限設定の漏れでもありませんでした。

RDSがマネージドサービスとして設計された構造上、オンプレで「当たり前」だった低レイヤーへのアクセスが、そもそも提供されていないのです。

今回の記事で伝えたいのは、RDSが劣っているという話ではありません。

マネージドの恩恵とトレードオフは表裏一体です。RDSを選ぶ時点で、オンプレの運用設計をそのまま持ち込まない前提が必要になります。

ここがポイントです。

なぜRDSではオンプレと同じ運用ができないのか

RDSは、AWSがOSとDB基盤の管理を代行するサービスです。

パッチ適用、バックアップ、フェイルオーバー、レプリケーション。これらをAWS側に任せられる一方で、ユーザーはOSやDBの深いレイヤーに直接触れることができません。

オンプレのOracle運用では、DBAがOSにログインしてリソースを確認し、カーネルパラメータを見直し、SYSDBA権限でDBの内部状態を操作することがあります。しかし、RDS for Oracleではその前提が根本から変わります。

これは単なる制限ではなく、マネージドサービスとしての設計上の選択です。ただし、事前に把握していないと、開発中に次々と壁にぶつかります。

今回、開発中に見えてきたギャップを整理すると、大きく以下の領域に分かれます。

「オンプレの感覚と、RDSで必要になる考え方」

上の図は、オンプレでの感覚と、RDSで必要になる考え方の違いを整理したものです。

ここからは、開発中に実際に表面化した設計ギャップを、具体的に見ていきます。

開発中に見えた設計ギャップ

① ストレージは「空き容量」だけを見ていると詰まる

この案件では、REDOログ・ファイルのサイズを大きく設定していたこともあり、空き容量が少なくなった局面でStorage-Fullが発生しました。

Storage-Fullになると、インスタンス操作やSQL*Plusでの接続にも影響し、通常の手順では復旧しづらい状態になります。

注意したいのは、「空き容量がまだ少し残っているから大丈夫」とは限らない点です。空き容量が限界に近づいた時点で、復旧作業そのものに必要な操作ができなくなる可能性があります。

オンプレであれば、OSにログインして一時的に領域を空ける逃げ道があります。しかし、RDS for OracleではOS上で直接ファイルを操作できません。容量が詰まってから「中に入って何とかする」ことはできず、ストレージ拡張など、RDSとして提供されている操作で対応する必要があります。

そのため、REDOログやアーカイブログのサイズ、生成量、一時的な蓄積を含めてストレージ容量を設計する必要があります。REDOログのサイズを不用意に大きくすると、容量の小さい環境では問題が表面化しやすくなります。本番環境よりも開発環境で先に問題が出るパターンです。

② アーカイブログは「出した後」の挙動まで設計する

この案件では、アーカイブログが一度RDS側のストレージに出力され、その後S3へ転送される構成でした。ただし、S3へ転送されるまで、また転送後にRDS側から削除されるまでにはタイムラグがあります。アーカイブログは生成後すぐに容量影響がゼロになるわけではありません。

退避先を用意していても、転送されるまでの間、削除されるまでの間はRDS側のストレージを使います。

生成量が多いタイミングでは、特に容量の小さい開発環境で、この一時的な蓄積によって Storage-Full になるケースがありました。

アーカイブログは「出したら終わり」ではありません。RDSでは、出力、転送、削除まで含めて容量設計する必要があります。

③ ストレージは増やせるが、必要な分を即座に増やせるわけではない

ストレージを拡張する際、以下の2点に注意が必要です。

拡張サイズは現在の割り当てから10%以上でないとエラーになる
小刻みな拡張はできません。10%未満の増量を指定するとエラーで拒否されます。開発環境のように小さい容量で構築していると、この制約が意外と効いてきます。

ストレージ変更後、一定時間は再度の変更ができない
拡張後は `storage-optimization`（ストレージ最適化）ステータスになり、完了まで数時間から数十時間かかります。ストレージ最適化が完了するか、変更から6時間が経過するまでのいずれか長い方が経過するまで、次のストレージ変更はできません。

使用量が急増するケースでは、連続した拡張ができないため、「足りなくなったら少しずつ増やせばよい」という考え方が通用しない場合があります。初期サイジングを余裕を持って設計することが重要です。

④ オンプレで当たり前だった管理操作が、別の手段に置き換わる

RDS for Oracleでは、オンプレのように SYSDBA で接続してDB全体を自由に操作する前提ではありません。代わりに以下の2つが用意されています。

RDSのマスターユーザー（master_user）
DBA権限を持ちますが、システム変更に関する一部操作が制限されます。オンプレと同じSQLをそのまま実行できない場合があります。

RDSADMINユーザー
ユーザーが直接使用することはできません。ただし、AWSが用意したパッケージやプロシージャを経由することで、システム変更に関する操作が可能です。

たとえばログスイッチは、以下のように変わります。

-- オンプレ
ALTER SYSTEM SWITCH LOGFILE;

-- RDS for Oracle
EXEC rdsadmin.rdsadmin_util.switch_logfile;

対応コマンドは少しずつ増えていますが、現時点でもカバーされていない操作があります。「いつものコマンドが通らない」という場面は、移行後に発生し得る前提で考えておくべきです。移行前に、オンプレで使っているコマンド・操作の棚卸しとRDS側の代替確認が必須です。

⑤ 障害時に必要なファイルを、OS上から直接集められない

RDSではOSへのSSHログインができないため、ファイルへのアクセスは「Amazon RDSプロシージャ」経由に限定されます。

DATA_PUMP_DIR 配下のファイルなど、マネジメントコンソールからダウンロードできないファイルは、RDSプロシージャを使って一旦S3にアップロードしてからダウンロードする手順が必要です。

特に注意が必要なのがADRディレクトリです。オンプレであれば、障害時にADR配下のファイルを確認してOracleサポートへ提供することがあります。しかし、RDS for Oracleでは「サポートから言われたファイルをOS上で探してzip化する」というオンプレの感覚では動けません。

RDS for Oracleでは rdsadmin.rdsadmin_adrci_util などを通じてADR関連の情報取得やインシデントパッケージ作成の手段が用意されていますが、オンプレのようにOSログインでファイルを直接収集できるわけではありません。

OracleサポートやAWSサポートに調査資料の提供を求められた場合、何をどの手順で提供できるかは事前に確認しておく必要があります。本番障害が起きてから手順を確立しようとしても遅いです。

⑥ 監査ログや診断ファイルは、出力したまま放置すると障害要因になる

オンプレでは、監査ログやトレースファイルをOS上に出力し、必要に応じて整理・退避する運用を組めます。しかし、RDSではOS上で直接ファイル操作ができません。

この案件では、Oracleのログイン監査で監査証跡をファイルとして出力していたところ、RDS内部のファイル保持数の上限に引っかかり、ファイル書き込みエラーが発生しました。その結果、RDSにログインできなくなる障害につながりました。

RDS内部のファイル保持数には上限がありますが、その上限値はAWSから公開されておらず、ユーザーが変更することもできません。上限値が非公開である以上、「どこまで出力できるか」を事前に把握することはできません。

監査ログ、トレースファイル、ダンプファイルなどをRDS内部に出し続ける設計にする場合は、定期的なクリーンアップ処理を必ず組み込んでください。監査ログはセキュリティ要件を満たすために必要ですが、出力設計を誤ると、監査ログ自体が障害要因になります。

⑦ DBのタイムゾーン設定だけでは、Schedulerジョブの時刻は保証できない

RDS for Oracleでは、オプショングループでタイムゾーンを設定できます。しかし、それだけでOracle Schedulerジョブのタイムゾーンまで意図通りになるとは限りません。

この案件では、RDSのオプショングループでタイムゾーンを設定していても、Oracle Schedulerジョブのタイムゾーンは Etc/UTC のままでした。

日本時間でスケジュール実行したいジョブがある場合、Oracle Scheduler側にも追加でタイムゾーン設定が必要になります。設定漏れがあると、ジョブが意図した時刻に動きません。これは開発中には見落とされやすく、本番稼働後に発覚すると影響が大きい問題です。

-- Oracle Schedulerのデフォルトタイムゾーンを変更する例
BEGIN
  DBMS_SCHEDULER.SET_SCHEDULER_ATTRIBUTE(
    attribute => 'default_timezone',
    value     => 'Asia/Tokyo'
  );
END;
/

RDSのタイムゾーン設定と、Oracle Schedulerのタイムゾーン設定は、分けて確認する必要があります。

⑧ Multi-AZは、配置が変わる前提で性能と運用を設計する

Multi-AZ構成では、プライマリが常に特定AZに固定され続ける前提では設計できません。障害時やメンテナンス時のフェイルオーバーにより、プライマリの配置先AZが変わる可能性があります。

この案件では、RDSとAPサーバーが異なるAZに配置された状態が発生し、AZ間のレイテンシによる処理遅延が問題になりました。一時対応として手動フェイルオーバーで配置を寄せた場面もありましたが、本来はAPサーバーとDBのAZ配置が変わり得る前提で、レイテンシ、接続先、リトライ、監視を設計しておくべきでした。

RDSを選ぶ時点で、「常に特定AZに固定され続ける」という前提ではなく、フェイルオーバーやメンテナンスで配置が変わり得る前提に切り替える必要があります。

⑨ 停止したRDSも、7日後には自動で起動する

RDSは、停止したまま放置できるサービスではありません。

Amazon RDSのDBインスタンスは、一時停止しても7日後に自動で起動します。これは、メンテナンス適用から長期間取り残されないようにするための仕様です。

この仕様を知らないと、開発環境や検証環境で思わぬコストが発生します。

たとえば、金曜夜に高スペックのRDSを停止したつもりでも、7日後に自動起動し、そのまま週末に誰も気づかず動き続けることがあります。停止中はインスタンス時間の課金は発生しませんが、ストレージやバックアップの課金は残ります。さらに、自動起動後は通常どおりインスタンス時間の課金も再開します。

オンプレやEC2の感覚で「止めておけば安心」と考えると、RDSではコスト事故につながります。

長期間使わない環境であれば、単に停止するだけでなく、自動起動後に再停止する仕組みや、不要環境の削除、スナップショット退避なども含めて設計する必要があります。

RDSでは、起動・停止も運用設計の一部です。

代替アプローチ：RDSでの運用をどう設計するか

オンプレの「低レイヤーを直接触る」アプローチはできません。しかし、RDSには別の手段が用意されています。重要なのは、オンプレのやり方を無理に持ち込むことではなく、RDSで提供されている手段に合わせて、運用設計を組み替えることです。

CloudWatch Database Insights / Performance Insights：AWR/ASHの代替として使う

オンプレのOracleでは、AWR（Automatic Workload Repository）やASH（Active Session History）でボトルネックを分析するのが定番でした。RDSでもEEライセンスのBYOL環境であればこれらは使えますが、SE2ライセンス込みモデルでは利用できません。

この代替として使えるのが CloudWatch Database Insights / Performance Insights系の可視化機能です。どのSQLが、どの待機イベントで詰まっているかをダッシュボードで可視化でき、問題のあるSQLをその場で特定できます。

以前はPerformance InsightsでボトルネックとなるSQLを特定した後、別途で実行計画の調査を実施する必要がありました。現在はCloudWatch Database Insights上でOracleの実行計画を直接確認できるようになっており、SQLの詳細情報と実行計画を同一画面で確認できます。インデックス作成前後など同一クエリの実行計画を並べて比較することも可能です。

ただし、利用できる機能や保持期間は、Database Insightsの設定モードや契約条件によって変わります。実行計画の確認まで運用で使う場合は、事前に対象インスタンスで有効化状態と利用可能な機能を確認しておくべきです。

パラメータグループ：init.oraの代替として使う

オンプレでは init.ora や SPFILE で初期化パラメータを自由に変更できましたが、RDSでは DBパラメータグループ 経由で変更します。変更不可のパラメータが存在する点と、一部パラメータの変更にインスタンス再起動が必要な点はオンプレと異なります。変更可能なパラメータの範囲を事前に確認しておくことが重要です。

拡張モニタリング：OSメトリクスの代替として使う

SSHログインができないため top や iostat は叩けませんが、拡張モニタリング を有効にすることで、OSレベルのCPU・メモリ・I/Oの詳細メトリクスをCloudWatchで確認できます。1秒間隔まで設定できるため、瞬間的な負荷スパイクの把握も可能です。

スケールアップ：チューニングより先に試す選択肢

クラウドの最大の強みは、数クリックでインスタンスクラスを変えられることです。チューニングに数日かけるより、インスタンスタイプをひとつ上げてCPUとメモリを倍にする、あるいはプロビジョンドIOPSを追加する方が、時間とコストの観点から合理的なケースがあります。問題の切り分けとして「リソース不足なのか」「SQLや設計の問題なのか」を早く見極めるための選択肢として、スケールアップも検討に入れてください。

SQLチューニング：最も重要な主戦場

インフラ側が触れない分、アプリケーション・SQLレイヤーでの最適化がオンプレ以上に重要になります。実行計画の確認（Explain Plan）、適切なインデックス設計、バインド変数の利用、統計情報の更新。これらはRDSでも変わらず有効で、かつ最も効果が出やすい領域です。

示唆：RDS採用時に設計へ織り込むべきこと

今回挙げたギャップの中には、ドキュメントを読めば事前に分かるものもあります。たとえば、SYSDBA前提の操作がそのまま使えないことや、RDS固有の管理手段を使う必要があることは、構築前の段階で把握できます。

一方で、Storage-Full、アーカイブログの一時蓄積、監査ログ出力、Schedulerの時刻設定、停止後の自動起動のように、実際に開発・検証環境で動かして初めて影響が見えやすいものもあります。

重要なのは、「PoCで動いたか」だけを見るのではなく、RDSを採用する時点で、運用設計・監視設計・コスト管理にこれらの制約を織り込んでおくことです。

容量・ストレージ挙動
ログの一時蓄積、Storage-Fullの発生条件、ストレージ拡張の制約を設計時に確認する。開発環境のサイジングは本番より小さくなりがちなため、これらが先に表面化しやすい。

ファイル操作・監査設計
大量ファイルを出力する設計がある場合、保持数の上限（非公開）と退避方法を確認する。監査ログ、トレース、ダンプファイルは、クリーンアップ処理まで運用設計に組み込む。

権限・管理操作
オンプレで使っているコマンド・権限がRDSで使えるかを一覧化し、代替手段まで確認する。「使えないことがわかった」で終わらず、「RDSではどう実現するか」まで詰めておく。

スケジューラと時刻設定
Oracle Schedulerを使うジョブがあれば、タイムゾーン設定を移行前に確認する。本番稼働後に発覚すると影響が大きい。

停止運用とコスト管理
開発・検証環境のRDSを長期停止する場合、7日後の自動起動を前提に再停止の仕組みや削除方針を決めておく。停止中も課金される項目（ストレージ、バックアップ）があることも把握しておく。

まとめ

今回のギャップを整理すると、こうなります。

RDSはAWSがOS・DB基盤を管理するトレードオフとして、ユーザーは低レイヤーに触れることができません。SYSDBA操作、OSアクセス、物理ファイル操作、一部の初期化パラメータ。これらはオンプレでは当然使えていたものが、RDSでは使えないか、別の方法に置き換わっています。

一方、CloudWatch Database Insights / Performance Insightsによる実行計画の可視化、拡張モニタリング、パラメータグループといった代替手段は年々充実しています。「以前はできなかった」ことが、アップデートで可能になっていくサービスでもあります。

重要なのは「RDSでできないことを嘆く」ことではなく、**「RDSで何ができて、何はできないのかを移行前に把握しておく」**ことです。

「起動した」「接続できた」「SQLが流れた」だけでは、RDS for Oracleを業務で使える確認にはなりません。障害時に調査できるか、容量が逼迫したときに復旧できるか、監査ログが障害要因にならないか、停止したつもりのRDSが自動起動していないか。そこまで確認して初めて「運用できる」と言えます。

ただし、これはRDSが不便だという話ではありません。OSやDB基盤の管理をAWSに任せることで、パッチ適用、バックアップ、フェイルオーバー、監視連携といった運用負荷を下げられるのがRDSの価値です。

その価値を活かすためには、オンプレと同じ操作権限を求めるのではなく、RDSで提供される仕組みに合わせて運用を再設計する必要があります。

オンプレの運用手法をそのまま持ち込むのではなく、RDSを選ぶ時点で、運用とチューニングのアプローチを切り替える。これが、RDS for Oracleを業務で使ううえで重要な前提になります。

参考リンク

• Amazon RDS DBインスタンスのストレージ拡張

• RDS for Oracleの一般的なDBAタスク

• RDS for OracleとS3のファイル転送

• RDS for Oracleのタイムゾーン設定

• RDS DBインスタンスの一時停止と7日後の自動起動

関連記事

RDS for Oracleでは、Oracle Database自体が同じでも、オンプレミスで使っていた管理操作や調査手順をそのまま持ち込めるとは限りません。

本記事ではその違いを設計・運用全体の観点から整理しましたが、個別の制約や代替方法については、以下の記事で詳しく解説しています。

• RDS for OracleでX$BHを直接参照できない理由｜RDS_X$BHとV$BHの使い分け
  オンプレミスで使用していたSYS.X$BHをRDS for Oracleから直接参照できない理由と、RDS_X$BHやV$BHへ調査手順を置き換える考え方を整理しています。

【RDS for Oracle】オンプレの調査SQLが動かない｜X$BHを直接参照できない理由

RDS for OracleでSYS.X$BHを直接参照できない理由を解説。SYSDBA権限の制約、RDS_X$BHの作成方法、V$BHとの使い分けや運用上の注意点を整理します。

sys-univ.com

2026.07.13

• RDS for OracleでV$BHを使う方法｜バッファキャッシュ調査とX$BHの代替
  V$BHを使って、どのテーブルやインデックスのブロックがDBバッファキャッシュ上に存在しているかを確認する方法を解説しています。X$BHの完全な代替ではありませんが、調査目的を整理すれば、RDS上でも必要な情報を取得できる具体例です。

【RDS for Oracle】V$BHでバッファキャッシュの内訳を調査する｜X$BHの代替方法

RDS for OracleでV$BHを使い、オブジェクト別のバッファキャッシュ量を調査する方法を解説。DATA_OBJECT_IDを使ったSQL、X$BHとの違い、結果の見方と実行時の注意点を整理します。

sys-univ.com

2026.07.13

• RDS for OracleのDBリンクは暗号化されているのか｜KMS暗号化とOracle Net通信は別物
  RDSのストレージをKMSで暗号化していても、DBリンク通信まで自動的に暗号化されるわけではありません。ストレージ暗号化、Oracle NetのNNE／SSL/TLS、AWS基盤側の通信暗号化を分けて考える必要がある理由を整理しています。

RDS for OracleのDBリンクは暗号化されているのか｜KMS暗号化とOracle Net通信は別物

KMSで暗号化したRDS for Oracleと非暗号化RDSを別AWSアカウント間でDBリンク接続した場合の挙動を、AWSサポートへの問い合わせと公式仕様をもとに整理。KMS暗号化はDBリンク通信へ伝播せず、NNEまたはSSL/TLSを別途設計します。

sys-univ.com

2026.08.25

• クラウドリフトの失敗は構築前に始まっている｜AWS移行でPoC不足が手戻りを招く理由
  RDS固有の制約も、構築後に気づけば個別トラブルに見えますが、本質的には構築前のPoCや設計で確認すべき事項です。オンプレミスの前提をそのままクラウドへ持ち込み、後工程で手戻りが発生する構造を、AWSへのクラウドリフト全体の観点から整理しています。

【第1回】クラウドリフトの失敗は構築前に始まっている｜PoC不足が手戻り・コスト超過・納期遅延を招く理由

クラウド移行（AWSへのクラウドリフト）で起きる手戻り・コスト超過・納期遅延は、構築中ではなくPoC不足から始まります。Auto Scaling、EFS/EBS、RDS、監視、バックアップ、ライセンスなど10の設計リスクを現場目線で整理します。

sys-univ.com

2026.08.20

AWS上の通信はNitro Systemによって暗号化される。

そう聞くと、「ではVPC Encryption Controlsは何をする機能なのか」と疑問に思うかもしれません。

VPC Encryption Controlsは、新しい暗号アルゴリズムではありません。VPC内やVPC間の通信について、暗号化状態を監視し、暗号化を保証できないリソースを特定し、Enforceでは暗号化されない構成を制限するための仕組みです。

ただし、Monitorで「暗号化」と表示された通信がEnforceでも必ず許可されるわけではありません。Flow Logsのapplication-encryptedも、AWSが任意のTLS通信をパケット解析して確認した結果ではありません。

この記事では、VPC Encryption Controlsを「何ができるか」だけでなく、暗号化状態をどう読み、Enforceへ移行できる構成かをどう判断するかという観点から整理します。

VPCの通信はもともとNitroで暗号化されているのではないか

AWSでは以前から、一部のNitroベースEC2インスタンス間で、条件を満たす通信をハードウェアレイヤーで透過的に暗号化できます。

ただし、暗号化にはインスタンスタイプや通信経路などの条件があります。

「条件を満たせば暗号化される」と「暗号化されない構成を許さない」は別です。

VPC Encryption Controlsは、Nitroによるハードウェア暗号化とアプリケーションレイヤーの暗号化を組み合わせ、VPC単位で暗号化状態を監視・強制します。

さらに、Nitroのハードウェア暗号化をFargate、Application Load Balancer、Transit Gatewayなど、EC2以外のAWSサービスへ広げる役割も持っています。

AWS公式：VPC Encryption Controls

つまり、単なる監視機能ではありません。

AWS基盤側の暗号化範囲を広げながら、その状態をVPC単位で統制する仕組みです。

VPC Encryption Controlsとは｜MonitorとEnforceで何が変わるのか

VPC Encryption ControlsにはMonitorとEnforceがあります。

既存VPCは、まずMonitorを有効にします。

非準拠リソースを是正するか、必要なExclusionを設定した後でEnforceへ移行します。新規VPCは作成時からEnforceを指定できます。

Enforceは既存通信を後から暗号化するスイッチではない

Enforceを有効にしても、既存リソースの通信へ後から暗号化処理を追加するわけではありません。

例えばRDSでは、Enforce VPCへ転送中暗号化に対応しないDBインスタンスを新規作成しようとすると、APIリクエストがブロックされます。既存ワークロードは動作を継続します。

AWS公式：Working with a DB instance in a VPC

ただしPrivateLinkは注意が必要です。

Enforce VPC内のPrivateLink Endpointでは、アプリケーションレイヤーで暗号化されていないトラフィックが破棄されます。

そのため、「Enforceは新規作成だけを止める」と一律には考えられません。

VPC Flow Logsで暗号化状態を見る｜encryption-statusの3つの落とし穴

VPC Flow Logsではencryption-statusで通信の暗号化状態を確認できます。

なお、一部のネットワークアプライアンスでは暗号化状態を報告できず、encryption-statusが-になる場合があります。

-を即座に平文と判断しないことも重要です。

落とし穴1｜application-encryptedは任意のTLS検査ではない

AWSがapplication-encryptedとして扱う通信は限定されています。

これは、AWSが通信内容を復号してペイロードを検査しているという意味ではありません。Interface EndpointやGateway Endpointでは、AWSはpacket dataを確認せず、使用しているポートから暗号化状態を推定しています。

したがって、

encryption-status=2だから、任意のアプリケーション通信についてTLSを実証した

とは言えません。

逆にOracle NNEなどで暗号化していても、Flow Logs上でapplication-encryptedと判定されるとは限りません。

アプリケーション／DBレイヤーの暗号化は、そのレイヤーの方法で別途確認する必要があります。

落とし穴2｜既存Flow Logsにはencryption-statusが追加されない

Encryption Controlsを有効にしても、encryption-statusは既存Flow Logsへ自動追加されません。

さらにFlow Logは、作成後にrecord formatのフィールドを追加・削除できません。

既存環境でencryption-statusを取得するには、このフィールドを含む新しいFlow Logを作成します。

AWS公式：Flow Logsの制約

すでにSIEMや監査基盤へ連携している場合は、新ログの保存先や切替・並走も運用設計に含めます。

落とし穴3｜MonitorのencryptedとEnforceの準拠判定は同じではない

ここが最も重要です。

Monitorでencryptedでも、Enforceでは非準拠になる場合があります。

一つは、AWSサービスが作成したENIを含む通信です。

フロー自体が暗号化されていても、そのAWSサービスがEncryption Controlsをサポートしている必要があります。

もう一つはVPC Peeringです。

Peeringで転送中暗号化を保証するには、同一リージョンの両VPCがExclusionなしのEnforceである必要があります。

逆にMonitorでnot encryptedでも、関連リソースをExclusionにしていればEnforceでは許容される場合があります。

つまり、

Flow Logsのencryption-statusは「そのフローをどう観測したか」
Enforceは「その構成をポリシー上許容できるか」

を見ています。

同じ判定ではありません。

Transit GatewayはEncryption Supportを別途有効化する

Transit Gatewayを利用している場合は、Encryption Supportを明示的に有効化します。

有効化は既存通信を停止せずに行われますが、enablingからenabledになるまで最大14日かかる場合があります。

また、Connect、Peering、Network Firewall、Client VPNなど、Encryption Supportと併用できないAttachmentや機能があります。

AWS公式：Transit Gateway Encryption Support

Encryption Supportを有効化したTGWで、両側のVPCがExclusionなしのEnforceなら、VPC間通信は暗号化された経路を通ります。

一方、

Enforce VPC → Transit Gateway → Monitor VPC

という構成では、暗号化が保証されるのはMonitor側のTGW Attachmentまでです。

その先は宛先リソースに依存します。

図：Enforce VPCからMonitor VPCへTransit Gateway経由で通信する場合の暗号化保証範囲

つまり、TGWを暗号化しただけで相手VPC内部まで暗号化が保証されるわけではありません。

RDSでVPC Encryption Controlsを使うときの注意点

RDSもVPC Encryption Controlsに対応しています。

AWSサービスによって、Enforceへの対応方法は異なります。

NLB、ALB、Fargate、EKS Control Planeは、Monitorを有効にするとAWS側で暗号化対応ハードウェアへ自動移行します。

一方、RDSは必要に応じて利用者がインスタンスクラスを見直すmanual migration側です。

すでに対応クラスなら変更不要ですが、古い非対応クラスではNitro native encryptionに対応したクラスへの変更が必要です。

また、VPCがEnforceでも、Oracle NetがNNEやSSL/TLSで暗号化されていることを意味しません。

RDS for Oracleでは、

• KMSによるRDSストレージ暗号化
• Oracle TDE
• Oracle NetのNNE／SSL/TLS
• AWS基盤側の通信暗号化

は別レイヤーです。

この違いは、以下の記事で整理しています。

RDS for OracleのDBリンクは暗号化されているのか｜KMS暗号化とOracle Net通信は別物

KMSで暗号化したRDS for Oracleと非暗号化RDSを別AWSアカウント間でDBリンク接続した場合の挙動を、AWSサポートへの問い合わせと公式仕様をもとに整理。KMS暗号化はDBリンク通信へ伝播せず、NNEまたはSSL/TLSを別途設計します。

sys-univ.com

2026.08.25

導入するならMonitorから始める｜Exclusion・Enforce移行・料金

既存VPCでは、次の順序で進めると整理しやすくなります。

1. Monitorを有効にする
2. encryption-statusを含むFlow Logsを作る
3. Enforceを阻害するリソースを確認する
4. 対応構成へ移行する
5. 必要なExclusionを判断する
6. PeeringやTGWも確認する
7. Enforceへ移行する

EnforceできるかはExclusionと非対応リソースで決まる

Exclusionを設定できるのは8種類だけです。

• Internet Gateway
• NAT Gateway
• Egress-only Internet Gateway
• 非Enforce VPCへのVPC Peering
• Virtual Private Gateway
• VPC内Lambda
• VPC Lattice
• EFS

Exclusionは、「AWSが暗号化済みと保証する」設定ではありません。

利用者がエンドツーエンド暗号化を維持する責任を負う、監査可能な例外です。

Exclusionを設定した通信はVPC Encryption Controlsによる暗号化保証の対象外となるため、AWSの責任共有モデルで見ても、利用者側で暗号化方式と証跡を明示的に管理する必要があります。

一方、Gateway Load BalancerとAWS Network FirewallはEnforce非対応で、これらがあるVPCはMonitorで運用する必要があります。

Local Zone subnetもEnforceでは利用できません。

したがってMonitorの目的は、平文通信を探すだけではありません。

「このVPCをそもそもEnforceへ移行できるのか」

を判断することです。

複数VPC・複数アカウントでは集中管理もできる

Account LevelではUnmanaged、Attempt Monitor、Attempt Enforceを設定でき、複数VPCへまとめて適用できます。

ただしAttempt Enforceは全VPCの移行成功を保証しません。

1つ以上のVPCが期待したモードへ移れなかった状態として、transitions-partially-successfulも定義されています。

AWS公式：AccountVpcEncryptionControl

AWS OrganizationsのDeclarative Policyを使えば、組織・OU・アカウント単位で集中適用することもできます。

Monitorでも料金は発生する

VPC Encryption Controlsは2026年3月1日から有料です。

Network Interfaceを持つnon-empty VPCでMonitorまたはEnforceを有効にすると、固定時間料金が発生します。

TGWでEncryption Supportを有効にした場合は、接続VPCのEncryption Controlsモードに関係なく料金対象になる場合があります。

具体的な単価はリージョンごとの最新料金を確認します。

AWS公式：VPC Encryption Controls pricing

Monitorのまま長期間放置する場合も、コスト設計上は無視できません。

まとめ｜「暗号化されることを期待する」から「暗号化されない構成を許さない」へ

VPC Encryption Controlsで押さえる点は3つです。

• Nitroの自動暗号化とEncryption Controlsによる統制は同じものではない
• Flow Logsのencryption-statusとEnforceの準拠判定は同じではない
• EnforceしてもTLSやOracle NNEなどアプリケーション／DBレイヤーの暗号化設計は別途必要

VPC Encryption Controlsによって、AWSの通信暗号化設計は、

「条件を満たせば暗号化されることを期待する」

から、

「暗号化を保証できない構成を許さない」

へ一段進みました。

導入時はまずMonitorで現在の構成と通信を可視化し、何をAWS基盤側で保証し、何をアプリケーション側で保証するのかを整理したうえでEnforceへ進むのがよいでしょう。

関連記事

VPC Encryption Controlsでは、AWS基盤側の通信暗号化をMonitor／Enforceで監視・強制できますが、実際の通信ではサービスごとの転送時暗号化もあわせて理解しておく必要があります。

特にEFSはVPC Encryption ControlsでExclusionを設定できるリソースの一つであり、ECS／FargateからEFSへ接続する場合は、NFS通信の転送時暗号化がどのように実現されるかを分けて考える必要があります。あわせて確認したい方は、以下の記事も参考にしてください。

• ECS/FargateでEFSが127.0.0.1にマウントされる｜NFSの接続先がlocalhostになる理由
  ECS／FargateでEFSの転送時暗号化を有効にすると、NFSの接続先が127.0.0.1として見える理由を、TLSトンネルとEFSマウント処理の仕組みから整理しています。

ECS/FargateでEFSが127.0.0.1にマウントされる｜NFSの接続先がlocalhostになる理由

ECS/FargateからEFSをマウントするとマウント元が127.0.0.1と表示される理由を、転送時暗号化で使われるefs-proxyの通信経路、タスク定義のtransitEncryptionとIAM認可の関係、mount.logで確認できた内容、障害調査時の切り分け観点から解説します。

sys-univ.com

2026.08.14

本シリーズでは、クラウドリフトのトラブルを個別の設定ミスとしてではなく、構築前に残った設計リスクという観点から整理します。

• 【第1回】この記事
  クラウドリフトの失敗は構築前に始まっている｜PoC不足が手戻りを招く理由

• 【第2回】クラウドリフトPoCの設計リスク｜可用性・性能・ストレージ・バックアップ・監視

• 【第3回】クラウドリフトPoCの設計リスク｜ジョブ・セキュリティ・ライセンス・DB互換性・コスト

はじめに

「AWSに移行したのに、なぜか現場が疲弊している」

「構築フェーズに入ってから想定外の問題が続き、スケジュールが削られていく」

クラウドリフトでは、こうしたことが実際に起こります。

クラウドリフトは、既存システムを大きく変更せずクラウドへ移行する方式ですが、オンプレミスで成立していた設計前提が、AWSでもそのまま成立するとは限りません。

• 性能が出ない。
• 別AZでEC2を起動したのに、OS内部のルート情報が原因で通信できない。
• Auto ScalingでEC2は再作成されたのに、監視やジョブ実行の対象として認識されない。
• RDSへ移行してから、オンプレミスOracleと同じ運用ができないことに気づく。
• 現場では、それぞれ「設定ミス」「確認不足」「製品仕様の見落とし」として見えます。

プロジェクト全体で振り返ると、共通点があります。

クラウドリフトの失敗は、構築前に始まっている。

問題が表面化するのは構築や試験の段階でも、その原因はもっと前に作られていることがあります。

• PoCで確認すべきことを残したまま基本設計へ進む。
• AWS上で成立するか確認していない処理方式を、オンプレミスの前提で決める。
• AWSサービスの仕様、制約、運用モデル、課金条件を十分に確認しないまま構築へ進む。

こうして残った設計リスクが、後工程で一つずつトラブルとして表面化します。

この記事では、クラウドリフトで発生する個別トラブルを、PoC不足によって未解消のまま残った設計リスクという観点から整理します。

この記事で分かること

ポイントは次の3つです。

• クラウドリフトのトラブルは、構築中に突然始まるわけではない

• 多くの場合、構築前に確認すべき設計リスクが残っている

• PoCは「動くか」だけを確認するのではなく、後工程の手戻りを防ぐための設計判断材料である

なぜクラウドリフトの失敗が「構築前」に始まっているのか。まず、実際のトラブルがどのように見えるのかから整理します。

クラウドリフトのトラブルは「個別事象」に見える

クラウドリフトでは、さまざまなトラブルが発生します。

たとえば、これまでの記事でも以下のようなテーマを扱ってきました。

• アクセス・起動：AMIから起動したEC2でSSHログインできない
• AZ障害・復旧：別AZで起動したWindowsが、OS内のルート情報により通信できない
• 可用性：Auto ScalingでEC2は再作成されたが、業務復旧まで到達しない
• 運用・ログ：CloudWatch LogsのS3エクスポートが想定通り動かない
• バックアップ：AWS Backupの「5日保存」を「5営業日保存」と誤解する
• ストレージ：EBSは容量拡張は比較的容易だが、縮小には再作成とデータ移行が必要になる。EFS/EBSの使い分けで性能・復旧方式が変わる
• データベース：RDS for Oracleの制約により、オンプレOracleと同じ運用ができない
• 運用・共通：ジョブ管理や監視方式をクラウド移行後に見直す必要が出る
• ライセンス：Microsoft製品や商用製品は、技術的に動いても、AWS上での利用がライセンスやサポート条件上認められない場合がある
• クラウド責任分界：クラウドがストレージ障害を吸収しても、IaaS/SaaS境界の外側にあるOS領域は利用者側の責任。ログ肥大化によるOS領域枯渇が盲点になる

こうしたトラブルを一つひとつ見ると、個別の設定ミスや確認不足に見えます。

• SSHの設定ミス。
• OS内部のルート情報の見落とし。
• cloud-init の理解不足。
• バックアップ保持期間の確認不足。
• ストレージ方式の選定ミス。
• 監視設計の漏れ。
• ライセンス確認の遅れ。

もちろん、それぞれの直接原因はあります。

しかし、クラウドリフト案件として見た場合、これらを単なる個別ミスとして片付けてはいけません。

なぜなら、こうした問題の多くは、構築中に突然発生したのではなく、もっと前の段階で確認すべきことを確認しないまま進んだ結果だからです。

問題の本質はここにあります。

クラウドリフトで発生する個別トラブルの多くは、PoC不足による設計リスクの未解消として説明できる。

個別トラブルに見えるものの正体

クラウドリフトの怖さは、トラブルが発生した瞬間ではありません。

本当に怖いのは、その時点ではすでに設計、構築、試験、運用設計、見積、スケジュールが進んでおり、手戻りが大きくなっていることです。

たとえば、構築フェーズで以下のような問題が分かったとします。

• この運用はAWSではそのままできない
• このミドルウェアはAmazon Linuxでは動かない
• RDS for Oracleでは、オンプレOracleと同じチューニングができない
• EFSの性能では、業務処理のレイテンシ要件を満たせない
• 既存のジョブ管理製品をそのまま使うと、クラウド環境での運用に合わない
• サーバー上のExcel帳票生成が、ライセンスやサポート上の理由でそのまま使えない

この時点で設計を変えようとすると、影響はかなり大きくなります。

• 設計書を直すだけでは済みません。
• 構築手順も変わります。
• パラメータシートも変わります。
• 試験項目も変わります。
• 運用手順も変わります。
• 顧客説明も必要になります。
• 場合によっては、見積とスケジュールも変わります。

これがクラウドリフトの手戻りです。

単なる技術トラブルではありません。
プロジェクト全体のQCDを崩す問題になります。

クラウドリフトで崩れるのは技術ではなくQCD

クラウドリフトで発生する問題は、最初は技術課題として見えます。

• ログインできない。
• 通信できない。
• 性能が出ない。
• バックアップが想定通りに戻せない。
• 監視がうまく飛ばない。
• ライセンスが使えない。

しかし、プロジェクトとして見ると、それは技術課題だけでは終わりません。

実際には、次のような形でQCD全体に波及します。

• コスト超過
• スケジュール遅延
• 品質劣化
• 設計手戻り
• 試験やり直し
• 運用設計の再検討
• 顧客説明の増加
• プロジェクトメンバーの疲弊

特に危険なのは、性能、ストレージ、DB、運用方式に関する問題です。

これらは、設定値を少し変えれば解決するとは限りません。

たとえば、PoC不足により、EFSの性能が本番相当負荷で足りないと後から分かったとします。

その場合、単にスループット設定を上げれば済むかもしれません。
しかし、それでも性能目標に届かない場合は、ファイル配置や処理方式そのものを見直す必要が出ます。

• EFSを使う前提だったものを、EC2＋EBS構成に変える。
• 共有ファイルの扱いを変える。
• アプリケーションの処理方式を変える。
• バックアップ方式を変える。
• 監視項目を変える。
• 障害時の復旧手順を変える。
• 性能試験シナリオを作り直す。

ここまで来ると、もはや一部設定の見直しではありません。

基本設計からの手戻りです。

さらにPM/PLの視点で見ると、影響は技術チームの中だけでは収まりません。

• 基本設計を直す。
• 詳細設計を直す。
• 構築手順を直す。
• 試験計画を見直す。
• 性能試験の前提を変える。
• 運用手順を作り直す。
• 顧客へ変更理由を説明する。
• 追加費用とスケジュール延伸を調整する。

この連鎖が発生します。

つまり、クラウドリフトの設計漏れは、技術課題として始まり、最後はQCD課題になります。

これを構築後や試験中に初めて認識するのは、かなり危険です。

AWSではオンプレの設計思想がそのまま通用しない

クラウドリフトは、オンプレのサーバをAWS上のEC2に置き換えるだけの作業ではありません。

ここを誤解すると、設計漏れが増えます。

オンプレ環境では、比較的自由に設計できたものが多くあります。

• OS設定。
• ミドルウェア設定。
• ストレージ構成。
• ネットワーク構成。
• 監視方式。
• ジョブ管理。
• バックアップ方式。
• セキュリティ設定。
• HA構成。
• 運用スクリプト。
• 商用製品の導入。
• ライセンス運用。

もちろん、オンプレにも制約はあります。

しかし、オンプレではサーバ、ストレージ、ネットワーク機器、ミドルウェア、運用製品を組み合わせて、プロジェクト側でかなり細かく作り込めました。

一方、AWSでは違います。

• AWSサービスの仕様があります。
• マネージドサービスの制約があります。
• 課金体系があります。
• メンテナンスの考え方があります。
• 責任共有モデルがあります。
• IAM、Security Group、CloudWatch、RDS、EFS、EBS、S3など、AWS側の設計思想があります。

つまり、プラットフォームがAWSに変わる以上、『非機能要件の実現手段』は必ず変わります。

正確には、こうです。

オンプレで暗黙的に成立していた設計を、AWSのサービス仕様、制約、課金体系、運用モデルの上で再検証する必要がある。

ここをPoCで確認せずに進めると、後から詰まります。

たとえば、オンプレではサーバが固定されている前提で、監視やジョブ管理を設計していたかもしれません。

しかし、AWSではAuto Scalingや復旧方式によって、EC2が入れ替わる前提になる場合があります。

この時、EC2が起動すれば終わりではありません。

• ホスト名はどうするのか。
• DNS登録はどうするのか。
• 監視対象への登録はどうするのか。
• ジョブ実行対象としてどう認識させるのか。
• ログ出力先はどうするのか。
• 障害時の運用手順はどう変わるのか。

ここまで確認して初めて、業務復旧と言えます。

EC2が起動しただけでは、業務復旧ではありません。

また、クラウドリフトはクラウドネイティブ化とも違います。

クラウドリフトの目的は、多くの場合、既存システムを大きく作り替えることではありません。
オンプレで動いているシステムを、できるだけ低リスク、低コスト、短期間でクラウド上に移すことです。

そのため、既存の設計思想や運用方式をある程度踏襲することになります。

しかし、ここに難しさがあります。

• 既存設計を踏襲したい。
• でも、AWSではそのまま実現できないことがある。
• マネージドサービスを使えば楽になる部分もある。
• しかし、既存運用と合わない部分もある。
• クラウドネイティブに寄せすぎると、アプリ改修や運用変更が増える。
• オンプレ方式を無理に残すと、クラウドの良さを活かせず、コストも運用も重くなる。

このバランスを見極める必要があります。

だからPoCが重要になります。

それでもクラウドリフトは避けにくい

クラウドリフトは難しい。
しかし、避け続けることも難しいのが現実です。

政府系・公共系では、クラウド・バイ・デフォルトの流れがあります。
民間企業でも、データセンター更改、ハードウェアEOL、OS・ミドルウェア保守切れ、オンプレ運用人材の不足、災害対策、拡張性確保、初期投資抑制といった理由から、クラウド利用を検討する場面が増えています。

だからこそ、効率よく、リスクを抑えて進める必要があります。

そのために必要なのは、大きく3つです。

• 1つ目は、実案件の事例を収集する
  AWS公式ドキュメントを読むことは大切ですが、それだけでは、既存運用との衝突、ライセンス制約、性能特性、バックアップの戻し方といった落とし穴は見えにくいです。実際に起きたトラブルの事例から学ぶことが重要です。

• 2つ目は、質の高いPoCを実施する
  「EC2上でアプリが起動した」で終わるPoCでは、設計リスクは潰せません。本番相当の負荷、障害時の復旧、監視、ジョブ、バックアップまで含めて検証シナリオに落とし込んで初めて、基本設計の判断材料になります。

• 3つ目は、リフト経験者を含めたチームを作る
  インフラエンジニアだけでは業務影響を判断しきれず、業務SEだけではAWSの制約やストレージ、ネットワークの設計リスクを判断しきれません。クラウド有識者、既存システム有識者、業務・アプリ担当、インフラ基盤・処理方式担当を巻き込み、PoCで分かったことを設計、試験、運用、見積へ反映する体制が必要です。

PoCは「試しに動かすこと」ではない

ここまでの話を踏まえると、PoCの意味が少し変わって見えるはずです。

PoCと聞くと、「試しに作ってみる」「動くか確認する」というイメージを持つかもしれません。

もちろん、それも間違いではありません。

しかし、クラウドリフトにおけるPoCをそれだけで捉えると危険です。

PoCで確認するのは、AWSサービスが使えるかどうかだけではありません。

既存業務の処理方式、運用方式、復旧方式、名前解決、バックアップ、監視、ジョブ、ファイル更新方式、DB運用、ライセンス、コストが、クラウド上の構成で成立するか。

そこまで確認して初めて、PoCの結果を基本設計の判断材料にできます。

たとえば、次のような確認だけでは不十分です。

• EC2でアプリケーションが起動した。
• EFSでファイルを読み書きできた。
• RDSに接続できた。
• CloudWatch Logsにログが出た。
• AWS Backupのジョブが成功した。

これらは大事な確認です。
ただし、それだけでは「業務で使える」とは言えません。

オンプレ時代の検証では、プロトタイプアプリケーションを作り、主要な処理を流して、基盤上でアプリケーションが動くことを確認する、という進め方もありました。

もちろん、それ自体が無意味だったわけではありません。
サーバ、OS、ミドルウェア、ネットワーク、ストレージの基本的な組み合わせを確認するうえでは、有効な検証です。

しかし、クラウドリフトでは、それだけでは足りません。

AWS上でアプリケーションが起動することと、クラウド上の構成で業務が安定して回ることは違います。

EC2が起動しても、ホスト名、DNS登録、監視、ジョブ実行対象、ログ収集先、ミドルウェア起動まで回らなければ、業務復旧とは言えません。

EFSでファイルを読み書きできても、本番相当のファイル数、ディレクトリ構造、排他制御、ファイル差し替え、バックアップ、リストアまで成立しなければ、業務で使えるとは言えません。

CloudWatch Logsにログが出ても、運用で必要なタイミングに確認できるのか、通知すべきアラームと通知抑止すべきメッセージを整理できるのか、試験工程へ監視観点を引き継げるのかを見なければ、運用設計にはつながりません。

バックアップジョブが成功しても、必要なデータを、必要な時間内に、整合性を保って戻せるとは限りません。

つまり、PoCで見るべきなのは、「AWS上でとりあえず動くか」だけではありません。

• 既存の機能要件・非機能要件・運用要件を、AWS上でどの方式なら現実的に満たせるのか。
• 既存設計を踏襲するのか。
• マネージドサービスに置き換えるのか。
• 商用製品を継続するのか。
• 代替製品に変えるのか。
• クラウドネイティブなサービスに寄せるのか。

この判断をするためにPoCがあります。

では、具体的に何を判断するのでしょうか。

• その構成で基本設計に進んでよいのか。
• その運用方式で本番後も回せるのか。
• そのサービス仕様で既存要件を満たせるのか。
• そのコストでプロジェクト計画に収まるのか。

こうした設計判断に使えるPoCでなければ、後工程の手戻りを防ぐことはできません。

クラウドリフトのPoCは、単なる動作確認ではありません。

基本設計に入る前に、クラウド上で成立する処理方式、構成方式、運用方式、復旧方式、コスト感を見極めるための設計リスク潰しです。

ここが最も重要です。

たとえば、以下のような確認は、単なる動作確認ではありません。

• RDS for Oracleで、既存DBの可用性・性能要件を満たせるか
• EFSで、共有ファイルの性能要件を満たせるか
• AWS Backupで、必要な世代管理とリストア要件を満たせるか
• CloudWatch中心の監視で、既存運用を置き換えられるか
• JP1を継続するのか、ZabbixやHinemosなどに置き換えるのか
• 既存のセキュリティポリシーをAWS上のIAMやSecurity Groupへどう落とすのか
• BYOLかMarketplaceかで、ライセンス費用やサポート条件はどう変わるのか
• RHELを継続するのか、Amazon Linuxへ寄せるのか
• その場合、既存ライブラリや運用スクリプトは動くのか
• 開発環境や試験環境の利用時間増加が、クラウド利用料にどれだけ影響するのか

これらはすべて、後工程で発覚すると危険な設計リスクです。

PoCで潰すべきなのは、こういう論点です。

なぜPoCで気づけなかったのか

クラウドリフトで怖いのは、AWSの機能を知らないことだけではありません。

もっと怖いのは、クラウドリフト固有のリスクを洗い出す機会が、プロジェクト計画の中に十分に組み込まれていないことです。

しかし、実際のプロジェクトではこれが簡単ではありません。

既存システムを、AWSの仕様、制約、課金体系、運用モデルの上に再配置する。

それがクラウドリフトです。

だから、PoCが必要になります。

ただし、PoCだけですべての設計リスクを見つけられるとは限りません。

事前にシナリオを立てても、実際には想定外の問題が出ます。

重要なのは、そこで出た問題を個別対応で終わらせないことです。

• なぜ見落としたのか。
• どの設計リスクに分類されるのか。
• 次の工程へ何を引き継ぐべきか。

ここまで整理して初めて、PoCは後工程の手戻りを防ぐ材料になります。

まとめ：失敗はPoC不足から始まる

オンプレミスで暗黙的に成立していた設計前提が、AWSでも同じように成立するとは限りません。

その違いを構築後に見つけると、修正は一つの設定変更では終わりません。設計の見直し、追加試験、運用手順の変更、スケジュール調整、追加費用まで波及します。

PoCは「AWS上で動くか」だけを試す作業ではありません。後工程で大きな手戻りになる設計リスクを、構築前に洗い出すための検証です。

クラウドリフトのPoCで確認しておきたい観点は、次の10項目です。

1. 可用性・信頼性
2. 性能・キャパシティ
3. ストレージ
4. バックアップ
5. 運用・監視
6. ジョブ管理・アプリ配布
7. セキュリティ・アクセス管理
8. ライセンス・製品サポート
9. DB・OS・ミドルウェア互換性
10. コスト・キャパシティ管理

この10項目は、チェックリストとして埋めれば終わりではありません。

見るべきなのは「動いたか」ではなく、想定と違った場合に設計・試験・運用・見積へどこまで影響するかです。構築前に未確認のまま残した項目と、オンプレミスの前提をそのまま持ち込んだ設計が、後工程で最も高くつきます。

10項目の詳細は、前編・後編で整理しています。

• 【第2回】クラウドリフトPoCの設計リスク｜可用性・性能・ストレージ・バックアップ・監視
  可用性、性能、ストレージ、バックアップ、監視について、クラウドリフトPoCで何を確認し、設計へどう反映するかを整理しています。

【第2回】クラウドリフトPoCの設計リスク｜可用性・性能・ストレージ・バックアップ・監視

クラウドリフトPoCで「動いた」だけでは、構築・試験・運用まで成立するとは限りません。可用性・性能・ストレージ・バックアップ・監視の5領域について、PoCで確認すべき設計リスクと、見落とした場合の後工程への影響を実務例から整理します。

sys-univ.com

2026.08.25

• 【第3回】クラウドリフトPoCの設計リスク｜ジョブ・セキュリティ・ライセンス・DB互換性・コスト
  ジョブ、セキュリティ、ライセンス、DB・OS・ミドルウェア互換性、コストについて、後工程の手戻りにつながる設計リスクを整理しています。

【第3回】クラウドリフトPoCの設計リスク｜ジョブ・セキュリティ・ライセンス・DB互換性・コスト

クラウドリフトPoCで「動いた」だけでは、運用・保守・統制・コスト管理まで成立するとは限りません。ジョブ、セキュリティ、ライセンス、DB・OS・ミドルウェア互換性、コストの5領域について、PoCで確認すべき設計リスクと後工程への影響を実務例から整理します。

sys-univ.com

2026.08.20

関連記事

クラウドリフトでは、「暗号化」という要件も一つの設定として扱うのではなく、保存データと通信を分けて確認する必要があります。

•  RDS for OracleのDBリンクは暗号化されているのか｜KMS暗号化とOracle Net通信は別物
  KMSによるRDSストレージ暗号化と、Database LinkのOracle Net通信暗号化の違いを、実案件とAWS・Oracleの公式仕様をもとに整理しています。

RDS for OracleのDBリンクは暗号化されているのか｜KMS暗号化とOracle Net通信は別物

KMSで暗号化したRDS for Oracleと非暗号化RDSを別AWSアカウント間でDBリンク接続した場合の挙動を、AWSサポートへの問い合わせと公式仕様をもとに整理。KMS暗号化はDBリンク通信へ伝播せず、NNEまたはSSL/TLSを別途設計します。

sys-univ.com

2026.08.25