Skip to content

MS_AzureVirtualMachine

Jump to bottom
nishi_74322014 edited this page Aug 19, 2026 · 1 revision

Azureの仮想マシン

概要

Azure の仮想マシン

詳細

構成

複数のリソースから構成される。

補足（「VM は 1 つのリソースではない」が本節の要点）: オンプレミスの
サーバは筐体 1 台が 1 つの管理単位だが、Azure の VM は
複数の独立したリソースの組み合わせである。

【仮想マシン(Microsoft.Compute/virtualMachines)】← これ自体は「設定の集合」に近い
   ├─ OS ディスク        (Microsoft.Compute/disks)
   ├─ データ ディスク    (Microsoft.Compute/disks)
   ├─ NIC               (Microsoft.Network/networkInterfaces)
   │    ├─ パブリック IP (Microsoft.Network/publicIPAddresses)
   │    └─ NSG          (Microsoft.Network/networkSecurityGroups)
   └─ 可用性セット       (Microsoft.Compute/availabilitySets)

この構造を理解していると、次のことが説明できる。

事象 理由
VM を削除してもディスクが残る（旧ポータル既定） ディスクが独立したリソースだから
VM を削除しても課金が減らない ディスク・IP が残っているから（Azureの課金）
ディスクだけを別 VM に付け替えられる 独立しているから（Azure上に素早く環境を構築する）
RBAC を細かく分けられる リソース種別ごとに権限を割り当てられるから

後掲の「変更・保守、作業の一覧化」で
ネットワーク設定だけ別ロールが要ると書かれているのも、
NIC / NSG が VM とは別リソースだからである。

仮想マシン自体

ディスク

  • 基本、管理ディスク（Azureのディスク ストレージ）を使用し、課金に注意する。
  • システム・ドライブ
    C ドラのシステム・ドライブ
    • 管理ディスクの Premium など。
    • ローカル・ディスクと比べ若干遅い。
  • データ・ドライブ
    • ローカル・ディスク
      D ドラのローカル・ディスクは、
      • ローカル SSD なので高速にアクセス可能。
      • ページング・ファイルなどでも利用される。
      • ただし、障害発生時、データは削除される。
    • データ・ディスク
      E ドラ以降のデータ・ディスクは、
      • ライト・キャッシュを消して使用する。
      • 管理ディスクの Ultra など。
      • DB のデータ・ファイル、トランザクション・ログ・ファイルなどを保存。
  • 共有ディスク
    クラスタ化では S2D（＝ソフトウェアベースの共有ディスク）を利用

補足（「ライト・キャッシュを消して使用する」が重要）: 一行だが、
DB を Azure VM で動かす際の必須設定である。

Azure のディスクにはホスト キャッシュの設定があり、
用途によって選ぶべき値が異なる。

ドライブ 推奨キャッシュ 理由
OS ディスク（C:） 読み取り/書き込み 既定。OS の起動を速くする
DB データ ファイル 読み取り専用 読み取りは速くしたい
DB トランザクション ログ なし（None） 書き込み順序の保証が必要

トランザクション ログでキャッシュを有効にすると、
障害時に書いたはずのログが失われる可能性があり、
DBMS の耐久性（Durability）の前提が崩れる。
これが「ライト・キャッシュを消して使用する」の意味である
（SQL Server のファイルの配置）。

なお、tempdb は D:（ローカル SSD）に置くのが
Azure での定石である。
揮発しても tempdb は起動時に再作成されるため問題にならず、
かつ最も高速だからである
（逆に、ユーザ DB を D: に置いてはいけない）。

NICとIPアドレス

補足（NLB / WSFC が使えない理由）: Azure の仮想ネットワークは
**ソフトウェア定義（SDN）**であり、物理 LAN のように
「同じセグメントに流したパケットが全員に届く」わけではない。
具体的には、

制約 影響
ブロードキャスト／マルチキャストが通らない NLB のハートビートが届かない
GARP（Gratuitous ARP）が効かない 仮想 IP の付け替えが伝播しない
IP は Azure 側（DHCP）が管理 OS 側で勝手に IP を持たせても Azure が知らない

WSFC の「クラスタ IP アドレス」は
GARP でノード間を移動する仕組みであるため、これが機能しない。

代替として、Azure では
内部ロード バランサー（ILB）＋ 正常性プローブを使う。
クラスタ IP の代わりに ILB のフロントエンド IP を使い、
「今どのノードが Active か」をプローブで判定させる方式である
（AzureのGW / LB的なモノ。）。

同じ理由で、OS 上で IP を固定してはいけない
（後述の「IP 固定」の項）。

Guest VM Agent

ポータルからの

  • インストール
  • コマンド実行

などを行うことが出来る。

補足: Azure VM Agent は、
VM 拡張機能（Extension）の実行基盤である。
ブート診断、バックアップ、監視エージェントの導入、
RunCommand によるコマンド実行など、
ポータルから VM 内部に対して行う操作はすべてこれを経由する。

重要なのは、この通信に受信ポートの開放が不要な点である
（VM 側から Azure 基盤へアウトバウンドで接続するため）。
後掲の「経路開放は、不要」がこれを指している。

逆に言えば、エージェントが止まると
ポータルからの操作が一切効かなくなる
（パスワード リセット、拡張機能の追加など）。
「ポータルの操作が反応しない」場合はエージェントの状態を疑う。

その他

課金

状態 仮想マシン ディスク ライセンス
開始中・実行中 課金される 課金される 課金される
停止済み（Stopped） 課金される 課金される 課金されない
割当解除済み、削除済み（Deallocated） 課金されない 課金される 課金されない

移行メモ（表の変換）: 原典は PukiWiki のセル結合記法（>）を
使用していたため、結合されていたセルは同じ値を展開して表現した。

補足（この表が Azure の課金で最も重要）: 3 状態 × 3 対象の
9 マスのうち、注意すべきは 2 つである。

マス 内容
停止済み × 仮想マシン ＝ 課金される OS からシャットダウンしても止まらない
割当解除済み × ディスク ＝ 課金される VM を止めてもディスク代は残る

前者への対処が次項、後者への対処は
「使わないディスクは削除する（またはスナップショットにして VHD を消す）」
になる。詳細はAzureの課金を参照。

仮想マシン費用

  • 仮想マシンのノード割り当てが解除されない限り、課金が継続する。
    • シャットダウンでは課金される。
    • シャットダウンは OS からではなく
      必ずポータルサイトから行い、割り当て解除する。
  • EA 契約のコミットメント額資金（MC : Monetary Commit）から減算される

ディスク費用

Azureのディスク ストレージを参照。

ライセンス費用

  • BYOL : Bring Your Own License
    • ライセンス持ち込み
    • Azure 側では課金されない
  • PAYG : Pay As You Go
    • マーケットプレイスのイメージ
    • 時間課金、月課金（日割りなし）などがある。
    • 2 タイプ
      • Azure 用の、SKU が存在するマイクロソフト製品
        ・EA 契約の MC から減算される（仮想マシン費用と同じ）。
      • Azure 用の、SKU が存在しないマイクロソフト製品、3rd party 製品
        ・EA 契約の MC から減算されず、
        　EA 契約の超過料金として扱われる。
        ・VL のディスカウントの対象にならない。
        ・四半期ごとの請求書一括請求になる。
    • 必ずマーケットプレイスの Web ページから確認

補足（BYOL は「Azure Hybrid Benefit」として実装されている）: Windows Server や
SQL Server の BYOL は、現在
**Azure Hybrid Benefit（AHUB / AHB）**という機能名で提供されている。

対象 割引
Windows Server（SA 付き） Windows のライセンス費用が無料になる
SQL Server（SA 付き） SQL のライセンス費用が無料になる
Linux（RHEL / SLES） サブスクリプション持ち込み可

有効化は VM 作成時の
「Windows ライセンスを既にお持ちの場合」で「はい」を選ぶだけで、
作成後にも切り替えられる。
保有しているのに設定し忘れると純粋な払い過ぎになるため、
既存 VM の設定を一度確認する価値がある。

なお、後掲の「セキュア化とロックダウン」で
「BYOL が正しく構成されている（AHUB の設定など）」が
高額請求抑止の項目として挙がっているのはこの意味である。

IPアドレス

DHCPとDNS

Azureのアウトバウンド設計を参照。

IP固定

補足（OS 上で固定すると何が起きるか）: Azure のプライベート IP は
Azure 側の管理台帳が正であり、VM には DHCP で通知される。
OS 側で同じ値を静的設定しても一見動作するが、

  • VM を割り当て解除して再起動すると、Azure 側が別の IP を割り当てる
    → OS 側の静的設定と食い違い、ネットワークに繋がらなくなる、
  • Azure 側から見た IP と実際の IP がずれ、
    NSG や LB のルールが効かなくなる

という事故が起きる。
正しい手順は
ポータル（または CLI）で割り当てを「静的」に変更することであり、
OS 側は DHCP のままにしておく。

az network nic ip-config update --name ipconfig1 --nic-name <NIC名> \
   --resource-group <RG名> --private-ip-address 10.0.0.10

なお、本文が「このシーンは比較的少ない」と述べるのは、
アクセスは ILB のフロントエンド IP 経由で行う設計が基本であり、
個々の VM の IP を意識する必要が無いためである。

日本語化

OSの日本語化

  • 日本語化作業は面倒なため、
  • 極力、英語版のまま利用することを推奨

ミドルの日本語化

  • BYOL
  • PAYG
    かなり厄介
    • OS の日本語化
    • アンインストールしてプロダクトキー入手
    • 日本語メディアを持ち込んでインストール

移行メモ（体裁）: 原典の「アンストール」は
「アンインストール」の脱字であるため補った。

補足（最新化）: 現在は Marketplace に
日本語版の Windows Server イメージが提供されているため、
OS の日本語化作業は不要になっている
（Azure上に素早く環境を構築する）。

一方、PAYG のミドルウェア（SQL Server 等）を
日本語版に入れ替える手間は依然として面倒である。
日本語版が必要と分かっている場合は、

  • OS のみの PAYG イメージを選び、
  • ミドルウェアはBYOL で日本語メディアから導入する

のが結果的に早い。
本文が PAYG を「かなり厄介」とするのは、
一度アンインストールしないとライセンス形態を変えられないためである。

ダウンタイム最小化

ハードウェア障害

メンテナンス

  • VM のメンテナンス
    ユーザが実施する。
  • ホストのメンテナンス
    • ゲストへの影響なし
      通知なく実施
    • ゲストへの影響あり
      • 30 秒以内で完了 → 15 分前通知（PHU : Preserving Host Update）
      • 30 秒以上必要 → 30 日前に通知（一定期間内に手動再起動）

移行メモ（正誤）: 原典の「30秒異常必要」は
「30 秒以上必要」の誤変換であるため修正した。

サービス・ヒーリング

仮想マシンが故障した場合でも、前述の構成から、
データ・ドライブ > ローカル・ディスクを除いて、壊れない。

  • 15 秒単位の死活監視
  • 10 分応答がない場合、自動リカバリ（別ノードへ移動）される。

移行メモ（体裁）: 原典の「〜以外を除いて」は
二重否定になっていたため「〜を除いて」とした。

補足（サービス ヒーリングの限界）: 「壊れない」とあるが、
自動的に別ノードで再起動されるという意味であり、
無停止ではない点に注意が要る。

項目 内容
検知まで 最大 10 分（15 秒間隔の監視で応答なしが続いた場合）
復旧 別ノードでOS が起動し直す
失われるもの メモリの内容、一時ディスク（D:）の内容
合計ダウンタイム 10 分＋ OS 起動時間

つまり、単一 VM では 10 分以上の停止が起こり得る。
これを許容できない場合は、
冗長オプション（可用性セット／ゾーン）で
複数台構成にする必要がある。

「単一 VM でも SLA 99.9%」は
月あたり約 43 分の停止を許容する水準であり、
サービス ヒーリング 1 回分でほぼ使い切る計算になる。

冗長オプション

仮想化レイヤーより下の構成

# 構成 要素
1 シングル VM サービスの復旧
(Service Healing)
2 クラスタ構成 可用性セット
・VM Scale Sets
・ロード・バランサ Basic
3 マルチ AZ 構成
（Availability Zone）		 可用性ゾーン
・ゾーン冗長 VM Scale Sets
・ロード・バランサ Standard
4 マルチリージョン構成 ・ペアリージョン
・Traffic Manager

※ 可用性セットと可用性ゾーンは「AND」ではなく「OR」。

補足: この 4 段階はAzureの冗長化の
表と同じ構造であり、そちらに図解がある。
なお、ロード バランサーの SKU が AZ 構成では Standard 必須である点は
見落としやすい（Basic はゾーン冗長に対応しない）。
Basic SKU は 2025 年 9 月に廃止されており、現在は Standard 一択である。

クラスタ構成

  • 可用性セット（AS）
    • ［障害ドメイン］や［更新ドメイン］を分ける事により、可用性を高める。
      • 障害ドメイン：共通の電源やネットワーク機器などを共有する範囲
      • 更新ドメイン：Azure のメンテナンスリブートの際に影響を受ける範囲
    • 1 つのラック障害で 2 台の仮想マシンが同時に停止することを回避できる。
      • 故に、サーバー・ファームを構成するとき、複数ラックに渡って冗長化して配置する。
      • 可用性セット自体にクラスタリング・負荷分散・データ複製などの機能がある訳ではない。
  • ロード・バランサ
    • 仮想マシン間で着信トラフィックを分散
    • 詳しくは、Azure Load Balancerを参照（Standard）。

補足（「可用性セット自体に機能がある訳ではない」が重要）: この一文は
誤解を防ぐうえで極めて重要である。

可用性セットが行うのは配置の制御だけであり、

可用性セットがすること しないこと
VM を別ラックに配置する 負荷分散（→ ロード バランサーが必要）
メンテナンス時に同時に落とさない データの複製（→ アプリ／DB 側の機能が必要）
－ フェイル オーバー（→ クラスタ ソフトが必要）

つまり、可用性セットに入れただけでは
**「たまたま同時に落ちない 2 台の別々のサーバ」**でしかない。
可用性セット ＋ ロード バランサー ＋ アプリのステートレス化が
揃って初めて冗長構成になる。

DB のように状態を持つものは、さらに
**レプリケーション（AlwaysOn 等）**が要る
（Azureの高可用性設計）。

マルチAZ構成

  • 可用性ゾーン（AZ）
    • 可用性ゾーンを分ける事により、可用性を高める。
      • リージョン内の各種ハードウェアが分離されたゾーン
      • リージョン内に、3 つ以上の可用性ゾーンが存在する。
    • 1 つの DC 障害で DC 中の仮想マシンが同時に停止することを回避できる。
      • サーバー・ファームを構成するとき、複数 DC 群に渡って冗長化して配置する。
      • 可用性ゾーン自体にクラスタリング・負荷分散・データ複製などの機能がある訳ではない。
  • ロード・バランサ
    • 仮想マシン間で着信トラフィックを分散
    • 詳しくは、Azure Load Balancerを参照（Standard）。

移行メモ（体裁）: 原典の「3つ以上のに可用性ゾーン」は
助詞が重複していたため修正した。

マルチリージョン構成

  • ペアリージョン
    リージョン ペアの間で事業継続とディザスタ・リカバリ (BCDR) を構成
    • 複数リージョンにまたがって構成することで地理的に冗長化
    • 災害でリージョン中の仮想マシンが同時に停止することを回避できる。
  • ロード・バランサ
    DNS ベースの機能を利用した Traffic Manager での切り替え。

注：AZをミニリージョンとして使用しない。

  • AZ はミニリージョンとしては機能しないため。

  • AZ は、ティアに渡って使用する。

    ※ ティア：水平方向のサーバー・ファーム（Web、AP、DB と言う集合）

  • 理由

    • AWS ではサブネットは特定の AZ に固定される。
      故に、AZ をミニリージョンとして使用できる。
      • サブネット中に垂直・水平方向のサーバー・ファームを構成し、AZ で冗長化していく。
      • このように構成すると、サブネット単位での設計が可能になる。
    • Azure では、サブネットは特定の AZ に固定されない。
      故に、AZ をミニリージョンとして使用できない。
      • 水平方向のサーバー・ファームを構成し、AZ で冗長化していく。
      • このように構成すると、Azure の AZ の特性から PaaS、SaaS と組み合わせ易くなる。

補足（この AWS との対比が本ページで最も価値のある指摘）: 「サブネットが
AZ に固定されるか否か」という一点の違いが、
設計手法そのものを変えるという指摘は極めて実務的である。

【AWS】サブネット = AZ に固定
  VPC
   ├─ サブネットA (AZ-1) : Web / AP / DB を一式配置  ← ミニリージョンとして完結
   └─ サブネットB (AZ-2) : Web / AP / DB を一式配置  ← 同上（丸ごと複製）
  → 「AZ ごとに一式」という縦割りの設計が自然

【Azure】サブネットは AZ に固定されない（VNET/サブネットはリージョン単位）
  VNET
   ├─ Web サブネット : Web-1(AZ1) Web-2(AZ2) Web-3(AZ3)
   ├─ AP サブネット  : AP-1(AZ1)  AP-2(AZ2)  AP-3(AZ3)
   └─ DB サブネット  : DB-1(AZ1)  DB-2(AZ2)
  → 「ティア（層）ごとに横に並べ、各層の中で AZ 分散」という横割りの設計が自然

本文が「ティアに渡って使用する」と言うのはこの意味である。

この違いが重要なのは、

観点 影響
サブネット設計 Azure ではサブネット＝層で切る。AZ ごとに切らない
NSG の設計 サブネット単位＝層単位の制御が素直に書ける
PaaS との併用 PaaS は元々リージョン単位でゾーン冗長。同じ考え方で揃う
AWS の設計をそのまま持ち込むと サブネットが AZ に対応しないため破綻する

「PaaS、SaaS と組み合わせ易くなる」という結論も、
Azure の PaaS はゾーン冗長がサービス側で完結しているため、
IaaS 側も同じ粒度で考えた方が整合する、という趣旨である。

注：Azure Backupする場合、AZにピン留めしない。

  • Azure Load Balancerは、負荷分散とピン留めの選択が可能。
  • シングル構成 DB のバックアップ・リストア運用のシナリオ等で、
    • AZ にピン留めされたサーバは、LB を使用しないでアクセスできるが、
    • Azure Backup でリストアする場合、ピン留めゾーンに復元しようとするため、機能しない。

移行メモ（体裁）: 原典の「バッグアップ」は
「バックアップ」の誤りであるため修正した。

補足: これはゾーン ピン留め（zone-pinned）された VM を
別ゾーンに復元できないという制約に由来する実務的な注意である。
復元先のゾーンで容量が確保できない場合、
リストア自体が失敗する。

対処としては、

  • ゾーンを指定しない（Azure に任せる）、
  • または復元時にゾーンを変更できる構成にしておく

ことになる。
バックアップ全般の考え方は
Azureの障害復旧を参照。

セキュア化とロックダウン

作業内容の安全性の確認

  • 入力制御（インバウンド）
  • ハードニング（クライアント or サーバ）
    • アンチ・マルウェア（OS）
      • 不正なディスク・イメージを利用しない
      • アンチ・マルウェア・ソフトをインストールする
        ・Linux OS：ClamAV
        ・Windows OS：Windows Antimalware（無償）
      • 仮想マシンの脅威検出や振る舞い監視を行う
        Azure Security Center（ASC）の VM 監視機能（VM Insights）
      • 更新プログラムが正しく管理されている
        ・更新プログラムの自動展開スケジュールの構成
        ・上記の VM 監視機能（VM Insights）の更新管理機能（Update Management）
    • アンチ・マルウェア（ミドル・アプリ）
      • ミドルウェア、アプリの挙動の監視方法について検討する
        ・ミドルウェア：JP1、Datadog
        ・アプリ：Application Insights
      • 必要に応じてファイルやレジストリの変更検知を行う
      • 適切なアプリのみが配置されるようになっている（DevOps）
      • 必要に応じて許可されたアプリのみを実行するようにサーバを構成する
        Azure Security Center（ASC）の Adaptive Application Control 機能
    • 無効化機能
      • 非管理ディスクを使わない
      • 確認が取れていない（＝許可されていない）拡張機能を使わない
    • 高額請求抑止
      • 巨大な VM サイズを利用しない。
      • 自動的な起動 / シャットダウンを正しく構成する。
      • スケールアウト / スケールインのルールを正しく構成する（VMSS）。
      • ライセンス費用
        ・追加ライセンス費用が必要な VM イメージを利用しない
        ・BYOL が正しく構成されている（AHUB の設定など）
    • 透過的暗号化
      • ディスクの暗号化
        ・ストレージは低レベルでは暗号化されているので、基本的には不要。
        ・必要に応じ ADE（Azure Disk Encryption）により管理ディスクを暗号化できる。
        　・Windows OS では BitLocker、Linux では DM-crypt。
        　・主に内部犯行防止のためだが、操作権限によっては無意味。
        　※ また、バックアップ・リストアが複雑化する。
      • メモリの暗号化
        Confidential Computing
  • 出力制御（アウトバウンド）

移行メモ（正誤・体裁）: 原典の以下を修正した。

原典 修正
Window OS Windows OS
アプリの挙動が監視監視方法について アプリの挙動の監視方法について
自動的な起動 / シャットダウンが正しく構成する 自動的な起動 / シャットダウンを正しく構成する
ADE（Advanced Data Encryption） ADE（Azure Disk Encryption）※ 略称の展開が誤り
内部犯行防止のタメ 内部犯行防止のため

補足（「経路開放は不要／必要」の切り分けが要点）: この節で最も実務的なのは、
VM エージェントが使う通信のうち、
どれが NSG やファイアウォールの設定を要するかの区別である。

種別 通信先 経路開放
基盤経路 Azure のプラットフォーム エンドポイント（168.63.129.16 等） 不要（NSG を通り抜ける）
一般経路 Log Analytics、Application Insights などのパブリック エンドポイント 必要（アウトバウンド許可、またはプライベート リンク）

168.63.129.16 は Azure の特殊な仮想 IP で、
DHCP、DNS、正常性プローブ、VM エージェントの通信に使われる。
NSG の設定に関わらず常に到達できる
（逆に、これをブロックすると VM が正常に動作しなくなる）。

一方、監視エージェントは通常のインターネット向け通信を行うため、
閉域環境では

  • Azure Firewall / プロキシで FQDN を許可する、
  • または **Azure Monitor プライベート リンク スコープ（AMPLS）**を使う

といった対応が要る
（Azureのアウトバウンド設計）。

補足（ディスク暗号化は「必要かどうか」を見極める）: 本文の
「基本的には不要」「操作権限によっては無意味」という判断は的確である。

層 何から守るか 既定
SSE（Storage Service Encryption） 物理ディスクの盗難・廃棄 既定で有効・無償
ADE（Azure Disk Encryption） ゲスト OS 内での不正な読み取り 任意
Confidential Computing ホスト／ハイパーバイザからの読み取り 任意（対応 SKU のみ）

つまり、「暗号化されていない」という状態は Azure には無い
（SSE が常に効いている）。
ADE を追加しても、VM にログインできる管理者からは平文に見えるため、
本文の「操作権限によっては無意味」は正しい。

ADE を採用する判断は、
規制・監査要件で「顧客管理キーによる OS レベルの暗号化」が
明示的に求められている場合に限るのが合理的である。
「バックアップ・リストアが複雑化する」という副作用も現実的な指摘である。

変更・保守、作業の一覧化

  • VM の主なメンテナンス作業と、必要な権限付与
    • 多くの作業は「Virtual Machine Contributor」ロールが必要で、
    • ネットワーク設定が必要な作業は、高権限である、
      「Network Contributor」ロールが必要になるので要注意。
    • 上記に合致しない作業も幾らか存在する。
    • また、カスタム・ロール化した方が良い作業もある。
      • NIC 追加、NSG 設定の変更
      • 仮想マシンの再起動、電源 on/off、電源 on/off スケジュール変更

移行メモ（正誤）: 原典の「Virtual Maschine Contributor」は
「Virtual Machine Contributor」の誤字であるため修正した。

補足（なぜ Network Contributor が「高権限」なのか）: 一見すると
ネットワーク設定は VM 操作より狭い権限に見えるが、
実際にはより危険である。理由は次のとおり。

Network Contributor でできること 危険性
NSG の規則を変更 すべてのポートを全世界に開放できる
ルート テーブルの変更 通信を任意の場所に迂回させられる（傍受）
パブリック IP の付与 閉域のはずの VM をインターネットに露出できる
ピアリングの構成 別 VNET への経路を作れる

つまり、Network Contributor は
ネットワーク境界による防御を無力化できる権限である。
VM を再起動する権限とは危険度の桁が違う。

だからこそ本文はカスタム ロール化を勧めている。
例えば、

  • **「VM の再起動・起動・停止だけ」**のロール
    （Microsoft.Compute/virtualMachines/restart/action 等のみ許可）、
  • **「NIC の追加はできるが NSG は変更できない」**ロール

のように、作業単位で必要最小限に絞る。
RBAC の詳細は
Role Based Access Control (RBAC)、
Azureのアクセス制御と権限を参照。

IaC化

Azure PowerShell

下記を参照。

Azure CLI

az vm create ^
--resource-group [既存のRG名] ^
--name [VM名] ^
--location [location] ^
--size [size] ^
--image [image名] ^
--admin-user [users名] ^
--admin-password [password] ^
--vnet-name [既存のVNET名] ^
--subnet [既存のSubnet名]

補足（--admin-password をコマンドラインに書かない）: 例のとおり
--admin-password をコマンドラインに指定すると、

  • シェルの履歴に残る、
  • CI のログに出力される、
  • ps で他ユーザから見える（Linux）

という問題がある。実務では次のいずれかを使う。

手段 内容
SSH 公開鍵（Linux） --ssh-key-values。パスワードを使わないのが最善
Azure Key Vault --admin-password $(az keyvault secret show ... --query value -o tsv)
対話入力 省略すると対話的に入力を求められる

また、az vm create は
省略した引数を自動生成する（VNET、NSG、パブリック IP など）。
手早く 1 台作るには便利だが、
意図しないパブリック IP が付くことがあるため、
閉域構成では --public-ip-address "" を明示する
（Azure Bastion）。

なお、^ は Windows のコマンド プロンプトでの行継続文字である。
PowerShell では `、Bash では \ になる。

参考

Azure上に素早く環境を構築する

SIOS Tech. Lab

Microsoft Docs > Azure Virtual Machines

参考

Azureのストレージ

Azure環境（仮想マシン）

Azureの評価環境を入手する

AzureのPoC環境を契約する

Azure上に素早く環境を構築する

SIOS Tech. Lab

nakama

※ IaaS の構成方法（Azureの仮想ネットワーク）中にも同様のトピックが含まれる。

Microsoft Docs

Azure Virtual Machines

Tags: 移行, インフラストラクチャ, クラウド, Azure

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally