Azure導入企業の多くが「PoC（概念実証）設定」のまま本番運用へ突入し、高額請求や管理不全に悲鳴を上げている――。Microsoft MVPが明かす「10の失敗パターン」と改善策を紹介する。
多くのMicrosoft Azure（以下、Azure）環境は、PoC（概念実証）の延長で作られたまま整理されずに運用されている。その結果、「コストが高い」「遅い」「保守しにくい」状態に陥りやすい――。
ソフトウェアコンサルティング会社Lean TECHniquesは、Azure環境の監査サービスを提供している。同社のMicrosoft MVP（注）でエンジニアリングディレクターのスコット・サウバー氏は、Azure環境の監査の中で見えてきた「よくある問題」をまとめ、環境をより保守しやすくするためのポイントを講演で紹介した。
※注：MVPはMost Valuable Professionalの略。Microsoft製品や関連技術に関する高度な専門知識を持ち、その知識をコミュニティ活動などを通じて継続的に共有している個人にMicrosoftが表彰し付与する称号を指す。
同講演は、2025年9月、デンマークで開催されたソフトウェア開発者向けのカンファレンスNDC Copenhagenで共有されたものだ。
サウバー氏は、サブスクリプションが整理されておらず、リソースグループにも明確な構造がないAzure環境を見ることがあるという。1つのサブスクリプションにさまざまなWebアプリケーションがまとめてひも付いている「全部入りサブスクリプション」も見かけるという。
全部入りサブスクリプションについてサウバー氏は、「最低限、開発環境と本番環境単位でサブスクリプションを分けるべきだ」と提言する。さらに、大企業であれば「チームと環境」単位で、リソースグループは必ず「アプリケーションと環境単位で作成すべきだ」と薦めている。
具体的には、あるアプリケーションに必要なデータベース、Webサーバなどのリソースは、必ず同一のリソースグループにまとめるとよい。同氏によると、Microsoftは2025年「Service Groups」を公開した。これはタグを進化させたようなもので、「本番アプリ群」や「GDPR対象アプリ群」などを論理的にまとめることができる。
2つ目は命名規則だ。サウバー氏は、「Azureのリソースの名前付けに自信がある人は、実はあまり多くない。多くの環境では、リソース名がバラバラだ」と指摘する。
対策は極めてシンプルで、命名規則を決めることに尽きる。Microsoftは推奨される命名規則を公開しており、リソース種別の略称、アプリケーション名、環境名、インスタンス番号を組み合わせる形が基本だ。Azureには「Azure Naming Tool」という専用ツールもある。重要なのは、どのルールを選ぶかではなく、「全チームが一貫したルールを使うこと」だ。この点もAzure Policyを使えば、技術的に強制できる。
タグはリソースのメタデータであり、「本番環境の月額コストはいくらか」「このリソースの責任者は誰か」といった問いに答えるための重要な手掛かりとなる。しかし、タグが統一されていない企業は少なくないとサウバー氏は指摘する。
そこで、環境名、オーナー、事業部など、必要なタグを標準化することが重要だ。タグの内容自体は組織ごとに自由に決めてよいが、「付けるかどうか」を人に委ねてはいけない。
「命名規則やタグのルール、暗号化プロトコル「TLS」（Transport Layer Security）の要件などをドキュメントにまとめても、それが守られるかどうかは別問題だ」とサウバー氏は指摘する。そこでサウバー氏は、リソースを組織のポリシーに沿って管理するための仕組みであるAzure Policyの利用を薦める。Azure Policyを使えば、リソース作成の拒否、監査、設定の強制といった制御が可能になる。ただし、Infrastructure as Code（IaC）を採用している場合、自動修正（Modify）はコードとの差分を生む可能性があるため注意が必要だ。
サウバー氏によると、ユーザー名、パスワード、クライアントシークレット（アプリケーションがMicrosoft Entra IDにアクセスするための認証情報）を使ってリソースにアクセスしている企業が見受けられる。これは、情報漏えいや管理コストの温床になりやすい。
AzureのManaged Identity（Managed ID）を使えば、クライアントシークレットを使わない認証が可能になり、IDの管理はAzure側に委ねられる。パスワードもクライアントシークレットも不要になり、接続文字列にはURLだけが残る。結果として、認証は完全にパスワードレスになる。
一方で注意が必要なのが、DefaultAzureCredential（Azure SDKを使用してアプリケーションを開発する際に、環境に合わせて自動で認証方法を切り替えるライブラリ）の使い方だ。DefaultAzureCredentialは便利な仕組みだが、内部で複数の認証方式を順番に試すため、状況によっては接続に数秒かかることがある。本番環境では、明示的に認証方式を指定する設計が望ましい。
Azureの各種サービスは、セキュリティ強化のためTLS 1.2以上を使用することを要件としている。可能であればTLS 1.3の採用も検討すべきだとサウバー氏は指摘する。
CI/CD（継続的インテグレーション/継続的デリバリー）では、クライアントシークレットに依存しないフェデレーションIDの活用が推奨される。有効期限を数分〜1時間程度と短く設定された短命トークンによる認証が可能となり、GitHub Actionsなどと組み合わせることで、より安全なデプロイパイプラインを構築できる。
サウバー氏によると、Azureにはデフォルトで「使い過ぎを止める仕組み」は存在しない。そのため「Azure Budgets」や「Cost Alerts」などの機能を使い、閾値アラートや異常検知を設定することが重要だ。ただし、あくまで「監視」を目的としており、リソースを自動停止するものではない点には注意したい。
長期間稼働が前提のリソースをオンデマンド課金で使い続けるのは、意図せず高いコストを払い続ける行為に等しい。サウバー氏は、「本来削減できる20〜70％のコストを取り逃している」と指摘する。年単位のリソースの利用を約束することで利用料金の割引を受けるAzure ReservationsやAzureの節約プランを利用できるAzure Savings Plan for Computeを活用すれば、20〜70％程度のコスト削減が見込めるという。サウバー氏は、「特にAzure Savings Plan for Computeは柔軟性が高く、多くの組織で検討に値する」と強調する。
これら10の失敗は、Azureの機能不足が原因ではない。多くは、初期設計の曖昧さと、標準を強制する仕組みの欠如から生まれている。1つでも思い当たる点があれば、そこが改善の出発点になる。Azure環境は、放置すれば自然に複雑化する。だからこそ、意識的に「失敗を避ける設計」を取り入れることが、長期的な安定運用への近道となる。
Copyright © ITmedia, Inc. All Rights Reserved.
なぜクラウド全盛の今「メインフレーム」が再び脚光を浴びるのか
メインフレームを支える人材の高齢化が進み、企業の基幹IT運用に大きなリスクが迫っている。一方で、メインフレームは再評価の時を迎えている。
「サイト内検索」＆「ライブチャット」売れ筋TOP5（2025年5月）
今週は、サイト内検索ツールとライブチャットの国内売れ筋TOP5をそれぞれ紹介します。
「ECプラットフォーム」売れ筋TOP10（2025年5月）
今週は、ECプラットフォーム製品（ECサイト構築ツール）の国内売れ筋TOP10を紹介します。
「パーソナライゼーション」＆「A／Bテスト」ツール売れ筋TOP5（2025年5月）
今週は、パーソナライゼーション製品と「A／Bテスト」ツールの国内売れ筋各TOP5を紹介し...
ITmediaはアイティメディア株式会社の登録商標です。
