物理サーバのスペックをEC2に翻訳する — コア・メモリ・ライセンスの換算

移行対象のサーバ一覧には「物理8コア／メモリ64GB」のようなスペックが並んでいます。これをそのままEC2に写像すると、ほぼ確実に過剰サイジングになります。オンプレのサーバは「5年先まで見込んで大きめに買う」文化で調達されているからです。翻訳の手順を示します。

01vCPUの意味を揃える

EC2のvCPUは、物理コアではなくハイパースレッド1本です。つまり物理8コア（HT有効で16スレッド）のサーバのCPU能力は、おおまかにvCPU16相当。ただしこれは「上限を揃えた」だけの話で、実際に選ぶサイズは次の使用率で決めます。

02カタログではなくピーク使用率で選ぶ

オンプレサーバの実測CPU使用率は、ピークでも30〜50%程度であることが珍しくありません。実測ピークが40%なら、必要なのは能力の半分以下です。「実測ピーク×余裕1.3倍」を目安に、カタログ換算より1〜2段小さいサイズから始めるのが定石です。

これができるのは、AWSではサイズ変更が数分で済むからです。オンプレの「買い直せないから大きめに」という保険は、もう掛け金の無駄です。詳しくはインスタンスタイプ選定の記事を。

03メモリは「実コミット量」で

メモリも同様に、搭載量ではなく実際の使用量（Linuxならsar等でキャッシュを除いた実需、Windowsならコミット済みバイト）を基準にします。「メモリ使用率95%」の大半がファイルキャッシュというケースは多く、これを鵜呑みにするとr系を無駄に選ぶことになります。実需＋アプリ推奨値で見積もり、ファミリー（m系1:4、r系1:8）を選びます。

04最大の罠：商用DBのライセンス

OracleやSQL Serverを載せるサーバだけは、性能ではなくライセンスがサイジングを支配します。クラウドではvCPU数を基準にライセンスを数える契約条項が適用されるのが一般的で、うっかり大きいインスタンスを選ぶと、インフラ費ではなくライセンス費が跳ね上がります。

• 必要最小限のvCPUに絞る（CPUオプションでvCPU数を制限する手もあります）
• BYOL（既存ライセンス持ち込み）の可否と条件をベンダー契約で確認する
• ライセンス費が支配的なら、RDSのライセンス込み構成や、PostgreSQL移行の検討価値が一気に上がる

05翻訳の手順まとめ

• ① サーバ一覧に「実測ピークCPU％・実メモリ使用量」の列を足す（2週間の実測）
• ② vCPU＝HTスレッド換算で上限を把握し、実測×1.3で初期サイズを決める
• ③ 商用ソフトのライセンス条件を確認し、必要ならサイズより先にライセンスで確定
• ④ 移行後2週間、CloudWatchとCompute Optimizerで答え合わせして調整