Instiq

Microsoft Azure Administrator のナレッジマップ

Microsoft Azure Administrator の主要概念 260 件と、そのつながり。上のマップでノードをクリックすると関連用語や前提をたどれます。下は全概念の索引で、定義と「前提・関連する概念」への内部リンクを掲載しています。

概念一覧(260)

  • 仮想ネットワーク(VNet)

    Azure内に作るプライベートなネットワーク。サブネットで区切り、ピアリングでVNet同士をつなぐ。

  • 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    性能を測る基本語彙。IOPS=1 秒あたりの I/O 回数(小さなランダムアクセスの指標、EBS io2 等)。スループット=単位時間のデータ量(MB/s、大きな連続転送)。帯域幅=回線容量。レイテンシー=1 操作の遅延。ワークロードに合う指標で設計・監視する。

  • リージョン(Azure)

    1つ以上のデータセンターをまとめた地理的なまとまり。遅延・データ主権・機能提供・コストで選ぶ。

  • Blob ストレージ

    画像・動画・バックアップなど非構造化データ(オブジェクト)向けのストレージサービス。

  • ExpressRoute

    インターネットを通らない専用のプライベート接続。高信頼・一貫した低遅延・広帯域。

  • Microsoft Entra ID

    クラウドのID/アクセス管理サービス(旧Azure AD)。MFA・SSO・条件付きアクセスを提供。オンプレのAD DSとは別物。

    前提: 条件付きアクセス

  • サブネット

    仮想ネットワークのアドレス空間を区切った小さなネットワーク範囲。用途や公開/非公開でリソースをグループ化し、ルーティングやアクセス制御の単位にする。

  • Azure SQL の認証/アクセス制御・データ保護

    認証は Microsoft Entra 認証(推奨・一元管理・MFA/条件付きアクセス・マネージドID でパスワードレス)と SQL 認証。ログイン(サーバー)とユーザー(DB)を区別し、SQL Database ではコンテインドユーザーが推奨。認可は固定/カスタムロールと GRANT/DENY/REVOKE(DENY 優先)で最小権限。行は行レベルセキュリティ(RLS)、列は列レベル権限で絞る。データ保護は動的データマスク(表示の制限・UNMASK で実値)と監査(操作を Log Analytics/Storage に記録)。暗号化は TDE/Always Encrypted(別項)。

    前提: 条件付きアクセスAlways Encryptedカスタムロール(Azure ロール / Entra ロール)コンテインドユーザー

  • サブスクリプション(Azure)

    課金と利用の境界であり、リソースの論理的な入れ物。部門や環境ごとに分けることが多い。

  • Azure App Service

    Web アプリや API を PaaS で手早くホストするサービス。OS管理不要でスケールも容易。

  • ルーティング(システムルート・サービスチェイニング・強制トンネリング)

    Azure の経路制御。システムルート=VNet 内・ピアリング・ゲートウェイ・既定インターネットへの経路を Azure が自動付与。UDR(ユーザー定義ルート)でこれを上書きし、宛先プレフィックス→次のホップ(仮想アプライアンス/ゲートウェイ/インターネット/なし)を定義する。サービスチェイニング=UDR の次ホップを NVA(ファイアウォール)にして必ず経由させる(NVA 側で IP 転送が必須、冗長化は内部 Load Balancer を前段に)。強制トンネリング=外向きインターネットを UDR でオンプレ経由に強制。ゲートウェイトランジット=スポークがハブの VPN/ExpressRoute ゲートウェイを共有。経路選択は最長プレフィックス一致→UDR>BGP>システム。

    前提: ExpressRoute仮想ネットワーク(VNet)Network Watcher 診断ツール(IP フロー検証・接続モニター・ネクストホップ)Azure Load Balancer

  • Azure Virtual WAN

    多数の拠点・VNet・リモートユーザーをマネージドなハブ(Microsoft バックボーン上)で一元管理する大規模ネットワークサービス。VPN・ExpressRoute・VNet 接続を集約し、ハブが中継するためスポーク間も非推移の問題なく到達できる。SKU は Basic(S2S VPN のみ)と Standard(ExpressRoute/P2S/ハブ間/Secured Hub などフル機能)。Secured Virtual Hub はハブに Azure Firewall を組み込み、Firewall Manager で複数ハブのポリシーを一元適用して集中検査する。小規模は手組みハブ&スポーク、大規模・グローバルは Virtual WAN。

    前提: ExpressRoute仮想ネットワーク(VNet)Azure Firewallサイト間 VPN(S2S)

    関連: 仮想ハブ(Virtual WAN)

  • 可用性ゾーン

    リージョン内で物理的に分離したデータセンター(独立電源/冷却/NW)。ゾーン冗長で高可用性を実現。

    前提: リージョン(Azure)

    関連: ゾーン冗長(Azure SQL)

  • Network Watcher 診断ツール(IP フロー検証・接続モニター・ネクストホップ)

    ネットワークの可視化・切り分けを行う Network Watcher の診断ツール群。IP フロー検証=特定の送信元/宛先/ポートが NSG で許可/拒否されるか(一致した規則名つき)を即判定。接続モニター=エンドポイント間の到達性・遅延・パケットロスを継続監視。ネクストホップ=あるパケットの実際の次ホップを表示し UDR の誤りを切り分ける。NSG/VNet フローログ=通過/拒否トラフィックを Storage に記録し Traffic Analytics で可視化。ほかにパケットキャプチャ・接続トラブルシューティング・トポロジ。「NSG で止まっている?経路の問題?」に応じて道具を選ぶ。

    前提: 仮想ネットワーク(VNet)接続モニター(Connection Monitor)パケットキャプチャ(Network Watcher)仮想ネットワークフローログ

  • 監視と最適化(Query Store・DMV・自動チューニング)

    まず計測してボトルネックを特定する。Query Store=クエリ履歴・実行プラン・待機統計を保持し劣化(リグレッション)検出やプラン強制(plan forcing)に使う。動的管理ビュー(DMV)=待機統計やブロッキング等の「今この瞬間」の内部状態を SQL で参照。実行プランでスキャン vs シーク・キールックアップ・非 SARGable を見て、インデックス(不足の作成/未使用削除/断片化の再構成)と統計更新で改善。Azure SQL の自動チューニング(推奨インデックスの自動適用・FORCE LAST GOOD PLAN)とインテリジェントクエリ処理が下支えする。

    前提: インデックス自動チューニング(plan forcing)セッションブロッキング動的管理ビュー(DMV)

  • Azure Key Vault

    鍵・シークレット・証明書を安全に保管・管理するサービス。アプリに直接埋め込まずに済む。

  • プライベートエンドポイント

    PaaS(Storage/SQL 等)へ VNet 内のプライベート IP を持つ NIC を通じて公開経路を使わず接続する仕組み。サブリソースごとにエンドポイントと DNS ゾーンが要る。

    前提: 仮想ネットワーク(VNet)

    関連: Azure NAT Gatewayユーザー定義ルート(UDR)

  • 条件付きアクセス

    場所・デバイス・リスクなどの条件に応じてアクセスを許可・追加要求する(ゼロトラストの実装)。

  • Azure API Management(APIM)

    複数のバックエンド API を統一された入口で公開する API ゲートウェイ。ポリシー(XML・インバウンド/バックエンド/アウトバウンド/エラー)で認証(validate-jwt)・レート制限・変換・キャッシュ・CORS を適用。製品とサブスクリプション(キー)で利用者へ提供、開発者ポータルでドキュメント提供、バックエンド認証はマネージド ID、シークレットは名前付き値(Key Vault)。

    前提: Azure Front Doorマネージド IDレート制限

    関連: 名前付き値(APIM)APIM ポリシー開発者ポータル(APIM)製品とサブスクリプション(APIM)

  • メッセージング/イベント(Service Bus・Event Grid・Event Hubs)

    疎結合連携の選択肢。Service Bus=エンタープライズメッセージング(キュー/トピック・順序/トランザクション/重複排除/デッドレター)。Storage Queue=シンプルで安価な大量キュー。Event Grid=離散イベントのリアクティブな pub/sub(「Blob 作成」等)。Event Hubs=大量ストリーミング/テレメトリ取り込み(高スループット・パーティション)。メッセージ=指示、イベント=通知。

    前提: Blob ストレージAzure Event GridAzure Event Hubs疎結合(デカップリング)

  • Azure SQL Database

    フルマネージドなリレーショナル PaaS。パッチ・バックアップ・可用性を Azure が担う。新規クラウドアプリ向け。

    前提: マネージドサービス(管理の境界)

  • インデックス

    特定の列の検索を高速化する仕組み。読み取りは速くなるが書き込み時の更新コストが増える。

  • データ保護と可用性・DR(バックアップ/復元・HA/DR・PITR・LTR・geo・フェイルオーバーグループ)

    Azure SQL は自動バックアップ(フル/差分/ログ)を取得。特定時点復元 PITR=保持期間(既定7日・最大35日)内の任意時点へ復元。長期保持 LTR=週/月/年で最大10年。geo 復元=GRS の geo 冗長バックアップから別リージョンへ復元(非同期=RPO 大きめ)。HA はゾーン冗長(リージョン内・AZ 間)、DR はアクティブ geo レプリケーション(別リージョンに読み取り可能な副)とフェイルオーバーグループ(複数 DB をリスナー越しに接続文字列を変えず自動フェイルオーバー)。VM は Always On 可用性グループ。設計は RPO/RTO で判断し、同期は RPO≈0・非同期は距離を稼ぐ。

    前提: リージョン(Azure)アクティブ geo レプリケーションAlways On 可用性グループフェイルオーバーグループ

  • サービスレベルと購入モデル(GP/BC/Hyperscale・vCore/DTU)

    Azure SQL の性能/可用性/コストを決める設定。サービスレベル=General Purpose(バランス型・リモートストレージ)/Business Critical(ローカル SSD・組み込みレプリカ・低遅延・読み取りスケールアウト)/Hyperscale(最大100TB級・ページサーバーでストレージ分離・高速バックアップ/復元)。購入モデル=vCore(柔軟・Azure Hybrid Benefit・予約割引が効く・推奨)/DTU(簡易指標)。計算は確定的(プロビジョンド)と、断続ワークロードで自動一時停止/再開するサーバーレス。多数 DB の容量共有はエラスティックプール。読み取りスケールアウトは BC/Hyperscale。

    前提: Business Critical レベルエラスティックプールGeneral Purpose レベルHyperscale レベルとページサーバー

    関連: 購入モデル(vCore / DTU)

  • ゾーン冗長(Azure SQL)

    リージョン内の複数の可用性ゾーンにレプリカを分散配置し、データセンター障害に耐える HA 構成。多くのサービスレベルで有効化できる。

    前提: リージョン(Azure)

    関連: 可用性ゾーン

  • Azure Front Door

    グローバルな L7 のエントリポイント。CDN キャッシュ・グローバルルーティング・WAF・SSL オフロードを兼ね、可用性と性能を高める。

  • マネージド ID

    シークレットの管理なしにアプリが Azure リソースへ安全にアクセスできる ID。Azure が自動管理するサービスプリンシパル。

  • Application Gateway

    L7(HTTP)のリージョン内ロードバランサー。URL パスベースルーティング・リスナー・HTTP 設定・SSL 終端・書き換え規則・WAF に対応する。

    前提: リージョン(Azure)

  • 冗長性(LRS/ZRS/GRS/GZRS)

    データのコピー数と範囲で耐障害性を決める設定。LRS<ZRS<GRS<GZRS。GRS/GZRSは別リージョンへ複製。

    前提: リージョン(Azure)フォールトトレランス(耐障害性)

  • ストレージのアクセス(アクセスキー/SAS)

    Azure ストレージへのアクセス手段。アクセスキー=アカウント全体のフルアクセス(要ローテーション)、SAS(共有アクセス署名)=対象/操作/期限を限定した委任(ユーザー委任SASが安全)、Entra ID + RBAC=キー不要の推奨方式。VNet 限定はプライベートエンドポイント/ファイアウォール。

    前提: Microsoft Entra IDロールベースのアクセス制御(RBAC)仮想ネットワーク(VNet)プライベートエンドポイント

  • Azure Load Balancer

    L4(TCP/UDP)でトラフィックを分散するリージョン内の高速ロードバランサー。公開/内部、ヘルスプローブ、バックエンドプールを構成する。

    前提: リージョン(Azure)

  • Azure ストレージアカウント

    Blob・File・Table・Queue の各ストレージサービスをまとめて提供する入れ物。

    前提: Blob ストレージQueue ストレージ

  • コンテインドユーザー

    サーバーレベルのログインに依存せず、データベース自身にパスワードや Entra ID を紐づけて認証できるユーザー。Azure SQL Database では標準の運用パターンで、フェイルオーバーグループでのセカンダリへの昇格時もサーバー側の再作成が不要になる利点がある。

    前提: Microsoft Entra IDAzure SQL DatabaseフェイルオーバーグループSQL ログイン

    関連: データベースユーザー

  • タスク自動化(SQL Server Agent・Elastic Jobs)

    定型運用の自動化はデプロイ先で異なる。SQL Server Agent=VM/Managed Instance のジョブスケジューラ(ジョブ・ステップ・スケジュール・オペレーター通知)。Azure SQL Database は SQL Agent が無いため Elastic Jobs(ジョブエージェント+ジョブDB、ターゲットグループで複数 DB に T-SQL を並列実行)を使う。Azure Automation の Runbook(PowerShell/Python・ハイブリッドワーカー)でクラウド/オンプレ横断の運用を自動化。統計更新・インデックス再構成・DBCC CHECKDB・バックアップ検証などをスケジュール化し、失敗時に通知する。

    前提: Azure SQL DatabaseインデックスAzure Automation(Runbook)Elastic Jobs

  • アクセス許可(GRANT/DENY/REVOKE・最小権限)

    固定/カスタムのデータベースロールと GRANT/DENY/REVOKE で securable ごとに権限を付与する。DENY が優先され、最小権限を全 securable に適用する。

  • ExpressRoute ゲートウェイ

    ExpressRoute 回線と VNet を接続する仮想ネットワークゲートウェイ。SKU で帯域とパフォーマンスが決まる。

    前提: ExpressRoute仮想ネットワーク(VNet)性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • マネージドサービス(管理の境界)

    AWS が運用の一部を肩代わりするサービス区分。フルマネージド(パッチ/スケール/可用性まで AWS)ほど運用負荷が下がる一方、制御は減る。アンマネージド(EC2 等)は柔軟だが自己管理。責任共有モデルの「どこまでが自分の責任か」を決める軸。

  • プライベート DNS ゾーン

    VNet 内だけで有効な DNS ゾーン。VNet にリンクして内部名や privatelink 名をプライベート IP に解決する。プライベートエンドポイント運用の要。

    前提: 仮想ネットワーク(VNet)プライベートエンドポイント

  • ユーザー定義ルート(UDR)

    システムルートを上書きする手動の経路。宛先プレフィックス→次のホップ(仮想アプライアンス/ゲートウェイ/インターネット/なし)を定義し、ルートテーブルをサブネットに関連付ける。

    前提: Network Watcher 診断ツール(IP フロー検証・接続モニター・ネクストホップ)サブネットシステムルート

    関連: Azure NAT Gatewayプライベートエンドポイント

  • ACR(Azure Container Registry)

    コンテナイメージを保存・管理するプライベートレジストリ。ACR Tasks でクラウド側ビルドができ、認証はマネージド ID を使う。

    前提: コンテナイメージマネージド ID

    関連: Azure Container Apps

  • Microsoft Defender for Cloud

    リソースのセキュリティ状態を採点(セキュアスコア)し、設定不備や脅威を検出して改善を促す。

  • 管理グループ

    複数のサブスクリプションを束ねる最上位コンテナ。ポリシーやアクセス制御を一括適用し下位へ継承。

    前提: サブスクリプション(Azure)

  • Azure Monitor

    リソースのメトリックとログを収集する監視の基盤。Log Analytics(KQL分析)やApplication Insights(アプリ監視)、アラートにつながる。

  • VPN Gateway

    インターネット経由の暗号化トンネルでオンプレミスと接続するサービス。

  • ストレージアカウントの種類と性能

    汎用 v2(GPv2)が標準で Blob/File/Queue/Table を扱う。性能は Standard(HDD)と Premium(SSD・低遅延)から選び、Premium は BlockBlob/FileShare/Page 用に種別が分かれる。

    前提: Blob ストレージAzure ストレージアカウント性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • Always Encrypted

    Azure SQL の機密列(クレジットカード番号など)をクライアント側で暗号化し、サーバーに平文を見せない仕組み。鍵(列マスターキー)はクライアントや Key Vault に置く。サーバーは平文を扱えないため通常は等価検索などに限られ、範囲演算などには Secure Enclaves が必要。保存時のみ守る TDE と異なり、利用時(DBA に対しても)保護する点が特徴。

    前提: 保管時の暗号化(at rest)Azure Key Vault

    関連: 顧客管理キー(CMK)/ プラットフォーム管理キー(PMK)

  • 顧客管理キー(CMK)/ プラットフォーム管理キー(PMK)

    保存時暗号化の鍵の管理方式。PMK=Azure が既定で管理(追加設定なし)。CMK=顧客が Key Vault で鍵を作成・ローテーション・失効を制御し、Storage や SQL TDE の保護キーに指定する(規制対応など)。暗号アルゴリズム自体は同じで、違いは「鍵を誰が管理するか」。ディスクは Azure ディスク暗号化(ゲスト OS 内 BitLocker/DM-Crypt)やホストでの暗号化(基盤側)で保護し、いずれも CMK 対応。

    前提: 保管時の暗号化(at rest)Azure Key Vault

    関連: Always Encrypted

  • 透過的データ暗号化(TDE)

    Azure SQL のデータベースを保存時(ファイル・バックアップ)に暗号化する機能で、既定で有効。アプリ側の改修は不要(透過的)で、処理時はサーバー上で復号されるため DB 管理者やサーバーは平文を扱える。保護キーは既定のサービス管理キーから CMK(BYOK)へ変更できる。「保存時」を守るのが役割で、転送時は TLS が担当する。

    前提: BYOK とインフラストラクチャ暗号化顧客管理キー(CMK)/ プラットフォーム管理キー(PMK)Azure SQL Database保管時の暗号化(at rest)

  • Web Application Firewall(Azure WAF)

    Application Gateway(リージョン内)または Front Door(グローバルエッジ)上で動き、SQL インジェクションや XSS など L7(アプリ層)攻撃を防ぐ。OWASP のマネージドルールセットと、地域遮断やレート制限などのカスタムルールを組み合わせる。導入時は検出(Detection)モードで誤検知を確認し、防御(Prevention)へ切り替える。NSG/Firewall が L3/L4 なのに対し WAF は L7。

    前提: Application Gatewayリージョン(Azure)Azure Front Doorレート制限

  • 負荷分散(Load Balancer / Application Gateway / Traffic Manager)

    トラフィックを複数バックエンドへ振り分ける Azure のサービス群。Azure Load Balancer=L4(TCP/UDP)・リージョン内・高速(内部/公開・ヘルスプローブ・バックエンドプール)。Application Gateway=L7(HTTP)・リージョン内・URL パスベースルーティング・SSL 終端・WAF。Front Door=L7・グローバル(エッジ配信・WAF/CDN・リバースプロキシ)。Traffic Manager=DNS ベースのグローバル振り分け(実トラフィックは直接バックエンドへ)。判断軸は「L4 か L7 か」「リージョンかグローバルか」。

    前提: Application Gatewayリージョン(Azure)Azure Load BalancerAzure Front Door

  • Azure Backup

    VM・ファイル共有・SQL/SAP HANA 等を定期的にバックアップし、Recovery Services コンテナーへ保存するマネージドサービス。必要なときに任意の復元ポイントからリストアする「データ復元」が目的で、暗号化・保持ポリシー・即時リストアに対応する。

    前提: マネージドサービス(管理の境界)

    関連: Azure Site Recovery(ASR)

  • 診断設定

    各リソースのログ・メトリックの送付先(Log Analytics ワークスペース/ストレージアカウント=長期保管/Event Hub=外部 SIEM 連携)を指定する構成。診断設定をしない限りリソースログは既定では集約されない点に注意(アクティビティログはサブスクリプション単位で自動記録される)。データ収集ルール(DCR)で収集対象や変換を細かく制御できる。

    前提: サブスクリプション(Azure)Azure ストレージアカウントLog Analytics ワークスペース

  • Azure Site Recovery(ASR)

    VM を別リージョン(または オンプレ⇔Azure)へ継続的にレプリケートし、災害時にフェイルオーバーして稼働を継続させる DR(災害復旧)サービス。テストフェイルオーバーで本番を止めずに手順検証でき、復旧計画(Recovery Plan)で複数 VM の起動順序をオーケストレーションする。

    前提: リージョン(Azure)

    関連: Azure Backup

  • Azure Cosmos DB

    グローバル分散・低遅延・自動スケールのマネージド NoSQL。複数 API(NoSQL/MongoDB/Cassandra/Gremlin/Table)対応。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • Azure SQL の Microsoft Entra 認証

    Azure SQL の推奨認証。Entra ID で一元管理し、MFA・条件付きアクセス・マネージド ID でのパスワードレス接続に対応する。Entra ID 管理者を構成して有効化する。

    前提: 条件付きアクセスMicrosoft Entra IDマネージド ID

    関連: SQL 認証

  • ExpressRoute FastPath

    通常は ExpressRoute ゲートウェイを経由するデータパスを、対応 SKU で仮想ネットワークゲートウェイを迂回させて低遅延・高スループットにするオプション。一部の構成(UDR やロードバランサー経由)では適用対象外になる制約がある。

    前提: ExpressRoute仮想ネットワーク(VNet)ExpressRoute ゲートウェイ性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    関連: ExpressRoute Direct

  • Azure NAT Gateway

    サブネットからの送信(アウトバウンド)専用の NAT。SNAT ポート枯渇を避けて安定した外向き接続を提供する(受信は提供しない)。

    前提: 送信規則と SNAT(Load Balancer)サブネット

    関連: プライベートエンドポイントユーザー定義ルート(UDR)

  • CIDR 表記

    IP アドレス範囲を「/24」のようなプレフィックス長で表す記法。/24 は 256 個、/16 は 65,536 個のアドレスを含み、数字が小さいほど範囲が広い。VPC/VNet やサブネットの設計、ルーティングの最長一致判定、ファイアウォールルールの許可範囲指定など、あらゆるクラウドのネットワーク設計の基礎になる。

    前提: 仮想ネットワーク(VNet)サブネット

  • ポイント対サイト VPN(P2S)

    個々のクライアント端末から Azure VNet へ接続する方式。トンネル種別と認証(証明書・RADIUS・Microsoft Entra ID)を選び、VPN クライアント構成を配布する。

    前提: Microsoft Entra ID仮想ネットワーク(VNet)VPN Gateway

  • サイト間 VPN(S2S)

    オンプレ拠点と Azure VNet を IPsec トンネルで常時接続する方式。VPN ゲートウェイとオンプレのローカルネットワークゲートウェイを構成する。

    前提: 仮想ネットワーク(VNet)VPN Gateway

  • SQL ログイン

    SQL Server/Azure SQL のサーバーレベルのセキュリティプリンシパル。認証(サーバーへ接続できるか)を担い、データベースへのアクセス権はユーザーへマッピングして初めて得られる。Microsoft Entra ログインと SQL 認証ログインの 2 系統がある。

    前提: SQL 認証

  • VPN ゲートウェイ SKU と冗長性

    VPN ゲートウェイの性能/帯域/トンネル数を決める SKU。可用性のためにアクティブ/アクティブ構成やゾーン冗長を選ぶ。

    前提: 冗長性(LRS/ZRS/GRS/GZRS)VPN Gatewayゾーン冗長(Azure SQL)性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • ARM テンプレート

    Azure リソースの構成を JSON で宣言的に記述する IaC の基盤形式。同じテンプレートを何度デプロイしても同じ状態に収束する冪等性を持ち、パラメーターファイルで環境ごとの値を切り替える。デプロイは増分(既定)または完全モードで、完全モードはテンプレートに無いリソースを削除する点に注意。

    前提: JSON

  • アクセス層(Hot/Cool/Cold/Archive)

    Blobの保存コストをアクセス頻度で最適化する層。下にいくほど保存は安く、取り出しは遅く割高。

    前提: Blob ストレージ

  • Azure Arc

    オンプレミスや他クラウドのサーバー・Kubernetes・DBを、Azureの管理面(ポリシー/タグ/RBAC)で一元管理する。

    前提: ロールベースのアクセス制御(RBAC)タグ(Azure)

  • Azure Functions

    サーバーレス(FaaS)の代表。イベント駆動で関数を実行し、実行分だけ課金。

  • ネットワークセキュリティグループ(NSG)

    サブネットやNIC単位で送信元・宛先・ポートに基づく許可/拒否ルールを適用する。

    前提: アクセス許可(GRANT/DENY/REVOKE・最小権限)サブネット

  • Azure Policy

    リソースが満たすべき条件(許可リージョン・必須タグ等)をルールとして定義・強制し、準拠状況を評価する。

    前提: リージョン(Azure)タグ(Azure)

  • ロールベースのアクセス制御(RBAC)

    誰に・どの役割を・どのスコープで割り当てて権限を与える認可の仕組み。最小権限が原則、割り当ては下位へ継承。

  • リージョンペア

    同一地理内の離れた2リージョンの組。広域災害への冗長性・順次更新・GRS の複製先に使う。なお2024年以降の新リージョンはペアを持たないものがあり、その場合は可用性ゾーン(ゾーン冗長)で代替する。

    前提: 可用性ゾーン冗長性(LRS/ZRS/GRS/GZRS)リージョン(Azure)ゾーン冗長(Azure SQL)

  • タグ(Azure)

    リソースに付ける key=value のラベル。コスト集計・整理や、Policyと組み合わせた統制に使う。

  • Azure Virtual Machines(VM)

    IaaSの仮想マシン。OSから上を自分で管理する最も自由度の高いコンピュート。

  • 仮想マシンスケールセット(VMSS)

    同一構成のVMを束ねて負荷に応じ自動スケールする仕組み(性能の軸。可用性は可用性セット/ゾーン)。

    前提: Azure Virtual Machines(VM)可用性セット(障害/更新ドメイン)

  • 可用性セット(障害/更新ドメイン)

    単一データセンター内で VM を障害ドメイン(電源/ネットワーク/ラック)と更新ドメイン(計画メンテの単位)に分散し、計画外障害と計画メンテの同時影響を避ける。データセンター規模の障害には可用性ゾーンを使う。

    前提: 可用性ゾーン

  • BCDR 設計(バックアップ/災害復旧)

    事業継続と災害復旧の設計。Azure Backup でデータを保護し、Azure Site Recovery でリージョン間レプリケーション/フェイルオーバー、ゾーン冗長やマルチリージョンで RPO/RTO 要件を満たす。

    前提: リージョン(Azure)Azure BackupAzure Site Recovery(ASR)ゾーン冗長(Azure SQL)

  • Azure Bastion

    VM に公開 IP を付けずに、ブラウザ越し(Azure ポータル)で RDP/SSH 接続できるマネージドな踏み台サービス。管理ポートをインターネットに開放せずに済み、攻撃面を減らす。必要時のみ管理ポートを一時開放する Just-In-Time VM アクセスと併用されることが多い。

    前提: Azure ポータルと Marketplace

    関連: Just-In-Time VM アクセス

  • Azure Firewall

    マネージドでステートフルなネットワークファイアウォール。中央で通信を制御する。

  • Log Replay Service(LRS)

    SQL Managed Instance への移行で、バックアップを Blob から継続的に復元・適用してオンライン移行を実現する手動カットオーバー方式の仕組み。

    前提: Blob ストレージオンライン/オフライン移行SQL Managed Instance

  • データベース移行(評価・DMS・オンライン/オフライン)

    オンプレ等から Azure SQL へ移す流れ。まず評価(Data Migration Assistant/Azure Migrate で互換性チェック・推奨先・SKU 見積り)→実行(Azure Database Migration Service や Azure SQL Migration 拡張、MI 向けは Log Replay Service)。停止を許容できるオフライン(一括コピー)か、変更を継続同期し最後にカットオーバーするオンライン(停止最小)を選ぶ。移行後は互換性レベル調整と Query Store で性能退行を確認。移行先は「インスタンス機能の要否・OS 制御の要否・許容停止時間」で判断。

    前提: Azure Database Migration Service(DMS)Log Replay Service(LRS)オンライン/オフライン移行Query Store

  • Query Store

    クエリのテキスト・実行プラン・実行時統計を履歴として保持する機能。性能退行(リグレッション)の検出やプラン強制の基盤になる。

    前提: 自動チューニング(plan forcing)実行プラン

  • 読み取りスケールアウト

    Business Critical / Hyperscale で、読み取り専用のセカンダリレプリカに読み取り負荷を振り分け、主レプリカの負荷を下げる機能。接続文字列の ApplicationIntent=ReadOnly で利用する。

    前提: リソースロックHyperscale レベルとページサーバー

    関連: Business Critical レベル

  • 保管時の暗号化(at rest)

    ディスクやオブジェクトストレージ上に保存されているデータを暗号化すること。クラウドの多くのマネージドストレージ(ブロック/ファイル/オブジェクト/DB)はサービス側の鍵管理(KMSなど)と統合した暗号化オプションを持つ。盗難・不正アクセスからデータ本体を守る基本対策。

  • B2B コラボレーション(Entra External ID)

    取引先など外部組織のユーザーをゲストとして招待し、相手側の既存 ID のまま自社リソースへ共同アクセスさせる仕組み。現行は Microsoft Entra External ID に統合されており、条件付きアクセスやクロステナントアクセス設定で招待・権限を細かく制御する。招待されたゲストは自社(招待元)テナント内にゲストユーザーとして登録され、外部組織の資格情報で認証される(別テナントが作られるわけではない)。

    前提: 条件付きアクセス

    関連: B2C(Azure AD B2C)

  • Azure Event Grid

    離散イベント(「Blob 作成」等)をリアクティブに配信する pub/sub。イベントサブスクリプションで購読し、ほぼリアルタイムに反応する。

    前提: Blob ストレージサブスクリプション(Azure)

  • Azure Event Hubs

    大量のストリーミング/テレメトリを取り込む高スループットのイベント取り込み。パーティションとコンシューマーグループで並列に処理する。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • 強制トンネリングとゲートウェイトランジット

    強制トンネリング=外向きインターネットを UDR でオンプレ経由に強制する。ゲートウェイトランジット=スポークがハブの VPN/ExpressRoute ゲートウェイを共有する設定。

    前提: ExpressRouteExpressRoute ゲートウェイ

  • HTTPS

    HTTPをTLSの上に載せて運ぶプロトコル。通常のHTTPと違い通信内容が暗号化され、途中経路での盗聴・改ざんを防げる。ブラウザは証明書を検証してサーバーの正当性を確認し、Webサイトの標準的な通信方式になっている。

    関連: TLS

  • Log Analytics ワークスペース

    各種リソースのログ・メトリックを集約して保持するデータストア。KQL(Kusto Query Language)でクエリして分析でき、Microsoft Sentinel や Azure Monitor アラートの土台にもなる。ワークスペース単位でアクセス制御と保持期間(既定30日、延長可)を設定する。

    前提: Azure MonitorMicrosoft Sentinel

  • ポート番号

    同じ IP アドレス上で動く複数のサービスを識別する 16 ビットの番号(例:HTTP は 80、HTTPS は 443、SSH は 22)。TCP・UDP のヘッダーに含まれ、ファイアウォールやセキュリティグループのルールは送信元/宛先ポートで通信を許可・拒否する。

    前提: アクセス許可(GRANT/DENY/REVOKE・最小権限)HTTPS

    関連: UDP

  • サービスチェイニング(NVA 経由)

    UDR の次ホップを NVA(ネットワーク仮想アプライアンス=ファイアウォール等)にして通信を必ず経由させる設計。NVA 側で IP 転送を有効化し、冗長化は内部 Load Balancer を前段に置く。

    前提: Azure Load Balancer

  • サービスエンドポイント

    サブネットから PaaS への通信を Azure バックボーン経由にし、PaaS 側のファイアウォールで当該サブネットを許可する仕組み。プライベート IP は付与しない(オンプレからは不可)。サービスエンドポイントポリシーで宛先を制限できる。

    前提: サブネット

  • SQL Managed Instance

    SQL Server と高い互換性を持つ PaaS。既存 SQL Server からの移行(リフト&シフト)に向く。

  • システムルート

    VNet 内・ピアリング・ゲートウェイ・既定インターネットへの経路を Azure が自動付与する既定ルート。UDR で上書きできる。

    前提: 仮想ネットワーク(VNet)

  • VNet ピアリング

    2 つの VNet を Microsoft バックボーンで低遅延に接続する。既定では非推移(A-B-C で A↔C は不可)なので、ハブ経由には UDR やゲートウェイトランジットが要る。

    前提: 仮想ネットワーク(VNet)強制トンネリングとゲートウェイトランジット性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • Azure App Configuration

    アプリ設定や機能フラグを一元管理するサービス。設定を集中管理し、機密は Key Vault 参照で安全に扱う。機能フラグで段階的リリースができる。

    前提: App Service の構成(設定・TLS・接続)Azure Key Vault

    関連: フィーチャーフラグ

  • App Service の構成(設定・TLS・接続)

    アプリ設定・接続文字列(環境変数として注入)、カスタムドメインの TLS/証明書、サービス接続などを構成する。機密は Key Vault 参照にできる。

    前提: Azure App ServiceAzure Key Vault

  • Application Insights

    アプリの APM サービス。要求・依存関係・例外・メトリック・ログ・トレースを収集して性能と障害を分析する。Azure Monitor の一部。

    前提: Azure Monitor

  • Azure Advisor

    自分のリソースに対するコスト・セキュリティ・信頼性・性能・運用の推奨を提示する。

  • リソースロック

    削除や変更を防ぐ安全網(CanNotDelete / ReadOnly)。権限があっても誤操作を止める。

  • Azure File Sync

    オンプレの Windows ファイルサーバーを Azure Files と同期するサービス。クラウド階層化でアクセス頻度の低いファイルをクラウドへ移し、ローカル容量を節約する。

    前提: Azure Files(File ストレージ)

  • ハイブリッド ID(Entra Connect)

    オンプレの Active Directory を Entra ID と同期してハイブリッド ID を実現する。パスワードハッシュ同期・パススルー認証・フェデレーション(AD FS)から認証方式を選ぶ。

    前提: Microsoft Entra ID

  • VM 拡張機能とカスタムスクリプト

    VM へ構成や自動化を後付けする仕組み。カスタムスクリプト拡張で起動時にスクリプトを実行し、DSC や Azure Monitor エージェントもエクステンションで導入する。

    前提: Azure Monitor

  • Azure Data Lake Storage Gen2

    Blob ストレージ上に階層型名前空間を追加した、大規模分析向けのデータレイク。ディレクトリ構造と POSIX 風の ACL を持ち、Synapse や Databricks の分析基盤の蓄積層として使われる。

    前提: Blob ストレージAzure DatabricksAzure Synapse Analytics

  • ハブスポークネットワークトポロジ

    中央ハブ VNet に共有サービス(ファイアウォール・ゲートウェイ・DNS)を集約し、スポーク VNet をピアリングで接続する設計。Virtual WAN でマネージドに実現することもできる。

    前提: 仮想ネットワーク(VNet)Azure Virtual WAN

  • Azure ランディングゾーン(CAF)

    Cloud Adoption Framework のエンタープライズスケールに基づく、標準化された基盤の青写真。ネットワーク(ハブ&スポーク)・ID・ポリシー・管理を事前構成し、管理グループ階層に沿って一貫したガバナンスを展開できる。

    前提: 管理グループハブスポークネットワークトポロジ

    関連: Azure ランディングゾーン

  • Azure Logic Apps

    多数のコネクタを使ってワークフローをノーコード/ローコードで統合するサービス。SaaS やオンプレ、Azure サービスをトリガー/アクションでつなぎ、業務プロセスの自動化やシステム間連携を実現する。

  • Azure Pipelines

    CI/CD をコード(YAML)で定義するパイプラインサービス。ステージ→ジョブ→ステップの階層で構成し、push/PR/スケジュールのトリガーで起動、テンプレートで再利用する。実行は Microsoft ホスト/セルフホストのエージェントで行う。

    前提: YAML

  • Just-In-Time VM アクセス

    Defender for Cloud の機能で、VM の RDP/SSH などの管理ポートを普段は閉じておき、要求・承認時のみ一時的に NSG/Firewall へ許可規則を入れて開放、時間が経つと自動で閉じる。常時公開を避けて攻撃面を減らす。常時利用できる踏み台の Bastion とは異なり、JIT は「必要なときだけ開ける」方式。

    前提: Microsoft Defender for Cloud

    関連: Azure Bastion

  • BGP とルート伝播

    オンプレと Azure ゲートウェイ間で経路を動的に交換する標準プロトコル。自律システム番号(ASN)で相手を識別し、Azure ゲートウェイの既定 ASN は 65515、オンプレは自社 ASN を設定する。VPN で BGP を有効化すると拠点のサブネット増減が自動学習され UDR の手直しが不要に。ExpressRoute は常に BGP で経路交換(プライベート/Microsoft ピアリング)。学習経路を VNet に反映するのがルート伝播で、ルートテーブルで伝播を無効化すると UDR を確実に優先できる。同一宛先に複数経路があると ExpressRoute が VPN より優先される(バックアップ VPN 設計の根拠)。優先順位は最長プレフィックス一致→UDR>BGP>システム。

    前提: ExpressRoute仮想ネットワーク(VNet)サブネット

  • Azure ランディングゾーン

    管理グループ・サブスクリプション・ポリシー・ネットワーク・ID を含む、拡張可能で統制された Azure 環境の設計図。Cloud Adoption Framework のエンタープライズスケールに基づく。

    前提: 管理グループサブスクリプション(Azure)

    関連: Azure ランディングゾーン(CAF)

  • Azure ポータルと Marketplace

    Azure portal は GUI でリソースを一元管理する Web コンソール。Azure Marketplace は Microsoft/サードパーティのソリューションを購入・デプロイできる。モバイルアプリでも監視/操作できる。

  • AzCopy

    Blob/ファイル共有との間で大量データを高速にコピー・アップロード・ダウンロードする コマンドライン ツール。並列転送やチェックポイント再開に対応し、GUI の Storage Explorer よりスクリプト化・自動化に向く。認証は Microsoft Entra ID または SAS トークン。

    前提: Blob ストレージMicrosoft Entra ID

    関連: Azure Storage Explorer

  • Azure Database for MySQL

    OSS の MySQL エンジンをマネージドで提供するリレーショナルサービス。現行は Flexible Server 形態で、同一可用性ゾーン内配置によるレイテンシ最適化や柔軟なコンピュート/ストレージのスケーリングに対応する。パッチ適用・バックアップ・フェイルオーバーは Azure が運用する。

    前提: 可用性ゾーン性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    関連: Azure Database for PostgreSQL

  • Azure DNS(パブリックゾーン)

    ドメインの公開 DNS レコードを Azure でホストするサービス。インターネットからの名前解決を提供する。

  • Azure Files(File ストレージ)

    SMB/NFS のファイル共有。複数のマシンから同時にマウントできる。

  • Azure Container Apps

    Kubernetes を意識せずコンテナ/マイクロサービスを動かすサーバーレス基盤。KEDA でイベント駆動スケール(ゼロスケール可)、Dapr 連携に対応。

    前提: マイクロサービス

    関連: ACR(Azure Container Registry)

  • Azure DNS Private Resolver

    オンプレと Azure 間の DNS 解決を仲介するマネージドサービス。条件付きフォワーダーで特定ドメインの問い合わせを適切な DNS へ転送する。

    前提: Azure DNS(パブリックゾーン)マネージドサービス(管理の境界)

  • Always On 可用性グループ

    SQL Server on VM / Managed Instance で、複数レプリカ間でデータベース群を同期/非同期にレプリケートし HA/DR を構成する機能。

    前提: SQL Managed InstanceSQL Server on VM

  • 自動チューニング(plan forcing)

    Azure SQL が推奨インデックスの自動作成や、退行時の FORCE LAST GOOD PLAN(直近の良いプランの強制)を自動適用する機能。

    前提: インデックス

  • Azure Automation(Runbook)

    PowerShell/Python の Runbook でクラウド/オンプレ横断の運用を自動化するサービス。ハイブリッドワーカーでオンプレ実行もできる。

  • セッションブロッキング

    あるセッションが保持するロックを別セッションが待つ状態。長時間化やデッドロックの兆候を DMV で特定し、クエリ/インデックス/分離レベルで解消する。

    前提: インデックス

  • Business Critical レベル

    ローカル SSD と組み込みの Always On レプリカで低遅延・高可用性を提供する Azure SQL のサービスレベル。読み取りスケールアウト用のセカンダリも持つ。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    関連: 読み取りスケールアウト

  • Azure Database Migration Service(DMS)

    データベースを Azure SQL へ移行するマネージドサービス。Azure SQL Migration 拡張機能と連携し、オンライン/オフライン移行を実行する。

    前提: オンライン/オフライン移行マネージドサービス(管理の境界)

  • 動的管理ビュー(DMV)

    サーバー/データベースの「今この瞬間」の内部状態(待機・ブロッキング・インデックス使用状況等)を SQL で参照できるビュー。

    前提: インデックスセッションブロッキング

  • エラスティックプール

    複数の Azure SQL Database で計算リソース(eDTU/vCore)を共有し、ピークがずれる多数 DB のコストを最適化する仕組み。

    前提: Azure SQL Database購入モデル(vCore / DTU)

  • 実行プラン

    クエリの実行手順の図。スキャン対シーク・キールックアップ・非 SARGable 述語を見て、インデックスや書き換えで改善点を判断する。

    前提: インデックス

  • General Purpose レベル

    Azure SQL のバランス型サービスレベル。計算とリモートストレージを分離し、コストと性能のバランスが良い汎用ワークロード向け。

  • オンライン/オフライン移行

    オフラインは一括コピーで停止を伴う。オンラインは変更を継続同期し最後にカットオーバーするため停止が最小。許容停止時間で選ぶ。

  • SQL 認証

    ユーザー名とパスワードを SQL 側で管理する従来型の認証。Entra 認証が使えない場合の代替で、強力なパスワードと最小権限が前提。

    関連: Azure SQL の Microsoft Entra 認証

  • B2C(Azure AD B2C)

    消費者向けアプリのサインアップ/サインインをカスタマイズできる CIAM(顧客 ID・アクセス管理)機能。ソーシャルログインやカスタムポリシーでブランド化したログイン体験を提供する。旧 Azure AD B2C は2025年5月以降に新規テナントを作成できず、Microsoft Entra External ID への統合・移行が進んでいる。

    前提: Microsoft Entra IDSQL ログイン

    関連: B2B コラボレーション(Entra External ID)

  • Microsoft Entra ID Protection

    漏洩資格情報やあり得ない移動などからユーザーリスク/サインインリスクを算出し、条件付きアクセスと連携する。

    前提: 条件付きアクセスMicrosoft Entra ID

  • ExpressRoute Direct

    接続事業者を介さず、10 Gbps または 100 Gbps の専用ポートペアを Microsoft のエッジルーターへ直接占有して接続する ExpressRoute の形態。1 つの物理接続上に複数の ExpressRoute 回線(サブレット化)を作成でき、大容量・低レイテンシが必要な用途向け。

    前提: ExpressRoute性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    関連: ExpressRoute FastPath

  • Functions のホスティングプラン

    実行環境の課金/性能の選択。Flex Consumption(現行主流・高速スケール・VNet・常時準備インスタンス可)/従量課金(旧 Consumption・自動スケール・コールドスタート有)/Premium(事前ウォーム・VNet)/専用(App Service プラン)。

    前提: Azure App ServiceAzure Functions仮想ネットワーク(VNet)

  • JSON

    波括弧とキー・値のペアで構造化データを表す軽量なテキスト形式。API のリクエスト/レスポンスや IAM ポリシー・バケットポリシーのような権限定義など、機械可読性を重視する場面で広く使われる。

  • Key Vault のオブジェクト(キー/シークレット/証明書・開発)

    コードからシークレット・キー・証明書を安全に取得して使う開発。接続文字列等はアプリに直書きせず、Key Vault 参照やマネージド ID で取得する。

    前提: Azure Key Vaultマネージド ID

  • 送信規則と SNAT(Load Balancer)

    バックエンドプールの VM がインターネットへ送信する通信の送信元アドレスを、Load Balancer のフロントエンド IP に変換(SNAT)する仕組み。パブリック IP を持たない VM のアウトバウンド接続を可能にし、送信規則でポート割り当て(SNAT ポートの枯渇に注意)を制御する。

    関連: インバウンド NAT 規則負荷分散規則

  • メッセージとイベントの違い

    メッセージ=送信側が処理を期待する「指示(コマンド)」(Service Bus/Queue)。イベント=起きた事実の「通知」(Event Grid/Event Hubs)。選定の軸になる。

    前提: Azure Event GridAzure Event HubsAzure Service Bus

  • マルチキャスト

    特定のグループに参加したホストにだけ一斉配信する通信方式。ブロードキャスト同様クラウドの仮想ネットワークでは標準サポートされないことが多く、必要な場合はトランジットゲートウェイのマルチキャスト機能のような専用サービスを使うか、設計をユニキャスト前提に置き換える。

    前提: 仮想ネットワーク(VNet)ブロードキャストユニキャスト

  • パケットキャプチャ(Network Watcher)

    VM の通信を実際に取得して解析する Network Watcher の機能。アプリ層の問題やNSGでは分からない事象の切り分けに使う。

  • レート制限

    単位時間あたりに受け付けるリクエスト数の上限を管理し、過負荷や乱用(DoS・スクレイピング等)から後段のシステムを守る仕組み。API ゲートウェイや Web アプリケーションファイアウォールのレートベースルールとして実装されることが多い。

  • Queue ストレージ

    コンポーネント間を疎結合にするメッセージキュー。処理の山を平準化できる。

    前提: 疎結合(デカップリング)

  • フォールトトレランス(耐障害性)

    構成要素が壊れてもサービスを止めない設計。高可用性(早期復旧)より一段強く、障害時も中断なく稼働し続ける。冗長な並行系(アクティブ/アクティブ)・N+1 構成・複数 AZ への分散で実現する(自動復旧は中断を伴うため高可用性側の手段)。

    前提: VPN ゲートウェイ SKU と冗長性

  • Defender for Servers

    VM の脆弱性スキャン(Defender 脆弱性管理)・EDR(Defender for Endpoint 統合)・エージェントレス スキャン・JIT VM アクセスを提供する。Azure Arc でオンプレや AWS/GCP のサーバーにも拡張できる。

    前提: Azure ArcJust-In-Time VM アクセス

  • Secured Virtual Hub

    仮想ハブに Azure Firewall を組み込み、Firewall Manager で複数ハブのポリシーを一元適用して通信を集中検査する構成。

    前提: Azure Firewall仮想ハブ(Virtual WAN)

  • Azure Service Bus

    エンタープライズ向けのメッセージブローカー。順序・トランザクション・重複排除・デッドレターに対応し、確実な指示(コマンド)の配送に使う。

  • データベースユーザー

    SQL Server(および Azure SQL)のデータベースレベルのセキュリティプリンシパル。ログインにマッピングされ、ロールメンバーシップや GRANT/DENY/REVOKE を通じてオブジェクトへのアクセス許可(認可)を決める。DENY は SQL Server の T-SQL 固有の権限状態で、PostgreSQL や MySQL には存在しない。ログイン無しで作る「コンテインドユーザー」と対比される。

    前提: アクセス許可(GRANT/DENY/REVOKE・最小権限)SQL ログイン

    関連: コンテインドユーザー

  • Azure Traffic Manager

    DNS ベースのグローバルなトラフィック振り分け。優先度/重み付け/パフォーマンス/地理的などのルーティング方式で応答する IP を返す(実通信は直接バックエンドへ)。

  • 仮想ハブ(Virtual WAN)

    Virtual WAN の中核となるマネージドのハブ。VPN/ExpressRoute/P2S ゲートウェイや接続を収容し、ハブルーティングでスポーク間も中継する。

    前提: ExpressRoute

    関連: Azure Virtual WAN

  • WAF ポリシーと検出/防止モード

    Web Application Firewall の構成。Application Gateway や Front Door に関連付け、検出モード(記録のみ)か防止モード(ブロック)を選ぶ。OWASP ルールセットで一般的な攻撃を防ぐ。

    前提: Application GatewayWeb Application Firewall(Azure WAF)Azure Front Door

  • YAML

    インデントで階層を表す、人が読み書きしやすいテキスト形式。CloudFormation や各種 IaC ツール、CI/CD パイプラインの設定ファイルで好まれ、同じデータを JSON とも相互変換できる。

    前提: JSON

  • エニーキャスト

    同じ IP アドレスを複数の拠点から同時に広告し、経路的に最も近いノードへ自動的に届ける通信方式。CDN や DNS、グローバル負荷分散サービスが低遅延・高可用性を実現する基盤として使う。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    関連: ユニキャスト

  • 開発者ポータル(APIM)

    API の利用者向けに、ドキュメント・試用・サブスクリプション取得を提供する自動生成ポータル。

    前提: サブスクリプション(Azure)

    関連: Azure API Management(APIM)

  • 名前付き値(APIM)

    ポリシーで使う定数や機密を一元管理する仕組み。シークレットは Key Vault と連携して安全に参照する。

    前提: Azure Key Vault

    関連: Azure API Management(APIM)

  • APIM ポリシー

    API の挙動を XML で制御する仕組み(インバウンド/バックエンド/アウトバウンド/エラー)。認証(validate-jwt)・レート制限・変換・キャッシュ・CORS を適用する。

    前提: レート制限

    関連: Azure API Management(APIM)

  • 製品とサブスクリプション(APIM)

    API を「製品」としてまとめ、利用者はサブスクリプション(キー)で利用する仕組み。公開範囲や利用条件を製品単位で管理する。

    前提: サブスクリプション(Azure)

    関連: Azure API Management(APIM)

  • 診断とログ(App Service)

    アプリ/Web サーバー/詳細エラーのログ収集とログストリームでのリアルタイム確認。App Insights と連携して監視する。

    前提: Azure App Service

  • スケールセットの自動スケール

    仮想マシンスケールセットを CPU 等のメトリックやスケジュールに応じて自動でインスタンス数を増減する。スケールイン/アウトのルールと上限/下限を定義する。

    前提: Azure Virtual Machines(VM)仮想マシンスケールセット(VMSS)

  • YAML パイプラインとテンプレート

    パイプラインをコード(YAML)で定義し、ステージ・ジョブ・ステップで構成する。テンプレートで共通処理を再利用し、マルチステージで CI と複数環境への CD を 1 本にまとめる。

    前提: Azure PipelinesYAML

  • App Service Environment(ASE)

    専用かつ分離された App Service の実行環境。仮想ネットワークに統合され、ネットワーク分離や高いスケールが必要な機密ワークロードに使う。

    前提: Azure App Service仮想ネットワーク(VNet)

  • BYOK とインフラストラクチャ暗号化

    BYOK(Bring Your Own Key)で顧客管理キーをストレージ暗号化に持ち込み、さらにインフラストラクチャ暗号化を有効化して 256 ビット AES の二層でデータを保護する。

    前提: 顧客管理キー(CMK)/ プラットフォーム管理キー(PMK)

  • キーのローテーションとバックアップ

    Key Vault のキー/シークレット/証明書を定期的に自動ローテーションして漏えいリスクを下げ、バックアップ/復元で誤削除や障害に備える。

    前提: Azure Key VaultKey Vault のオブジェクト(キー/シークレット/証明書・開発)

  • ワークフロー自動化(Defender for Cloud)

    セキュリティアラートや推奨事項をトリガーに Logic Apps を起動し、通知・チケット起票・修復などの対応を自動化する。

    前提: Microsoft Defender for CloudAzure Logic Apps

  • Azure CDN

    静的コンテンツをエッジにキャッシュし低遅延で配信する。Microsoft 標準プロファイルが現行で、旧 Verizon/Edgio プロファイルは廃止方向。新規は Azure Front Door(CDN 統合)が推奨。更新はパージで反映。

    前提: Azure Front Door性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • Azure Database for PostgreSQL

    OSS の PostgreSQL エンジンをマネージドで提供するリレーショナルサービス。現行は Flexible Server 形態で、可用性ゾーン配置やバーストキャパブル SKU、きめ細かなメンテナンスウィンドウ設定に対応する。パッチ適用・バックアップ・フェイルオーバーは Azure が運用する。

    前提: 可用性ゾーン

    関連: Azure Database for MySQL

  • Azure Storage Explorer

    Blob・ファイル共有・キュー・テーブルを GUI で閲覧・アップロード・管理できるスタンドアロンアプリ(Windows/macOS/Linux)。少量データの確認や手動操作、アクセス許可の簡易設定に向き、大量データの高速転送は AzCopy を使う。

    前提: Blob ストレージ

    関連: AzCopy

  • Bicep

    ARM テンプレート(JSON)をより簡潔に書ける DSL(ドメイン固有言語)。az bicep build でコンパイルすると等価な ARM テンプレート JSON に変換され、最終的にデプロイされるのは ARM テンプレートである。モジュール化やループ(loop)記法で可読性・再利用性が高い。

    前提: ARM テンプレートJSON

  • Blob のアクセス層

    アクセス頻度に応じたコスト最適化の層。ホット(高頻度)/クール(低頻度)/コールド/アーカイブ(ほぼ参照なし・取り出しに時間)。

    前提: アクセス層(Hot/Cool/Cold/Archive)Blob ストレージ

  • Blob のライフサイクル管理

    一定日数で自動的にアクセス層を移動(ホット→クール→アーカイブ)したり削除したりするポリシー。保管コストを最適化する。

    前提: アクセス層(Hot/Cool/Cold/Archive)Blob ストレージ

  • 接続モニター(Connection Monitor)

    エンドポイント間の到達性・遅延・パケットロスを継続的に監視する Network Watcher の機能。経路の変化や障害を検知する。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • コンテナイメージ

    アプリと依存関係をまとめた不変のパッケージ。Dockerfile からビルドし、レジストリ(ACR)に push して各サービスで実行する。

  • クロスリージョン Load Balancer

    複数リージョンの Load Balancer を 1 つのグローバル IP の背後に束ねる構成。地理的冗長と低遅延ルーティングを提供する。

    前提: リージョン(Azure)性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • アクティブ geo レプリケーション

    別リージョンに読み取り可能なセカンダリを非同期に作る DR 機能。手動フェイルオーバーでき、最大4つのセカンダリを持てる。

    前提: リージョン(Azure)

  • Elastic Jobs

    Azure SQL Database 向けの自動化。ジョブエージェントとジョブ DB を使い、ターゲットグループで複数 DB に T-SQL を並列実行する。

    前提: Azure SQL Database

  • フェイルオーバーグループ

    複数 DB をグループ単位でリスナー越しに接続し、接続文字列を変えずに自動フェイルオーバーさせる DR 機能。

  • geo 復元

    GRS の geo 冗長バックアップから別リージョンへ復元する DR 手段。非同期コピーのため RPO は大きめになる。

    前提: リージョン(Azure)

  • Hyperscale レベルとページサーバー

    最大 100TB 級まで拡張できる Azure SQL のサービスレベル。ページサーバーでストレージを分離し、スナップショットベースの高速バックアップ/復元と迅速なスケールを実現する。

  • インテリジェントクエリ処理(IQP)

    クエリを書き換えずに実行性能を底上げする一連の機能(適応結合・メモリ許可フィードバック・バッチモード等)。互換性レベルで有効化する。

    前提: アクセス許可(GRANT/DENY/REVOKE・最小権限)

  • 長期保持(LTR)

    週次/月次/年次のバックアップを最大10年保持し、コンプライアンス要件に応えるバックアップ戦略。

  • 購入モデル(vCore / DTU)

    vCore は CPU・メモリ・ストレージを個別に選べる柔軟なモデルで、Azure Hybrid Benefit や予約割引が使える(推奨)。DTU は計算・ストレージをまとめた簡易指標。

    関連: サービスレベルと購入モデル(GP/BC/Hyperscale・vCore/DTU)

  • 転送時の暗号化(in transit)

    ネットワーク経路を通過中のデータを暗号化すること。多くの場合TLSで通信を保護する。保管時の暗号化と組み合わせて初めて、データのライフサイクル全体(保存中・移動中)を防御できるため、両方を満たすのがセキュリティの基本要件となる。

    前提: 保管時の暗号化(at rest)

  • ExpressRoute ピアリング(プライベート/Microsoft)

    ExpressRoute の経路種別。プライベートピアリング=VNet への到達、Microsoft ピアリング=Microsoft 365/PaaS の公開サービスへ専用線で到達。常に BGP で交換する。

    前提: ExpressRoute仮想ネットワーク(VNet)

  • 結果整合性(eventual consistency)

    書き込み直後は古い値が読まれる可能性があるが、時間の経過とともに全レプリカが最終的に収束する整合性モデル。高可用性・低遅延を優先する分散データストアの既定挙動になっていることが多い。強整合性が不要な読み取りに使うことでスループットを稼げる。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    関連: 強整合性(strong consistency)

  • Functions のトリガー

    関数を起動するきっかけ。HTTP(要求)、タイマー(定時)、Blob/Queue/Event(データ操作)、Webhook などがある。1 関数に 1 トリガー。

    前提: Blob ストレージAzure Functions

  • 水平スケーリング(スケールアウト)

    インスタンスの台数を増やして負荷を分散するスケーリング方式。ステートレス設計とロードバランサ・Auto Scalingが前提になり、1台の故障がシステム全体に影響しにくいため耐障害性も高まる。クラウドネイティブな設計では基本の方向性とされる。

    前提: フォールトトレランス(耐障害性)

  • インバウンド NAT 規則

    フロントエンドの特定ポートへの通信を、バックエンドプール内の 1 台の VM の特定ポートへピンポイントで転送する Load Balancer の規則。RDP/SSH を個別 VM へ振り分ける用途などに使い、複数バックエンドへ分配する負荷分散規則とは目的が異なる。

    前提: 負荷分散規則

    関連: 送信規則と SNAT(Load Balancer)

  • 負荷分散規則

    Load Balancer のフロントエンド IP/ポートで受けた受信トラフィックを、バックエンドプールへヘルスプローブの結果に基づいて分配する規則。既定は 5 タプルのハッシュ分散で、セッションの永続化(送信元 IP アフィニティ)も設定できる。

    関連: 送信規則と SNAT(Load Balancer)

  • 疎結合(デカップリング)

    コンポーネント間を直接呼び出しでなくキュー(SQS)や通知(SNS)・イベント(EventBridge)で分離する設計。片方の障害や負荷変動が連鎖せず、独立してスケール・更新できる。バッファリングでスパイクも吸収。

  • ブロードキャスト

    同一ネットワークセグメント内の全ホストへ一斉にデータを送る通信方式。多くのパブリッククラウドの仮想ネットワーク(VPC/VNet 相当)は既定でブロードキャストをサポートしないため、オンプレ前提のアプリをそのまま移行しようとすると設計の見直しが必要になる。

    前提: 仮想ネットワーク(VNet)

  • デフォルトルート(0.0.0.0/0)

    ルートテーブルで「他のどのルートにも一致しない宛先」を送る既定の経路。パブリックサブネットでは IGW を、プライベートサブネットでは NAT ゲートウェイを指す。外向き通信の出口を決める。

    前提: Azure NAT Gatewayサブネット

  • エフェメラルポート

    クライアントが接続の戻り通信用に一時的に使う高位のポート番号(一般に 1024–65535)。ステートレスなファイアウォールルール(例:ネットワーク ACL)では、戻り通信を許可するためにこの範囲を明示的に開ける必要があり、見落としやすい設定ミスの原因になる。

    前提: ポート番号

  • ブラストラディウス(影響範囲)

    障害や誤操作・侵害が及ぶ影響範囲。アカウント分離・複数リージョン/AZ・最小特権・セル分割で範囲を小さく保つ。範囲を限定する設計が回復力とセキュリティの基本。

    前提: リージョン(Azure)

  • Azure Route Server

    NVA と Azure の間で BGP により経路を自動交換させるマネージドサービス。UDR の手動更新なしに NVA の経路を VNet に反映できる。

    前提: 仮想ネットワーク(VNet)マネージドサービス(管理の境界)

  • Azure Virtual Network Manager

    多数の VNet をネットワークグループとして束ね、接続構成とセキュリティ管理者規則を一元適用する。セキュリティ管理者規則は NSG より先に評価される高位規則で、各チームが NSG で上書きできない組織全体のガードレールを強制する。

    前提: 仮想ネットワーク(VNet)

    関連: Azure Virtual Network Manager

  • トピックとサブスクリプション(Service Bus)

    1 つのメッセージを複数の受信者へ配る pub/sub。サブスクリプションごとにフィルターで受け取るメッセージを選別できる。

    前提: サブスクリプション(Azure)Azure Service Bus

  • 強整合性(strong consistency)

    書き込み完了後の読み取りは必ず最新の値を返す整合性モデル。結果整合性より遅延やコストが増えがちだが、在庫数や残高のように古い値の読み取りが許されない場面で選ぶ。整合性モデルはこのトレードオフに基づき用途ごとに使い分ける。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    関連: 結果整合性(eventual consistency)

  • サブネットマスク

    IP アドレスのうちネットワーク部とホスト部の境界を示す値(例 255.255.255.0)。CIDR のプレフィックス長と表裏一体の表現で、オンプレのネットワーク機器や一部のクラウド設定ではこのドット区切り表記が使われる。

    前提: CIDR 表記サブネット

  • TLS

    通信を暗号化し、証明書によってサーバー(要件次第ではクライアントも)を認証するプロトコル。ハンドシェイクで鍵交換と認証を行った後、対称鍵でデータを暗号化して送受信する。クラウドのロードバランサやCDNで終端し、証明書はマネージドサービスで発行・更新するのが一般的。

    前提: マネージドサービス(管理の境界)

    関連: HTTPS

  • UDP

    コネクションを確立せず、順序保証や再送を行わない軽量なトランスポート層プロトコル。オーバーヘッドが小さく高速なため、DNS 問い合わせや動画/音声ストリーミングなど、多少の欠落より低遅延を優先する通信に使われる。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

    関連: ポート番号

  • ユニキャスト

    1 台の送信元から 1 台の宛先へ届ける、最も一般的な 1 対 1 の通信方式。通常のクライアント・サーバー通信やほとんどの API 呼び出しはこの方式を前提に設計される。

    関連: エニーキャスト

  • 垂直スケーリング(スケールアップ)

    1台のインスタンスのスペック(CPU・メモリ等)を増強するスケーリング方式。アプリの構成変更が少なく手軽だが、インスタンスタイプの上限があり、単一障害点になりやすく、変更時に停止を伴うことが多い。水平スケーリングと対比される選択肢。

    前提: 水平スケーリング(スケールアウト)単一障害点(SPOF)

  • 仮想ネットワークフローログ

    通過/拒否トラフィックを Storage に記録するログ(NSG フローログの後継)。Traffic Analytics で可視化し、通信の傾向や異常を分析する。

    前提: 仮想ネットワーク(VNet)

  • Azure Virtual Network Manager

    多数の VNet の接続(メッシュ/ハブ&スポーク)とセキュリティ規則を一元管理するサービス。ネットワークグループ単位で構成を一括適用する。

    前提: 仮想ネットワーク(VNet)

    関連: Azure Virtual Network Manager

  • 分散トレースとアプリケーションマップ

    複数のサービスをまたぐ要求の流れを相関 ID で追跡し、依存関係と遅延をアプリケーションマップで可視化する機能。

    前提: 性能の指標(IOPS/スループット/帯域幅/レイテンシー)

  • App Service の自動スケール

    負荷に追従してインスタンス数を増減する仕組み。ルールベースの Autoscale(CPU/メモリ等のメトリックやスケジュール条件で増減)と、プラットフォーム任せの自動スケーリングが選べる。コストと性能を両立する。

    前提: Azure App Service

  • App Service へのデプロイ

    コードやコンテナーを App Service に配置する方法(ZIP デプロイ・コンテナーデプロイ・CI/CD)。スロットと組み合わせて無停止化する。

    前提: Azure App Service

  • サイドカーパターン

    メインのコンテナに補助コンテナ(ログ収集・プロキシ・セキュリティ)を同じタスク/Pod に並走させる構成。アプリ本体を変えずに横断的関心事を追加できる。サービスメッシュ(Envoy プロキシ)が代表例。

    前提: ログ配布(Log shipping)

  • Azure Service Health

    Azure 自体の障害・計画メンテナンス・正常性を通知する(Advisorは自分のリソースへの助言で別物)。

    前提: Azure Advisor

  • Blob の保護(論理削除・バージョン管理・オブジェクトレプリケーション)

    Blob/コンテナーの論理削除で誤削除から復元、バージョン管理で履歴を保持、オブジェクトレプリケーションで別アカウントへ非同期コピーする。

    前提: Blob ストレージ

  • NSG の評価と有効なルール

    NSG はサブネットと NIC の両方に適用でき、優先度の低い番号から評価して最初に一致したルールで許可/拒否する。有効なセキュリティ規則で実際の適用結果を確認する。

    前提: サブネット

  • 環境と承認/ゲート(Azure Pipelines)

    デプロイ先(Dev/Test/Staging/Prod)を表す環境と、そこへのデプロイを統制するチェック。承認(人手のサインオフ)、ゲート(監視クエリ等の自動チェック)、ブランチ制御、ビジネスアワー、必須テンプレートなどを組み合わせて本番リソースを保護する。

    前提: Azure Pipelines

  • フィーチャーフラグ

    デプロイ(コードを本番に置く)と機能の有効化(リリース)を分離する仕組み。Azure App Configuration の Feature Manager 等で管理し、段階公開・A/B テスト・即時無効化(キルスイッチ)を再デプロイなしで行える。

    関連: Azure App Configuration

  • セキュリティテスト(SAST/DAST/SCA)

    パイプラインに組み込む脆弱性検査。SAST=ソースの静的解析、DAST=稼働中アプリの動的解析、SCA(依存関係スキャン)=OSS の既知脆弱性検出、IaC/コンテナイメージスキャン=設定不備/イメージ脆弱性。動かさない検査は左(早期)、動的検査は右(デプロイ後)に置く。

    前提: コンテナイメージ

  • 変数グループと Key Vault 連携

    パイプライン間で共有する設定を変数グループにまとめ、機密値は Azure Key Vault と連携して安全に取得する。セキュアファイルで証明書等を扱う。

    前提: Azure Key Vault

  • AKS のセキュリティ

    AKS のネットワーク分離(プライベートクラスター・ネットワークポリシー)、Entra 連携の認証/認可、Defender for Containers による監視で、Kubernetes ワークロードを保護する。

    前提: Defender for Containers

  • カスタムロール(Azure ロール / Entra ロール)

    組み込みロールで粒度が足りないとき、必要な操作だけを許可するカスタムロールを定義する。Azure リソースロールと Microsoft Entra ロールは別系統で管理する。

  • Defender for Cloud DevOps セキュリティ

    GitHub・Azure DevOps・GitLab を Defender for Cloud に接続し、コードやパイプラインの構成ミス・シークレット露出・脆弱性を検出する。

    前提: Microsoft Defender for Cloud

  • Defender 脆弱性の管理

    VM やコンテナの既知の脆弱性(CVE)を継続的に検出し、優先度付けと修復推奨を提示する機能。Defender for Servers/Containers に組み込まれる。

    前提: Defender for Servers

  • ExpressRoute 上の暗号化

    プライベート回線である ExpressRoute の通信を暗号化する手段。MACsec で接続自体を、または IPsec VPN を ExpressRoute 上に重ねて保護する。

    前提: ExpressRoute

  • Microsoft Cloud Security Benchmark(MCSB)

    Defender for Cloud が既定で評価する Microsoft のセキュリティベストプラクティス集。セキュアスコアの基準となり、業界フレームワークにマッピングされる。

    前提: Microsoft Defender for Cloud

  • 規制コンプライアンス(標準・カスタム標準)

    Defender for Cloud の規制コンプライアンスダッシュボードで、PCI DSS や ISO 等の標準への準拠状況を評価し、独自要件はカスタム標準として追加できる。

    前提: Microsoft Defender for Cloud

  • BLOB バージョン管理

    上書き・削除のたびに以前の版を自動保持し、誤操作からの復元を可能にする Blob ストレージの保護機能。論理削除や不変ストレージと組み合わせて使う。

    前提: Blob ストレージ

  • Azure のサポートプラン

    Basic(無料・課金/サブスク管理)、Developer(試用)、Standard(運用)、Professional Direct(ビジネスクリティカル)から選ぶ。応答時間とアーキテクチャ支援が異なる。

    前提: サブスクリプション(Azure)

  • Azure Databricks

    Apache Spark に最適化された大規模データ処理・機械学習の基盤。データサイエンス用途に強い。

  • Azure Firewall の規則

    Azure Firewall の 3 種類の規則。DNAT 規則=受信を内部へ変換転送、ネットワーク規則=IP/ポート/プロトコルの L3-L4 制御、アプリケーション規則=FQDN ベースの L7 制御。

    前提: Azure Firewall

  • Azure Pricing Calculator

    これから構築する Azure 構成の月額コストを見積もる Web ツール。リージョン・SKU・使用時間・データ転送量などを入力してサービスごとの概算料金を算出し、構成案の比較や提案書作成に使う。実際の請求とは為替・実利用量の差で乖離しうる。

    前提: リージョン(Azure)

  • Azure Synapse Analytics

    大規模なデータウェアハウジングと統合分析(SQL・Spark・パイプライン)を1つにまとめたプラットフォーム。機能は次世代の Microsoft Fabric に統合・継承が進み、新規ワークロードは Fabric が推奨。

  • 双方向フォワーディング検出(BFD)

    隣接ルーター間の障害を高速に検出するプロトコル。ExpressRoute で有効化すると BGP の収束を速め、フェイルオーバーを早める。

    前提: ExpressRoute

  • Blob のプロパティとメタデータ

    BLOB に付随するシステムプロパティ(Content-Type 等)と、ユーザー定義のキー/値メタデータの設定・取得。

    前提: Blob ストレージ

  • Blob の SDK 操作

    BlobServiceClient/ContainerClient/BlobClient でコンテナーや BLOB を作成・アップロード・ダウンロード・列挙する開発操作。

    前提: Blob ストレージ

  • コネクション追跡

    ステートフルなファイアウォール(例:セキュリティグループ)が確立済みの接続を状態テーブルで記憶し、その戻り通信を自動的に許可する仕組み。ステートレスなルールと違い、戻り方向のエフェメラルポートを個別に開ける必要がない。

    前提: エフェメラルポート

  • 変更フィード(Cosmos DB)

    コンテナーへの作成/更新を発生順に読み出せる永続ログ。イベント処理・マテリアライズドビュー・他ストアへの同期に使う(削除は既定で含まない)。

    前提: Azure Cosmos DB

  • 整合性レベル(Cosmos DB)

    読み取りの一貫性と性能/可用性のトレードオフを選ぶ 5 段階:強固→有界整合性制約→セッション(既定)→整合性のあるプレフィックス→最終的。

    前提: Azure Cosmos DB

  • パーティションキー(Cosmos DB)

    データを論理パーティションに分散させる列。高カーディナリティで均等分散する値を選ぶとホットパーティションを避け、RU/s を効率化できる。

    前提: Azure Cosmos DB

  • Cosmos DB の SDK 操作

    CosmosClient でデータベース/コンテナー/アイテムを作成・読み取り・クエリ・更新する開発操作。要求コストは RU で計測される。

    前提: Azure Cosmos DB

  • デプロイメントスロット

    App Service で本番とは別の環境(ステージング等)にデプロイし、暖機後にスワップで無停止リリースする仕組み。問題時は元に戻せる。

    前提: Azure App Service

  • Azure Arc 対応 SQL

    オンプレや他クラウドの SQL Server を Azure Arc で Azure に接続し、インベントリ・評価・更新・Defender/Purview 等を一元管理する仕組み。

    前提: Azure Arc

  • 動的データマスク

    実データは変えずに、クエリ結果の表示だけをマスクして機微情報を隠す。UNMASK 権限を持つユーザーには実値が見える。

  • インデックス/統計メンテナンス

    断片化したインデックスの再構成/再構築と、統計の更新を定期実行して性能を保つ運用。自動化(ジョブ)でスケジュールするのが一般的。

    前提: インデックス

  • 整合性チェック(DBCC CHECKDB)

    データベースの論理的・物理的な破損を検査するコマンド。定期実行で破損を早期検出し、バックアップと併せてデータ保全を担保する。

  • Intelligent Insights

    性能問題を自動検出し、根本原因と改善案を診断ログとして出力する Azure SQL の機能。

    前提: 診断とログ(App Service)

  • ログ配布(Log shipping)

    トランザクションログのバックアップを別サーバーへ定期的にコピー・復元して待機系を維持する、シンプルで枯れた DR 手法。

  • Managed Instance のデータベースコピー/移動

    SQL Managed Instance 間でデータベースをコピー(複製)または移動(移管)するネイティブ操作。インスタンス再編成や環境分離に使う。

    前提: SQL Managed Instance

  • 行レベルセキュリティ(RLS)

    セキュリティ述語(関数)でユーザーごとに見える行を制限する。テナント分離や担当範囲の制御に使う。

  • サーバーレスコンピューティング(Azure SQL)

    使用に応じて計算を自動スケールし、非アクティブ時に自動一時停止して秒課金を止める Azure SQL の計算層。断続的なワークロードに向く。

  • SQL 監査(サーバー/データベース)

    データベースイベントを記録し、Log Analytics・ストレージ・Event Hubs へ出力する。サーバー監査は全 DB に、データベース監査は個別に適用する。

    前提: Azure Event Hubs

  • Azure SQL Database in Fabric

    Microsoft Fabric 内に統合された Azure SQL Database。OneLake へのミラーリングや Fabric の分析体験と密接に連携する運用形態。

    前提: Azure SQL Database

  • Always Encrypted(VBS エンクレーブ)

    仮想化ベースのセキュリティ(VBS)エンクレーブを使う Always Encrypted。暗号化したままサーバー側で範囲比較やパターン一致などの演算を可能にする。

    前提: Always Encrypted

  • 待機統計

    セッションが何を待っているか(I/O・ロック・CPU 等)を示す指標。ボトルネックの種類を切り分ける出発点になる。

  • 最小権限の原則

    各アイデンティティ(人・アプリ・サービス)には、業務の遂行に必要な最小限の権限だけを与えるという設計原則。過剰な権限は誤操作や侵害時の被害範囲(ブラスト半径)を広げるため、IAM ロールやポリシー、権限境界を通じて継続的に絞り込む。

    前提: ブラストラディウス(影響範囲)

  • ローカルネットワークゲートウェイ

    S2S VPN で「オンプレ側」を表す Azure 上のオブジェクト。オンプレの公開 IP とアドレス空間(または BGP 設定)を登録する。

    前提: サイト間 VPN(S2S)

  • マイクロサービス

    アプリケーションを小さく独立したサービス群に分割するアーキテクチャスタイル。サービスごとに個別デプロイ・個別スケール・障害分離ができる一方、サービス間通信や運用の複雑さが増す。コンテナやサーバーレス基盤、API ゲートウェイと組み合わせて構築されることが多い。

  • NSG のセキュリティ規則

    NSG のインバウンド/アウトバウンド規則。優先度順に評価し、送信元/宛先(IP・ASG・サービスタグ)・ポート・プロトコルで許可/拒否する。既定規則は最後に評価される。

    前提: アクセス許可(GRANT/DENY/REVOKE・最小権限)

  • セキュリティグループ(環境)

    Microsoft Entra ID のグループを使って、その環境を利用できるユーザーを制限する仕組み。環境ごとにメンバーシップで囲い込む。

    前提: Microsoft Entra ID

  • 単一障害点(SPOF)

    そこが壊れるとシステム全体が止まる箇所。マルチ AZ 配置・冗長化・ロードバランサ・自動フェイルオーバーで排除する。可用性設計の出発点=SPOF を洗い出して潰す。

  • Defender for Containers

    コンテナワークロードの構成ミスと実行時リスク(不審なプロセス・既知の悪用など)を検知する Defender プラン。イメージの既知脆弱性スキャンと信頼イメージ許可(ACR)とは補完的に併用する。

  • Microsoft Sentinel

    クラウドネイティブな SIEM+SOAR。各所のログを収集し脅威を検知・調査・自動対応する。

  • SQL Server on VM

    IaaS で SQL Server を動かす形態。OS まで自分で管理でき完全に制御できるが運用負荷は大きい。

  • サブネット委任

    特定の PaaS サービスにサブネットの管理権限を委ねる設定。サービスが必要なネットワーク構成(NIC 注入等)を自動適用できるようにする。

    前提: サブネット