Oracle Cloud無料サーバーの安定化、エフェメラルIPの正体とUFW・Swap・タイムゾーン設定

前回、無事に「Welcome to nginx!」の画面を表示させるところまで到達したものの、このまま実運用に入るには少々不安が残る状態でした。外部からの疎通テストのために sudo iptables -F でファイアウォールを全開放したまま放置していましたし、サーバーに割り当てられたパブリックIPもOracleによって自動付与されたものをそのまま使っていたからです。将来的に独自ドメインを紐付けてWebサービスを公開する予定なので、まずは「このIPアドレスは勝手に変わってしまう一時的なものなのか？」を確かめる必要がありました。

そこで今回は、IP仕様の確認を皮切りに、ファイアウォールの再構築、スワップ領域の確保、タイムゾーン設定まで、24時間常時稼働させても安心できる状態にサーバーを整える（安定化させる）ことにしました。

結論から言うと、UFWによるFW再構築・Swap 4GB・JST設定は20分ほどでスムーズに完了したのですが、パブリックIPの固定化（予約済IPへの変更）については「現在のIPアドレスを維持したまま固定化することはできない」というOCIの仕様の壁にぶつかり、アドレス解放の一歩手前で手を止めることになりました。

検証環境: 2026年10月時点 / ホームリージョン: Japan East (Tokyo) / OCIコンソール: 日本語表示（英語併記） / OS: Canonical Ubuntu 24.04 / シェイプ: VM.Standard.A1.Flex (2 OCPU / 12GB RAM) / 作業端末: Windows 11 前回の記事: Oracle Cloud無料サーバー、登録からPAYG移行とAmpereインスタンス作成まで

予約済パブリックIPの一覧が空だった理由

インスタンス作成時にOracle側で自動的に割り当てられるパブリックIPは、通常「エフェメラル・パブリックIP（Ephemeral Public IP）」と呼ばれます。一時的な動作確認ならこれでも問題ありませんが、将来的に独自ドメインを紐付けるのであれば、IPが変動しない「永続的な固定IP」であるかどうかが極めて重要になります。そこでまずは、自分のアカウントに固定IPとして予約済のアドレスが存在しているかを確認しに行きました。

[ナビゲーション・メニュー (≡)] > [ネットワーキング (Networking)] > [IP管理 (IP Management)] > [予約済パブリックIP (Reserved Public IPs)]

画面を開いてみると、テーブルには「アイテムがありません」という案内が出ているだけで、完全に空っぽ（0件）の状態でした。前回確かにパブリックIPが払い出されてSSH接続までできているのに、なぜ一覧に表示されないのかと一瞬戸惑いましたが、理由は単純でした。現在インスタンスが保持しているのは「予約済IP（固定IP）」ではなく「エフェメラルIP（動的・一時IP）」だったため、予約済IPの管理画面にはリストアップされなかったわけです。

画面上部にある [パブリックIPアドレスの予約 (Reserve public IP address)] を押せば、新規に固定IPを発行するダイアログが開きます。しかし、ここで発行してしまうと、現在サーバーが使用しているIPとは無関係な新規IPがもう1つ追加されてしまうだけです。そのため一旦キャンセルし、インスタンス側の設定画面から現在のIPの状態を詳しく調べに行くことにしました。

インスタンスのVNICでIPのライフタイムを確認

IPの正確な種別やライフタイムは、インスタンスにアタッチされている仮想ネットワークカード（VNIC）の詳細設定まで潜らないと確認できません。たどった経路は次のとおりです。

[ナビゲーション・メニュー (≡)] > [コンピュート (Compute)] > [インスタンス (Instances)] > インスタンス名 > [ネットワーキング (Networking)] タブ > [アタッチされたVNIC (Attached VNICs)] > プライマリVNIC名 > [IP管理 (IP administration)] タブ

各画面で確認できた内容を整理すると、次のようになります。

画面	確認した内容
インスタンス一覧	instance-20260810-2215、実行中、プライベートIP 10.0.0.165、A1.Flex 2 OCPU / 12GB、作成 2026-08-10 14:02:17 UTC
インスタンス詳細	AD-1、ap-tokyo-1、オンデマンド。パブリックIPは表示されるが固定かどうかは判別不能
ネットワーキング・タブ	プライマリVNIC、プライベートIP 10.0.0.165、subnet-20260810-2217
VNIC詳細のプライマリIP情報	パブリックIPアドレスの横に「エフェメラル」、割り当て 2026-08-10 14:02:21 UTC
VNICのIP管理タブ	IPv4アドレス一覧のIPライフタイムが「エフェメラル」

ここで前回の謎がひとつ解けました。前回の作成ログに残っていたインスタンス名は instance-20260810-1357 でしたが、実際に稼働しているインスタンス名は instance-20260810-2215（作成日時: 8月10日 14:02 UTC）となっていたのです。スタックの初回再試行ログが 06:02 UTC でしたので、その日の夜23時頃（JST）にあらためてインスタンスを作り直して成功していたことがわかりました。コンソールの画面をじっくり見返して、ようやく当時の状況を把握できました。

そして「プライマリIP情報」の画面を開いた瞬間、IPの正体についての疑問もすべて解消しました。パブリックIPアドレスのすぐ横に「エフェメラル」というラベルがしっかりと明記されていたのです。割り当て日時もインスタンス起動とほぼ一致する 14:02:21 UTC でした。つまり、前回の作成時に「設定トグルがOFFのままだったのになぜか付与されていたパブリックIP」の正体は、インスタンスプロビジョニング時にOCI側で自動付与されたエフェメラルIPだったというわけです。

ここから予約済固定IPへ切り替えられないかと考え、IPv4アドレス行の右端にある [⋯] メニューから [編集 (Edit)] を開いてみました。

エフェメラルIPは番号のまま固定にできない仕様の壁

プライベートIPアドレスの編集画面が開きましたが、パブリックIPタイプの選択肢には次の2つしか存在しませんでした。

• パブリックIPなし (No public IP)
• エフェメラル・パブリックIP (Ephemeral public IP)

表示された選択肢は上記の2つのみ。目当ての「予約済パブリックIP」はどこにも見当たりませんでした。

OCIの公式仕様を確認したところ、これがOracle Cloudの基本的な仕様であることが判明しました。すでにインスタンスに割り当てられているエフェメラルIPのアドレス番号を維持したまま、予約済IP（固定IP）へ昇格させる機能は用意されていません。 予約済IPを割り当てたい場合は、必ず次の2段階の手順を踏む必要があります。

1. [編集] で [パブリックIPなし] を選択して [更新] を押し、現在のアドレスを一度完全に解放する
2. 再度 [編集] を開き、その際に選択可能になる [予約済パブリックIP] を選んで新規IPを割り当てる

つまり、この切り替えを行うとIPアドレスの変更が不可避となります。

区分	エフェメラル・パブリックIP（デフォルト）	予約済パブリックIP（固定IP）
料金	無料（自動で付与）	無料（1アカウントあたり1つまで無料枠内）
インスタンス終了時	IPは自動的にプールへ回収される	アカウント内にIPアドレスが保持される
番号を維持した昇格	不可（解放後に新規発行が必要）	新規発行してインスタンスに再アタッチ
向いている用途	一時的な接続テスト、短期の検証	ドメイン運用、常時稼働の本番サーバー

実際に [パブリックIPなし] を選択してみると、「エフェメラル・パブリックIPの割り当てが解除されます」という警告メッセージが表示されました。ここで [更新] を押した瞬間に現在のIPが剥奪され、接続中のSSHセッションを含め、外部からのアクセスは即座に切断されます。

もしこのIPをまだ外部のDNSや他サービスに登録していない構築初期段階であれば、このタイミングで一度解放し、新規の予約済IPを払い出して付け直すのがベストプラクティスです。アドレス番号こそ変わってしまいますが、一度予約済IPにしておけば、将来インスタンスを停止・再構築しても同じIPアドレスをアカウントに保持し続けられます。OCIの無料枠では「パブリックIPv4アドレスが1つ」まで無料ですので、エフェメラルIPを解放して予約済IPに切り替える構成であれば追加費用も一切かかりません。逆に、すでにこのIPを重要な設定に登録してしまっている場合は、慎重な判断が求められます。

私は更新ボタンを押す直前で一旦作業をストップしました。なぜここで保留にしたのかは、記事後半の「今後の課題」で触れます。

エフェメラルIPの挙動に関する考察: 技術系ブログ等では「OCIコンソールからインスタンスを停止（Stop）して再起動するとエフェメラルIPが変わってしまう」「SSHターミナルから sudo reboot するだけならIPは維持される」といった体験談が散見されます。一方でOracleの公式ドキュメントには「エフェメラル・パブリックIPであっても、インスタンスを完全に終了（Terminate）するまでは維持される」と受け取れる記述もあり、ネット上の情報とドキュメントの間で少し見解が分かれている印象です（※現時点で自ら停止・起動を試しての検証は行っていません）。不用意にIPが変わってしまうと面倒ですので、当面の間はWebコンソールからの停止操作は行わず、再起動が必要な際はターミナルから sudo reboot を実行する運用に留めることにしました。

UFWでファイアウォールを立て直す

前回は疎通テストを最優先にするため sudo iptables -F でルールを全消去し、sudo netfilter-persistent save でそのまま保存していました。テスト時には手軽ですが、これではサーバーのポートが丸裸のノーガード状態ですので、実運用に向けてしっかり立て直す必要があります。iptablesの複雑なチェインを直接コマンドで組み立てるより、Ubuntuで標準的に使われる直感的なUFW（Uncomplicated Firewall）のほうが扱いやすいため、今回はUFWで再構築しました。OCI標準のUbuntuイメージに組み込まれていた初期iptablesルールは前回すでにフラッシュしているため、既存ルールとの競合を気にせずクリーンに設定できます。

【超重要】: 必ずファイアウォールを有効化（enable）する前に、SSH用の22番ポートを明示的に開放（allow）しておくことです。順番を誤ってFWを先に有効化してしまうと、接続中のSSHセッションが強制切断され、サーバーから完全に締め出されて二度と接続できなくなる（いわゆるセルフ締め出し）という大惨事になります。

# SSH、HTTP、HTTPSだけを開放
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# ファイアウォールを有効化する
sudo ufw enable

# 状態と許可ポートを確認
sudo ufw status verbose

sudo ufw enable を実行すると、「既存のSSH接続が中断される可能性がありますが続行しますか？（Command may disrupt existing ssh connections. Proceed with operation (y|n)?）」という確認が出るので、y を入力してEnterを押します。その後 sudo ufw status verbose を実行し、Status: active とともに22・80・443ポートの ALLOW IN ルールが正しく表示されれば設定完了です。

なお、前回OCIのセキュリティ・リスト側で開放した8080ポートは、現時点で動作させるサービスがないため今回のUFWルールには追加していません。Oracle側のインフラレベルでの制御（イングレス・ルール）とUbuntu内部のホストFW（UFW）の2段構えで、安全な通信経路を確保できました。

Swap 4GBでOOMに備える

今回割り当てたAmpereインスタンスはRAMが12GBあるため、通常の小規模Webサーバー用途であればメモリ不足に陥ることはまずありません。しかし、重いDockerイメージのビルドを実行したり、アクセススパイクが発生したりした際に、OOM（Out of Memory）Killerが発動して主要プロセスが突然強制終了されるリスクを避けるため、安全マージンとして4GBのSwap領域を確保しておくことにしました。ディスク（ブートボリューム200GB）の空き容量をスワップファイルとして割り当てるだけなので、追加料金は一切発生しません。

# 4GBのスワップファイルを作成
sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile

# スワップ領域として初期化して有効化
sudo mkswap /swapfile
sudo swapon /swapfile

# サーバー再起動後も永続化されるよう fstab に登録
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

# スワップの割り当て状況を確認
free -h

chmod 600 は、メモリ内容がダンプされるスワップファイルに対して他ユーザーから読み書きされないようパーミッションを厳格化するための設定です。また、/etc/fstab に定義を追加しておかないとサーバー再起動時にスワップが自動マウントされません。最後に free -h を実行し、Swap行の「total」に 4.0Gi と表示されていれば設定完了です。

タイムゾーンを日本時間（JST）に変更する

UbuntuサーバーのデフォルトタイムゾーンはUTC（協定世界時）に設定されているため、システムログの記録時刻やcronのスケジュール実行時刻が日本時間（JST）から9時間遅れて動作します。トラブルシューティングでログを解析するたびに脳内で「+9時間」の時差計算をするのは地味にストレスですし、監視や定期バッチの時刻設定ミスを誘発する原因にもなります。サーバー自体のロケーションも東京リージョンに置いていますので、迷わずJST（Asia/Tokyo）へ切り替えておきます。

sudo timedatectl set-timezone Asia/Tokyo
date

コマンド実行後、date の出力結果の末尾が JST に切り替わっていれば設定完了です。

ハマったポイントと気付き

• エフェメラルIPをそのまま固定IP化できない仕様: 最も戸惑ったのは、既存のエフェメラルIPを維持したまま予約済IPへ昇格させる設定が存在しない点でした。編集画面の選択肢は「なし」か「エフェメラル」の2択のみで、予約済IPを割り当てるには現在のIPを一度完全にデタッチ（解放）しなければなりません。「どこかに固定化のチェックボックスが隠れているのでは？」と管理コンソールの各タブやメニューを小一時間探し回ってしまいましたが、見落としではなくOCIの根本的な仕様でした。

今後の課題と次回予告

エフェメラルIPを解放して新規の予約済IPへ切り替えるかどうかは、現時点ではあえて保留としています。独自ドメインを接続する段階までには固定化を完了させておく必要がありますが、IPアドレスを変更した瞬間に手元のSSH接続情報も切り替える必要があるため、ドメイン設定の記事で一連の作業としてまとめて実施する予定です。

また、Webコンソールからの停止・起動でエフェメラルIPが本当に再割り当て（変更）されてしまうのかについても、機会を見て実際に検証してみたいと考えています。

次回は、この安定化したサーバー上に独自ドメインを紐付け、Nginxのリバースプロキシ設定とLet’s Encryptによる無料SSL/TLS証明書を導入してHTTPS化を完了させる手順をまとめていきます。

参考にした情報

• https://cloud.oracle.com
• https://docs.oracle.com/en-us/iaas/Content/Network/Tasks/managingpublicIPs.htm