はじめに

既存のAWS環境を変更する仕事では、設定を新しく作る知識だけでは不十分です。

現在動いているシステムには、過去の障害対応、個別の運用、古い製品との互換性など、構築時には見えない事情が残っています。セキュリティグループのルールを一つ削除しただけでも、別システムの通信や監視が止まることがあります。

これは新築工事というより、営業中の店舗を改装する仕事に近いものです。

この記事では、既存AWS環境の設計変更、設定変更、OS・ミドルウェア・データベースのバージョンアップを安全に進めるために、次の内容を整理します。

現状をどこまで調べるか
影響範囲をどう見つけるか
作業手順と切り戻しをどう設計するか
本番前後に何を確認するか
AWS、Linux、Windows、データベースで何に注意するか

まず理解しておきたい2つの用語

OS更改とは

OS更改（オペレーティングシステムの更新・移行）とは、サポート終了、セキュリティ対策、ハードウェアやクラウド基盤の更新、業務要件の変化に合わせて、古いOSから新しいOSへバージョンアップまたは移行する作業です。

単に更新プログラムを適用するだけではありません。対象OSやシステムの条件に応じて、主に次の方法を選びます。

方法	何をするか	主な注意点
既存サーバーを更新する	現在のEC2上でOSをアップグレードする	既存設定を引き継げる一方、互換性確認と切り戻しが難しくなる場合がある
新しいサーバーへ移行する	新しいOSのAMIからEC2を作り、アプリやデータを移して通信先を切り替える	新旧比較と切り戻しをしやすい一方、データ移行と切り替えの設計が必要になる

OSによっては、現在の環境をそのまま新しいメジャーバージョンへ更新できません。ベンダーのサポート方針を確認し、OSだけでなく、ミドルウェア、エージェント、アプリケーション、監視、バックアップを含めて更改計画を作ります。

例えば、MicrosoftはWindows Serverの更新方法を、既存環境を維持するインプレースアップグレード、クリーンインストール、別環境への移行などに分けています。

Amazon Linux 2は、2026年6月30日にサポートを終了しました。Amazon Linux 2023へ移行する場合は、AWS公式資料でパッケージやcronからsystemd timerへの変更点を確認し、環境を適応させます。

現新比較（現新比較テスト）とは

現新比較（現新比較テスト）とは、システムの改修や移行前の現行環境と、変更後の新環境で同じ処理や操作を行い、出力結果に意図しない差異や不具合がないかを確認する検証手法です。

目的は、すべての結果を完全に同じにすることではありません。仕様変更による予定どおりの差分と、変更するつもりがなかった差分を分けて確認します。

現場によっては、「新旧比較」「移行前後比較」などと呼ばれる場合もあります。最初に、比較対象、入力条件、許容する差分、合否基準を関係者でそろえます。

比較対象	確認例
Web・API	HTTPステータス、レスポンス項目、計算結果、エラー内容
データベース	件数、合計値、更新対象、NULL、文字化け、小数・日時の扱い
バッチ	入力件数、成功・失敗件数、出力ファイル、終了コード、処理時間
画面	表示項目、入力、画面遷移、権限ごとの表示、主要ブラウザーでの動作
運用	ログ、監視、アラーム、バックアップ、定期処理、外部システム連携

同じ条件をそろえて比較する

入力データ、データベースの状態、実行時刻、ユーザー権限、外部サービスの応答などの条件が違うと、OS更改とは無関係な差分が発生します。比較前に条件をそろえ、そろえられない項目は記録します。

次は、現行APIと新APIへ同じリクエストを送り、JSONを比較する簡単な例です。

現行APIと新APIの比較

# パイプ途中のcurlが失敗した場合も、コマンド全体を失敗として扱う。
set -o pipefail

# 比較対象のURLを明示する。本番環境への実行は、事前に許可を得る。
CURRENT_URL="https://current.example.com"
NEW_URL="https://new.example.com"

# 両方の環境へ同じ入力を送り、JSONのキー順をそろえて保存する。
# 実行ごとに変わる時刻とリクエストIDは、比較対象から除外する。
curl --fail-with-body --silent --show-error \
  "${CURRENT_URL}/api/orders/123" \
  | jq --sort-keys 'del(.timestamp, .requestId)' \
  > current.json

curl --fail-with-body --silent --show-error \
  "${NEW_URL}/api/orders/123" \
  | jq --sort-keys 'del(.timestamp, .requestId)' \
  > new.json

# 差分がなければ何も表示されない。差分があれば変更箇所が表示される。
diff -u current.json new.json

diffは、差分がなければ終了コード0、差分があれば1、処理自体に問題があれば2以上を返します。timestampやrequestIdのように毎回変わる値を除外する場合も、勝手に無視してはいけません。除外する理由と対象項目を、テスト仕様書や結果へ残します。

AWSの具体例では、AWS Database Migration Service（AWS DMS）のデータ検証が、移行元と移行先の対応する行を比較し、不一致を報告します。ただし、検証処理は移行元・移行先・ネットワークのリソースを追加で使用します。大きなデータを比較する場合は、本番負荷と所要時間も考慮します。

また、現新比較だけでは新機能の正しさや、障害時の動作、性能限界までは確認できません。新仕様のテスト、異常系テスト、性能テスト、切り戻しテストと組み合わせます。

先に結論

既存環境の変更では、次の順番を崩さないことが重要です。

変更作業の評価は、「設定を変えられたか」だけでは決まりません。

影響を説明できること、異常時に止まれること、決めた時間内に戻せること、作業後の状態を証跡で示せることが重要です。

新規構築と既存環境の変更は何が違うのか

新規構築では、設計した状態をゼロから作れます。既存環境では、設計書、実機、IaC、運用手順が一致しているとは限りません。

観点	新規構築	既存環境の変更
出発点	設計した初期状態	現在稼働している実環境
主な確認	要件を満たすか	既存機能を壊さず変更できるか
隠れた条件	比較的少ない	手動設定、例外、外部連携が残りやすい
失敗時	作り直せる場合がある	利用者や業務へ影響する
完了条件	構築できたこと	変更後も業務、監視、運用が継続すること

「一般的にはこの構成だから」と推測してはいけません。正しい出発点は、目の前の環境で確認できた事実です。

1. 作業範囲と判断権限を確認する

最初に、変更対象だけでなく、自分がどこまで判断してよいかを確認します。

対象のAWSアカウント、リージョン、環境
対象リソースと変更しないリソース
作業可能な時間帯
サービス停止や再起動の可否
作業開始、続行、中止、切り戻しを判断する人
顧客、運用、アプリ、データベース担当の連絡先
変更申請、レビュー、承認の流れ

作業範囲や契約、運用ルールが不明な場合は、担当者だけで解釈せず、リーダーや所属会社へ確認します。

2. 現在の状態を調べる

設計書だけでなく、実機、AWSの設定、監視、変更履歴を組み合わせて確認します。

分類	主な確認項目
AWS	アカウント、リージョン、VPC、EC2、ELB、RDS、IAM、Auto Scaling、タグ
OS	種類、バージョン、カーネル、パッチ、ディスク、時刻、稼働サービス
ミドルウェア	製品、バージョン、設定ファイル、起動方法、依存ランタイム
データベース	エンジン、バージョン、接続方式、ドライバー、バックアップ、レプリケーション
アプリ	使用ポート、接続先、バッチ、外部API、稼働時間、停止順序
運用	監視、アラーム、バックアップ、定期作業、障害連絡、保守時間
管理	CloudFormation・Terraform、Git、手動変更、過去の申請と障害記録

AWSアカウントとリージョンを確認する

コンソールの表示名だけでなく、アカウントIDとリソースIDまで確認します。

AWS CLI

# 現在の認証情報が、どのAWSアカウントとIAM主体を指しているか確認する。
aws sts get-caller-identity --output table

# CLIが参照しているプロファイル、アクセスキー、リージョンの設定元を確認する。
aws configure list

環境変数や実行ロールによって設定が上書きされる場合があります。コマンドの結果と作業申請のアカウントIDを照合してから、変更コマンドを実行します。

EC2の現在値を記録する

AWS CLI

# 対象を取り違えないよう、インスタンスIDを明示する。
INSTANCE_ID="i-0123456789abcdef0"

# Nameタグ、状態、VPC、サブネット、プライベートIPを作業前の証跡として取得する。
aws ec2 describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[].Instances[].{Name:Tags[?Key==`Name`]|[0].Value,State:State.Name,VpcId:VpcId,SubnetId:SubnetId,PrivateIp:PrivateIpAddress}' \
  --output table

実際の案件では、EC2だけでなく、関連するセキュリティグループ、ロードバランサーのターゲット、EBS、IAMロール、CloudWatchアラームも記録します。

過去の変更を調べる

CloudTrailのイベント履歴では、過去90日間の管理イベントをリージョン単位で確認できます。継続的・横断的に保存する必要がある場合は、証跡またはCloudTrail Lakeの設計が必要です。

「誰が悪いか」を探すのではなく、現在値になった経緯と、変更後に戻される可能性を把握するために使います。

3. 変更後の状態と完了条件を決める

「バージョンを上げる」だけでは、作業のゴールとして不十分です。

項目	変更前	変更後	完了条件
ミドルウェア	1.5	2.0	サービスが起動し、主要APIが成功する
OSパッケージ	現行版	指定版	再起動後も正常で、監視が継続する
セキュリティグループ	旧許可ルール	不要ルール削除	必要な通信だけ成功し、不要な通信は失敗する
DBドライバー	旧版	対応版	アプリから接続でき、主要SQLが成功する

次の4点を文章にできる状態にします。

何を変更するか
何を変更しないか
何を確認できれば成功か
どの状態なら失敗として止めるか

4. 影響範囲を依存関係から調べる

変更対象の前後にあるものを確認します。

依存関係の例

利用者
  -> Route 53
  -> Load Balancer
  -> EC2上のアプリケーション
  -> DBドライバー
  -> データベース
  -> バックアップ・監視

ミドルウェアのバージョンアップであれば、次の組み合わせを確認します。

OS × ミドルウェア × ランタイム × アプリケーション × DB × ドライバー × 監視・バックアップ製品

製品単体が新バージョンに対応していても、周辺製品との組み合わせがサポートされているとは限りません。ベンダーの互換性表、リリースノート、既知の問題、サポート期限を確認します。

影響調査表の例

変更対象	影響候補	確認方法	担当	結果
EC2上のミドルウェア	アプリ起動	検証環境で起動試験	アプリ担当	未確認
DBドライバー	DB接続	接続、参照、更新テスト	DB担当	未確認
使用ポート	SG・NACL・FW	疎通とフローログ確認	インフラ担当	未確認
ログ形式	監視・通知	テストエラーを発生させる	運用担当	未確認
再起動	バッチ・定期処理	次回実行時刻と結果を確認	運用担当	未確認

未確認を空欄にしないことがポイントです。分かっていない事項を見えるようにすると、作業前に相談できます。

5. IaC管理と手動変更の不一致を確認する

IaCはInfrastructure as Codeの略で、AWS環境の設定をCloudFormationやTerraformなどのコードで管理する方法です。

IaCで管理しているリソースをコンソールから変更すると、次回のデプロイで元へ戻ったり、別の差分と一緒に変更されたりすることがあります。

変更前に次を確認します。

どのリポジトリ、テンプレート、スタック、Terraform stateで管理しているか
コンソールからの手動変更が許可されているか
コードと実環境に差分がないか
更新か、置き換えか、削除か
コード、設計書、パラメータシートをいつ更新するか

CloudFormationの変更セット

変更セットは、スタックへ適用する前に、変更・置き換え・削除の候補を確認する機能です。ただし、依存先の状態や実行時の制約まで含めて、更新成功を保証するものではありません。

本番適用前に、変更セットだけでなく、アプリケーションの互換性、リソースクォータ、IAM権限、停止時間も確認します。

CloudFormationのドリフト検出

ドリフトとは、テンプレートで期待する状態と実リソースの状態がずれていることです。

AWS CLI

# 対象スタック名を明示する。
STACK_NAME="example-production-stack"

# スタック全体のドリフト検出を開始し、確認用IDを取得する。
DETECTION_ID=$(aws cloudformation detect-stack-drift \
  --stack-name "$STACK_NAME" \
  --query 'StackDriftDetectionId' \
  --output text)

# 検出処理の完了状態と、スタック全体のドリフト状態を確認する。
aws cloudformation describe-stack-drift-detection-status \
  --stack-drift-detection-id "$DETECTION_ID" \
  --output table

# 差分があるリソースを一覧にする。
aws cloudformation describe-stack-resource-drifts \
  --stack-name "$STACK_NAME" \
  --stack-resource-drift-status-filters MODIFIED DELETED \
  --output table

ドリフト検出は、すべてのAWSリソースやすべてのプロパティを確認できるわけではありません。対応状況と、テンプレートに明示したプロパティを確認し、検出結果だけで「差分なし」と断定しないようにします。

6. 作業手順と切り戻しを一緒に作る

切り戻しとは、異常が起きたときに変更前の状態へ戻すことです。

作業手順書には、最低限次を記載します。

目的と対象
作業日時と影響
作業前の確認
バックアップと復元方法
変更コマンド・操作
各手順の期待結果
動作確認
中止・切り戻し条件
切り戻し手順
判断者、連絡先、次回報告時刻

切り戻し条件を数値や事象で決める

中止・切り戻し条件の例

- 主要APIの疎通確認が3回連続で失敗した
- 予定した作業時間を30分超過する見込みになった
- DB接続エラーが解消せず、原因を説明できない
- 監視、バックアップ、外部連携のいずれかが復旧しない
- 手順書と実環境が異なり、承認済み範囲で続行できない

数値は案件のSLA、停止可能時間、復旧目標に合わせて決めます。上の値をそのまま本番へ流用しないでください。

バックアップと「戻せること」は別

バックアップが存在しても、次が不明なら切り戻し計画は完成していません。

どの復旧ポイントを使うか
誰が復元を実施するか
復元先は元リソースか、新リソースか
復元に何分かかるか
復元後にDNSや接続先をどう切り替えるか
データ整合性をどう確認するか
変更後に発生したデータをどう扱うか

AWS Backupの復元テストは、復元可能性と復元ジョブの所要時間を定期的に評価するために利用できます。復元後のアプリケーション検証は、別途テスト内容を決める必要があります。

EC2のAMI取得で確認すること

EBS-backed AMIの作成では、デフォルトでインスタンスを再起動し、ファイルシステムの整合性を確保してイメージを作成します。再起動しない設定もありますが、AWSはファイルシステムの整合性を保証しません。

停止可否、アプリケーションの書き込み、複数ボリューム、データベースの整合性を確認し、AMIを取っただけで完了としないことが大切です。

7. 本番に近い環境で検証する

検証環境では、正常に変更できることだけでなく、失敗時に止まり、戻せることも確認します。

テスト	確認内容
正常系	変更、起動、主要機能、外部連携が成功する
異常系	エラー時に手順を止め、想定したログと通知が出る
切り戻し	変更前へ戻り、主要機能とデータを確認できる
再起動	OS再起動後も設定、マウント、サービスが維持される
性能	CPU、メモリ、ディスク、応答時間が許容範囲に収まる
定期処理	バッチ、バックアップ、証明書更新、監視が動作する

本番と検証環境の差分も記録します。インスタンスタイプ、データ量、接続先、IAM、監視、外部システムが異なる場合、検証結果をそのまま本番へ当てはめられません。

8. OSとデータベースの確認例

Linux

# OSのディストリビューションとバージョンを確認する。
cat /etc/os-release

# 稼働中のカーネルを確認する。
uname -r

# 対象サービスの状態と直近ログを確認する。
systemctl status example-app.service --no-pager
journalctl -u example-app.service -n 100 --no-pager

# 待ち受けポートとディスク使用量を確認する。
sudo ss -lntp
df -hT

パッケージ更新後は、設定ファイルの差分、自動起動、権限、SELinux、ログ出力先、再起動後の状態を確認します。

Windows Server

PowerShell

# OS名、バージョン、ビルド番号を確認する。
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

# 稼働中のサービスと待ち受けTCPポートを確認する。
Get-Service | Where-Object Status -eq 'Running'
Get-NetTCPConnection -State Listen

# ボリュームの空き容量を確認する。
Get-Volume | Select-Object DriveLetter, FileSystemLabel, Size, SizeRemaining

Windows Updateや.NETの変更では、再起動の有無、サービスアカウント、イベントログ、タスクスケジューラ、時刻同期を確認します。

Oracleなどのデータベース

Oracle SQL

-- Oracle Databaseのバージョン情報を確認する。
SELECT banner FROM v$version;

-- インスタンスとデータベースの稼働状態を確認する。
SELECT instance_name, status, database_status FROM v$instance;

データベースでは、エンジンだけでなく、クライアント、JDBC・ODBCドライバー、文字コード、タイムゾーン、バックアップ、レプリケーション、接続プールを確認します。製品ごとのサポートマトリクスとアップグレード手順を優先してください。

9. AWSサービスごとの注意点

Auto Scaling配下のEC2

Auto ScalingグループのEC2を停止すると、EC2 Auto Scalingはstoppingやstoppedのインスタンスを異常と判断し、置き換えます。単体EC2と同じ感覚で停止してはいけません。

作業方法として、Standbyへの移行、Instance Refresh、起動テンプレートの更新など、構成に合う方法を検討します。

Load Balancer配下のサーバ

ロードバランサーから切り離す前に、Connection DrainingまたはDeregistration Delay、セッション、ヘルスチェック、残りの台数を確認します。作業後はターゲットがHealthyへ戻ったことだけでなく、実際の主要リクエストを確認します。

RDSのバージョンアップ

データベースエンジンとバージョンによって、停止時間、事前チェック、パラメータグループ、拡張機能、レプリカ、切り戻し方法が異なります。

インプレースのアップグレードを設定値の変更だけで元へ戻せるとは考えず、スナップショットから別DBを復元する方法や、新旧環境を切り替える方法を含めて設計します。必ず対象エンジンのAWS公式手順とベンダー資料を確認してください。

10. 本番作業では一手順ずつ確認する

作業直前

AWSアカウントID、リージョン、環境を確認した
対象リソースIDを申請書と照合した
監視、バックアップ、バッチの状態を確認した
最新バックアップと復元手順を確認した
作業開始の承認を受けた
判断者と連絡手段を確認した
中止判断の期限を確認した

作業中

手順番号を読み上げる
対象と期待結果を確認する
コマンドまたは操作を実行する
結果と時刻を記録する
期待結果と一致した場合だけ次へ進む

想定外の結果が出たら、自己判断でコマンドを追加しません。事実、影響、現在の状態、次の選択肢を整理して報告します。

初動報告の例

【事実】手順12のサービス起動でエラーが発生しました。
【影響】現在、対象サーバはロードバランサーから切り離した状態です。
【確認済み】設定ファイルの構文とディスク空き容量を確認しました。
【未確認】新バージョン固有の依存パッケージは確認中です。
【提案】切り戻し判断時刻まで15分のため、手順書どおり旧版へ戻す判断をお願いします。

作業後

対象サービスとOSが正常である
主要なユーザー操作が成功する
データベースと外部システムへ接続できる
ログとCloudWatchアラームに異常がない
CPU、メモリ、ディスク、応答時間に異常がない
バッチ、監視、バックアップが継続している
設計書、手順書、IaC、パラメータシートを更新した
実施内容、差分、結果、残課題を報告した

作業直後が正常でも、夜間バッチや翌日の業務開始時に問題が出ることがあります。監視強化の終了条件と、翌営業日の確認担当を決めます。

初心者が避けたい行動

設計書だけを見て、実環境を確認しない
リソース名だけで判断し、アカウントIDやリソースIDを見ない
エラーを消すために、承認されていないコマンドを追加する
バックアップを取っただけで、切り戻せると判断する
正常系だけを試し、切り戻しを検証しない
手順と異なる結果を黙って進める
問題を自分だけで解決してから報告しようとする
変更後の監視、バッチ、バックアップを確認しない

分からないことを早く共有するのは、技術力不足ではありません。既存環境では、分からない前提を明らかにすること自体が安全な変更管理です。

参考・確認先

AWS CloudFormation: 変更セットを使ったスタックの更新
AWS CloudFormation: スタック全体のドリフト検出
AWS Backup: 復元テスト
Amazon EC2 Auto Scaling: ヘルスチェックの仕組み
Amazon EC2: EBS-backed AMIの作成
AWS CloudTrail: イベント履歴の操作
AWS Systems Manager Change Manager
Amazon RDS: DBインスタンスエンジンバージョンのアップグレード
Amazon Linux 2: Amazon Linux 2023への移行準備
Amazon Linux 2023 FAQ
Microsoft Learn: Windows Serverアップグレードの計画
AWS DMS: データ検証
筆者独自に追加した内容: 既存AWS環境の変更案件で用いる影響調査表、手順書項目、初動報告、中止・切り戻し判断の整理
事実確認日: 2026年8月27日

まとめ

既存AWS環境の変更では、AWSサービスの知識に加えて、次の行動が重要です。

設計書、実機、IaC、監視、変更履歴を組み合わせて現状を調べる
変更後の状態、完了条件、失敗条件を先に決める
変更対象の前後にある依存関係を確認する
変更手順と切り戻し手順を同時に作る
バックアップ取得ではなく、復元方法と時間まで確認する
本番に近い環境で正常系、異常系、切り戻しを試す
想定外の結果が出たら止め、事実を報告する
作業後も監視、バッチ、バックアップを確認する

素早く変更することより、関係者が安全に判断できる状態を作ることが先です。

おわりに

初めて既存AWS環境の変更を担当する場合は、まず「変更前」「変更後」「完了条件」「切り戻し条件」の4列を作ってみてください。曖昧な点が見えれば、作業前に相談できます。

Wealthy Designでは、AWS・Google Cloud・Azureの設計、実装、運用で得た知見を、現場で再利用できる形に整理して発信しています。

はじめに

まず理解しておきたい2つの用語

OS更改とは

現新比較（現新比較テスト）とは

同じ条件をそろえて比較する

先に結論

新規構築と既存環境の変更は何が違うのか

1. 作業範囲と判断権限を確認する

2. 現在の状態を調べる

AWSアカウントとリージョンを確認する

EC2の現在値を記録する

過去の変更を調べる

3. 変更後の状態と完了条件を決める

4. 影響範囲を依存関係から調べる

影響調査表の例

5. IaC管理と手動変更の不一致を確認する

CloudFormationの変更セット

CloudFormationのドリフト検出

6. 作業手順と切り戻しを一緒に作る

切り戻し条件を数値や事象で決める

バックアップと「戻せること」は別

EC2のAMI取得で確認すること

7. 本番に近い環境で検証する

8. OSとデータベースの確認例

Linux

Windows Server

Oracleなどのデータベース

9. AWSサービスごとの注意点

Auto Scaling配下のEC2

Load Balancer配下のサーバ

RDSのバージョンアップ

10. 本番作業では一手順ずつ確認する

作業直前

作業中

作業後

初心者が避けたい行動

関連記事

参考・確認先

まとめ

おわりに