前回の【削除編】に続く第2弾。今回のテーマは【リサイズ（サイズ変更）】です！
スマホで「20GB契約なのに、実際は3GBしか使っていない」なんてこと、ありませんか？
余った分のお金を払うのは、もったいないですよね。
AWSのサーバー（EC2）も同じで、「念のため」と選んだ高性能なサーバーを、全然使いきれていないというケースが多いのです。
今回は、そんな「プランの見直し（リサイズ）」で、コストを下げる方法をご紹介します。
cloudpack+ PORTALで使える、AWSの分析ツールです。
「無駄なリソース（EC2などのサーバー）」や「サイズが大きすぎるリソース」を自動で診断し、「ここを直せばいくら安くなるか」を具体的に教えてくれます。
「リサイズ」って何？
簡単に言うと、EC2（サーバー）のスペック（性能）を見直すことです。
AWSのEC2（サーバー）にも、スマホと同じようにたくさんの「料金プラン（サイズ）」があります。
しかし、ほとんど使わないのに「一番高いプラン」を契約したままだと、当然もったいないですよね。
専門用語では、この状態を「オーバープロビジョニング（過剰スペック）」と呼びます。
コストシミュレーションは、この「過剰スペック」を見つけ出し、「今の稼働状況なら、こちらのサイズに変更することでコストを最適化できますよ！」と提案してくれるのです。
4ステップで解決！無駄なコストをカット！
では、実際にコストシミュレーションを使って、無駄に高いEC2（サーバー）を見つけて安くしてみましょう！
今回は、検証環境で動いているEC2（サーバー）を例に見ていきます。
STEP1. 診断結果を見てみよう
まず、実際の画面でどこに無駄があるのかチェックします。
コストシミュレーションを開いてから、リストに辿り着くまでの手順は以下の通りです。
1. アカウントを選択する
「コストシミュレーション」を開くと、AWSアカウントのリストが表示されます。
チェックしたいアカウントの行にある 「詳細を見る」 をクリックします。
👉
2. 「推奨事項」を開く
画面を少し下へスクロールすると、「AWSリソース毎の推奨事項（ライツサイジング）」 という項目があります。
ここにある 「推奨事項」 のリンクをクリックします。
👉
3. 具体的な提案内容を確認する
リストから「OVER_PROVISIONED（サイズが大きすぎる）」となっている行の 「詳細」 をクリックします。
すると、以下のような「コスト削減プラン」が提案されました。
m5.xlarge ➡ t4g.medium
削減効果
月額 約 147ドル（約 22,000円）OFF！
※画面の表示額は直近の稼働実績ですが、上記は月間フル稼働（24時間×30日）で試算した金額です。
たった1台見直すだけで、これだけの効果！
しかし、「安くして性能は大丈夫？」と心配になりますよね。そこで次のステップです。
STEP2. 実際の稼働状況をチェックしよう
念のため、実際のデータも自分の目で見ておきましょう。
AWSコンソールの「EC2インスタンス一覧」から対象のインスタンスをクリックし、「モニタリング」タブを選びます。
CPU使用率： 25% 付近
メモリ使用率： 10% 付近
これだけのスペック（m5.xlarge）がありながら、ほとんど使われていない状態です。
これなら、サイズを下げても全く問題なさそうです！
※あくまで一例です。サイズを下げても問題がないかは、稼働しているシステムやワークロードによって異なります。
最終的な変更のご判断は、お客様ご自身にてお願いいたします。
STEP3. いざ変更！…の前に「落とし穴」に注意
診断結果も確認OK。では、推奨された「t4g.medium」への変更を進めましょう。
ただしその前に、1つだけ非常に重要な注意点があります。
⚠️ 「CPUの種類」が変わる変更は要注意！
今回、変更元は「m5（Intel製）」、変更先は「t4g（AWS Graviton / Armベース）」です。
これは単なるサイズ変更ではなく、EC2（サーバー）の仕組み（アーキテクチャ）が「x86」から「Arm」に変わるという大きな変更です。
【必ず事前に確認してください】
- お使いのOSやミドルウェアは「Arm64」に対応していますか？
- アプリケーションやライブラリは「Arm」で動きますか？
※アーキテクチャが変わるかどうかは、コストシミュレーションの推奨オプション情報にある「プラットフォームの違い」の項目で確認できます。
もし対応状況に不安がある場合や、検証が難しい場合は、無理に「t4g」を選ばないでください。
その場合は、CPUの種類が変わらない「x86ベース」の中で、最新世代へのサイズダウン（例：m6i.large への変更など）を検討しましょう。
変更の手順について
互換性の確認が取れたら、実際にインスタンスタイプを変更します。
具体的な操作手順は、AWSの公式サイトをご覧ください。
STEP4. 変更後の稼働状況を確認
変更作業が終わったら、もう一度AWSコンソールの「モニタリング」タブを見てみましょう。
今回は検証の結果、無事に稼働し、数値は以下のようになりました。
CPU使用率： 50% 付近
メモリ使用率： 40% 付近
使用率が上がったことで「余裕がなくなった？」と心配になるかもしれませんが、これは「リソースを無駄なくしっかり使い切れている」という非常に良い状態です。
そして、コストシミュレーションの結果も確認します。
反映まで最大24時間ほどかかるため、改めて確認した画面がこちらです。
推奨事項の表示がなくなり、検出結果が「最適化済み」に変わりました！
これで、コストシミュレーション上でも「適正なサイズである」とお墨付きをもらえたことになります。
過剰なスペックによるコストの無駄を解消し、月額コストを大幅に下げることができました！
まとめ：定期的な「サイズ診断」を習慣に！
AWSのEC2（サーバー）は、一度作るとそのまま放置してしまいがち。
でも、ビジネスの状況に合わせて「今のサイズは適切かな？」と定期的に診断をしてあげることが大切です。
ぜひコストシミュレーションを活用して、隠れた「コストの無駄」をなくしていきましょう！
まずは「IAMロール連携」からスタート！
本記事でご紹介した便利なツール（コストシミュレーション）を使うには、お客様のAWSアカウントとcloudpack+ PORTALを連携する必要があります。
簡単な設定で、すぐにツールが使えるようになります。ぜひ「IAMロール連携」から始めましょう！
設定方法について
IAMロール連携の設定方法は、わかりやすいこちらのマニュアルをご覧ください。
※マニュアルの確認には、cloudpack+ PORTALへログインが必要です。
もし「ちょっと難しそう…」と感じたら、お気軽にお問い合わせください！
※cloudpack+をご利用中のお客様のみの窓口となります
最後に
これからも、よりご満足いただけるサービスをお届けできるよう、チーム一丸となって取り組んでいきます！
「cloudpack+サービスやツールがちょっと気になる…」そんな方は、こちらのcloudpack+のページも是非ご覧ください！詳しいサービスの内容や、申し込みの流れなどがわかります。
また、「サイトを見るほどの時間がない…」という方は、1分半でわかる！cloudpack+の動画をぜひご視聴ください！👇
今後も随時、cloudpack+の便利なサービスについてご紹介してまいります！お楽しみに！
簡単30秒