計算・保存・ネットワーク｜クラウドの基本・IAM・責任

このページはプロモーション（広告）を含みます。

クラウドの基本・IAM・責任（初級・読む30分＋演習35分）

この授業のゴール

• 処理の性質（常時稼働か、短時間か、イベントで起動か）から、仮想サーバー・コンテナ・関数実行のどれを使うか選べる
• オブジェクト保存・ブロック保存・ファイル保存・マネージドDBの違いを、アクセスの仕方と用途で説明できる
• CIDR表記からアドレスの範囲と個数を求め、公開サブネットと非公開サブネットに資源を配置できる
• 受信ルールの表を読み、ある送信元とポートの通信が許可されるかをPythonで判定できる

仕事でどう使うか

クラウドで借りるものは、大きく計算（処理を動かす場所）、保存（データを置く場所）、ネットワーク（つなぎ方と通してよい通信）の3つに分かれます。構成図はこの3つの組合せで描かれ、費用や事故の多くもこの3つの選び方で決まります。

サービス名は提供者ごとに違いますが、この授業では一般名で説明します（名前の対応は 「サービス名と役割」（有料版））。料金やサービスの細部は変わるため、執筆時点（2026年）の一般的な説明として読み、最新は公式情報で確認してください。ネットワークの判定はPythonによる模擬で、実際のクラウドの設定画面とは表記が異なります。

前提

次の言葉を使います。

• IPアドレス：ネットワーク上の機器の住所。192.168.1.10 のように、0〜255の数4つを点で区切って書く（IPv4）。
• ポート：1台の機器の中で、どの窓口（サービス）に届けるかを示す番号。HTTPSは443、SSH（遠隔ログイン）は22、PostgreSQL（データベース）は5432が一般的。
• HTTP・API → 「HTTPと要求応答」（有料版）
• IaaS / PaaS → クラウドとオンプレミス

Pythonでは、標準ライブラリ ipaddress を使います。リストと辞書、for 文、any() が読めれば十分です。

身近な状況：画像分類の試作を「全部1台」で作る

みなと商店の分析者が、商品画像の自動分類を試作しています。最初の構成は次のとおりでした。

• 仮想サーバー1台に、画像ファイル 50,000枚（合計200GB）、PostgreSQL（データベース）、学習用のコード、予測APIを全部入れた。
• 外から接続できるよう、受信ルールを「すべての送信元（0.0.0.0/0）から、すべてのポートを許可」にした。

1か月後に起きたこと：

1. 学習中はAPIの応答が極端に遅くなった（同じ機械で重い計算と常時の処理が取り合った）。
2. ディスクが満杯になり、DBが止まった。
3. インターネット中から、DBのポート5432にログインを試す通信が大量に届いていた。

どれも「機能が足りない」のではなく、計算・保存・ネットワークの選び方の問題です。この授業の最後には、この構成を次のように分けられるようになります。

直感的な説明：工場・倉庫・道路と門番

3つの柱を、町の設備にたとえます。

• 計算＝工場：材料を加工する場所。いつも動く工場（常時稼働のサーバー）もあれば、注文が来たときだけ動く臨時の作業場（関数実行）もある。
• 保存＝倉庫：大量の箱に番号札を付けて積む倉庫（オブジェクト保存）、工場の作業台に直結した棚（ブロック保存）、複数の工場から同時に使う共有棚（ファイル保存）、索引付きの帳簿係（DB）がある。
• ネットワーク＝敷地と道路と門番：自社の敷地（仮想ネットワーク）を区画（サブネット）に分け、表通りに面した区画（公開）と奥の区画（非公開）を作る。門番（受信ルール）は「どこから来た人を、どの窓口に通すか」の名簿を持つ。名簿にない人は通さない。

ポイントは、大事な帳簿（DB）を表通りに置かないこと、そして門番の名簿に「誰でも・どの窓口でも」と書かないことです。

たとえ話の限界：実際のオブジェクト保存は「敷地の外」にあり、ネットワークの区画ではなく権限設定（IAMと最小権限）と公開設定で守ります。区画だけ見て安心すると、保存場所の公開設定の誤りを見落とします。

正確な定義：3つの柱の種類

計算（compute）

保存（storage）

ネットワーク（network）

• 仮想ネットワーク（VPC：Virtual Private Cloud などと呼ばれる）：クラウドの中に作る、自分専用の論理的なネットワーク。
• サブネット：仮想ネットワークを区切った範囲。インターネットとの出入口に経路があるものを公開サブネット、ないものを非公開サブネットと呼ぶ。
• CIDR（Classless Inter-Domain Routing）表記：10.0.1.0/24 のように書き、/ の後ろの数 $p$ は「先頭から $p$ ビットが固定」を意味する。IPv4は32ビットなので、範囲に含まれるアドレス数は

$$N = 2^{32-p}$$

$p=24$ なら $N=2^{8}=256$ 個（10.0.1.0〜10.0.1.255）、$p=26$ なら $2^{6}=64$ 個。提供者によっては、範囲の先頭などの数個が予約されて使えません。0.0.0.0/0 は $p=0$ で、すべてのアドレス（＝インターネット全体）を表します。
- 受信ルール（ファイアウォールルール、セキュリティグループなどと呼ばれる）：「送信元の範囲（CIDR）」「ポート」の組を許可として列挙し、どれにも当たらない通信は拒否する（既定拒否）。

段階付き例題：受信ルールで通信の可否を判定する

問題：予測APIのサーバーには次の受信ルールが設定されている。3つの通信は許可されるか。

通信：(a) 203.0.113.5 から443、(b) 203.0.113.5 から22、(c) 10.0.2.77 から22。

ステップ1：ポートが一致するルールを探す。(a)はR1、(b)と(c)はR2。

ステップ2：送信元がCIDRの範囲に入るか調べる。

• (a) 0.0.0.0/0 はすべてを含む → R1に一致 → 許可。
• (b) 10.0.2.0/24 は 10.0.2.0〜10.0.2.255。203.0.113.5 は範囲外 → どのルールにも一致しない → 拒否（既定拒否）。
• (c) 10.0.2.77 は範囲内 → 許可。

ステップ3：Pythonで確かめる。ipaddress.ip_network(文字列) はCIDRを表すオブジェクトを返し、ipaddress.ip_address(文字列) in ネットワーク で範囲に含まれるか（True/False）を判定できます。

import ipaddress

rules = [
    {"name": "R1", "cidr": "0.0.0.0/0",   "port": 443},
    {"name": "R2", "cidr": "10.0.2.0/24", "port": 22},
]

def matched_rule(rules, src_ip, port):
    # 一致した最初のルール名を返す。なければ None（=既定拒否）
    ip = ipaddress.ip_address(src_ip)
    for r in rules:
        if r["port"] == port and ip in ipaddress.ip_network(r["cidr"]):
            return r["name"]
    return None

for src, port in [("203.0.113.5", 443), ("203.0.113.5", 22), ("10.0.2.77", 22)]:
    m = matched_rule(rules, src, port)
    print(src, port, "->", f"許可({m})" if m else "拒否")

net = ipaddress.ip_network("10.0.2.0/24")
print("アドレス数:", net.num_addresses, "範囲:", net[0], "-", net[-1])

出力：

203.0.113.5 443 -> 許可(R1)
203.0.113.5 22 -> 拒否
10.0.2.77 22 -> 許可(R2)
アドレス数: 256 範囲: 10.0.2.0 - 10.0.2.255

意味：APIは世界中から使えるが、管理用のSSHは社内の管理サブネットからしか届かない、という意図どおりの設定であることが確認できました。

操作して理解する：CIDRを変えて範囲の広さを見る

/ の後ろの数を変えると、許可する範囲の広さが何倍も変わります。次のコードで、範囲の個数と、ある送信元が含まれるかを確認してください。

import ipaddress

src = ipaddress.ip_address("10.0.3.20")
for cidr in ["10.0.2.0/24", "10.0.0.0/22", "10.0.0.0/16", "0.0.0.0/0"]:
    net = ipaddress.ip_network(cidr)
    print(f"{cidr:<13} 個数={net.num_addresses:>13,}  10.0.3.20を含む? {src in net}")

出力：

10.0.2.0/24   個数=          256  10.0.3.20を含む? False
10.0.0.0/22   個数=        1,024  10.0.3.20を含む? True
10.0.0.0/16   個数=       65,536  10.0.3.20を含む? True
0.0.0.0/0     個数=4,294,967,296  10.0.3.20を含む? True

考えてみましょう。

• /24 を /22 に「少し」変えただけで、許可する範囲は4倍（$2^{10}/2^{8}$）になり、隣のサブネット 10.0.3.x まで含まれます。
• 0.0.0.0/0 は約43億個、つまりインターネット全体です。SSH（22）やDB（5432）をこの範囲に開けると、世界中から攻撃の試行が届きます。
• 「動かないからとりあえず広げる」と、意図しない相手まで許可します。動かないときは、送信元の実際のIPアドレスを確認し、必要な範囲だけを足します。

発展：外向きの通信・私設接続・ネットワークだけに頼らない設計

• 外向き（送信）の通信：非公開サブネットのサーバーがライブラリを取得するなど、外へ出る通信が必要な場合があります。一般に、外向きだけを中継する仕組み（NAT：Network Address Translation など）を使い、外からの接続は受け付けないようにします。外向き通信には転送費用がかかることがあります（費用と停止）。
• 私設の接続口：オブジェクト保存やマネージドDBに、インターネットを経由せず仮想ネットワーク内から接続する仕組み（プライベートエンドポイントなどと呼ばれる）を多くの提供者が用意しています。
• ネットワークだけに頼らない：ネットワークの境界の内側にいる相手を無条件に信用しない考え方をゼロトラストと呼びます。境界で絞ったうえで、各要求を権限（IAMと最小権限）で確認し、通信は暗号化します（「転送と保存の暗号」（有料版））。
• ルールの評価方式の違い：この授業の模擬は「許可を列挙し、どれにも当たらなければ拒否」です。提供者や機能によっては、拒否ルールを書けるもの、ルールに優先順位があるものもあります。実環境では、その機能の評価順序を公式の説明で確認してください。

よくある失敗

失敗1：「とりあえず全開放」で接続を通す

誤った設定：接続できない原因を調べずに、受信ルールを「0.0.0.0/0 から、ポート0〜65535を許可」にした。

import ipaddress
rules_bad = [{"cidr": "0.0.0.0/0", "from": 0, "to": 65535}]
def allowed(rules, src, port):
    ip = ipaddress.ip_address(src)
    return any(r["from"] <= port <= r["to"] and ip in ipaddress.ip_network(r["cidr"]) for r in rules)
print("外部からDB(5432):", allowed(rules_bad, "198.51.100.9", 5432))
print("外部からSSH(22):", allowed(rules_bad, "198.51.100.9", 22))

出力はどちらも True です。

なぜ誤りか：接続できない原因（送信元のアドレス違い、アプリが起動していない等）は解決しておらず、代わりにDBやSSHが世界中に開きます。

直し方：必要な通信を「誰から・どのポートへ」で書き出し、それだけを許可する。例：APIは 0.0.0.0/0 から443、DBは APIサーバーのサブネットから5432だけ。

失敗2：大きなファイルをDBに入れる・VMのディスクに置き続ける

誤った設計：200GBの画像をDBの列（バイナリ型）に格納した。あるいはVMのディスクに置き、VMを削除したら画像も消えた。

なぜ誤りか：DBは「条件で行を探して更新する」のが得意で、大きなファイルを大量に入れるとバックアップや複製が重くなります。VMのディスク（ブロック保存）は、そのVMの一部として扱われることが多く、削除の設定によってはVMと一緒に消えます。

直し方：画像そのものはオブジェクト保存に置き、DBには product_id, image_key（オブジェクトのキー）, label のような参照情報だけを入れる。

失敗3：長時間の学習を関数実行（サーバーレス）で動かす

誤った設計：「サーバー管理が不要で安い」として、2時間かかるモデル学習を関数実行で動かした。途中で実行時間の上限に達して強制終了し、毎回最初からやり直しになった。

なぜ誤りか：関数実行は、短く小さな処理をイベントごとに動かすための仕組みで、一般に1回の実行時間やメモリに上限があります（上限値は提供者・設定により異なり、変わり得ます）。

直し方：処理の時間とメモリを見積もってから選ぶ。数秒〜数分の小さな処理（ファイル到着時の形式チェックなど）は関数実行、時間のかかる学習はバッチ実行やVMにする。途中結果を保存して再開できるようにしておくと、失敗時の損失も減ります。

まとめ

• クラウドの資源は計算・保存・ネットワークの3つの柱で、処理の性質に合わせて選ぶ。
• 大きなファイルはオブジェクト保存、条件で検索・更新する表はDB、短いイベント処理は関数実行、長い処理はバッチやVM。
• CIDR /p の個数は $2^{32-p}$。0.0.0.0/0 はインターネット全体を意味する。
• 受信ルールは許可の列挙で、どれにも当たらない通信は拒否。DBやSSHを全体に開けない。
• 非公開サブネットは権限や暗号の代わりにならない。ネットワーク・権限・暗号を重ねて守る。

用語

オブジェクト保存（object storage）

バケットとキーでファイル単位に、HTTPのAPIで読み書きする保存方式。

ブロック保存（block storage）

VMにディスクとして接続して使う保存方式。

関数実行（サーバーレス）（serverless functions）

イベントのたびに短い関数を実行し、サーバーの管理を利用者が行わない計算方式。実行時間などに上限がある。

仮想ネットワーク（virtual private cloud (VPC)）

クラウドの中に作る、自分専用の論理的なネットワーク。

サブネット（subnet）

仮想ネットワークを区切ったアドレス範囲。公開・非公開に分けて資源を配置する。

CIDR表記（CIDR notation）

アドレス/固定ビット数 でアドレス範囲を表す書き方。/p の範囲は 2^(32-p) 個。

受信ルール（inbound rule / firewall rule）

どの送信元からどのポートへの通信を許可するかを列挙した設定。一致しない通信は拒否される。

よくある質問

なぜ計算と保存を分けるのですか？

寿命と増え方が違うからです。計算は必要なときだけ起動して止めたい一方、データは長く残したい。分けておけば、計算を止めたり作り直したりしてもデータは消えず、それぞれ独立に増減できます。

オブジェクト保存とファイル保存の違いは何ですか？

オブジェクト保存はファイル単位でAPIを通して丸ごと読み書きし、途中の一部だけを書き換える使い方は想定していません。ファイル保存は複数のサーバーから普通のフォルダとして使え、ファイルの一部の更新もできます。大量に貯めて読むならオブジェクト、共同編集の作業フォルダならファイル保存が向きます。

受信ルールの設定でどこを間違えやすいですか？

CIDRの範囲を広げすぎる（/24のつもりで/16）、検証用に開けたポートを閉じ忘れる、送信元をIPアドレスで固定したのに相手のアドレスが変わる、の3つが典型です。ルールには意図と担当者と期限をメモしておき、定期的に棚卸しします。

サブネットの大きさはどう決めますか？

将来置くサーバーやコンテナの数に余裕を持たせます。後から広げるのは手間がかかることが多いため、仮想ネットワーク全体を /16 など大きめに確保し、用途別に /24 程度のサブネットに分ける例がよく見られます（具体的な推奨は提供者の公式情報で確認）。

VMとコンテナのどちらを選べばよいか、仕事ではどう判断しますか？

「同じ環境を何度も再現する必要があるか」「OSの細かい設定が必要か」「チームにコンテナの運用経験があるか」で判断します。試作は使い慣れたVMで始め、本番運用で再現性が重要になったらコンテナに移す、という段階的な判断もよくあります。

確認問題

次に学ぶこと

次は リージョンと可用性 で、資源を「どの地域に、何か所に分けて」置くかを、可用性の計算とともに学びます。

権限による保存データの守り方は IAMと最小権限、保存場所の公開設定の確認は 責任共有とログ で扱います。HTTPやポートの基本に不安があれば 「HTTPと要求応答」（有料版） に戻ってください。保存形式と保存費用の詳細は 「オブジェクト保存」（有料版） で学びます。