「PoCでは問題なかったのに、構築に入ったら次々と課題が出てきた」

「接続確認はできていたのに、業務処理を流すと性能が出ない」

「バックアップは成功していたのに、戻す手順や時間を詰めていなかった」

「共有ストレージとして使えると思ったのに、既存アプリのファイル更新方式と合わなかった」

クラウドリフトでは、こうしたことが実際に起こります。

PoCでEC2上のアプリは起動した。EFS上のファイルは読み書きできた。FSx経由のファイル共有も確認した。RDS上で主要なアプリ機能も動いた。CloudWatch Logsにもログは出力された。バックアップジョブも正常終了した。

しかし、それだけでは、クラウドリフトPoCとしては足りません。

「動いた」という確認は、業務が回るという確認とは別だからです。

クラウドリフトで本当に怖いのは、PoCで「動いた」と判断したあとに、設計・構築・試験・運用の段階で後から手戻りになることです。

性能が出ない。名前解決が想定どおりに動かない。Auto Scaling後に監視やジョブ実行対象として認識されない。EFS上のファイル更新方式が既存アプリと合わない。CloudWatch LogsのS3エクスポートが運用時間内に終わらない。バックアップの保持期間が業務要件とずれる。ライセンスやデータ転送量のコストが見積から漏れている。

こうした問題は、現場では個別の設定ミスや確認不足に見えます。

しかし、多くのプロジェクトで、PoCや設計段階で潰すべきリスクが残ったまま後工程へ進み、結果として大きな手戻りや追加対応につながる場面を見てきました。

この記事は、クラウドリフトPoCを扱う全3部作の第2部前編です。

第1部では、クラウドリフトの失敗が構築後ではなく、構築前のPoC不足から始まることを整理しました。

【第1部】クラウドリフトの失敗は構築前に始まっている｜PoC不足が手戻り・コスト超過・納期遅延を招く理由

第2部では、その続きとして、クラウドリフトPoCで見落とすと手戻りになりやすい10の設計リスクを整理します。

第2部は、前編と後編に分けています。

前編で扱うのは、クラウド基盤として業務を受け止めるために必要な、次の5項目です。

１.可用性・信頼性
２.性能・キャパシティ
３.ストレージ
４.バックアップ
５.運用・監視

後編では、構築後に運用・保守・統制・コスト管理で詰まりやすい、次の5項目を扱います。

６.ジョブ管理・アプリ配布
７.セキュリティ・アクセス管理
８.ライセンス・製品サポート
９.DB・OS・ミドルウェア互換性
１０.コスト・キャパシティ管理

つまり第2部では、「PoCで動いたか」ではなく、「その方式で設計・試験・運用・見積まで成立するか」を、10の観点から確認していきます。

この記事で整理する設計リスクは、机上で作ったチェックリストではありません。

大規模なクラウドリフト案件で、PoCを実施し、有識者も交えてリスクを潰しにいった中で見えてきた論点をもとにしています。

RDS for OracleのDBA権限制約、EFS上での複数ノードによるファイル更新の競合、FSxのKerberos/SPN認証、名前解決経路とTTLの切替挙動、マネージドサービスのパッチ適用と自社セキュリティルールの整合などは、PoCで事前に確認しておくべき代表的な論点です。

一方で、事前に検証していても、後工程で表面化した問題もありました。

別AZ起動後のOS内ルート情報による通信不能、CloudWatch LogsのS3エクスポート制約、EBSの容量縮小、S3クロスアカウントのオブジェクト所有者問題、RHELとAmazon LinuxのOS設定差分、cloud-initによるSSH設定上書き、Auto Scalingの意図しないEC2再作成などです。

「PoCで潰せたこと」と「PoCで潰しきれなかったこと」。

その両方を踏まえて、現時点でクラウドリフトPoCに必要なチェック観点を整理したのが、この第2部です。

PoCは、AWSサービスが使えるかを確認する作業ではありません。

既存業務の処理方式、運用方式、復旧方式、名前解決、バックアップ、監視、ジョブ、ファイル更新方式、DB運用、ライセンス、コストが、クラウド上の構成で成立するかを確認する作業です。

以下の図は、クラウドリフトPoCで見るべき10の設計リスクを整理したものです。

それぞれ、単なるチェックリストではありません。

見落とすと、設計、試験、運用、見積、スケジュールにどう跳ね返るのかまで含めて整理します。

PoC観点を強化するきっかけになった個別事例

以下は、クラウドリフトPoCの観点を見直すきっかけになった個別事例です。

本記事では、これらの個別事例に加え、PoCで事前に潰せた設計論点も含めて、クラウドリフトPoCで見るべきリスクを整理しています。

• 【AWS】別AZで起動したWindowsが通信不能に｜原因はVPCではなく「OS内のルート情報」だった
• CloudWatch Logsのログエクスポートが失敗した話｜「ジョブは動く」と「運用で回る」は別物
• バックアップ設定の「5日保存」は、5営業日分とは限らない｜AWS Backupの保持期間から考える、詳細設計の落とし穴
• EBSは増やせても、簡単には減らせない｜RHEL環境で見落とした「容量縮小＝ディスク移行」という現実
• S3バケットにあるのに取得できない｜クロスアカウント構成で見落とした「オブジェクト所有者」の罠
• RHELで使えた設定方法が、Amazon Linuxでは使えなかった｜MTU設定に見る、OS差分と永続化確認の落とし穴
• EBSは見えているのにマウントできない？｜AMIコピーで起きた落とし穴
• AMIからRHELインスタンスを起動したらSSHログインできなくなった｜cloud-initが上書きする設定を知らないと、復旧以前に入れなくなる
• EC2を止めただけなのに再作成？Auto Scaling運用の落とし穴｜クラウドの自動化は、作業者の意図までは読んでくれない

なお、後編では購入者特典として、10項目全体を整理したExcel資料「クラウドリフトPoC設計リスクチェックリスト」も添付します。

PoC計画、設計レビュー、リスク洗い出しのたたき台として使えるようにしています。

1. 可用性・信頼性

EC2が起動しただけでは、業務復旧とは言えない

クラウドリフトでは、可用性設計が軽く見られることがあります。

EC2は再作成できる。
RDSはMulti-AZにできる。
Auto Scalingを使えば復旧できる。
ロードバランサー配下に置けば切り替えられる。

マネージドサービスがすべてやってくれるように見えるからです。

しかし、業務システムの復旧は、EC2が起動することではありません。

業務処理が再開できることです。

Auto Scalingを使う場合でも、EC2が新しく作られれば終わりではありません。

実際の復旧方式では、障害ノードをロードバランサー配下から切り離し、AMIから新規EC2を作成し、cloud-initやUser Dataを使って初期設定を反映し、ホスト名を付与し、DNSに登録し、監視エージェントやミドルウェアを起動する、といった一連の処理が必要になります。

ここで重要なのは、単にスクリプトを書けるかどうかではありません。

実行タイミングです。

ホスト名の付与が監視エージェントやミドルウェアの起動より後になると、誤ったホスト名でサービスが起動し、監視登録やジョブ実行対象の認識がずれることがあります。

そのため、cloud-initのどの段階で設定を反映するのか、User Dataで実行するのか、設定ファイル側で制御するのか、サービス起動順序をどうするのかまで確認しなければなりません。

さらに、ロードバランサーのヘルスチェックに戻す条件、監視対象への再登録、ジョブ実行対象としての認識、ログ収集先の切替、障害解析のために旧EC2を残すかどうかも決める必要があります。

Auto Scalingは復旧方式の一部であって、復旧方式そのものではありません。

AWS側が支援してくれるのは、インスタンスの再作成、ロードバランサーのヘルスチェック、マネージドサービスの切替といった基盤機能の部分です。

一方で、作り直されたEC2を業務システムとして使える状態に戻す設計は、利用者側の責任です。

ホスト名、DNS登録、監視エージェント、ミドルウェア起動順序、ジョブ実行対象への再登録、ログ収集先の切替、復旧後の業務確認は、クラウドが自動で判断してくれるわけではありません。

PoCでは、EC2が作られるかではなく、作られたEC2が業務システムの構成要素として正しく組み込まれるかを確認する必要があります。

この復旧の流れは、文章だけでは見落とされやすいため、図に整理すると次のようになります。

保守停止と障害検知は分けて考える

Auto Scalingでは、EC2が意図せず停止した場合に、期待する台数を維持するため、新しいEC2が作られることがあります。

これは可用性の観点では便利です。

しかし、運用の観点では注意が必要です。

保守作業としてEC2を停止したいだけでも、停止方法や事前の切り離し手順が適切でなければ、Auto Scaling側では障害や不足状態として扱われることがあります。

作業者は「保守のために止めた」と思っている。
しかし、Auto Scalingは期待台数を維持する仕組みとして、元の台数へ戻そうとします。

その結果、意図しないEC2が作られ、監視、ジョブ、ログ、ライセンス、コストの前提が崩れることがあります。

このようなことが起こります。

つまり、Auto Scalingを使うなら、障害時にどう復旧するかだけでなく、保守時にどう止めるかも設計しなければなりません。

保守作業時には、Auto Scalingグループの期待台数を変更するのか。
インスタンス保護を使うのか。
スケーリングを一時停止するのか。
ロードバランサーから切り離して作業するのか。
作業後にどう戻すのか。

この運用手順を決めずにAuto Scalingを使うと、「自動復旧」が「作業者の意図しない再作成」になります。

クラウドの自動化は、作業者の意図までは読んでくれません。

PoCでは、障害時の自動復旧だけでなく、保守停止、再起動、切り離し、再登録、戻し忘れの検知まで確認する必要があります。

別AZで起動できても、通信できるとは限らない

別AZでEC2を起動できたとしても、通信できるとは限りません。

VPC、サブネット、ルートテーブル、Security Groupが正しく見えていても、OS内に残っている静的ルート、永続ルート、NIC設定、メトリック設定が移行後のネットワーク構成と合わないことがあります。

その場合、AWS側のネットワーク設定だけを見ても原因にたどり着けません。

クラウド移行では、ネットワークの問題を見るときに、どうしてもVPC側へ目が向きます。

ルートテーブルは正しいか。
Security Groupは開いているか。
NACLで落ちていないか。
サブネットの関連付けは正しいか。
Transit GatewayやVPN経路は正しいか。

もちろん、それらは重要です。

しかし、OS内に固定で設定されていたルート情報、古いネットワークアダプタ前提の設定、特定AZや特定サブネットのIPを前提にした設定が残っていると、AWS側のネットワークが正しくても通信できないことがあります。

特にWindowsサーバでは、GUI上のネットワーク設定だけでなく、永続ルート、メトリック、複数NIC構成、過去に追加した静的経路などが影響することがあります。

PoCでは、EC2が起動するか、疎通確認が一度通るかだけでなく、OS内のルート情報、再起動後の永続化、AZ変更後の通信経路まで確認する必要があります。

「AWS側の設定は正しいのに通信できない」という状態は、原因調査に時間がかかります。

だからこそ、PoCの段階で、OS内のネットワーク前提まで確認しておく必要があります。

名前解決は、クラウドリフトにおける最重要設計論点

クラウドリフトでは、名前解決が非常に重要です。

オンプレでは、サーバ名、IPアドレス、DNS登録、参照経路が長期間固定されている前提で運用されていることがあります。

しかし、クラウドでは、EC2の再作成、AZ変更、復旧方式、切替方式によって、同じIPアドレス、同じ物理名、同じ参照経路で戻ってくるとは限りません。

そのため、必要に応じてDNSやRoute 53のレコードを書き換える設計が必要になります。

ここで注意すべきなのは、「DNSを書き換えればよい」という単純な話ではないことです。

参照元がAWS内のEC2なのか。
別VPCなのか。
オンプレミスのクライアントなのか。
AD DNSを見ているのか。
オンプレDNSからRoute 53へフォワードしているのか。
Route 53 Private Hosted Zoneを直接見ているのか。

この経路によって、復旧時に変更すべき場所が変わります。

特にハイブリッド構成では、Route 53 ResolverのInbound endpoint、Outbound endpoint、転送ルールの設計も重要になります。

オンプレ側からAWS内の名前を解決するのか。
AWS側からオンプレDNSへ問い合わせるのか。
どのドメインを、どのDNSへフォワードするのか。

また、名前解決は成功するか失敗するかだけでなく、問い合わせにどれくらい時間がかかるかも重要です。

オンプレDNS、Route 53 Resolver、AD DNS、別VPCのDNSをまたぐ構成では、フォワード先の設定、再帰問い合わせ、リトライ挙動によって、名前解決の遅延がアプリケーションの応答時間やタイムアウトに影響することがあります。

この設計を誤ると、AWS側では名前解決できているのに、オンプレ端末や業務サーバからは名前解決できない、という状態になります。

場合によっては、クラウド側のレコードを変更したつもりでも、参照元が別のDNSサーバを見ていて、期待した名前解決にならないことがあります。

ここを知らずに進むと、基盤結合試験まで発見されないことがあります。

システムテストのユースケースが甘いと、本番切替後に初めて通信できない、接続先が違う、名前解決できない、という形で発覚する可能性があります。

クラウドリフトでは、DNSは単なる付帯設定ではありません。

復旧方式、切替方式、運用方式そのものに関わる設計要素です。

DNSキャッシュとTTLも見落としやすい

切替直後は、クライアントやアプリケーションが古い名前解決結果をキャッシュしているため、一見すると通信できているように見えることがあります。

しかし、TTLが切れて再度名前解決が行われたタイミングで、参照先DNS、Route 53、オンプレDNS、Resolver経路、レコード状態のどこかに不整合があると、名前解決エラーや接続先誤りとして表面化します。

また、OS、JVM、ミドルウェア、接続プール、プロキシなどが名前解決結果や接続先情報を保持していると、Route 53側のTTLだけを見ていても切替挙動を説明できません。

DNS再解決を契機に接続先が変わり、TLS証明書のホスト名検証、DB接続、認証処理、接続プールの再接続で失敗することもあります。

特にアプリケーションサーバやバッチ処理では、起動時に解決した接続先情報をプロセス内で保持し続けることがあります。

その場合、DNSレコードを変更しても、アプリケーションが再起動されるまで新しい接続先を見に行かないことがあります。

逆に、TTL経過後に再解決された瞬間に、今まで見えていた接続先と別の接続先へ向かい、初めて問題が出ることもあります。

PoCでは、切替直後だけでなく、TTL経過後、キャッシュクリア後、アプリ再起動後、接続プール再作成後の挙動まで確認しておく必要があります。

DNSは、切替直後に疎通できればよいわけではありません。

TTLが切れた後、キャッシュが消えた後、アプリが再接続した後に、同じように業務が継続できるかを見る必要があります。

RDS Multi-AZも「切り替われば終わり」ではない

RDSがフェイルオーバーして待機系へ切り替わった場合、DBとしては復旧していても、Web/APサーバとのAZ配置が変わることがあります。

Web/APはAZ-A中心に残り、RDSのプライマリだけAZ-Bへ切り替わると、Web/APからDBへの通信がAZまたぎになります。

実務では、切替直後は一時的な縮退状態として許容し、業務影響を見ながらフェイルバックする方針を取ることもあります。

また、DBがフェイルオーバーしても、アプリケーション側が正しく再接続できるとは限りません。

コネクションプールが古い接続を保持したままになる。
接続リトライの回数や間隔が足りない。
DNS再解決が走らない。
一時的な接続断をアプリが異常終了として扱う。

このような場合、RDSとしては復旧していても、アプリケーションは接続エラーを出し続けることがあります。

PoCや障害試験では、DBの切替だけでなく、アプリ側の再接続、リトライ、コネクションプールの挙動まで確認する必要があります。

ここで重要なのは、切り替わるかどうかではありません。

切り替わった後の配置で、画面応答、バッチ処理、帳票処理、データ転送量、運用手順に問題が出ないかを確認することです。

PoCで見るべき観点

• 障害時に、どの単位で、どこまで自動復旧するのか
• そのEC2は、自動で作り直してよいサーバなのか
• Auto Scaling後に、ホスト名、DNS登録、OS設定、監視エージェント、ミドルウェア起動まで再現できるか
• cloud-initやUser Dataの実行タイミングが、サービス起動順序と矛盾していないか
• ロードバランサーのヘルスチェック、切り離し、復帰の条件は明確か
• 保守作業としてEC2を停止した場合と、障害として停止した場合を、Auto Scalingがどう扱うか
• 保守時にスケーリング停止、期待台数変更、インスタンス保護などの運用手順が必要か
• 別AZ起動後に、OS内の静的ルート、永続ルート、NIC設定、メトリック設定が移行後の構成と合っているか
• 参照元ごとに、どのDNSサーバを経由して名前解決しているか
• DNS問い合わせの遅延、リトライ、再帰問い合わせがアプリケーション応答やタイムアウトに影響しないか
• Route 53 ResolverのInbound/Outbound endpoint、転送ルールがハイブリッド構成に合っているか
• EC2再作成、AZ変更、切替後に、DNSやRoute 53のレコード変更が必要になるか
• DNSキャッシュやTTL経過後に、参照元から再度正しく名前解決できるか
• OS、JVM、ミドルウェア、接続プール、プロキシが独自に名前解決結果を保持していないか
• RDSがフェイルオーバーした後、Web/APとのAZ配置や通信経路に問題が出ないか
• DB切替後に、アプリ側の再接続、リトライ、コネクションプールの再作成が正しく行われるか
• 縮退状態を許容するのか、フェイルバックするのか
• 復旧後に何を確認すれば業務再開と言えるのか

可用性は、サーバが再起動することではありません。

自動復旧できるものと、手動で戻すべきものを切り分けること。
切り替わった後の配置、性能、縮退運用、フェイルバック方針まで確認すること。
そして、業務が再開できる状態を説明できること。

ここまで見て、初めてクラウドリフトにおける可用性設計です。

2. 性能・キャパシティ

動いたことと、業務時間内に処理できることは違う

性能面において最も危険なのは、単純な正常系テストで『動いた』と満足してしまうことです。

EC2上でアプリが起動した。
DBに接続できた。
バッチが1回流れた。
ファイルを読み書きできた。

しかし、それだけでは性能要件を満たしたことにはなりません。

現場では、日次の夜間バッチだけが重いとは限りません。

週次処理、月次処理、締め処理、大量帳票、ファイル集計、洗い替え処理など、特定日だけ極端に重くなる処理があります。

通常日の軽いデータや単発の小さな検証だけで判断すると危険です。

性能が出るかどうかは、インスタンスタイプ選定とも切り離せません。

オンプレからクラウドへ移行する場合、既存サーバのCPU、メモリ、ディスクI/O、ネットワーク使用量をそのまま見ても、クラウド上の適切なインスタンスタイプが自動的に決まるわけではありません。

オンプレ環境では、CPU性能をSPECintや独自の換算指標で見ていたとしても、AWS上ではインスタンスタイプごとにvCPU数、メモリ量、ネットワーク性能、EBS帯域、CPU世代、ファミリー特性が異なります。

そのため、単純に「CPUが何個あるからこのタイプ」「メモリが何GBあるからこのタイプ」と決めるのは危険です。

バッチサーバのように、大量データを読み込み、ソートし、一時領域を使い、一定時間内にまとめて処理するサーバでは、CPUだけでなくメモリやI/Oが効いてくることがあります。

一方で、Web/APサーバのように、1件あたりの処理は軽くても、多数のリクエストやトランザクションをさばくサーバでは、vCPU数、同時実行性能、スレッド数、コネクションプールの設計が効いてくることがあります。

CPUが足りないのか。
メモリが足りないのか。
I/Oが詰まっているのか。
ネットワークが詰まっているのか。
同時実行数に対してスレッドやコネクションプールが足りないのか。

ここを見ずにインスタンスタイプだけを上げると、コストだけが増えて、性能問題が解消しないことがあります。

また、拡張性を残すことも重要です。

最初からそのファミリーの最大サイズ、または上限に近いタイプを選んでしまうと、負荷が増えたときに同じ考え方でスケールアップできません。

「性能が足りなければタイプを上げればよい」と考えていたのに、すでに上限に近いタイプを選んでいたため、設計変更、構成変更、スケールアウト方式の見直しが必要になることがあります。

PoCでは、今の負荷を処理できるかだけでなく、将来の増加分をどこまで同じ構成で吸収できるかも確認しておく必要があります。

同じファミリー内のサイズ変更で対応できるのか。
メモリ最適化、コンピューティング最適化、汎用系など、ファミリー選定から見直す必要があるのか。
スケールアップではなく、スケールアウトや処理分散を考えるべきなのか。

この判断は、性能設計であり、同時にコスト見積やキャパシティ管理の前提にもなります。

PoCで見るべきなのは、単に「このタイプで動いたか」ではありません。

このタイプで本番負荷に耐えられるのか。
将来の増加に対して拡張余地があるのか。
同じファミリー内で上げればよいのか、ファミリー選定から見直すべきなのか。
見積、性能試験計画、キャパシティ管理の前提として説明できるのか。

ここまで確認しないと、設計段階でインスタンスタイプを決められず、試験やサービス開始後に「タイプを変えれば済むと思っていたのに、そう簡単ではなかった」という状態になります。

EFSを使う場合、標準的なバースト前提では、重いバッチ処理を安定して処理できないことがあります。

EFSのバーストスループットは、クレジットの蓄積と消費で動きます。

軽い処理を続けている間はクレジットが回復しますが、重いバッチを集中的に流すとクレジットを一気に使い切り、ベースラインスループットまで落ちることがあります。

また、EFSの性能を見るときは、単純な転送量だけでは不十分です。

読み取り中心なのか、書き込み中心なのか。
大きなファイルを少数扱うのか、小さなファイルを大量に扱うのか。
`ls`、`find`、属性確認、ディレクトリ走査のようなメタデータ操作が多いのか。

この違いによって、同じデータ量でもボトルネックの出方は変わります。

特に小さなファイルが大量にあり、バッチ処理でディレクトリを再帰的に走査するような場合、データ転送量よりもメタデータ操作が効いてくることがあります。

そのため、通常日のPoCでは問題なかったのに、月次締め処理や大量ファイル処理だけ極端に遅い、という現象が起こります。

バッチ処理がEFSから大量のファイルを読み込み、CPUとI/Oを同時に使い切るような処理であれば、エラスティックスループットやプロビジョンドスループットを検討する必要があります。

重要なのは、単に性能が出るかどうかではありません。

最も重い処理を、最も重い条件で流したときに、どのスループットモードが必要なのか。
一時的に性能を上げる運用が可能なのか。
処理後に下げられるのか。
変更に制約はないのか。
戻し忘れた場合にどれだけ課金されるのか。
見積上、その運用を説明できるのか。

ここまで含めて検証する必要があります。

もし、インフラ側の調整だけでは性能要件を満たせない場合は、バッチ処理の分割、コミット単位の見直し、ソート処理の方式、DBアクセス方式、ログ出力方式など、アプリケーションや処理方式の見直しに波及します。

性能PoCの最大のポイントは、軽い処理で「動いた」と確認することではありません。

最も重い処理を、最も重い条件で流し、必要な性能、構成、課金、運用手順、そしてアプリ改修要否まで判断することです。

PoCで見るべき観点

• 週次・月次・締め処理など最も重いバッチを本番相当データで流せるか
• 既存サーバのCPU、メモリ、I/O、ネットワーク使用量をもとに、アプリケーション特性に合ったインスタンスタイプやファミリーを選べているか
• バッチサーバ、Web/APサーバ、DBサーバなど、役割ごとにvCPU、メモリ、I/O、ネットワークの見方を分けているか
• 最初から最大サイズや上限に近いタイプを選んでおらず、将来のスケールアップ余地を残しているか
• 同じファミリー内のサイズ変更で足りるのか、ファミリー変更やスケールアウト設計まで必要になるのか
• EFS、EBS、DB、ネットワーク、EC2インスタンスのどこがボトルネックになるか
• EFSを使う場合、バースト、エラスティック、プロビジョンドのどのスループットモードが必要か
• 一時的に性能を上げ、処理後に下げる運用が現実的にできるか
• インフラ側の性能調整で足りない場合、アプリ改修や処理方式変更が必要になるか
• 読み取り/書き込み比率、大量小ファイル、`ls`/`find`などのメタデータ操作が性能ボトルネックにならないか

性能は、CPUやメモリの数字だけで決まるものではありません。

業務処理が、必要な時間内に、必要な量を、安定して処理できるか。
そして、その性能を必要なときだけ使い、不要なときにはコストを抑える運用ができるか。

ここまで見て、初めてクラウドリフトにおける性能設計です。

3. ストレージ

共有できることと、業務で使えることは違う

ストレージは、クラウドリフトPoCで大きな手戻りになりやすい領域です。

しかし、同じ感覚で「小さくできる」と考えると、実務では詰まります。

今回扱うのは、Red Hat Enterprise Linuxを利用しているEC2で、EBSの容量縮小を検討したときの話です。

容量拡張であれば、AWS側でEBSボリュームサイズを拡張し、OS側でパーティションやファイルシステムを拡張することで対応できます。

一方で、容量縮小は同じ考え方では進みません。

なぜなら、EBSの容量縮小は、既存ディスクのサイズを小さくする作業ではないからです。

実態としては、小容量ディスクを新しく作り、必要なデータを移して切り替える作業です。

つまり、容量縮小に見えても、考えるべきことはディスク移行です。

今回は、EBS縮小にあたって検討した3つの案と、最終的にどのような考え方で対応したのかを整理します。

そもそも、なぜ認識がズレるのか

まず最初に確認しておきたいのは、「縮小しようとしたこと」自体が悪いわけではない、ということです。

コスト削減や容量適正化の観点から、過剰に確保されたディスク容量を見直すことは当然あります。

問題は、容量縮小を「単なるサイズ変更」と捉えてしまうことです。

クラウドストレージは柔軟に見えます。

実際、EBSの拡張は比較的やりやすいです。

AWS側でボリュームサイズを拡張し、OS側でその拡張分を認識させれば、既存の領域を広げることができます。

しかし、縮小は違います。

AWSのEBSにおいて、拡張と縮小は非対称です。

• 拡張方向：既存のボリュームを大きくできる

• 縮小方向：既存のボリュームをそのまま小さくする操作はできない

ここを誤解すると、設計や作業計画の段階でズレます。

「クラウドだから柔軟に変えられる」

この感覚は、拡張方向にはある程度当てはまります。

しかし、縮小方向にはそのまま当てはまりません。

この非対称性を理解していなかったことが、今回のつまずきの根本でした。

容量拡張は比較的素直にできる

EBSの容量拡張であれば、作業の考え方は比較的明確です。

RHEL環境であれば、流れはおおむね次のようになります。

1. AWS側で既存EBSボリュームのサイズを拡張する

2. Linux OS上でパーティションを拡張する

3. 必要に応じてLVM側の設定を拡張する

4. ファイルシステムを拡張する

この流れを図にすると、以下のようになります。

容量拡張は、既存の構成を保ったまま、ディスク領域を順番に広げていく作業です。

EBSを拡張し、OS側でパーティションやLVM、ファイルシステムに反映していく。

つまり、拡張は「今ある領域を広げる」作業として整理できます。

もちろん、実務では事前バックアップを取得したうえで作業します。

それでも、容量拡張は「既存構成を壊さずに広げる」方向の作業として成立しやすいです。

しかし縮小は、同じ考え方ではできない

問題は、容量縮小です。

容量縮小も、拡張と同じ感覚で考えたくなります。

「AWS側でサイズを小さくして、OS側でも縮小すればよい」

一見、自然に見えます。

しかし、これはできません。

EBSは、既存ボリュームを直接縮小する操作を提供していません。

つまり、容量縮小は「既存ディスクを小さく加工する」作業ではないのです。

実務上の考え方は、こうなります。

縮小するのではなく、小容量EBSを新しく作り、必要なデータだけを移す。

これはディスク縮小ではありません。

小容量ディスクへの移行です。

この発想の切り替えが必要です。

また、OSのファイルシステムとしてXFSを使用している場合、ファイルシステム自体を縮小することはできません。

そのため、バックアップ、ファイルシステムの再作成、リストアという流れで考える必要があります。

ここで必要なのは、縮小コマンドを探すことではありません。

「これは移行作業である」と捉え直すことです。

拡張と縮小の違いを、あえてシンプルに図にするとこうなります。

ポイントは、縮小が「既存ディスクを小さくする作業」ではないことです。

小容量EBSを新しく作り、必要なデータを移し、切り替える。

この時点で、容量縮小はサイズ変更ではなく、移行作業として考える必要があります。

検討した3つの案

今回、実際に検討した案は次の3つです。

案1：既存EBSを直接縮小する

結論：不可

EBSボリューム自体を直接縮小することはできません。

無理に考えると、OS上のパーティションやファイルシステムとの整合性が崩れ、データ破損につながるリスクがあります。

案2：AMIから小容量EBSへ復元する

結論：今回は不可

AMIからの復元そのものが悪いわけではありません。

しかし、元ディスクの構成を、そのまま小容量EBSへ復元する前提では整合性が取れません。

EBSは、元のボリュームより小さいサイズへ単純に戻すことはできません。

また、OS領域、パーティション構成、LVM、ファイルシステムの状態を踏まえずに小容量EBSへ戻そうとすると、容量不足や構成不整合が発生します。

特にXFSのように縮小できないファイルシステムを使っている場合、LVMだけを見て小さくできるとは判断できません。

そのため、今回の対策としては採用できませんでした。

案3：OS上でバックアップ・リストアする

結論：採用

小容量EBSを新規作成し、OS上でデータを退避・復元する方法です。

ただし、OS上の使用容量が、縮小後のEBS容量より小さいことが前提です。

つまり、EBSを直接縮小するのではなく、小容量ディスクへ必要なデータを移す、という考え方です。

文章だけだと少し分かりにくいので、3つの案をイメージで並べると以下のようになります。

案1は、既存EBSを直接小さくしようとする考え方です。

案2は、AMIから小容量EBSへ戻そうとする考え方です。

案3は、小容量EBSを新規作成し、必要なデータを移す考え方です。

今回採用したのは、案3でした。

ここからは、それぞれの案で何が問題だったのかを見ていきます。

案1：既存EBSをそのまま縮小する

最初に考えたのは、既存EBSを直接小さくできないか、という案です。

容量拡張の逆で、既存ボリュームのサイズを小さい値に変更できないか、という発想です。

しかし、これは採用できませんでした。

理由は単純です。

EBSには、既存ボリュームを直接縮小する操作がないためです。

容量拡張はできます。

しかし、容量縮小はできません。

ここで重要なのは、EBSのサイズだけを見てはいけないということです。

EC2から見れば、EBSはディスクです。

その上にはパーティションがあり、場合によってはLVMがあり、その上にファイルシステムがあります。

仮にディスクの外側だけを小さくできたとしても、OS上のパーティションやファイルシステムとの整合性が崩れれば、データ破損につながります。

つまり、既存EBSをそのまま小さくするという発想自体が危険です。

案2：AMIから小容量EBSへ復元する

次に考えたのは、既存インスタンスからAMIを取得し、小容量EBS構成で復元する案です。

バックアップから新しい環境を作り直すだけなので、一見うまくいきそうに見えます。

しかし、これも今回の条件では採用できませんでした。

問題は、元ディスクの構成と、復元先ディスクの容量の整合性です。

AMIから復元する場合、元のブロックデバイス構成、パーティション構成、ファイルシステムの状態が前提になります。

その構成を、元より小容量EBSへそのまま復元しようとすると、容量不足や構成不整合が発生します。

ここで誤解してはいけないのは、「AMIが使えない」という話ではないことです。

AMIはバックアップや環境複製の手段として有効です。

ただし、今回のように「元より小容量ディスクへそのまま戻す」前提では、単純には成立しません。

OS領域、パーティション構成、LVM構成、ファイルシステムの状態を踏まえずに、

「AMIを取って、小容量EBSで戻せばよい」

と考えるのは危険です。

案3：OS上でバックアップ・リストアする

最終的に採用したのは、Linux OS上でデータをバックアップし、小容量EBSを新規作成して、そこへリストアする方法です。

ここで重要なのは、EBSを縮小しているわけではない、ということです。

小容量EBSを新しく作る。

そこに必要なデータを戻す。

つまり、これはディスク縮小ではなく、ディスク移行です。

ただし、この方法にも重要な前提があります。

OS上の使用容量が、縮小後のEBS容量よりも小さいこと。

これが満たされない場合、この方法も採用できません。

たとえば、100GBのEBSを50GBにしたい場合、実際にOS上で使用している容量が50GBを超えていれば、当然ながら移行先に入りません。

「EBSの見かけ上の容量」ではなく、「実際に使用している容量」を確認する必要があります。

XFSを利用している環境では、ファイルシステム単位のバックアップ・リストアとして、`xfsdump` / `xfsrestore`を使う方法があります。

単純なファイルコピーではなく、ファイルシステムの属性や構造を踏まえて退避・復元したい場合に検討する方法です。

ただし、実際に採用するバックアップ方式は、対象がOS領域なのか、データ領域なのか、停止可能時間、整合性要件、アプリケーション要件によって変わります。

「XFSなら必ずこの方法」という話ではありません。

あくまで、今回の条件において選択した方法です。

作業の全体像は、以下のようになります。

1. Linux OS上でデータをバックアップする

2. 小容量EBSを新規作成する

3. Linux OS上でパーティションを設定する

4. 必要に応じてLVMを設定する

5. ファイルシステムを作成する

6. バックアップデータをリストアする

7. マウント設定やサービス起動を確認する

8. アプリケーションの動作確認を行う

ここで大事なのは、バックアップして戻せば終わりではない、ということです。

特に注意したいのが、UUIDとマウント設定です。

小容量EBSを新規作成すると、既存EBSとは別のディスクになります。

そのため、ファイルシステムのUUIDが変わる場合があります。

`/etc/fstab` でUUIDで指定している場合、移行後のUUIDと設定が一致していないと、OS起動時にマウントできない、起動が遅延する、あるいは起動時にエラーになることがあります。

また、マウントできたとしても、それだけで作業完了とは言えません。

アプリケーションの起動、ログ出力先、ジョブの出力先、監視・バックアップ対象などは、環境によって確認観点が変わります。

そのため、単に「リストアできたか」ではなく、自社の運用定義に合わせて確認観点を整理しておく必要があります。

今回、何が甘かったのか

今回の反省点は、単に「EBS縮小の手順を知らなかった」ことではありません。

もっと根本的には、容量縮小という作業の捉え方が甘かったことです。

甘かった点①：削減作業を、移行作業として計画していなかった

これが一番大きいです。

容量縮小は、見た目にはコスト削減作業です。

不要に大きく確保されたディスク容量を見直し、適正なサイズにする。

そう考えると、単なる設定変更やリソース変更のように見えます。

しかし実態は違います。

容量縮小は、小容量ディスクへの移行作業です。

移行作業として捉えていれば、最初から次の観点を計画に入れます。

• どのデータを退避するのか

• どの方式でバックアップするのか

• どれくらい停止時間が必要なのか

• 復元後に何を確認するのか

• 失敗した場合、どう切り戻すのか

• アプリケーションや運用にどの影響があるのか

しかし、「縮小作業」とだけ捉えていると、これらの検討が後回しになります。

そして作業直前になって、

「どうやって戻すのか」

「切戻しはどうするのか」

「業務影響はどこまであるのか」

という話になります。

これは、かなり危険です。

容量縮小は、削減作業である前に移行作業です。

ここを間違えると、作業計画そのものが甘くなります。

甘かった点②：EBSは増やせるから減らせる、と思い込んでいた

次に甘かったのは、拡張と縮小を同じ種類の作業だと考えていたことです。

クラウドのストレージは柔軟に見えます。

しかし、柔軟なのは主に拡張方向です。

容量を増やす場合は、既存領域を広げる方向の作業になります。

一方で、容量を減らす場合は、既存領域を削るのではありません。

小さい領域を新しく作り、必要なデータを移す作業になります。

この違いを理解していないと、

「AWS側でサイズを小さくできないのか」

「OS側でファイルシステムを縮められないのか」

「AMIで戻せばよいのではないか」

という発想になります。

しかし、実務で必要なのは、縮小操作を探すことではありません。

移行方式を設計することです。

甘かった点③：OS・パーティション・ファイルシステムの関係を軽く見ていた

EBSの容量を変える作業は、AWS側だけでは完結しません。

EC2から見れば、EBSはディスクです。

その上にはパーティションがあります。

場合によってはLVMがあります。

その上にファイルシステムがあります。

そして、そのファイルシステム上にOSやアプリケーションのデータがあります。

この階層を意識せずに作業すると、どこを変更しているのか分からなくなります。

EBSを変更しているのか。

パーティションを変更しているのか。

LVMを変更しているのか。

ファイルシステムを変更しているのか。

マウント設定を変更しているのか。

ここを曖昧にしたまま進めると、OSが起動しない、マウントできない、データが読めない、といった事故につながります。

クラウドを使っていても、OSとファイルシステムの基本は消えません。

むしろ、AWS側の操作とOS側の構造をつなげて理解していないと、簡単そうな作業ほど危険になります。

手順の前に、作業の性質を見極める

この話は、EBSだけの話ではありません。

クラウドサービスを使っていると、リソース変更が簡単に見えることがあります。

• CPUを増やす

• メモリを増やす

• ディスクを増やす

• インスタンスタイプを変える

• スナップショットを取る

コンソール上では、確かに操作できます。

しかし、システムとして安全に変更できるかは別です。

今回の自分の反省も、まさにそこにありました。

最初は、容量縮小を「ディスクサイズを小さくする作業」として見ていました。

だから、まず探したくなるのは、縮小するための手順やコマンドです。

しかし実際には、これはサイズ変更ではなく、小容量ディスクへの移行作業でした。

この見立てが変わると、考えるべきことも変わります。

• バックアップはどうするのか

• リストアはどうするのか

• 停止時間はどれくらい必要なのか

• 失敗した場合、どう切り戻すのか

• 移行後に、OS・アプリケーション・運用の観点で何を確認するのか

作業の性質を見誤ると、手順をどれだけ調べても計画が甘くなります。

逆に、最初に「これは移行作業だ」と捉えられれば、必要な確認観点が見えてきます。

今回の学びは、EBS縮小の具体的な手順そのものではありません。

手順の前に、作業の性質を見極めること。

これが、クラウド環境の変更作業では特に重要だと感じました。

まとめ

EBSの容量縮小は、単なるサイズ変更ではありません。

拡張は、既存の領域を広げる作業です。

縮小は、新しい小容量ディスクへ移し替える作業です。

この2つは、同じ種類の作業ではありません。

この違いを理解していないと、作業直前になって次のような状態になります。

• AWS側に縮小操作がない

• AMIから戻せばよいと思ったが、容量が合わない

• OS上でどう復元するか決めていない

• UUIDやマウント設定の確認が漏れている

• 切戻し方針を用意していない

• 動作確認の観点が整理されていない

クラウドだから簡単、ではありません。

クラウドを使うほど、インフラの基本が不要になるわけでもありません。

むしろ、AWSの仕様とOSの構造をつなげて理解していないと、簡単そうに見える作業ほど危険になります。

EBSの容量縮小で必要なのは、縮小コマンドを探すことではありません。

「これはディスク移行作業である」と捉え直すことです。

このあたりは、以下の記事でも詳しく書いています。

【前編】詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程

シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。

なのに、本番運用で失敗する。

そういうことがあります。

今回起きたのは、CloudWatch Logsのログエクスポートジョブが、日次処理でエラーになるという事象です。

CloudWatch Logsのログを、定期的にS3へエクスポートする。

AWSを使ったシステムでは、よくある運用設計です。

ログをCloudWatch Logsに集約し、一定期間ごとにS3へ退避する。
監査、障害調査、保存期間、コスト、運用保守を考えると、自然な構成に見えます。

しかし、今回の本質は、ジョブの実装ミスではありませんでした。

問題は、AWSサービスの制約を、運用ジョブ設計とテスト設計に織り込めていなかったことです。

CloudWatch Logsのログエクスポートは、ジョブを作れば好きなだけ並列に流せるものではありません。

ここを知らないと、単体では正常に動いていたジョブが、本番運用で突然失敗します。

起きたこと

あるシステムで、日次ジョブとしてCloudWatch Logsのログエクスポートを実行していました。

処理内容はシンプルです。

CloudWatch Logsに出力されたログを、一定期間ごとにS3へエクスポートする。
S3側に保存しておけば、長期保管、調査、監査対応にも使える。
CloudWatch Logs側の保持期間も適切に管理できる。

よくある構成です。

ところが、日次ジョブで実行しているログエクスポートがエラーになりました。

確認すると、ロググループは存在している。
S3バケットも存在している。
IAMロールも大きく間違っていない。
以前は同じ処理が動いていた。

にもかかわらず、ジョブが失敗する。

この時点で、最初に疑うのは個別設定です。

権限が足りないのではないか。
出力先バケットのポリシーが変わったのではないか。
ロググループ名が間違っているのではないか。
対象期間の指定がおかしいのではないか。
Lambdaやシェルの実装に不備があるのではないか。

もちろん、それらの確認は必要です。

しかし、調べていくと、原因はもっと上位の設計にありました。

何が問題だったのか

問題は、CloudWatch Logsのログエクスポートには、AWS側の制約があるという点です。

CloudWatch Logsのログエクスポートでは、CreateExportTaskを使って、ロググループのログをS3へ出力します。

このExportTaskには制約があります。

1つのAWSアカウント、1つのリージョンにつき、アクティブなExportTaskは1つしか持てません。

ここでいうアクティブとは、実行中または保留中の状態です。

つまり、あるログエクスポートタスクがまだ実行中、または開始待ちの状態で残っている場合、同じアカウント・同じリージョン内で次のエクスポートタスクを作成しようとしても失敗する可能性があります。

これはAWS公式ドキュメントにも記載されているCloudWatch Logsのクォータです。

これが盲点でした。

1つのシステムだけを見ていると、この問題は見えにくいです。

1つのロググループを対象にしている。
手動で1回だけ実行する。
単体テストで1回だけエクスポートする。

この条件なら、正常に見えます。

しかし、同じAWSアカウントの同一リージョンの中に複数システムが存在し、それぞれが日次でCloudWatch Logsのエクスポートを実行していると、話が変わります。

Aシステムのログエクスポートが実行中。
そのタイミングで、Bシステムのログエクスポートが起動する。
さらに、Cシステムのログエクスポートも同じ時間帯に起動する。

それぞれのジョブは、単体で見れば正しい。

しかし、アカウント全体で見ると、同時に実行できない処理が重なっている。

これでは失敗します。

ジョブの中身が間違っていなくても、AWSサービスの制約に引っかかるからです。

個別には正しい。
しかし、共通のAWSアカウント／リージョン側で競合する。

今回の問題は、まさにここでした。

原因

「AWSの制約でした」で終わらせてはいけません。

それは調べれば分かる話です。

実務で問うべき原因は、もう一段深いところにあります。

それは、AWSサービスの制約を、設計時点でジョブ設計・スケジュール設計・テスト設計に落とせていなかったことです。

AWSの制約そのものは障害ではありません。
AWSが壊れていたわけではありません。
CloudWatch Logsが異常だったわけでもありません。

仕様どおりに動いていただけです。

問題は、その仕様を使う側が、運用条件に織り込めていなかったことです。

特に、複数システムを1つのAWSアカウントに載せる場合、各システムが独立してジョブを設計すると、こういう問題が起きます。

Aシステムの担当者は、Aシステムのログエクスポートだけを見る。
Bシステムの担当者は、Bシステムのログエクスポートだけを見る。
Cシステムの担当者は、Cシステムのログエクスポートだけを見る。

個別に見ると、それぞれの設計は間違っていない。

しかし、アカウント全体で見ると、同時実行できないジョブが同じ時間帯に並んでいる。

この状態では、本番運用で失敗します。

打った対策と運用の設計観点

対策を考えるときに、単純に「エラーになったらリトライすればよい」と考えるのは危険です。

もちろん、リトライは必要です。

しかし、何も考えずにリトライを入れると、別のシステムのExportTaskがまだ完了していない状態で、同じ失敗を繰り返すだけになります。

今回考えるべき対策は、少なくとも次の3つです。

1つ目は、ログエクスポートジョブの実行時間をずらすことです。

同じAWSアカウント・同一リージョン内で複数システムがCloudWatch Logsのエクスポートを行う場合、各ジョブの起動時刻を重ねないようにする必要があります。

たとえば、以下のように時間帯を分けます。

変更前：
01:00 Aシステム ログエクスポート
01:00 Bシステム ログエクスポート
01:00 Cシステム ログエクスポート

変更後：
01:00 Aシステム ログエクスポート
02:00 Bシステム ログエクスポート
03:00 Cシステム ログエクスポート

ただし、これは最低限の対策です。

2つ目は、ExportTaskの状態を確認してから、次のタスクを作成することです。

ログ量が多い日には、前のエクスポート処理が想定より長引くことがあります。
障害や遅延により、前日のタスクが残っていることもあります。
単純に時刻をずらしただけでは、処理時間の変動に対応できません。

そのため、既存のExportTaskの状態を確認し、実行中または保留中のタスクがある場合は、待機する、スキップする、後続へ回す、といった制御が必要になります。

処理の流れとしては、以下のような形です。

1. 既存のExportTaskを確認する
2. RUNNINGまたはPENDINGのタスクがあれば待機する
3. 一定時間待っても完了しなければスキップまたは異常終了する
4. 実行可能な状態であれば新しいExportTaskを作成する
5. 作成したタスクIDを記録する
6. 完了状態を確認する
7. 失敗時はリトライまたは運用通知する

ここで重要なのは、ジョブの成功条件を「APIを呼べたこと」にしないことです。

CreateExportTaskを呼び出せた。
タスクIDが返ってきた。
だから成功。

これだけでは不十分です。

運用上は、実際にエクスポートが完了し、S3に期待したログが出力されていることまで確認する必要があります。

3つ目は、失敗時の運用を決めておくことです。

エクスポートに失敗した場合、翌日にまとめて再実行するのか。
対象期間を分割して再実行するのか。
失敗したロググループだけを再実行するのか。
運用担当者にアラートを出すのか。
一定回数までは自動リトライするのか。
リトライしても失敗した場合、誰が判断するのか。

ここまで決めて、初めて運用ジョブの設計になります。

「毎日1時にジョブを起動する」だけでは、設計として足りません。

「その時間に実行してよい状態か」
「実行できなかった場合にどう扱うか」
「ログ欠損や二重出力をどう防ぐか」

ここまで考える必要があります。

失敗時の設計観点は、最低でも次のように整理します。

・リトライ回数
・リトライ間隔
・再実行対象期間
・二重出力の扱い
・ログ欠損時の対応
・通知先
・運用手順書への記載

ジョブは、処理を起動するだけではありません。

失敗したときに、運用担当者が判断できる状態にしておくところまで含めて、ジョブ設計です。

補足：そもそもExportTaskでよかったのか

ここまでの対策は、CloudWatch LogsのExportTaskを使い続ける前提の話です。

しかし、設計としては、そもそもS3へ日次エクスポートする方式でよかったのか、という確認も必要です。

障害調査や一時的なログ検索が目的であれば、CloudWatch Logs Insightsで足りるケースもあります。
CloudWatch Logsにログを保持し、必要なときに検索・分析できれば、必ずしもS3へエクスポートしなくてよい場合があります。

一方で、長期保管、監査対応、CloudWatch Logsの保持期間外の保存、S3を前提にしたログ管理が必要であれば、S3への保存は必要になります。

その場合も、日次のExportTaskだけが選択肢ではありません。

リアルタイム性が必要な場合や、ExportTaskの同時実行制約を避けたい場合は、CloudWatch LogsのサブスクリプションフィルターからAmazon Data Firehoseへ連携し、Firehose経由でS3へ配信する構成も検討対象になります。

つまり、対策は「ExportTaskの起動時間をずらす」だけではありません。

ログの用途、保存期間、検索頻度、監査要件、リアルタイム性、コスト、運用負荷を踏まえて、そもそものログ保存方式を選ぶ必要があります。

今回のようなトラブルは、単にジョブを直すだけでなく、ログ運用方式そのものを見直すきっかけにもなります。

テスト工程で見るべきだったこと

今回の話で重要なのは、設計だけではありません。

テスト工程でも、見方を間違えるとこの問題は見逃されます。

単体テストでは、CloudWatch LogsからS3へエクスポートできるかを確認します。

これは必要です。

ロググループを指定する。
対象期間を指定する。
S3バケットに出力される。
IAMロールで実行できる。
エラー時にログが出る。

ここまでは確認します。

しかし、単体テストで1回エクスポートが成功しても、本番運用で問題なく回ることは保証できません。

結合テストでは、ジョブスケジューラから起動できるか、LambdaやシェルからAWS APIを呼べるか、S3に出力されるか、異常時に通知されるかを確認します。

これも必要です。

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

システムテストや運用テストでは、実際の運用に近い条件で確認する必要があります。

たとえば、次のような観点です。

・同じAWSアカウント内に複数システムが存在する
・同一リージョン内で複数のログエクスポートジョブが日次で動く
・ログ量が多い日にExportTaskの完了が遅れる
・前日のExportTaskが残っている状態で翌日のジョブが起動する
・他システムのExportTask実行中に自システムのジョブが起動する
・失敗した場合に再実行すると対象期間が重複する
・スキップした場合にログ欠損が起きる
・運用担当者が失敗に気づける
・通知を受けた担当者が、何を見て判断すればよいか分かる

ここまで見ないと、運用ジョブとしての品質は確認できません。

「1回エクスポートできた」ことと、
「毎日、運用として成立する」ことは別です。

これは、テスト工程で非常に重要な考え方です。

機能確認だけなら、1回エクスポートできれば合格に見えます。

しかし、運用確認として見るなら、複数システム、複数ジョブ、ログ量増加、遅延、再実行、通知、手順まで確認しなければいけません。

テスト工程は、単に「作ったものが動くか」を見る工程ではありません。

設計した運用が、実際の条件で破綻しないかを確認する工程です。

クラウドでも設計は省けない

今回の気づきは、CloudWatch LogsのExportTask制約そのものではありません。

それは調べれば分かります。

本当の気づきは、クラウドサービスを使う場合、設計対象は自分たちが作った処理だけではないということです。

AWSのマネージドサービスを使うと、OSやミドルウェアを自分たちで管理しなくてよい部分が増えます。

それは大きなメリットです。

しかし、その代わりに、サービスごとの仕様、クォータ、非同期処理、状態遷移、リトライ設計、料金体系を理解する必要があります。

CloudWatch Logsのエクスポートも同じです。

画面上は簡単に見えます。
APIも用意されています。
S3へ出力できるので、仕組みとしてはシンプルに見えます。

しかし、実運用では、同時実行数、処理時間、ログ量、再実行、監視、通知まで考える必要があります。

クラウドだから簡単になる部分はあります。

しかし、クラウドだから設計しなくてよい、という話ではありません。

むしろ、クラウドサービスの仕様を知らないまま設計すると、オンプレとは別の形で詰まります。

オンプレでは、サーバ、ディスク、ネットワーク、ジョブスケジューラ、ミドルウェアの制約を見ていました。

クラウドでは、そこにAWSサービスごとの制約が加わります。

サービスを使うだけなら簡単です。

しかし、業務システムとして運用するなら、サービスの制約まで含めて設計する必要があります。

再発防止として見るべきこと

同じ問題を繰り返さないためには、個別ジョブを修正するだけでは不十分です。

今回のような問題は、担当者がCloudWatch LogsのExportTask制約を知っていれば防げます。
しかし、知らない人が設計すれば、また同じことが起きます。

だからこそ、個人の知識や注意力に頼るのではなく、設計レビューやテスト計画の観点として残しておく必要があります。

以下は、設計レビューやテスト計画にそのまま転用できる形で整理したチェックリストです。

・使用するAWSサービスのクォータを確認したか
・アカウント単位、リージョン単位の制約を確認したか
・同一アカウント内の他システムと競合しないか
・同一リージョン内で競合するジョブがないか
・同時実行できない処理を並列に起動していないか
・ジョブの起動時刻だけでなく、完了時刻も考慮したか
・処理時間が長引いた場合の後続影響を確認したか
・前回処理が残っている場合の動作を決めたか
・リトライ時に二重処理やログ欠損が起きないか
・スキップ時にどのように検知するか決めたか
・失敗時に誰が、どの通知で、何を見て判断するか
・運用手順書に再実行方法を記載したか
・運用テストで複数システム同時稼働を確認したか

このような観点を、設計レビューやテスト計画に入れておく。

それが再発防止のために見るべきことです。

今回のような問題は、担当者個人の注意力だけに頼ると再発します。

CloudWatch LogsのExportTask制約を知っている人がいれば防げる。
知らない人が設計するとまた起きる。

それでは、組織として弱いです。

だから、レビュー観点にする。
テスト観点にする。
運用設計のチェックリストにする。

これが、実務では必要になります。

若手SEに伝えたいこと

若手SEのうちは、どうしても「処理が動くか」に意識が向きます。

コマンドが成功した。
APIが通った。
S3にファイルが出た。
ジョブが正常終了した。

もちろん、それは大事です。

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

本番では、他のシステムも動いています。
他のジョブも動いています。
ログ量も日によって変わります。
AWSサービス側の制約もあります。
障害時には再実行もあります。

だから、設計では「単体で動くか」だけでなく、「運用全体の中で成立するか」を見なければいけません。

CloudWatch Logsのログエクスポート失敗は、小さなトラブルに見えるかもしれません。

しかし、ここには大事な教訓があります。

ジョブは、処理単体ではなく、運用全体で設計する。

そして、

テストは、機能確認ではなく、運用で破綻しないことを確認する工程である。

この視点がないと、クラウドでもオンプレでも、同じように運用で詰まります。

AWSを使うこと自体は難しくありません。

しかし、AWSを使って業務システムを安定運用するには、サービス仕様、制約、ジョブ設計、監視、再実行、テスト工程までつなげて考える必要があります。

「1回動いたから大丈夫」

この考え方が、本番運用では一番危ないです。

単体で動くことと、運用で回ることは違います。

この違いを理解しているかどうかが、実務のSEとしてかなり大きな差になります。

今回の話は、単なるCloudWatch Logsの制約の話ではなく、
「ジョブ単体では動く」ことと、
「本番運用で毎日回る」ことは別物である、という話でもあります。

このあたりは、以下の記事でも詳しく書いています。

【前編】詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程

シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。

「これで設定完了です」

そう報告したあと、OSを再起動したら設定が戻っていた。
クラウド環境でインスタンスを再作成したら、同じ設定が入っていなかった。

インフラ構築では、こういうことが起きます。

特に危ないのは、作業直後には正しく見えるケースです。

コマンドを実行した。
設定値も変わった。
疎通もできた。

だから大丈夫だと思っていた。

しかし、再起動後、AMI化後、インスタンス再作成後、DHCP更新後に設定が戻る。

本番運用でこれが起きると、単なる作業ミスでは済まなくなります。

今回は、MTU設定を題材にします。

MTUとは、ネットワークで一度に送れるパケットサイズの上限です。

通常のWebシステムでは、普段あまり意識しないかもしれません。
しかし、クラウド環境、VPN、Direct Connect、閉域接続、ジャンボフレーム、オンプレからクラウドへの移行などが絡むと、MTUは設計・構築・試験で確認すべき項目になります。

今回のトラブルは、次のようなものでした。

RHEL7の環境では、NetworkManager を使ってMTUを設定していた。
ところが、Amazon Linux 2の環境では、同じように設定しようとしても、RHEL7と同じ前提では作業できなかった。

つまり、RHELで使っていた設定手順を、そのままAmazon Linux 2に横展開できなかったのです。

何が起きたのか

ある環境で、ネットワークインターフェースのMTU値をカスタマイズする必要がありました。

RHEL7の環境では、次のように nmcli を使って設定していました。

nmcli c modify "My favorite connection" ethernet.mtu 1600

nmcli は、NetworkManagerを操作するためのコマンドです。

NetworkManagerが管理している接続設定に対して、MTU値などを変更できます。

この場合、設定内容は結果的に以下のようなファイルにも反映されます。

/etc/sysconfig/network-scripts/ifcfg-XXXX

そのため、RHEL7で構築経験がある人からすると、

「MTUを変えるなら、nmcli で設定すればよい」

という感覚になりがちです。

しかし、今回のAmazon Linux 2環境では、同じ前提が成り立ちませんでした。

RHEL7と同じように NetworkManager.service を前提にした構成ではなく、nmcli 前提の手順をそのまま使うことができなかったのです。

問題は「MTUの設定方法を知らなかったこと」ではない

ここで大事なのは、

「Amazon Linux 2では、このファイルを編集しましょう」

という単純な話ではありません。

本質的な問題は、OSが変わったにもかかわらず、ネットワーク設定の管理方式が同じだと思い込んだことです。

Linuxといっても、すべてが同じではありません。

RHEL、CentOS、Amazon Linux、Ubuntu、Oracle Linuxなど、ディストリビューションが違えば、設定ファイルの場所、サービス管理の考え方、ネットワーク設定の反映方法、標準で有効になっているサービスが変わることがあります。

さらに、同じRHEL系に見えても、バージョンやクラウドイメージの作りによって、デフォルト構成が違うこともあります。

つまり、

「前の案件で動いた」
「RHELではこうだった」
「Linuxだから同じだろう」

という判断は、インフラ構築では危険です。

なぜこういうことが起きるのか

オンプレミス環境のLinuxと、クラウド環境のLinuxでは、サーバの作られ方が違います。

オンプレミスでは、OSをインストールし、ネットワーク設定を作り込み、固定的なサーバとして長期間運用することが多くあります。

一方、クラウド環境では、AMIなどのイメージからインスタンスを起動し、起動時にIPアドレス、ホスト名、鍵情報、ネットワーク関連の初期設定などが自動的に構成されることがあります。

Amazon Linux 2のようなクラウド向けのOSイメージでは、オンプレミスのRHEL環境と同じ管理サービス構成になっているとは限りません。

そのため、NetworkManagerだけでなく、network service、DHCP、cloud-init、AMI作成時の状態など、複数の仕組みが関係する場合があります。

今回の環境では、RHEL7で使っていたNetworkManager前提の設定手順を、そのまま使える構成ではありませんでした。

見るべきポイントは、

「どのOSか」

だけではありません。

より正確には、

「そのOSイメージでは、ネットワーク設定を何が管理しているのか」

です。

ここを確認せずに手順を横展開すると、設定が反映されない、再起動後に戻る、別インスタンスでは挙動が違う、というトラブルにつながります。

なお、Amazon Linux 2023では、さらに事情が変わります。

AWS公式ドキュメントでは、AL2023では `systemd-networkd` がネットワークインターフェースを管理し、AL2で使われていた `dhclient` から変更されていると説明されています。

つまり、Amazon Linux 2で確認した手順も、Amazon Linux 2023にそのまま横展開できるとは限りません。

RHEL7ではNetworkManager、Amazon Linux 2では別の見方が必要だった

今回の差分を簡単に整理すると、以下のようになります。

RHEL7では、NetworkManagerがネットワーク設定の中心になっている環境があります。

その場合、nmcli で接続プロファイルを変更することが自然な方法になります。

一方で、Amazon Linux 2では、環境によってはNetworkManagerを前提にできません。

そのため、インターフェース設定ファイルやDHCPクライアント設定、起動時にネットワーク設定へ関わる仕組みを確認する必要があります。

たとえば、インターフェース側では以下のような設定ファイルを確認します。

/etc/sysconfig/network-scripts/ifcfg-eth0

MTU値を指定する場合、環境に応じて次のような設定を追加・変更します。

MTU=1600

さらに、DHCPでネットワーク設定を取得している場合は、DHCPクライアント側の設定も確認対象になります。

/etc/dhcp/dhclient.conf

ここで出てくるコマンドやファイルパスを、すべて丸暗記する必要はありません。

大事なのは、個別のコマンドを覚えることではなく、

「誰がネットワーク設定を管理しているのか」
「どこに書けば再起動後も残るのか」
「何に上書きされる可能性があるのか」

という構造を押さえることです。

この図で見てほしいのは、設定値の違いではありません。

同じMTU設定でも、RHEL7ではNetworkManager経由、Amazon Linux 2では設定ファイルやDHCP関連の確認が中心になる、という設定経路の違いです。

一番怖いのは、設定できたように見えてしまうこと

この手のトラブルで怖いのは、最初から完全に失敗してくれるとは限らないことです。

コマンドが存在しない。
サービスが存在しない。
設定ファイルが見つからない。

ここまで分かりやすく失敗してくれれば、まだよいです。

問題は、設定したつもりになっているケースです。

たとえば、次のようなコマンドで確認したとします。

ip link show eth0

その時点では、MTUが変わっているように見える。

しかし、ネットワークサービスを再起動すると戻る。
OSを再起動すると戻る。
AMIから再作成すると戻る。
DHCP更新後に戻る。
別のインスタンスでは挙動が違う。

この場合、作業者の感覚としては、

「設定したのに戻った」
「なぜか環境によって違う」
「手順通りにやったのに再現しない」

となります。

しかし、原因はシンプルです。

その設定が、永続化される場所に入っていなかった。
または、
永続化したつもりの設定が、別の仕組みに上書きされていた。

作業直後に設定値が変わることと、運用中もその設定が維持されることは、別の話です。

設定確認は「今」だけで終わらせない

MTU設定後に ip link show eth0 で確認することは必要です。

しかし、それは「今そうなっている」ことを見ているだけです。

インフラ構築では、設定直後だけでなく、network再起動後、OS再起動後、AMI化・再作成後、DHCP更新後まで確認します。

• 設定直後にMTUが変わっているか

• network再起動後も維持されるか

• OS再起動後も維持されるか

• AMI化・再作成後も維持されるか

• DHCP更新後に戻らないか

この図で伝えたいのは、「今変わっているか」だけでなく、戻らないかまで見る必要がある、ということです。

このトラブルを防ぐための確認観点

1. ネットワーク設定の管理方式を確認する

対象OSでネットワーク設定を何が管理しているかを最初に確認します。

systemctl status NetworkManager
systemctl status network
ls -l /etc/sysconfig/network-scripts/
cat /etc/sysconfig/network-scripts/ifcfg-eth0

見るべきなのは、コマンドが使えるかどうかだけではありません。

そのサービスがOS起動時に使われているか。
対象インターフェースを管理しているか。
設定ファイルの内容と実際の状態が合っているか。

ここまで確認します。

2. 一時設定と永続設定を分ける

MTUは、一時的に変更するだけなら次のようなコマンドでも変更できます。

ip link set dev eth0 mtu 1600

しかし、これは基本的に一時的な変更です。

OS再起動後に維持されるかは別問題です。

一時設定で確認するのか。
永続設定として設計するのか。

ここを混同すると、構築時は動いていたのに、本番運用で戻るということが起きます。

3. DHCPやcloud-initによる上書きを確認する

クラウド環境では、OSが起動した後に、DHCPやcloud-initなどがネットワーク設定に関わることがあります。

そのため、設定ファイルに値を書いただけでは不十分な場合があります。

確認すべきことは、たとえば次のような点です。

• DHCPで取得した設定によりMTUが上書きされないか

• dhclient.conf で明示的な設定が必要か

• cloud-initが起動時にネットワーク設定を生成・変更していないか

• AMI化した後、別インスタンスで同じ設定が再現されるか

さらに対策として、手作業で変更した内容を、AMI作成手順、構築手順、構成管理、または自動構築の仕組みに反映しておく必要があります。

詳細設計と構築手順では「設定値」だけでなく「反映と確認」まで書く

詳細設計書に、

とだけ書いてあったとします。

設定値だけでは、構築する側は判断できません。
少なくとも次の情報が必要です。

対象OS：
  Amazon Linux 2

対象インターフェース：
  eth0

設定値：
  MTU=1600

設定箇所：
  /etc/sysconfig/network-scripts/ifcfg-eth0

DHCP設定：
  /etc/dhcp/dhclient.conf の更新要否を確認

反映方法：
  networkサービス再起動、またはOS再起動

確認方法：
  ip link show eth0
  ping疎通
  必要に応じてパケットサイズ指定で疎通確認

永続化確認：
  OS再起動後もMTU値が維持されること
  AMI化・再作成後もMTU値が維持されること
  DHCP更新後にMTU値が戻らないこと

これくらい書いて、ようやく構築・試験できる設計になります。

構築手順書に落とす場合も同じです。

手順書には、設定コマンドだけでなく、変更前確認、変更後確認、再起動後確認、必要に応じてAMI化・再作成後の確認まで含める必要があります。

たとえば、作業の流れとしては次のようになります。

1. 現在のMTU値を確認する
2. 対象インターフェースを確認する
3. ネットワーク設定の管理方式を確認する
4. 設定ファイルやDHCP設定を修正する
5. network再起動またはOS再起動で反映する
6. MTU値を確認する
7. OS再起動後に再確認する
8. 必要に応じてAMI化・再作成後に再確認する

試験項目では「今の設定値」だけを見ない

ip link show eth0 だけでは「今の状態」しか分かりません。
実務では次の観点まで確認します。

特にクラウド環境では、AMI化・再作成後の確認が重要です。

Auto Scalingや障害復旧で新しいインスタンスが起動したときに設定が戻るなら、構築時に確認できていても運用には耐えません。

レビューでは設定値ではなく、設定が残る仕組みを見る

MTU設定の設計書や手順書をレビューするなら、次のような観点で見ます。

• 対象OS・バージョン・対象インターフェースが明記されているか

• 設定箇所と反映方法が明記されているか

• NetworkManager前提か、network service前提かが明記されているか

• DHCP・cloud-initの影響を確認しているか

• OS再起動後の確認があるか

• AMI化・再作成後の確認があるか

「MTU=1600と書いてあるからOK」では、このトラブルは防げません。
設定値ではなく、設定が残る仕組みまで見ることがレビューのポイントです。

まとめ

今回のトラブルは、RHEL7とAmazon Linux 2でMTU設定方法が違っていた、という事例です。

ただし、学ぶべきことは「Amazon Linux 2ではこのファイルを編集する」という単純な話ではありません。

重要なのは、以下です。

• OSが変われば、設定の管理方式も変わる

• コマンドではなく、管理している仕組みを見る

• 設定直後だけでなく、再起動後・再作成後も確認する

• 詳細設計では、設定値だけでなく設定箇所・反映方法・確認方法まで書く

• クラウド環境では、AMI化・再作成後も同じ設定になるかを見る

コマンドを知っていること以上に、その設定がどの仕組みに管理され、再起動後も維持されるのかを確認できること。

この視点が、インフラ構築の品質を分けます。

関連記事

今回の記事で扱った「設定値だけでなく、設定箇所・反映方法・確認方法・永続化確認まで設計に落とす」という考え方は、以下の記事でも整理しています。

【前編】詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程

シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。

それでも通信できない。

そんなとき、原因は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が起動できること」と「起動後に業務通信が成立すること」は別問題だという点です。

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

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への移行が進んでいます。

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

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

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

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

特に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

さらに、User Dataを起動ごとに実行したい場合は、persist を有効にします。

<persist>true</persist>

これにより、インスタンス起動時にUser Dataの処理が繰り返し実行され、移動先環境に合わせたルート追加処理を走らせることができます。

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

タスクスケジューラ、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のルーティングテーブルが移動先環境に合っているかを見る

今回の原因は、AWSインフラ層ではなく、初期化エージェント層とOS設定層の間にありました。

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

この図で言いたいのは、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や起動時スクリプトは期待どおり実行されたか
・初期化処理のログにエラーは出ていないか

DRテストで見るべきなのは、インスタンスの起動成功ではありません。

業務として使える状態になったかどうかです。

ここを間違えると、テストでは成功したように見えても、本番障害時に通信できないサーバが立ち上がることになります。

まとめ

今回は、EC2を別AZで起動した際に、Windows Serverのルーティング情報が更新されず、通信できなくなった事象を扱いました。

原因は、AWS側のセキュリティグループやVPCルートテーブルではなく、OS内部のルート情報でした。

そして、その背景には、EC2Config、EC2Launch、EC2Launch v2といったクラウド初期化エージェントの挙動差がありました。

クラウドでは、サーバを起動するだけなら簡単です。

しかし、起動したサーバが業務として使える状態になっているかは、別の問題です。

若手SEは、EC2が起動したかどうかだけで安心してはいけません。

見るべきなのは、起動後に、どの設定が、どのタイミングで、どの仕組みによって反映されるのかです。

サーバは起動した。
でも通信できない。

その原因は、AWS側ではなく、OSの中にあるかもしれません。

関連記事

この考え方については、以下の記事でも整理しています。

【前編】詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程

シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。

たとえば、検証作業、メンテナンス、OS設定変更、ミドルウェア設定変更、不要時間帯の停止などです。

単体のEC2であれば、停止して、起動する。それだけです。

しかし、そのEC2がAuto Scaling Group配下のインスタンスだった場合、話は少し変わります。

Auto Scaling Groupは、単にEC2をまとめて管理する仕組みではありません。指定された台数を維持するために、インスタンスの状態を監視し、異常と判断した場合には新しいインスタンスに置き換える仕組みです。

ここで、現場で起こりがちな事故があります。

Auto Scaling対象のEC2を停止・起動したところ、意図せずインスタンスが再作成されてしまう。

作業者としては「既存のEC2を一時停止して、また起動しただけ」のつもりです。しかしAuto Scaling側から見ると「正常ではないインスタンスがいる。希望台数を維持する必要がある」という判断になることがあります。そして結果として新しいEC2が起動され、元のEC2が置き換えられてしまう。

これが、Auto Scaling配下のEC2停止・起動で起こる落とし穴です。

クラウドでも、過去の落とし穴が消えているとは限らない

実はこれ、かなり昔に経験した事象です。

Auto Scaling配下のEC2を停止・起動したところ、意図せずインスタンスが再作成されてしまった。

当時は、「そんな動きをするのか」と思いました。

ただ、クラウドサービスは日々進化します。

昔の事故事例を、今もそのまま起こる前提で語るのは危険です。

一方で、過去に起きた事故や落とし穴が、現在では完全に解消されているとも限りません。

特に、Auto Scaling、ヘルスチェック、自動復旧、フェイルオーバーのような仕組みは、クラウドサービスの基本的な設計思想に関わります。

そのため、昔の事例であっても、今の仕様ではどうなっているのかを確認することが大切です。

今回の事象も、現在のAWS公式ドキュメントで確認できます。

つまり、Auto Scaling Group配下のEC2を停止するという行為は、今でも単体EC2の停止とは意味が違います。

単体EC2なら、停止はただの停止です。

しかしAuto Scaling Group配下では「本来動いているべきインスタンスが、正常な状態ではない」と判断される可能性があります。

これはAWSのバグというより、Auto Scalingが希望台数を維持するための仕様です。

問題は、作業者の意図とAuto Scalingの判断がずれることです。

HealthCheckとReplaceUnhealthyの違い

Auto Scalingには複数の内部プロセスがあります。今回特に関係するのがHealthCheckとReplaceUnhealthyです。

HealthCheckはインスタンスの正常性を確認し、ReplaceUnhealthyは、異常と判断されたインスタンスを置き換えるプロセスです。

AWS公式ドキュメントでは、以下のとおり説明されています。

つまり、ReplaceUnhealthyを止めていたとしても、その間にインスタンスが異常扱いになっていると、再開した瞬間に置き換えが走る可能性があります。

作業者としては「作業が終わったから戻そう」という感覚です。しかしAuto Scaling側では「このインスタンスはすでに異常とマークされています。プロセスが再開されたので置き換えます」という動きになる可能性があります。だから、単にプロセスを戻すのではなく、戻す前の状態確認が必要になります。

「ヘルスチェック猶予期間があるから大丈夫」ではない

ヘルスチェック猶予期間は、新しく起動したインスタンスがInServiceになってから、Auto Scalingがヘルスチェックの評価を始めるまでの待ち時間です（AWS公式ドキュメント）。

これだけを見ると「猶予期間を長くしておけば安全では？」と思うかもしれません。しかしここに落とし穴があります。

ヘルスチェック猶予期間は、アプリケーションの起動待ちには役立ちます。しかし、Auto Scaling Group内のインスタンスを停止した場合に、それを安全に見逃してくれる仕組みではありません。ここを勘違いすると危険です。

どう対策すべきか

対策として重要なのは、EC2を起動した直後にAuto Scalingのヘルスチェックや置き換えプロセスを機械的に戻さないことです。

「EC2起動後、5分待ってからヘルスチェックを有効化する」という運用は実務上よく見ます。ただし、5分という数字そのものが本質ではありません。本質は「Auto Scalingが正常と判断できる状態になってから戻す」ことです。

戻す前に確認すべきことは次のとおりです。

• EC2のステータスチェックが正常であること

• OSが正常に起動していること

• ミドルウェアが起動していること

• アプリケーションが正常応答していること

• ELBまたはターゲットグループでHealthyになっていること

• Auto Scaling Activityに異常な置き換え履歴がないこと

手順書には「起動後5分待つ」だけでなく、「何を確認できたら次の操作に進んでよいのか」を書く必要があります。

事前にどうチェックすべきか

このような事象を防ぐために、作業前に確認すべき点は大きく4つあります。

1. 対象EC2がAuto Scaling Group配下か確認する

EC2一覧だけを見ていると、普通のEC2に見えます。しかしタグやAuto Scaling Group名を見ると、ASG管理対象であることがあります。少なくとも以下を確認してください。

• 対象EC2はAuto Scaling Group配下か

• Desired Capacityはいくつか

• 対象インスタンスを停止した場合、希望台数維持のために補充されるか

• 再作成された場合、元の状態を再現できるか

特に危険なのは、手作業で設定変更されたEC2がAuto Scalingで再作成されるケースです。再作成されたEC2は起動テンプレートやAMIに基づいて作られるため、手作業で入れた設定が消える可能性があります。

2. どのAuto Scalingプロセスを止めるべきか確認する

HealthCheckとReplaceUnhealthyは意味が違います。状況に応じて、どちらを止めるのか、Standbyを使うのかを判断する必要があります。スケジュールスケーリングやスケーリングポリシーの影響も確認してください。

• プロセスの一時停止・再開：（AWS公式ドキュメント）

• Standby機能：（AWS公式ドキュメント）

3. ヘルスチェック猶予期間と起動時間を確認する

EC2起動からステータスチェック正常化まで何分かかるか、アプリケーションが正常応答するまで何分かかるか、ELBがHealthyになるまで何分かかるか。これらがヘルスチェック猶予期間と整合しているかを確認してください。

4. 手順書に「戻し条件」を書く

運用手順書でよくあるのは、操作手順は書いてあるが戻し条件が曖昧なケースです。「EC2起動後、Auto Scalingのヘルスチェックを有効化する」だけでは危険です。上で挙げた確認項目をすべて満たしたことを確認してから戻す、と明記する必要があります。

運用手順で大事なのは操作そのものではありません。次の操作に進んでよい条件を明確にすることです。

これは運用設計の問題である

今回の話は、AWSのAuto Scalingという個別サービスの話に見えます。しかし実際には運用設計の問題です。

Auto Scalingを使うなら、設計時点で少なくとも以下を決めておく必要があります。

• インスタンスを手動停止してよいのか

• メンテナンス時はStandbyに入れるのか

• HealthCheckやReplaceUnhealthyを一時停止するのか

• どの条件を満たしたらAuto Scalingのプロセスを戻してよいのか

• 再作成された場合、設定やデータは失われないのか

• 手作業で変更した内容はAMI、起動テンプレート、IaCに反映されているのか

これらは、運用当日に作業者がその場で判断するものではありません。設計書、運用設計書、作業手順書、チェックリストに落としておくべき内容です。

クラウドでは、ひとつの操作に対して裏側で複数の自動化機能が反応します。作業対象のサーバだけを見ていると危険です。周辺にある自動制御の仕組みまで含めて、作業手順を考える必要があります。

これはバックアップ保存期限の設計と同じ構図です。「5日保存」と書いてあっても5営業日分なのか5世代なのかを確認しないと復旧時に認識違いが起きます。Auto Scalingも同様で、「EC2を停止・起動する」とだけ書くのではなく、その操作に対してAuto Scaling、ELB、CloudWatchがどう反応するのかまで設計しておく必要があります。

設計で決めるべきことを曖昧にしたまま運用に渡すと、作業時に現場が迷います。Auto Scalingの事故は、そのことを教えてくれる典型例です。

まとめ

Auto Scaling対象のEC2を停止・起動する場合、単体EC2と同じ感覚で作業してはいけません。

停止中にUnhealthyとマークされ、起動直後にプロセスを戻した瞬間に置き換えが走る。ヘルスチェック猶予期間を長くしても、それは防げない。「起動後5分待つ」は暫定ルールであって、設計ではない。

本質は、Auto Scalingが正常と判断できる状態になってから戻すことです。そしてその判断基準を、設計時点で手順書に落としておくことです。

クラウドの自動化は便利です。しかし、作業者の意図までは読んでくれません。だからこそ、設計では正常時の構成だけでなく、メンテナンス時・障害時・復旧時にシステムがどう振る舞うかまで考える必要があります。

この考え方については、以下の記事でも整理しています。

【前編】詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程

シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。

クラウドリフトでは、既存サーバをAMI化し、そこからEC2を作成することがあります。

オンプレミスのサーバ更改でいえば、既存環境を複製して、新しい環境で起動するようなイメージです。

一見すると、とても便利です。

OS、ミドルウェア、設定ファイル、アプリケーション、ディレクトリ構成などを、元の環境に近い状態で再現できます。

そのため、クラウド移行では、

と思いがちです。

しかし、ここに落とし穴があります。

EC2は起動できる。
EBSボリュームも作成できる。
別のEC2へアタッチもできる。

それなのに、OS上で期待どおりにマウントできないことがあります。

今回扱うのは、AMIコピーやスナップショットから復元したEBSを、既存EC2にアタッチしてデータ復旧しようとしたときに起きたトラブルです。

何が起きたのか

過去のAMIバックアップからデータを復旧したい場面がありました。

やろうとしたことは、よくある復旧作業です。

1. 過去のAMIまたはスナップショットからEBSを復元する

2. 復元したEBSを既存のEC2にアタッチする

3. OS上でマウントする

4. 必要なファイルを取り出す

クラウド環境では、障害調査や復旧作業でよく出てくる手順です。

EBSはAWS上では問題なく作成できました。
既存EC2へのアタッチもできました。
OS上でもディスクとして見えていました。

ところが、いざマウントしようとすると失敗しました。

たとえば、以下のようにデバイスを直接指定してマウントしようとします。

mount /dev/xvdf2 /mnt

すると、次のようなエラーになります。

mount: /mnt: unknown filesystem type 'LVM2_member'

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

OSから見ると、/dev/xvdf2 はそのままマウントできるXFSやext系のファイルシステムではありませんでした。

LVM2_member として認識されています。

つまり、直接マウントしようとしていた対象は、ファイルシステムそのものではなく、LVMの物理ボリュームとして扱われる領域だったということです。

原因は「EBSが壊れていた」ではない

この手のエラーを見ると、最初はこう考えがちです。

EBSの復元に失敗したのではないか。
スナップショットが壊れているのではないか。
デバイス名を間違えたのではないか。

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

しかし今回の本質は、EBSそのものが壊れていたことではありません。

原因は二つあります。

一つ目は、直接マウントしようとした対象が LVM2_member だったことです。

二つ目は、同じAMIを元にしたインスタンス同士で、ディスクやボリューム管理情報の識別子が競合したことです。

AMIからEC2を作ると、OSの中身も含めて複製されます。

ファイルシステムのUUID、LVMのボリューム情報、/etc/fstab の記述、デバイス構成の前提なども、元の環境を引き継ぎます。

そのため、同じAMIを元にしたEC2に、同じ系統のAMIやスナップショットから復元したEBSをアタッチすると、OSから見た識別情報が競合することがあります。

作業者としては、

です。

しかしOS側から見ると、同じような識別情報を持つボリュームが複数見えている状態になります。

AWS上ではEBSがアタッチできていても、OS上で安全にマウントできるとは限りません。

ここを取り違えると、復旧作業で詰まります。

これはAWSの不具合というより、Linuxのディスク管理、UUID、LVM、fstab の仕組みに基づく動作です。

EBSはクラウド上のブロックストレージですが、最終的にそれをどう認識し、どうマウントするかはOS側の話になります。

なぜ LVM2_member になるのか

Linuxでは、ディスク上に直接ファイルシステムが作られている場合もあれば、LVMを使ってボリューム管理している場合もあります。

単純な構成であれば、パーティションにXFSなどのファイルシステムがあり、そのパーティションを直接マウントできます。

一方、LVMを使っている場合、物理ディスクやパーティションは、まずLVMの物理ボリュームとして扱われます。

その上にボリュームグループがあり、さらに論理ボリュームが作られ、その論理ボリューム上にファイルシステムがあります。

つまり、LVM構成では、次のような階層になります。

この場合、LVMの物理ボリュームを直接 mount しても、ファイルシステムとして認識できません。

そのため、

unknown filesystem type 'LVM2_member'

となります。

これは、OSが対象を見失っているというより、

という意味に近いです。

たとえば、blkid で見ると、対象パーティションが次のように見えることがあります。

blkid /dev/xvdf2

/dev/xvdf2: UUID="xxxxx" TYPE="LVM2_member"

この状態で /dev/xvdf2 を直接 mount しても、XFSやext系のファイルシステムとしては扱えません。

UUIDの競合も見落としやすい

もう一つ重要なのがUUIDです。

Linuxでは、ディスクやパーティションを /dev/xvdf、/dev/xvdf1、/dev/nvme1n1p1 のようなデバイス名で扱うことがあります。

しかし、クラウド環境ではデバイス名だけを信じると危険です。

AWSコンソール上で指定したデバイス名と、OS上で見えるデバイス名が直感どおり一致しないことがあります。

さらに、AMIやスナップショットから復元したボリュームでは、ファイルシステムUUIDやLVM関連の識別情報が元の環境と同じまま残ることがあります。

そのため、同じAMI由来のボリュームを同じ系統のEC2にアタッチすると、UUIDやボリューム管理情報が競合し、どのボリュームをマウントすべきかが分かりにくくなります。

ここで必要なのは、勘でデバイス名を指定することではありません。

OSが実際にどう認識しているかを確認することです。

たとえば、以下のようなコマンドで確認します。

lsblk
blkid
ls -l /dev/disk/by-uuid

これらを使って、次の情報を確認します。

• どのデバイスが追加ボリュームなのか

• どのパーティションにファイルシステムがあるのか

• LVM2_member として見えているのか

• どのUUIDがどのデバイスに対応しているのか

• 既存ボリュームと識別情報が競合していないか

どう対処したのか

今回の対処の核心は、同じAMI由来ではない作業用EC2を用意し、そこに復元EBSをアタッチしてマウントするという点です。

狙いは、同じAMI由来のOSボリュームと復元ボリュームを同じEC2上に同居させることで起きる、UUIDやLVM関連の識別情報の競合を避けることです。

ここでいう「別のEC2を用意する」とは、LVM2_member が自動的にマウントできるようになる、という意味ではありません。

そのうえで、OS上で lsblk、blkid、/dev/disk/by-uuid を確認し、どの領域が直接マウントできるファイルシステムなのか、どの領域が LVM2_member なのかを切り分けました。

LVM構成を維持したまま確認したい場合は、pvscan、vgscan、vgchange -ay でボリュームグループを有効化する方法や、複製されたLVMボリュームを別物として扱う vgimportclone を使う方法もあります。

また、既存EC2上で対応せざるを得ない場合は、mount -o nouuid で一時的に参照する方法もあります。

ただし、これらは環境と目的によって適否が分かれます。

今回は復旧対象のファイルを一時的に安全に取り出すことが目的だったため、作業用EC2を用意し、UUIDで対処する方針を採りました。

具体的な手順は以下のとおりです。

まず、/dev/disk/by-uuid でUUIDとデバイスの対応を確認します。

ls -l /dev/disk/by-uuid

たとえば、以下のように表示されます。

lrwxrwxrwx. 1 root root 11 Feb 16 07:47 1c5999b9-594d-40aa-84d2-167a92a977c5 -> ../../xvdf1
lrwxrwxrwx. 1 root root 11 Feb 16 07:46 949779ce-46aa-434e-8eb0-852514a5d69e -> ../../xvda2

この例では、xvdf1 がアタッチした復元ボリューム、xvda2 が既存のルートボリュームとして見えています。

次に、/etc/fstab にマウント先を追記します。

# fstab.new（変更後）
UUID=949779ce-46aa-434e-8eb0-852514a5d69e /      xfs  defaults  0 0
UUID=1c5999b9-594d-40aa-84d2-167a92a977c5 /mnt   xfs  defaults  1 1

そのうえで、マウントを実行します。

mount -a

最後に、マウント先の中身を確認して、意図したボリュームであることを確認します。

cat /mnt/etc/hostname

この確認により、単にマウントできたかどうかだけでなく、本当に目的のボリュームを参照できているかを確認できます。

クラウドリフトでは「コピーできた」と「運用できる」は違う

クラウドリフトでよくある誤解があります。

AMIを作れた。
EC2が起動した。
EBSもアタッチできた。
だから移行できている。

もちろん、これらは重要です。

しかし、それだけでは十分ではありません。

本当に確認すべきなのは、移行後に必要な運用作業ができるかです。

たとえば、障害時に旧ボリュームを別EC2にアタッチして中身を確認できるか。
/etc/fstab の記述は移行後の構成に合っているか。
デバイス名だけに依存せず、UUIDで対象を識別できるか。
LVM構成なら、LVMとして認識・有効化できるか。

こうした確認が抜けると、本番障害時に困ります。

通常時は問題なく動いているように見えても、いざ障害調査や復旧作業をしようとしたときに、

となります。

クラウドリフトでは、このような運用時の確認観点が後回しになりがちです。

事前にどうチェックすべきだったのか

チェックリストとして最小限に絞るなら、見るべきポイントは次の4つです。

1. OSのディスク構成を確認する

ルートボリュームはどれか。
追加ボリュームはどれか。
パーティション構成はどうなっているか。
ファイルシステムは何か。
LVMを使っているか。
UUIDは何か。
/etc/fstab はどう書かれているか。

クラウドリフトでは、EC2を起動できるかだけでなく、移行後のOS内部構成まで確認する必要があります。

2. LVM構成か、直接マウント可能なファイルシステムかを確認する

lsblk や blkid で、対象がXFSなどのファイルシステムなのか、LVM2_member なのかを確認します。

LVM2_member であれば、直接 mount する対象ではありません。

LVMとして認識させるのか、UUIDでマウント対象を指定するのかを、OS構成に応じて判断する必要があります。

3. UUIDの対応を確認する

/dev/disk/by-uuid を確認し、どのUUIDがどのデバイスを指しているかを確認します。

同じAMI由来のボリュームを扱う場合は、UUIDやボリューム管理情報の競合に注意します。

デバイス名だけで判断せず、UUID、ファイルシステム、マウント先の対応を確認します。

4. 復旧手順として事前に試す

設計書や手順書に「EBSをアタッチしてマウントする」と書いてあっても、本当にできるとは限りません。

別EC2にEBSをアタッチする。
OS上でデバイスを確認する。
UUIDを確認する。
必要に応じてLVM構成を確認する。
マウントして中身を確認する。
作業後にアンマウントする。

ここまで一度試しておくべきです。

復旧手順は、障害が起きてから初めて実行するものではありません。

これは詳細設計・運用設計の問題である

今回の話は、EBSをマウントできなかったという作業トラブルに見えます。

しかし、本質は詳細設計・運用設計の問題です。

クラウドリフトでAMIやEBSを扱うなら、設計時点で少なくとも以下を決めておく必要があります。

• 移行後のEBS構成

• OS上のデバイス認識

• LVMを使っているかどうか

• ルートボリュームと追加ボリュームの識別方法

• UUIDの確認方法

• /etc/fstab の記述方針

• 障害時に別EC2へアタッチして確認する手順

• マウント確認後に何を見て正常と判断するか

これらは、運用当日に作業者が感覚で判断するものではありません。

設計書、運用設計書、作業手順書、復旧手順書に落としておくべき内容です。

特に、構築担当者と運用担当者が分かれているプロジェクトでは、この問題が起きやすくなります。

構築担当者は、「AMIからEC2は起動した」「EBSも作成できた」と考える。

一方、運用担当者は障害時に、「復元したEBSをどのEC2にアタッチし、どのUUIDを見て、どのディレクトリにマウントし、何を確認すればよいのか」で迷う。

この間を埋めるのが、詳細設計と運用設計です。

「EC2が起動した」ことと、「運用できる」ことは違います。

「EBSがアタッチされた」ことと、「安全にマウントできる」ことも違います。

この違いを設計で潰しておくことが重要です。

まとめ

AMIコピーやスナップショット復元で作成したEBSは、AWS上でアタッチできていても、OS上でそのまま期待どおりにマウントできるとは限りません。

今回の事象では、直接マウントしようとした対象が LVM2_member であり、さらに同じAMI由来のボリューム識別情報が競合していたことが問題でした。

対処の核心は、同じAMI由来ではない作業用EC2を用意して、そこに復元EBSをアタッチすることです。

そのうえで、/dev/disk/by-uuid を確認し、実際にマウント対象となるファイルシステムのUUIDを指定してマウントしました。

作業前には、lsblk、blkid、/dev/disk/by-uuid で、OSが対象ボリュームをどう認識しているかを必ず確認します。

デバイス名だけで判断せず、UUID、ファイルシステム、マウント先の対応を確認してから作業に入ることが重要です。

クラウドリフトで本当に大事なのは、サーバをクラウド上で起動することだけではありません。

移行後に、調査できること。
復旧できること。
運用できること。

ここまで確認して初めて、クラウドリフトは現場で使えるものになります。

関連記事

この考え方については、以下の記事でも整理しています。

【前編】詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程

シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。

ネットワークは到達している。
OSも起動している。
sshd も動いているように見える。

それでも入れない。

原因は、/etc/ssh/sshd_config そのものではなく、起動時に動作する cloud-init 側の設定でした。

今回の記事で伝えたいのは、パスワード認証の是非ではありません。

クラウド環境では、OSの設定ファイルだけを見ても、起動後の状態を正しく判断できないことがある。

ここがポイントです。

事象：AMIから起動したらSSHパスワードログインできない

あるRHEL系のEC2環境で、SSHのパスワードログインを有効にした状態でAMIを作成しました。

元のEC2インスタンスでは、SSHのパスワード認証が有効になっていました。

そのため、AMIから新しいEC2インスタンスを起動しても、当然同じようにSSHログインできるだろうと考えていました。

ところが、実際にAMIからインスタンスを起動すると、SSHのパスワードログインができません。

OSは起動している。
インスタンスのステータスチェックも通っている。
ネットワーク的にも到達できている。
でも、SSHのパスワード認証が通らない。

この状態になると、非常に困ります。

障害調査をしたい。
ログを見たい。
設定を戻したい。
サービスを再起動したい。

そう思っても、そもそもサーバに入れなければ作業できません。

SSHログイン不可は、単なる接続ミスではありません。
復旧作業の入口を塞いでしまう、かなり重いトラブルです。

最初に疑いたくなるポイント

SSHログインできない場合、まず疑うのは、だいたい次のような箇所です。

• セキュリティグループ

• ネットワークACL

• ルートテーブル

• 鍵の指定ミス

• ユーザー名の誤り

• /etc/ssh/sshd_config の設定

• sshd サービスの状態

• OS側のファイアウォール

もちろん、これらを確認すること自体は正しいです。

SSH接続不可の調査では、ネットワーク、認証、OS設定、サービス状態を順番に切り分ける必要があります。

ただ、今回の事象では、単純に /etc/ssh/sshd_config だけを見ていても原因にたどり着きにくいものでした。

なぜなら、SSHの設定を起動時に別の仕組みが変更していた可能性があるからです。

原因：cloud-initがSSH設定を上書きしていた

原因は、cloud-init の設定でした。

cloud-init は、クラウド環境でインスタンス起動時に初期設定を行う仕組みです。

EC2でLinuxインスタンスを起動するとき、ホスト名、ユーザー、SSH関連設定、ユーザーデータなど、起動時にさまざまな初期処理が行われます。

今回問題になったのは、次の設定です。

/etc/cloud/cloud.cfg

ssh_pwauth: 0

この `ssh_pwauth: 0` は、SSHのパスワード認証を無効にするための設定です。

クラウド環境では、パスワード認証よりも鍵認証、IAM、SSM Session Managerなどで接続経路を管理する方が、セキュリティ上のベストプラクティスに沿いやすいため、このような初期設定になっていることがあります。

問題は、その設定自体ではありません。

運用上の理由でパスワード認証を使う設計にしている場合、`cloud-init` 側の設定を理解していないと、AMIから起動したときに想定外のログイン不可につながる、という点です。

この状態でAMIからインスタンスを起動すると、起動時に cloud-init が動作し、SSHの設定を反映することがあります。

その結果、/etc/ssh/sshd_config が次のような状態になる場合があります。

/etc/ssh/sshd_config

PasswordAuthentication no

つまり、AMI取得前に手作業で /etc/ssh/sshd_config を変更していたとしても、AMIから起動したタイミングで cloud-init 側の設定が再度反映されることがあります。

ここが落とし穴です。

AMIから新しいEC2インスタンスを作成した場合、cloud-init はそれを新しいインスタンスの初回起動として扱い、初期設定を再実行することがあります。

そのため、

元サーバではログインできていた

ことと、

AMIから起動した新インスタンスでも同じようにログインできる

ことは、必ずしも同じではありません。

クラウド環境では、ここを混同するとトラブルにつながります。

図で見るとこういう流れ

この事象を図で整理すると、流れはこうです。

• AMI取得前は、sshd_config 上ではパスワード認証が有効

• しかし、cloud.cfg には ssh_pwauth: 0 が残っている

• AMIから新しいインスタンスを起動すると、cloud-init が実行されることがある

• cloud-init が設定を反映し、sshd_config が書き換えられることがある

• 結果として、PasswordAuthentication no になり、SSHパスワードログインできなくなる

見るべきポイントは、

今のsshd_configがどうなっているか

だけではありません。

起動時に誰がsshd_configを書き換える可能性があるか

まで見る必要があります。

クラウド環境では、ある時点の設定ファイルだけを見ても不十分です。

その設定が、いつ、誰によって、どのタイミングで反映されるのか。

ここまで見ないと、起動後の状態を正しく予測できません。

対策：cloud-init側の設定も確認する

対策は、/etc/ssh/sshd_config だけではなく、cloud-init 側の設定も確認することです。

今回の例では、SSHパスワード認証を有効にする必要がある場合、次のように設定します。

ssh_pwauth: 1

これにより、AMIからインスタンスを起動した際に、SSHパスワード認証を有効にする設定として扱われます。

結果として、/etc/ssh/sshd_config 側も次のようになります。

PasswordAuthentication yes

ただし、新しめのRHEL系OSや最近のAMIでは、/etc/cloud/cloud.cfg 本体を直接編集するよりも、

追加設定ファイルとして管理する方が望ましい場合があります。

たとえば、次のようなファイルです。

/etc/cloud/cloud.cfg.d/99_custom_ssh.cfg

中身は、たとえば次のようにします。

ssh_pwauth: 1

cloud.cfg 本体は基本設定として残し、環境ごとの差分や個別設定は cloud.cfg.d 配下のファイルで管理する、という考え方です。

ただし、どの方法を使うべきかは、利用しているOS、AMI、cloud-init のバージョン、運用ルールによって変わります。

重要なのは、見えている設定だけを直すことではありません。

それを後から上書きする仕組みが残っていないかを見ることです。

起動後に確認するコマンド例

実際のトラブルシューティングでは、

「起動後に本当に sshd_config がどうなっているのか」
「cloud-init が動いていた形跡はあるのか」

を確認したくなります。

まず、起動後のSSH設定は、次のように確認できます。

grep -i '^PasswordAuthentication' /etc/ssh/sshd_config

パスワード認証が有効であれば、次のように表示されます。

PasswordAuthentication yes

逆に、意図せず無効化されている場合は、次のようになります。

PasswordAuthentication no

また、cloud-init が起動時に動作していたかを確認するには、ログを見る方法があります。

sudo grep -i 'ssh\|pwauth\|PasswordAuthentication' /var/log/cloud-init.log

ただし、ログの出方は、OS、AMI、cloud-init のバージョンによって異なります。

このコマンドで必ず原因が一発で分かる、というものではありません。

重要なのは、起動後の /etc/ssh/sshd_config だけでなく、起動時に cloud-init が何を実行したのかも確認することです。

RHEL 8/9/10でも考え方は同じ

ここまでの話は、特定の古いRHEL環境だけの話ではありません。

RHEL 8、RHEL 9、RHEL 10などのRHEL系OSでも、cloud-init がインスタンス起動時の初期設定に関与するという考え方は同じです。

そのため、AMIから新しいインスタンスを起動したときに、cloud-init の設定に基づいてSSH関連設定が反映される可能性があります。

ただし、OSバージョン、AMIの提供元、cloud-init のバージョンによって、デフォルト値や設定ファイルの構成は異なります。

つまり、見るべきポイントは、RHELのバージョン名だけではありません。

• cloud-init が何を管理しているか

• cloud.cfg や cloud.cfg.d に何が書かれているか

• AMIから新規起動したときに何が再実行されるか

• sshd_config が最終的にどうなっているか

• SSHログインできなくなった場合の復旧経路があるか

最新版でも見るべき本質は変わりません。

「SSH設定ファイルを直したから終わり」ではなく、起動時にその設定を上書きする仕組みが残っていないかを見る。

これが重要です。

もし実際に入れなくなったら

実際にSSHログインできなくなった場合でも、環境によっては救出手段が残っていることがあります。

たとえば、EC2 Instance Connectが利用できる条件であれば、別経路で接続できる可能性があります。

また、SSM Agentが動作しており、必要なIAMロールやネットワーク経路が用意されている場合は、SSM Session Managerから接続できる可能性があります。

さらに、NitroベースのインスタンスでEC2シリアルコンソールが有効化されていれば、ネットワーク経由のSSHに依存せずにトラブルシュートできる場合もあります。

ただし、これらは万能ではありません。

事前の有効化、IAM権限、対応OS、インスタンスタイプ、ネットワーク条件、SSM Agentの状態などに左右されます。

障害が起きてから初めて使おうとしても、すぐに使えるとは限りません。

最低限、AMIを作成する前に、EC2 Instance ConnectやSSM Session Managerなど、SSH以外の接続経路が使える状態かを確認しておくことが、現実的な保険になります。

「入れなくなったら考える」では遅い場合があります。

ただし、パスワード認証を推奨する話ではない

ここで誤解してはいけないのは、この記事はSSHのパスワード認証を推奨する話ではない、ということです。

本番環境では、SSH接続方式は慎重に設計すべきです。

鍵認証を使うのか。
踏み台サーバを経由するのか。
SSM Session Managerを使うのか。
IAMやMFAと組み合わせるのか。
運用者のアクセス経路をどう制限するのか。
障害時の緊急ログイン手段をどうするのか。

これらは、セキュリティ要件や運用要件に応じて決めるべきものです。

今回伝えたいのは、

パスワード認証を有効にしましょう

という話ではありません。

そうではなく、

AMIから起動したとき、OS設定がそのまま維持されるとは限らない

という話です。

もっと言えば、

起動時に設定を書き換える仕組みを知らないと、
設計したつもりの状態でサーバが起動しない

という話です。

まとめ

今回の事象は、RHEL系のEC2環境でAMIからインスタンスを起動した際、SSHのパスワードログインができなくなったというものです。

原因は、cloud-init 側にSSHパスワード認証を無効化する設定が残っていたことでした。

ssh_pwauth: 0

この設定により、AMI起動時に cloud-init がSSH設定を反映し、PasswordAuthentication no になることがあります。

対策としては、必要に応じて cloud.cfg または cloud.cfg.d 配下の設定を確認し、SSHパスワード認証をどう扱うかを明示します。

ssh_pwauth: 1

そして、起動後の sshd_config が期待どおりになっているか確認します。

PasswordAuthentication yes

ただし、重要なのはパスワード認証を有効にすることではありません。

本質は、クラウド環境では、OSの設定ファイルだけを見ても不十分だということです。

AMI、cloud-init、ユーザーデータ、Launch Template、Auto Scaling、構成管理ツール、起動後スクリプト。
こうした仕組みが、サーバ起動時や再作成時に設定を書き換えることがあります。

AMIを使う設計では、最低限、次の観点を確認しておくべきです。

• cloud.cfg や cloud.cfg.d にSSH関連設定が残っていないか

• AMI起動後に cloud-init が何を実行するか把握しているか

• 起動後に sshd_config が期待値になっているか確認したか

• SSHログインできなくなった場合の復旧経路があるか

「設定したはずなのに、なぜか反映されていない」。

そういう事象に当たったとき、OSの設定ファイルだけでなく、起動時に何が動いているかを問う習慣が、現場での対応速度を変えます。

これは、基盤SEやインフラエンジニアだけでなく、クラウド上で動くシステムに関わるアプリケーションエンジニアにとっても大事な視点だと思います。

関連記事

今回の話は、単なるSSH設定の話ではなく、詳細設計・運用設計で「起動時に何が反映されるか」を見落とさない、という話でもあります。

この考え方については、以下の記事でも整理しています。

【前編】詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程

シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。

「設定は合っているはずなのに、取れない」

権限設定もした。
バケットも見える。
テストも通った。

それなのに、本番で特定のファイルだけ取得できない。

こういう問題は、AWSの仕様を知らないというより、誰が作ったオブジェクトなのかまで設計・テストしていなかったことで起きます。

今回は、S3のクロスアカウント構成で実際に起きた事象をもとに、単なる技術論ではなく、設計とテスト観点の話として整理します。

AWSでS3を使っていると、ついこう考えてしまいます。

「S3バケットへの権限を付ければ、その中のオブジェクトも操作できるはず」

しかし、クロスアカウント構成では、この前提が崩れることがあります。

バケットは見える。
オブジェクトも存在する。
ユーザーがアップロードしたファイルは取得できる。

それなのに、AWSサービスが出力したオブジェクトだけ取得できない。

一見すると、IAMポリシーの設定ミスに見えます。
しかし、原因は単純な権限不足ではありませんでした。

今回の本質は、S3の操作権限だけではなく、オブジェクトの所有者まで設計・テストしていたかという話です。

バケットにはあるのに、なぜか取得できなかった

構成としては、アカウントAから、アカウントBのS3バケットにあるオブジェクトを取得する必要がありました。

アカウントBにS3バケットがあり、そこに複数のオブジェクトが存在していました。

その中には、ユーザーが手動でアップロードしたオブジェクトもあれば、AWSサービスが出力したオブジェクトもありました。

たとえば、S3アクセスログやCloudTrailログのように、AWSサービス側の処理によってS3へ出力されるファイルです。

また、AWSサービスではなくても、別アカウントのEC2やバッチ処理がS3へ書き込む構成では、同じように「誰が作成したオブジェクトなのか」が問題になることがあります。

現象としては、次のような状態でした。

ユーザーがアップロードしたオブジェクトは取得できる。
しかし、AWSサービスが出力したオブジェクトは取得できない。

CLIであれば、AccessDeniedや403 Forbiddenのようなエラーとして見えることがあります。

ただし、このエラーだけを見ても、IAMポリシー不足なのか、バケットポリシーなのか、オブジェクト所有者なのかはすぐには分かりません。

同じS3バケット内にあるにもかかわらず、取得できるものと取得できないものが混在していたのです。

この時点で、単純な「バケットに対する権限不足」とは言い切れません。

もしバケットそのものへのアクセス権限が不足しているのであれば、ユーザーがアップロードしたオブジェクトも取得できないはずです。

しかし実際には、一部のオブジェクトは取得できていました。

つまり、問題はバケット単位ではなく、オブジェクト単位の条件差にありました。

見落としていたのは、バケットではなくオブジェクトの所有者だった

原因は、オブジェクトの所有者が異なっていたことです。

S3では、バケットの所有者と、オブジェクトの所有者が常に同じとは限りません。

特にクロスアカウント構成や、AWSサービスがS3に出力する構成では、この点を意識する必要があります。

昔のS3では、ACLによってバケットやオブジェクト単位の権限を細かく制御する考え方が使われていました。その名残がある既存環境では、現在の新規バケットとは異なる前提で動いていることがあります。

今回の場合、ユーザーがアップロードしたオブジェクトは、想定していた権限設計の範囲で操作できました。

一方、AWSサービスが出力したオブジェクトは、所有者や権限の扱いが異なっていました。

AWSサービスがS3にオブジェクトを出力する場合、利用者が手動でアップロードしたファイルと同じ所有者・同じ権限になるとは限りません。

バケットのObject Ownership設定、ACLの扱い、サービス側の出力仕様によって、バケット所有者がそのまま自由に操作できるとは限らない状態が発生します。

そのため、アカウントAからアカウントBのS3バケットに対する操作を許可していても、対象オブジェクトによっては取得できない状態になっていました。

ここで重要なのは、次の点です。

「S3バケットにある」ことと「そのオブジェクトを操作できる」ことは同じではない。

S3をファイルサーバーのように見ていると、この違いを見落とします。

ディレクトリの中にファイルがある。
だから、フォルダに権限を付ければ中のファイルも読める。

オンプレのファイルサーバー感覚では、こう考えがちです。

しかし、S3ではこの前提がそのまま通用しません。

今回の直接原因は「オブジェクト所有者」でしたが、そもそもS3の権限設計は単一の概念では完結しません。

S3では、バケット、オブジェクト、オブジェクト所有者、バケットポリシー、IAMロール、ACL、Object Ownershipなど、複数の要素が絡みます。

現在のAWSでは、S3 Object OwnershipのBucket owner enforcedを使い、ACLを無効化して、バケットポリシーやIAMポリシーで制御する設計が基本です。新規バケットではBucket owner enforcedがデフォルトになっています。

ただし、既存環境や移行案件では、過去に作成されたバケット、既存アプリケーション、ACL前提の処理、サービス出力、外部連携が残っていることがあります。

そのため、「今のAWSではデフォルトがこうだから、この問題は起きない」とは言い切れません。

既存環境では、今回のようにオブジェクト所有者やACLの考え方が残っていて、運用時に問題として表面化することがあります。

このように、S3では「バケットに権限を付けたから終わり」ではありません。

誰がバケットを持っているのか。
誰がオブジェクトを作ったのか。
そのオブジェクトの所有者は誰なのか。
どのアカウント、どのIAMロールで操作するのか。

ここまで整理しないと、実際の運用で詰まります。

誰に権限を付けるかではなく、誰として操作するかを決めた

今回の対策を考えるうえで、最初に整理すべきだったのは、単に「誰にS3権限を付けるか」ではありません。

見るべき観点は、次のようなものでした。

• 誰がバケットを所有しているのか。
• 誰がオブジェクトを作成するのか。
• 作成されたオブジェクトの所有者は誰になるのか。
• そのオブジェクトを誰が読むのか。
• 読む主体はユーザーなのか、IAMロールなのか、別アカウントのサービスなのか。
• 対象はユーザーがアップロードしたファイルだけなのか、AWSサービスが出力したファイルも含むのか。

ここまで整理して初めて、対策の方向性が決まります。

現在のAWS設計として優先すべき方向は、S3 Object OwnershipをBucket owner enforcedにし、ACLを無効化して、バケット所有者に所有権を寄せることです。

新規プロジェクトであれば、基本的にはこの設計を第一候補にすべきです。

この設計にできれば、オブジェクトごとのACL差分や所有者差分による混乱を減らせます。

ただし、現場では理想形にすぐ寄せられないことがあります。

• 既存アプリケーションがACLを前提にしている。
• 外部サービスや既存ジョブの出力仕様が変えられない。
• 過去に作成されたオブジェクトが大量にある。
• 設定変更による影響範囲をすぐに確認できない。
• 監査ログや運用ログの保管先としてすでに使われている。

こうした制約がある場合、いきなりBucket owner enforcedへ変更するのではなく、影響調査と段階的な移行が必要になります。

今回も、根本的な方向性としてはBucket owner enforcedへの移行を検討すべき構成でした。

ただし、既存環境では、すぐに設定変更できない事情がありました。

そこで今回は、まず権限の使い方を整理する現実的な対策として、アカウントB側のIAMロールにスイッチして操作する方式を採用しました。

いきなり理想形へ変更できないのであれば、まずは現在の権限設計のどこが曖昧だったのかを整理する必要があります。

今回の改善前の考え方は、こうでした。

「アカウントAに、アカウントBのS3バケットを操作する権限を与える」

一見、正しそうに見えます。

しかし、この考え方では、バケットに対する権限を中心に見ています。

改善後は、考え方を変えました。

「アカウントB側にIAMロールを作成し、アカウントAからそのロールにスイッチして、S3操作を行う」

つまり、バケットが存在するアカウント側の権限設計に寄せました。

これにより、アカウントAから直接アカウントBのS3を操作するのではなく、アカウントB側のロールとして操作する形にします。

対策としては、次のいずれかを明確に決める必要があります。

• アカウントB側のIAMロールにスイッチして操作するのか。
• S3 Object Ownershipを見直して、バケット所有者に所有権を寄せるのか。
• サービス出力時の権限付与方式を見直すのか。
• 既存オブジェクトについて、所有者やアクセス権の扱いを整理するのか。
• 将来的にACL依存をなくす移行計画を立てるのか。

対策は、技術的な設定値だけで決めるものではありません。

• 運用で誰が取得するのか。
• 障害時に誰が調査するのか。
• 監査ログとして誰が参照するのか。
• 保管期間中に別アカウントから読む必要があるのか。
• 削除やライフサイクル管理は誰が行うのか。

ここまで含めて、対策を選ぶ必要があります。

直接取りに行くのをやめ、バケット側のロールを使った

今回の対策では、アカウントB側にIAMロールを作成し、アカウントAからスイッチロールして操作する方式に変更しました。

アカウントBのIAMロールとして操作することで、アカウントB側のアイデンティティでS3にアクセスする形になります。

これにより、別アカウントから直接バケット内のオブジェクトを操作するのではなく、バケットを持つアカウント側の権限に寄せて操作できるようになります。

改善前は、アカウントA側のIAMに対して、アカウントBのS3バケット操作を許可していました。

しかし、これでは対象オブジェクトの所有者やサービス出力の扱いによって、取得できるものとできないものが発生しました。

改善後は、バケットが存在するアカウントB側にS3操作用のIAMロールを用意しました。

アカウントAのユーザーは、そのロールにスイッチします。

そして、アカウントB側のロールとしてS3バケット内のオブジェクトを操作します。

この形にすることで、少なくとも「アカウントAから直接、別アカウントのバケット内オブジェクトを操作する」という曖昧な構成を避けることができます。

また、権限設計の説明もしやすくなります。

「アカウントBのS3バケットを操作する場合は、アカウントBのIAMロールを使う」

このように整理できるからです。

運用手順としても、どのロールで作業するのかを明確にできます。

これは地味ですが、現場ではかなり重要です。

障害調査のときに、担当者ごとに違うIAMユーザーや違う権限で確認していると、現象が再現したりしなかったりします。

• ある人は見える。
• 別の人は見えない。
• CLIでは取れる。
• マネジメントコンソールでは取れない。
• アプリからは失敗する。
• 運用端末からは成功する。

こうなると、原因調査が一気に複雑になります。

権限設計は、セキュリティのためだけにあるのではありません。

障害時に、同じ条件で確認できるようにするためにも必要です。

テストで手動ファイルだけ見ていたら、この問題は見逃される

今回の話で一番重要なのは、対策そのものではありません。

本来、テスト工程で何を確認すべきだったのか、という点です。

もしテストで、ユーザーが手動アップロードしたファイルだけを使っていたら、この問題は見逃されます。

なぜなら、そのファイルは取得できてしまうからです。

「S3からファイル取得できました」
「クロスアカウントアクセスできました」
「権限設定は問題ありません」

このようなテスト結果になってしまいます。

しかし、本番運用で実際に取得したいのは、ユーザーが手動アップロードしたファイルとは限りません。

• AWSサービスが出力したログファイルです。
• 運用バッチが出力したファイルです。
• 監査用に自動生成されたファイルです。
• 障害調査で必要になるファイルです。

つまり、テストデータの作り方が間違っていると、設計ミスを検知できません。

今回であれば、少なくとも次の観点でテストする必要がありました。

• ユーザーがアップロードしたオブジェクトを取得できるか。
• AWSサービスが出力したオブジェクトを取得できるか。
• 別アカウントから取得できるか。
• 想定するIAMロールで取得できるか。
• 運用担当者の作業手順で取得できるか。
• CLI、アプリ、運用ジョブなど、実際の利用経路で取得できるか。
• 取得できない場合に、どのログやエラーで原因を追えるか。

ここまで確認して、初めて「運用で使える」と言えます。

単体テストでS3の設定値を確認するだけでは足りません。

結合テストでアカウント間のアクセスを確認するだけでも足りません。

システムテストや運用テストでは、本番と同じようにAWSサービスが出力したオブジェクトを使い、実際の運用手順で取得できるかを確認する必要があります。

ここを省略すると、テストでは成功したのに、本番運用で失敗します。

「同じバケットなら同じ扱い」という思い込みが危ない

今回の気づきは、S3の権限設計は「バケットにアクセスできるか」だけで終わらないということです。

特にクロスアカウント構成では、次のような思い込みが危険です。

S3バケットに権限を付ければ、中のオブジェクトも読める。
同じバケットにあるオブジェクトなら、同じように操作できる。
テスト用に手動で置いたファイルが取れれば、本番のログファイルも取れる。
AWSサービスが出力したファイルも、ユーザーがアップロードしたファイルと同じ扱いになる。
IAMポリシーだけ見れば原因が分かる。

これらは、実務では危ない前提です。

S3はシンプルに見えます。

バケットを作る。
ファイルを置く。
権限を付ける。
取得する。

表面的にはそれだけに見えます。

しかし、複数アカウント、AWSサービス出力、ログ保管、監査、運用ジョブが絡むと、一気に設計論点が増えます。

だからこそ、詳細設計では「S3バケット名」「保存先プレフィックス」「IAMポリシー」だけを書いて終わりにしてはいけません。

誰が作るのか。
誰が所有するのか。
誰が読むのか。
誰が消すのか。
誰が障害時に調べるのか。

ここまで書かないと、運用で使える設計にはなりません。

「取れました」で終わらせないためのチェックポイント

ここからは、同じ問題を防ぐための具体的なチェックリストです。

まず、S3を使う設計では、少なくとも次の項目を確認します。

• バケット所有アカウント。
• オブジェクト作成主体。
• オブジェクト所有者。
• アクセスするアカウント。
• アクセスに使うIAMロール。
• AWSサービスが出力するオブジェクトの有無。
• クロスアカウントアクセスの有無。
• S3 Object Ownershipの設定。
• ACLを使うのか、使わないのか。
• 運用時に参照・取得・削除する主体。
• 将来的にBucket owner enforcedへ移行できるか。

次に、テスト工程では、テストデータの作り方を明確にします。

• 手動でアップロードしたファイルだけで試験しない。
• AWSサービスが実際に出力したファイルで試験する。
• 本番運用で使うIAMロールで試験する。
• 別アカウントからの取得を試験する。
• 運用手順書どおりに取得できるか確認する。
• 失敗時のエラー確認方法も試験する。

そして、レビュー時には次の質問を入れます。

• 「そのオブジェクトは誰が作るのか」
• 「そのオブジェクトの所有者は誰になるのか」
• 「本番で取得するファイルと、テストで使ったファイルは同じ条件か」
• 「AWSサービスが出力したファイルでも確認したか」
• 「運用担当者が使うロールで確認したか」
• 「ACLに依存した設計が残っていないか」
• 「Bucket owner enforcedにした場合の影響を確認したか」

この質問を入れるだけで、今回のような問題はかなり防ぎやすくなります。

まとめ

今回の事象は、S3のクロスアカウントアクセスにおけるオブジェクト所有者の問題でした。

ただし、本質はAWSの細かい仕様そのものではありません。

本質は、次の一文です。

設計で決めていないことは、テストでも確認されない。

S3バケットに権限を付ける。
IAMポリシーを書く。
ロールを作る。
テストでファイルを取得する。

これだけでは、まだ足りません。

本番で実際に扱うオブジェクトは、誰が作るのか。
そのオブジェクトは、誰の所有になるのか。
どのアカウントから、どのロールで、どの手順で取得するのか。
障害時に、誰が調査できるのか。

ここまで設計して、初めて運用に耐える構成になります。

クラウドサービスは便利です。

しかし、サービスが自動で出力するものほど、利用者が手で作ったものと同じ前提で扱ってはいけません。

「作成できた」
「保存できた」
「バケットに存在する」

そこで安心してはいけません。

本当に確認すべきなのは、その先です。

必要な人が、必要なタイミングで、必要な権限で、そのオブジェクトを扱えるか。

そこまで見て、初めて設計とテストがつながります。

関連記事

今回の記事で扱った「設定したか」ではなく、「実運用で誰が、どの権限で、何を扱えるか」まで確認する考え方は、以下の記事でも整理しています。

【前編】詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程

シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。

たとえば、こんな要件です。

バックアップデータを5日分保存すること

一見すると、単純な要件に見えます。

バックアップソフトの保持期間を5日に設定すればよい。

AWS Backupであれば、ライフサイクルの保持期間を5日にすればよい。そう考えたくなります。

しかし、ここで確認すべきことがあります。

この「5日」は、カレンダー上の5日なのか。
それとも、業務日としての5日なのか。

この確認を曖昧にしたまま設計すると、バックアップジョブは正常に動いているのに、実は業務要件を満たしていない、という状態になることがあります。

「5日」と「5営業日」は違う

要件が次のようなものだったとします。

バックアップデータを5営業日分保存すること

この場合、単純に保持期間を5日に設定してよいとは限りません。

なぜなら、多くのバックアップ製品やクラウドサービスの保持期間は、営業日ではなく、カレンダー上の日数ベースで管理されるからです。

AWS Backupを例にすると、バックアップのライフサイクルでは、リカバリポイントを作成後、何日で削除するかを指定します。

つまり、基本的には「作成後なん日」という考え方です。

土日祝日や会社独自の休日カレンダーを考慮して保持期間を調整する。

こうした営業日ベースの世代管理を、標準の保持期間設定だけで実現できるとは限りません。

AWS Backupではスケジュール設定により、取得する曜日や時間を制御することはできます。

しかしこれはあくまで「いつバックアップを取得するか」の話です。「何営業日分のバックアップを保持するか」とは別の話です。

ここを混同すると、設計ミスになります。

土日や大型連休をまたぐと、要件未達になることがある

たとえば、バックアップを毎日取得し、保持期間を5日に設定したとします。

土日をまたぐと、保持されているバックアップの中に土日分が含まれます。

その結果、業務日として見ると、5営業日分ではなく3営業日分程度しか残っていない、ということが起こり得ます。

さらに、年末年始、ゴールデンウィーク、会社独自の休業日を挟む場合はもっと問題が大きくなります。

5日間の連休がある場合、保持期間を5日にしていると、連休前に取得したバックアップが連休明け時点で削除対象になっている可能性があります。

システム上は、保持期間5日で正しく動いている。バックアップジョブも正常終了している。リカバリポイントも存在している。

それでも、業務要件としての「5営業日分保存」は満たせていない可能性があります。

障害が起きているわけではありません。
ジョブが失敗しているわけでもありません。製品の不具合でもありません。

ただ、要件の解釈と製品仕様がずれている。その結果、設計として不足している状態になります。

バックアップ要件で確認すべきこと

バックアップ保存期限の要件が出てきたら、少なくとも次の点は確認する必要があります。

• 保存期限の「日」はカレンダー上の日数か、営業日か
• 土日祝日、年末年始、大型連休をどう扱うか
• 必要なのは「日数保持」なのか「世代保持」なのか
• 復旧時に必要なのは、直近何営業日分なのか、特定時点なのか
• 月次・年次・決算期など、長期保持が別途必要か

特に重要なのは、次の3つは同じ意味ではないということです。

• 5日保持：期間の話
• 5世代保持：バックアップ取得回数の話
• 5営業日分保持：休日カレンダーを考慮した復旧可能時点の話

似ています。しかし、設計上は別物です。この違いを曖昧にしたまま詳細設計に入ると、後工程で問題になります。

また、要件の言葉をそのまま受け取らず、製品仕様にぶつけるための問いに変換する習慣も重要です。

たとえば、次のように考えます。

現実的な３つの対策

休日カレンダーを考慮した世代管理機能がない場合、現実的な対策は大きく3つです。

1　保持期間を長めに設定する

5営業日分を確実に残したいのであれば、土日祝日や大型連休を考慮して、10日、14日など余裕を持った保持期間にする。

これで要件を満たせるなら、構成はシンプルです。
ただし、バックアップ容量が増え、ストレージコストも増えます。

2　バックアップ取得はAWS Backupなどに任せ、世代管理をジョブ管理側で制御する

営業日、祝日、会社休日に柔軟に対応しやすい一方で、ジョブ設計、運用設計、監視、試験項目が増えます。

3　AWS CLIやLambdaなどを使って、独自に削除・保持制御を実装する

追加のジョブ管理製品なしで柔軟に制御できますが、スクリプト開発、試験、保守、誤削除防止の設計が必要になります。

特に削除処理を独自に作る場合、単に不要なバックアップを削除すればよいわけではありません。
誤削除防止、削除ログ、削除失敗時の検知、復旧テストまで含めて設計する必要があります。

要件・製品仕様・運用仕様のズレは、次のように整理すると分かりやすくなります。

これは詳細設計で見つけるべき論点である

今回の話は、バックアップ設計だけの話ではありません。

詳細設計で考えるべきことの典型例です。

基本設計で「バックアップを5営業日分保存する」と書くことはできます。しかし詳細設計ではそこで終わりません。

実際に採用する製品やサービスで、

その要件をどう実現するのか。
標準機能で実現できるのか。
設定だけで足りるのか。
運用で補う必要があるのか。
スクリプトやジョブ管理が必要なのか。

その場合、監視、ログ、異常時対応、試験はどうするのか。
ここまで確認して、初めて設計として実装可能になります。

詳細設計書にはパラメータを書く必要がありますが、パラメータだけでは弱いです。

「保持期間：14日」とだけ書かれていても、なぜ14日なのかが分かりません。

本来はこういう根拠が必要です。

要件は5営業日分の保持。標準機能では営業日単位の保持制御ができないため、土日祝日および大型連休を考慮し、保持期間を14日に設定する。これにより、通常の土日祝日を含む期間でも5営業日分のリカバリポイントを保持する。

こう書いておけば、レビューでも説明できます。
運用担当にも伝わります。テスト担当も、何を確認すべきか分かります。

後から気づくと、設計書の修正、スクリプト追加、試験項目の追加、運用手順書の修正、顧客説明、コスト再見積もりが発生します。
一つひとつは小さく見えても、後工程では明確な手戻りです。

詳細設計とは、パラメータシートを埋める作業ではありません。

基本設計で決めた内容を、製品仕様、制約、運用条件に照らして、構築できる形、試せる形、運用できる形に落とし込む工程です。

まとめ

「5日保存」は、単純にバックアップソフトへ5日と設定すればよい、という話ではありません。

その5日がカレンダー上の日数なのか、営業日なのか。土日祝日や大型連休をどう扱うのか。何世代必要なのか。どの時点に復旧できる必要があるのか。これを確認しないまま設計すると、バックアップジョブは正常でも、業務要件を満たせない可能性があります。

バックアップは、取れていればよいわけではありません。必要な時点に、必要な期間分、確実に戻せること。そこまで確認して、初めてバックアップ要件を満たしていると言えます。

こういうズレを構築前に見つけるのが、詳細設計の仕事です。

この考え方については、以下の記事でも整理しています。

〖後編②〗詳細設計で決めること｜基本設計を「構築・テスト・運用できる形」に落とし込む工程

シリーズ全体は「実務で使えるシステム開発方法論」マガジンにまとめています。