Oracle Cloud無料サーバー、登録からPAYG移行とAmpereインスタンス作成まで

Oracle CloudのAlways Free（常時無料枠）でAmpere（ARM）サーバーが無料で使えると聞き、個人開発や検証用のサーバーを1台確保しておくことにしました。無料枠の仕様は以前からアップデートされており、現在の基準ではAmpere A1インスタンスで2 OCPU / 12GB RAM、ブートボリューム最大200GB、パブリックIPv4アドレスが1つまで無料で利用できます。このハイスペックなサーバー環境が完全無料で手に入るなら、試さない手はありません。

結論から言うと無事にサーバーは立ち上がったのですが、途中でしっかり2回ハマりました。アカウント登録時のクレジットカード認証で1回、そしてインスタンス作成時の「Out of Capacity（容量不足）」エラーでもう1回です。本記事では、アカウント登録からNginxの初期画面が表示されるまで、実際に試行錯誤した流れを時系列でそのまま記録しています。

検証環境: 2026年8月時点 / ホームリージョン: Japan East (Tokyo) / OS: Canonical Ubuntu 24.04 / シェイプ: VM.Standard.A1.Flex (2 OCPU / 12GB RAM) / ブートボリューム: 200GB / 作業端末: Windows 11 ノートPC（アカウント登録は社内ネットワーク、以降の作業は自宅Wi-Fi）。当時のOCI Webコンソールは英語UIで操作していたため、本記事内のメニュー表記は英語UIをベースに記載しています。

作業全体の流れは次のとおりです。

1. アカウント登録（基本情報の入力とホームリージョンの選択）
2. クレジットカード認証（約1ドルのテスト決済）
3. PAYGへのアップグレード（約100ドルの仮売上）
4. インスタンス作成（Ampere 2 OCPU / 12GB）
5. ファイアウォールを2箇所で開放（OCIのイングレス・ルールとUbuntuのiptables）
6. SSH接続とNginxでの初期表示確認

登録前に準備したもの

• 海外決済に対応したVisaまたはMastercardのクレジットカード
• 英語表記の住所（番地、町名、市区町村、都道府県、郵便番号の順）
• SMSを受信できる携帯電話番号（国番号+81、先頭の0を除いた形式）

デビットカードを利用する場合は、登録時のテスト決済（約1ドル）とPAYG移行時の仮売上（約100ドル相当＝日本円で約1万5千円前後）の与信枠確保に対応できるよう、口座にあらかじめ十分な残高（最低でも1万5千円〜2万円以上）を入れておく必要があります。

基本情報の入力とホーム・リージョン

まずは cloud.oracle.com にアクセスし、「Start for free」から登録を進めました。入力した主な項目は次のとおりです。

項目	入力内容	備考
Country	Japan
First Name / Last Name	カード名義と同じローマ字
Email	認証コードを受け取れる実際のアドレス	届いたメールの Verify email を押すと次の入力が開く
Password	英大文字・小文字・数字・記号の組み合わせ
Account Type	Individual	個人アカウント
Cloud Account Name	英小文字と数字の管理者ID	以後ログインのたびに使う重要な値
Home Region	Japan East (Tokyo)	あとから二度と変更できない
Address / Phone	英語表記の住所、+81形式の電話番号

メール内の「Verify email」をクリックして認証を完了しないと次の入力項目が表示されない仕様のため、画面が次へ切り替わればメール認証は無事通過です。

ホームリージョンは「Japan East (Tokyo)」を選択しました。日本国内からであれば「Japan Central (Osaka)」も有力な候補ですが、ホームリージョンは一度決めると後から二度と変更できないため、迷う前にあらかじめ決めておくべき最重要ポイントです。画面左側のサマリーでHome RegionがJapan East (Tokyo)になっていることを再確認し、決済情報の入力ステップへと進みました。

続いて、本人・決済確認のための請求先情報（Billing Information）を入力します。氏名、住所、郵便番号、連絡先はすべて英語表記で入力しました。

カード認証エラーの壁：自宅回線で弾かれ続けた原因と対策

自宅のWi-Fi環境からクレジットカードを登録しようとしたところ、決済承認の段階で弾かれてしまいました。カード番号や名義を念入りに見直し、何度入れ直しても同じ画面で止まってしまいます。画面には「アカウント作成中にエラーが発生しました」という警告メッセージが出るだけで、具体的な理由は一切書かれていません。

調べてみると、Oracle側の不正防止セキュリティチェックはかなり厳格で、接続元のIP環境や短時間での連続決済試行を「不審なアクセス」と判定して自動ブロックしてしまうケースが非常に多いようです。

今振り返ると、焦ってその場で何度も再試行してしまったのが最大の失敗でした。同一環境・同一ネットワークから拒否ログが積み重なることで、セキュリティフィルターにさらに厳しく弾かれやすくなる悪循環に陥っていたようです。実際、どれだけ間隔を空けずに押し直しても結果は変わりませんでした。

自宅での登録はいったんあきらめ、翌日オフィスの回線を使って最初から登録プロセスをやり直してみました。すると……カードも名義も入力情報もまったく同じなのに、ネットワーク（IP環境）を変えただけで、何事もなかったかのようにあっさり通過しました。

スマホに約1ドルのテスト決済通知（SMS）が届き、ほどなくしてアカウント登録完了メールを受信。無事に第一関門を突破できました。なお、このテスト決済はカードの有効性確認用の一時的なものなので、後日自動的に返金・キャンセルされます。

ここでひとつ、強くお伝えしたい教訓があります。カード認証が一度でも弾かれたら、その場ですぐに再試行するのは絶対に避けてください。

ブラウザをリロードして同じカードで押し直すのはもちろん、慌てて別のカードに切り替えて入力するのもNGです。同じネットワークから連続で試行してもブロック履歴が増えるだけで、状況は好転しません。一度弾かれてしまったら、翌日まで時間を置くか、オフィスの回線やスマホのテザリングなど、全く別のネットワーク環境に移って最初から登録をやり直すことを強くおすすめします。

自宅に戻ってログイン、ホーム・リージョンは東京

アカウント登録さえ別の回線で済ませてしまえば、それ以降の操作は自宅のWi-Fiからでも全く問題ありませんでした。実際、これ以降の作業はすべて自宅のネットワークで行っています。cloud.oracle.com でテナンシ名（登録時に決めたCloud Account Name）を入力してログインしました。

ログイン後、画面上部のリージョンメニューを開くと、指定どおりホームリージョンが「Japan East (Tokyo)」となっており、1つのリージョンのみをサブスクライブしている状態であることが確認できました。

PAYGに移行した理由と手順

無料枠（Free Tier）のアカウントのままだと、インスタンス作成時にリソース不足、いわゆる「Out of Capacity」エラーで弾かれることが非常に多いと言われています。一方、従量課金プランであるPAYG（Pay As You Go）へアップグレードすると、有料顧客として優先的にリソースが割り当てられるため、すんなり作成できるという情報・体験談を多く見かけました。PAYGに移行してもAlways Free枠の範囲内で運用する限り請求は0円ですので、迷わず即座にアップグレードすることにしました。

区分	無料アカウントのまま	PAYGに移行
インスタンス作成	Out of Capacityで弾かれやすい	有料枠として優先割り当て（とされる）
請求額	0円	Always Free範囲内（2 OCPU / 12GB / ディスク200GB）なら0円
移行時の仮売上	なし	約100ドル（数日で自動取消）

コンソールの操作手順は次のとおりです。

[ナビゲーション・メニュー (≡)] > [Billing & Cost Management] > [Upgrade to Pay As You Go] > 支払いカードを選択 > [Upgrade Account]

アップグレードを申し込むと、すぐに約100ドル相当（為替レートによりますが、日本円で1万5千円前後）の仮売上（オーソリ・与信枠の確保）が発生します。これはカードの有効性を確認するための一時的なもので、実際の請求にはならず、私の環境でも数日以内に自動で全額キャンセル（枠の解放）が行われました。カード会社から利用速報の通知が届いたことで、アップグレード申請が無事に受理されたことを確認できました。

インスタンス作成と設定値

インスタンス作成画面にはダッシュボードの [Create a VM instance] から入りました。メニューからたどる場合は次の経路です。

[ナビゲーション・メニュー (≡)] > [Compute] > [Instances] > [Create instance]

最終的に指定した設定値をまとめると次のようになります。

項目	設定値	備考
Name	instance-20260810-1357	自動入力のまま
Availability domain	AD-1	デフォルトのまま
Capacity type	On-demand capacity	Advanced options のデフォルト値
Image	Canonical Ubuntu 24.04	デフォルトは Oracle Linux 9
Shape	VM.Standard.A1.Flex	Ampere、2 OCPU / 12GB
Shielded instance	オフ	Security ステップ
Primary network	Create new virtual cloud network	デフォルトは既存VCNの選択
Subnet	Create new public subnet	CIDR 10.0.0.0/24 が自動入力
Public IPv4 address	自動割り当て（後述のとおり有効にできず）
SSH keys	Generate a key pair for me	秘密鍵・公開鍵の両方をダウンロード
Boot volume	200GB、VPU 10	Always Free の上限

インスタンス名は自動生成された「instance-20260810-1357」のままにしました。用途に合わせて分かりやすい名前に変えても良いのですが、今回はデフォルトのまま進めています。

イメージをUbuntuに、シェイプをAmpereに

デフォルトのOSイメージは「Oracle Linux 9」になっています。私は普段から使い慣れているUbuntuのほうが扱いやすいため、Ubuntuに変更しました。「Image」セクションの [Edit] から「Canonical Ubuntu 24.04」を選択して [Select image] をクリックし、設定一覧でイメージ名が正しく切り替わっていることを確認します。

シェイプの初期値はAMDベースの「VM.Standard.E2.1.Micro (1 OCPU / 1GB)」になっています。「Always Free-eligible（常時無料対象）」のバッジは付いていますが、スペック的に心もとないため、パワフルなAmpere（ARM）に変更します。

Shape の Edit > [Browse all shapes] > Shape series で [Ampere] > [VM.Standard.A1.Flex]

A1.Flex を選択するとデフォルト値は「1 OCPU / 6GB」になっているので、OCPU を 2、メモリを 12GB に変更して [Select shape] をクリックしました。

設定時の注意点: OCIのAlways Free枠で無料になるAmpere A1のリソースは、現在「2 OCPU / 12GB RAM」までです。ところが、OCPUとメモリを4 OCPU / 24GBまで上げても、画面上の「Always Free-eligible」バッジは表示されたままでした。私も一度4 OCPU / 24GBの状態まで進めてしまい、あとから「2 OCPU / 12GB」に直しています。バッジの表示だけを鵜呑みにせず、数値が無料枠の上限内に収まっているかを自分で確認する必要があります。

Basic information のサマリーでシェイプが Ampere A1.Flex になっているのを確認して次へ進み、Security ステップの「Shielded instance」はオフのまま通過しました。

ネットワーキングと、オンにならないパブリックIPトグル

Networking のデフォルト値は「Select existing virtual cloud network」です。初めて作成するアカウントのため既存のVCNは存在せず、変更が必要でした。

「Create new virtual cloud network」に切り替えると、VCN名（vcn-20260810-1415）、Create new public subnet、サブネット名（subnet-20260810-1415）、CIDR 10.0.0.0/24 が自動で入力されました。値が埋まったことを確認し、そのまま進めます。

ここでひとつ不可解な問題に直面しました。「Public IPv4 address assignment」の項目です。インターネット経由でSSH接続したりWeb公開したりするにはパブリックIPが必須なため自動割り当てを有効にしたいのですが、トグルスイッチが無効（オフ）のままグレーアウトしており、次の警告メッセージが表示されていました。

You must select a public subnet to assign a public IPv4 address

「Create new public subnet」を選択して新規のパブリックサブネットを作る設定にしているにもかかわらず、なぜかパブリックサブネットが選ばれていないと判定されてトグルが操作できませんでした。

SSHキーとブート・ボリューム200GB

SSHキーペアは、サーバーログイン時の認証鍵（パスワード代わり）です。「Generate a key pair for me」を選択した状態で [Download private key] と [Download public key] をそれぞれクリックし、手元のダウンロードフォルダに秘密鍵（.key）と公開鍵（.pub）の2つのファイルが保存されたことを確認します。秘密鍵は C:\OracleKey など、自分専用の安全なフォルダを作成して移動させておきました。この秘密鍵を紛失すると、サーバーへのログイン手段が完全に失われるため厳重に保管しておく必要があります。

Storage ステップのデフォルト値は、ブートボリューム46.6GB、カスタムサイズのトグルはオフ、in-transit encryption はオンでした。「Specify a custom boot volume size」をオンにして 200GB、VPU 10 に設定すると、「12,000 IOPS、96MB/s、Balanced」と表示が変わったので正しく反映されたことを確認しました。ディスクはAlways Freeの上限が合計200GBですので、せっかくの無料枠なら最初から上限いっぱいまで活用することにしました。

ReviewとOut of Capacityエラー

Review画面で入力値を順に確認しました。

Review の項目	表示内容
Basic information	名前、AD-1、on-demand、Canonical Ubuntu 24.04
Shape	VM.Standard.A1.Flex
Networking	新しいVCNとサブネット名、CIDR、Public IPv4 address: No
SSH keys / Boot volume	ssh-rsa の公開鍵、200GB、VPU 10、in-transit encryption Enabled

Networking項目の「Public IPv4 address」は「No」のままでした。「やっぱりダメか……」という心境です。全体の入力ステップを完了したあとに再度Networking設定に戻ってみましたが、トグルは相変わらず無効化されたままで警告も消えませんでした。この時点でパブリックIPのトグルをONにできたのか、あるいはインスタンス作成後に別途割り当てられたのかはログだけでは判然としませんでしたが、とりあえず前へ進めることにしました。

祈る思いで [Create] ボタンをクリック。……が、あえなく次のAPIエラーで弾かれてしまいました。

Out of capacity for shape VM.Standard.A1.Flex in availability domain AD-1.
Create the instance in a different availability domain or try again later.

無料アカウントで頻発すると噂の容量不足エラーですが、まさかPAYGにアップグレードした直後にも食らうとは思っておらず、少なからず面食らいました。

Resource Managerのスタックで再試行

エラー画面の下部に [Save as stack] ボタンが表示されていたため、入力した構成情報をOCIの「Resource Manager」にスタック（Terraform定義）として保存する方法へ切り替えることにしました。エラーで弾かれるたびにWeb画面の長い入力フォームを最初から埋め直す手間を避けるためです。

手順	内容
Save as stack	Stack origin: Compute instance、Terraform 1.5.x
Review	Run apply にチェックして Create（スタック作成と同時に apply）
1回目の apply ジョブ	06:02 UTC に Accepted で開始、最終的に Failed
2回目の apply ジョブ	スタック画面で Apply を再実行、Automatically approved、06:06 UTC に Accepted

Resource Manager の Stacks 一覧でスタックが「Active」になっているのも確認しました。

試行錯誤の末、サーバーは最終的に無事作成できました（2回目のジョブで通ったのか、時間を置いて再実行したのかはこの時点のログでは曖昧でしたが、この謎は第2回で明らかになります）。インスタンス一覧画面でステータスがオレンジ色の「PROVISIONING」から鮮やかな緑色の「RUNNING」へと遷移したのを確認できたときはホッとしました。表示されたパブリックIPアドレスをコピーし、次の接続確認へ進みます。

ファイアウォールを2箇所で開放する

外部からサーバーへHTTP/HTTPS等でアクセスできるようにするには、2箇所のファイアウォール（FW）を開放する必要があります。1つはOracle側の仮想ルーターに設定する「セキュリティ・リスト（Security List）」、もう1つはUbuntuサーバー内部の「iptables」です。

まずはOracle側です。次の経路で Ingress Rules を追加しました。

[ナビゲーション・メニュー (≡)] > [Networking] > [Virtual Cloud Networks] > 自分のVCN > [Default Security List] > [Add Ingress Rules]

項目	設定値
Source CIDR	0.0.0.0/0
IP Protocol	TCP
Destination Port Range	80, 443, 8080

続いてサーバー内部のファイアウォールです。サーバー内部を操作する必要があるため、次の節のSSH接続を済ませたあとに入力しました。

sudo iptables -F
sudo netfilter-persistent save

sudo iptables -F は既存のパケットフィルタリングルールをすべてフラッシュ（全消去）するコマンドで、sudo netfilter-persistent save はその初期化状態を永続保存します。すべてのルールを丸ごとクリアする強引な方法なのでセキュリティ的には少し躊躇したものの、まずは外部からの疎通確認を最優先にするため、いったんこの手順で進めました（※このセキュリティホールは、第2回でUFWを導入してしっかり塞ぎ直します）。ポートが正常に開放されたかどうかは、このあとのNginx接続確認で検証します。

SSH接続とNginxの表示確認

作業端末はWindowsですので、[Win] + [R] で cmd（コマンドプロンプト）を起動しました。接続コマンドは次のとおりです。

ssh -i "C:\OracleKey\<秘密鍵ファイル名>.key" ubuntu@<パブリックIP>

初回接続時にホスト鍵の確認（fingerprint）を求められますが、yes と入力してEnterを押せばログインできます。ターミナルのプロンプトがサーバー側の表記（ubuntu@instance-...:~$）に切り替われば、SSH接続成功です。

続いてNginxをインストールしました。

sudo apt update && sudo apt install -y nginx

インストール完了後、念のため先ほどのiptablesの2行をもう一度実行しました。

ブラウザを立ち上げ、アドレスバーに http://<パブリックIP> を入力してアクセスします。無事に「Welcome to nginx!」のデフォルトページが表示されました！この画面が確認できれば、OCIの仮想ネットワークからUbuntu内部のポート開放、そしてWebサーバーの稼働まで、すべての通信経路が正常に通っている証拠です。

ハマったポイントと教訓

• クレジットカード決済のエラー: 自宅回線で何度入力し直しても弾かれ続けましたが、翌日オフィスのネットワークから再登録したところ一発で通りました。一度弾かれたらその場で無理に再試行を繰り返さず、環境を変えて最初からやり直すのが最も確実な対処法でした。
• シェイプの割り当てスペック: 無料枠の上限は2 OCPU / 12GBですが、4 OCPU / 24GBに上げても無料対象バッジは表示されたままです。私も一度4 OCPU / 24GBまで上げてから「2 OCPU / 12GB」に直しました。画面上のバッジだけを過信せず、数値が上限内かどうかを手動で確認する必要があります。
• Out of Capacity（容量不足）エラー: PAYGにアップグレードすれば即時作成できるというネットの体験談を信じていましたが、実際にはあっさり弾かれました。しかしエラー画面から「Save as stack」で構成を保存しておいたおかげで、Webフォームを再入力することなくResource Managerからスムーズに再試行することができました。
• パブリックIP割り当てトグルの無効化: 新規パブリックサブネットを指定していたにもかかわらず、作成画面のトグルが有効化されませんでした。結果的にはパブリックIPが割り当てられてSSH接続できたものの、これがどのタイミングで付与されたのかは謎が残り、次回の検証課題となりました。

今後の課題と次回予告

パブリックIPのトグルがなぜ有効にならなかったのか、そして現在割り当てられているパブリックIPのライフタイム（一時的なものか固定か）については、OCI管理コンソールから詳細を調査する予定です。

次回は、このサーバーのIPの正体を突き止めつつ、iptables -F で全開放したままのファイアウォールをUFWで強固に再構築し、Swap領域の確保やタイムゾーンのJST設定など、サーバーを本番運用に耐えうる状態へと安定化させていく手順をまとめます。

参考にした情報

• https://cloud.oracle.com