Azure App Service で本番 Web アプリを運用していると、「平日はそこまで負荷が高くないが、週末だけアクセスが急増する」「バッチ処理の日だけ上位プランにしたい」といったニーズがよくあります。こうした “短時間だけリソースを増強したい” ケースでは、Azure Logic Apps とマネージド ID を組み合わせることで、App Service Plan のスケールアップ／スケールダウンを完全自動化し、無駄なコストを抑えつつ安定したパフォーマンスを両立できます。本記事では、週末だけ SKU を自動変更する具体的な構成手順と、運用上のポイントを詳しく解説します。
Azure App Service のスケール課題と Logic Apps での解決イメージ
まず、解決したいシナリオと、それに対して Logic Apps をどう使うのかを整理します。
| 項目 | 内容 |
|---|---|
| やりたいこと | 土曜など負荷が高い時間帯だけ App Service Plan を上位 SKU（例: Premium）にスケールアップし、それ以外の時間帯は Standard や Basic など低価格プランにスケールダウンしてコスト削減したい。 |
| 前提 | 既に Azure App Service / App Service Plan が稼働している。サブスクリプション、リソースグループ、App Service Plan 名を把握している。 |
| 課題 | Logic Apps から Azure Resource Manager (ARM) の REST API を呼び出し、いつ・どのように SKU を変更すればよいか分からない。特にマネージド ID の権限設定と HTTP アクションの認証設定が不明。 |
| 解決アプローチ | Logic Apps の Recurrence トリガーで「土曜朝にスケールアップ」「日曜夜にスケールダウン」のスケジュールを組み、HTTP アクション＋マネージド ID で App Service Plan リソースの SKU を PATCH する。 |
この構成により、運用担当者が毎週ポータルで手動変更したり、スクリプトを実行したりする必要がなくなり、「一度作るだけであとはお任せ」の仕組みを実現できます。
なぜ Logic Apps を使うのか？ 他サービスとの比較
Azure には自動化手段がいくつもあり、どれを選ぶべきか悩みがちです。代表的な選択肢と Logic Apps の位置づけを整理します。
| 選択肢 | 特徴 | メリット | デメリット |
|---|---|---|---|
| 手動で変更 | ポータルから毎週 SKU を変更 | 初期構成不要 | 人が作業するためミスが発生しやすく、担当者不在時に対応できない |
| Azure Automation Runbook | PowerShell / Python スクリプトで ARM を操作 | 柔軟性が高く、複雑なロジックも実装可能 | スクリプト管理・更新が必要で、インフラ担当者以外にはハードルが高い |
| Azure Functions (Timer トリガー) | コード（C#, JavaScript など）で自動化 | アプリ開発者にとっては馴染みやすく CI/CD に組み込みやすい | コードの品質・テスト・デプロイの運用が必要 |
| 自動スケール (Autoscale) | CPU やメトリックに応じてインスタンス数を増減 | リアルタイム負荷に応じた水平スケールが可能 | SKU（縦スケール）の変更は対象外。週末など「時間帯」での制御にはやや不向き |
| Logic Apps（本記事） | GUI でフローを定義し、ARM REST API を呼び出して SKU を変更 | ノーコード／ローコードで構成しやすく、スケジュールと HTTP 呼び出しだけで完結。マネージド ID でセキュア。 | コードのような細かな制御はやや苦手だが、スケジュールベースの単純なタスクには最適 |
「特定の曜日・時間だけ App Service Plan の SKU を切り替えたい」というシンプルで時間帯ベースの要件には、Logic Apps がもっとも手軽かつ運用しやすい選択肢になります。
全体アーキテクチャと処理の流れ
今回構成するシステムの流れは、非常にシンプルです。
- Logic Apps（消費プラン）で 2 つのワークフローを作成
- 週末のスケールアップ用（例:
ScaleUp-Saturday） - 平日のスケールダウン用（例:
ScaleDown-Sunday）
- 週末のスケールアップ用（例:
- それぞれのワークフロー冒頭に Recurrence（スケジュール）トリガーを配置
- トリガーのあとに HTTP アクションを置き、ARM REST API を
PATCHで呼び出して App Service Plan の SKU を変更 - HTTP アクションの認証には Logic App のシステム割り当てマネージド ID を使用
| コンポーネント | 役割 |
|---|---|
| Logic App（消費プラン） | スケジューラ兼オーケストレーター。指定した時刻に ARM REST API を呼び出す。 |
| Recurrence トリガー | 週単位・日単位・時間単位などでワークフローを定期実行する。 |
| HTTP アクション | Azure Resource Manager の管理 API を呼び出し、App Service Plan の SKU や capacity を変更する。 |
| マネージド ID | Logic App が ARM API を呼び出すための認証情報。秘密情報を持たずに Azure AD からトークンを取得する。 |
| App Service Plan | スケール対象のリソース。SKU（Standard, Premium など）やインスタンス数を変更することで、Web App の性能・料金を変化させる。 |
事前に確認しておくべき情報
Logic Apps から App Service Plan を変更するには、以下の情報を事前に把握しておく必要があります。
- サブスクリプション ID
- リソースグループ名（App Service Plan が所属しているもの）
- App Service Plan 名（例:
myappserviceplan-prod） - 現在の SKU（例: Standard S1）と、変更先の SKU（例: PremiumV2 P1V2）
これらは Azure ポータルの App Service Plan 画面から確認しておきましょう。後ほど HTTP アクションの URI や Body で利用します。
Logic App（消費プラン）の作成
次に、スケジュール処理を行う Logic App を作成します。スケールアップ用とスケールダウン用で 2 つ作るパターンと、1つの Logic App 内に 2 つのワークフローを作るパターンがありますが、ここでは理解しやすいように 2 つに分ける例を紹介します。
推奨構成（消費プラン）
| 設定項目 | 値の例 | ポイント |
|---|---|---|
| リソースの種類 | Logic App（Consumption） | トリガー実行回数ベースの課金で、週 2 回程度ならほぼ無視できるコストで運用可能。 |
| 名前 | ScaleUp-Saturday, ScaleDown-Sunday など | 役割が分かる名前にしておくと、運用時に識別しやすい。 |
| リージョン | App Service と同一または近いリージョン | レイテンシやリソース管理の観点から、同一リージョンを推奨。 |
Logic App を作成したら、デザイナーを開き、空のワークフローから構成を始めます。
スケジュール設定：Recurrence トリガーの構成
まずは「いつ」スケール操作を行うかを決める Recurrence トリガーを設定します。
スケールアップ用ワークフロー（例: 土曜 08:00）
- トリガーに Recurrence を追加
- Frequency: Week
- Interval: 1
- On these days: Saturday
- At these hours: 08
- Time zone: 運用に合わせたタイムゾーン（例: Japan Standard Time）
スケールダウン用ワークフロー（例: 日曜 22:00）
- 同様に Recurrence トリガーを追加
- Frequency: Week
- Interval: 1
- On these days: Sunday（もしくは平日の複数曜日）
- At these hours: 22
- Time zone: 同じく Japan Standard Time など
特定の曜日や時間を柔軟に選択できるため、「金曜の夜にスケールアップして月曜の朝にスケールダウン」といった構成も簡単に実現できます。
HTTP アクションで App Service Plan をスケール変更する
次に、実際に App Service Plan の SKU を変更する HTTP アクションを設定します。ここが本記事の中核部分です。
App Service Plan 変更用 REST API のエンドポイント
App Service Plan は、ARM 上では Microsoft.Web/serverfarms リソースとして管理されています。URI の例は以下の通りです。
https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/serverfarms/{planName}?api-version=2022-03-01
| パラメーター | 意味 |
|---|---|
{subscriptionId} | 対象サブスクリプションの ID |
{resourceGroupName} | App Service Plan が存在するリソースグループ名 |
{planName} | 対象 App Service Plan 名 |
api-version | 使用する ARM API のバージョン。最新情報は公式ドキュメントで確認することを推奨。 |
Logic Apps の HTTP アクション設定例
- Method: PATCH
- URI: 上記のエンドポイント
- Headers:
Content-Type:application/json
- Body: 変更後 SKU や capacity を指定する JSON
スケールアップ（例: Standard S1 → PremiumV2 P1V2）
{
"sku": {
"name": "P1V2",
"tier": "PremiumV2",
"size": "P1V2",
"family": "Pv2",
"capacity": 1
}
}
スケールダウン（例: PremiumV2 P1V2 → Standard S1）
{
"sku": {
"name": "S1",
"tier": "Standard",
"size": "S1",
"family": "S",
"capacity": 1
}
}
| プロパティ | 例 | 説明 |
|---|---|---|
name | P1V2 / S1 | SKU 名。ポータルの価格レベル表示と対応。 |
tier | PremiumV2 / Standard | 料金レベル。Standard, Premium, PremiumV2 など。 |
size | P1V2 / S1 | サイズ。一般的には name と同じ値を指定。 |
family | Pv2 / S | SKU のファミリー。たとえば PremiumV2 系なら Pv2。 |
capacity | 1 | インスタンス台数（水平スケール）。本記事の例では 1 のままにして縦スケール（SKU 変更）のみ行う。 |
capacity を増やせばインスタンス台数を増やす「水平スケール」も同時に行えますが、今回は「週末だけ SKU を変える」というシンプルなケースに絞っています。
マネージド ID を使った認証設定
HTTP アクションから ARM API を呼び出すには、適切な認証が必要です。ここではパスワードやクライアントシークレットを扱わずに済む「システム割り当てマネージド ID」を利用します。
Logic App でマネージド ID を有効化する
- Logic App のブレードを開く
- [Identity] を選択
- システム割り当て (System assigned) を オン にして保存
- 表示される オブジェクト ID を控えておく（後でロール割り当てで使用）
リソースグループへのロール割り当て
- 対象のリソースグループ（App Service Plan が含まれる）のブレードを開く
- [アクセス制御 (IAM)] を選択
- [ロールの割り当ての追加] から Contributor ロールを選択
- メンバーの選択画面で、先ほど有効化した Logic App のマネージド ID を検索して選択
- 保存してロール割り当てを完了
| ロール | 用途 | 注意点 |
|---|---|---|
| Contributor | App Service Plan の SKU 変更やリソース更新に必要な権限を包括的に付与。 | 最小権限の原則に従い、可能であれば専用のカスタムロールで権限範囲を絞ることも検討。 |
HTTP アクション側の認証設定
Logic Apps デザイナーで HTTP アクションを開き、認証設定を以下のように構成します。
- Authentication: Managed Identity を選択
- Managed identity: System-assigned managed identity
- Audience:
https://management.azure.com
これにより、Logic App のマネージド ID が Azure AD から ARM 用のアクセストークンを取得し、そのトークンを付与して HTTP アクションを実行します。認証情報（シークレット等）を保持する必要がないため、セキュアで運用もシンプルです。
週末だけスケールアップ／スケールダウンする具体例
ここまでの内容を踏まえて、「土曜 08:00 に PremiumV2 P1V2 へスケールアップ」「日曜 22:00 に Standard S1 へスケールダウン」という具体例を整理します。
| ワークフロー | トリガー設定 | HTTP Body（sku） |
|---|---|---|
| ScaleUp-Saturday | Frequency: Week On: Saturday At: 08:00（JST など） | { "sku": { "name": "P1V2", "tier": "PremiumV2", "size": "P1V2", "family": "Pv2", "capacity": 1 } } |
| ScaleDown-Sunday | Frequency: Week On: Sunday At: 22:00 | { "sku": { "name": "S1", "tier": "Standard", "size": "S1", "family": "S", "capacity": 1 } } |
動作確認としては、いきなり本番時間を待たずに、トリガーを「数分おき」に一時的に変更し、実行ボタンから手動実行して App Service Plan の SKU が変わるかを確認する方法が安全です。十分に検証したあとで、本番のスケジュールに戻しましょう。
パラメータ化して複数環境で使い回す
開発・検証・本番といった複数環境を運用している場合、ワークフローをコピーして環境ごとに URI や SKU を書き換えるのは手間がかかります。Logic Apps では、これらの値をパラメータ化して再利用性を高めることができます。
- HTTP アクションの URI に埋め込む
subscriptionId,resourceGroupName,planNameをパラメータにする - スケールアップ／スケールダウンで使用する
skuの JSON をパラメータで持たせる - 環境ごとに異なる値をパラメータとして渡すことで、ワークフローのロジックは共通化
Infrastructure as Code（Bicep や ARM テンプレートなど）と組み合わせれば、「App Service Plan とそのスケール自動化 Logic App をセットでデプロイする」といった高度な運用も可能になります。
運用・監視・トラブルシューティングのポイント
実行履歴での確認
Logic Apps には [実行履歴] があり、各トリガー実行ごとに HTTP アクションの結果（ステータスコード、レスポンスボディ）を確認できます。スケール変更が期待通りに動いているか、定期的にチェックしておくと安心です。
App Service 側での確認
- App Service Plan のブレードで SKU が想定どおりに変更されているか
- Web App の再起動が必要になる点（SKU 変更時にアプリ再起動が発生する）を考慮し、ピーク時間外にスケール操作を行う
- アプリケーションの起動に時間がかかる場合は、余裕を持った時刻にスケールアップしておく
よくあるエラーと対処
| HTTP ステータス | 典型的な原因 | 対処方法 |
|---|---|---|
| 401 / 403 | マネージド ID に適切な権限がない、Audience の指定ミスなど | リソースグループまたは App Service Plan に Contributor ロールが割り当てられているか確認。HTTP アクションの認証設定で Audience が https://management.azure.com になっているか確認。 |
| 404 | URI の subscriptionId, resourceGroupName, planName が誤っている | ポータルから正しい ID / 名前をコピーし直す。スペルミスや大文字小文字に注意。 |
| 409 | 別の操作中で App Service Plan がロックされている、または不正な SKU への変更 | 少し時間を置いて再実行する。変更先 SKU がリージョンや現在のプランでサポートされているか確認。 |
| 429 | 短時間に大量のリクエスト | 基本的に週 1, 2 回の実行であれば問題になりにくいが、テスト時に過度な頻度で実行しないようにする。 |
水平スケール（インスタンス数変更）との組み合わせ
本記事では SKU 変更による「縦スケール」にフォーカスしましたが、同じ JSON の capacity を変更することで、インスタンス数（水平スケール）を増減させることもできます。
- 週末は
capacity: 3にして 3 インスタンスで運用 - 平日は
capacity: 1に戻してコスト削減
ただし、App Service の自動スケール（Autoscale）を併用する場合は、Logic Apps で capacity を固定値にしてしまうと自動スケールの挙動とぶつかることがあります。以下のような分担がおすすめです。
| 制御対象 | 担当 | 役割 |
|---|---|---|
| SKU（プランのグレード） | Logic Apps | 曜日や時間帯ベースで Standard/Premium などを切り替える。 |
| インスタンス数（capacity） | 自動スケール | CPU やリクエスト数に応じてダイナミックに増減させる。 |
このように役割を分けることで、「週末だけ Premium プランにして、その中でさらに Autoscale でインスタンス数を調整する」といった高度なスケーリング戦略も実現できます。
Function App から呼び出す場合との違い
既に Azure Functions ベースのサーバーレス基盤を持っている場合、「Logic Apps ではなく Function App から HTTP クライアントで ARM API を叩く」という構成も可能です。実は、その際に使う JSON やマネージド ID の考え方は Logic Apps とほぼ共通です。
- Function のタイマートリガーでスケジュール実行
- App Service Plan 変更用の REST API を呼び出すコードを実装
- Function のマネージド ID に Contributor ロールを付与
ただし、コードのビルド・デプロイ・バージョン管理などの運用が必要になるため、「とりあえず素早く自動化したい」「インフラ担当者が GUI ベースで管理したい」といったケースには Logic Apps の方が適しています。環境やチーム体制に応じて使い分けると良いでしょう。
セキュリティ・ガバナンス上の注意点
- マネージド ID の権限は必要最低限に
- 最初はシンプルに Contributor で構成し、運用が安定してきたらカスタムロールで権限を絞るのも一案です。
- 誰がいつスケール変更したかをトレースできるようにする
- Logic Apps の実行履歴に加え、Activity Log でリソース変更履歴を確認できるようにしておくと監査にも役立ちます。
- スケールスケジュールの変更ルールを決めておく
- 業務側から「今週だけスケジュールを変えたい」といった要望が来ることが多いため、変更フローや連絡手順をあらかじめ決めておきましょう。
まとめ：Logic Apps で週末だけ上位プランに、自動で戻す
本記事では、Azure Logic Apps とマネージド ID を用いて、App Service Plan のスケールアップ／スケールダウンを自動化する方法を解説しました。ポイントをあらためて整理すると、次の通りです。
- Logic Apps（消費プラン）と Recurrence トリガーを使うことで、週末や特定の時間帯だけ SKU を自動で切り替えられる
- HTTP アクションで ARM の REST API（
Microsoft.Web/serverfarms）をPATCHし、skuJSON を指定して縦スケールを実行する - マネージド ID にリソースグループの Contributor 権限を付与し、HTTP アクションの認証に Managed Identity（Audience:
https://management.azure.com）を使うことで、シークレットレス・セキュアな構成を実現できる - スケール操作はアプリ再起動を伴うため、ピーク時間を避けたスケジュール設定が重要
- capacity を変更すれば水平スケールも可能だが、Autoscale と組み合わせる場合は役割分担を意識する
週末や特定イベント時だけ上位へスケールアップし、それ以外は低コストプランに自動で戻せば、パフォーマンスとコストのバランスを最適化できます。まだ手動で App Service Plan を切り替えている場合は、ぜひ Logic Apps を使ったスケール自動化を検討してみてください。一度構成してしまえば、あとは Azure が毎週決まった時間に「勝手にやってくれる」状態になり、運用負荷の大幅な削減にもつながります。
コメント