本記事は 2024 年 2 月 16 日に公開された” Enhance your AWS cloud infrastructure security with AWS Managed Services (AMS) “を翻訳したものです。 はじめに セキュリティやデータ損失インシデントは、金銭的損失と社会的信用の失墜につながる可能性があります。セキュリティとコンプライアンスは、AWS とお客様の間における責任共有により維持されます。この責任共有では、AWS は「クラウドのセキュリティ」に責任を持ち、お客様は「クラウドにおけるセキュリティ」に責任を持ちます。しかし、クラウドにおけるセキュリティは、特にクラウドインフラおよびオペレーティングシステム(OS)レベルにおいて、より広い範囲に及びます。クラウドにおいて、セキュアでコンプライアンスに準拠した監視環境を大規模に構築するには、高度な自動化、人的リソース、およびスキルが必要です。 このブログでは、「クラウドにおけるセキュリティ」を向上させるために AWS サービスを組み合わせて活用する方法を紹介します。多くの組織にとって、スキル不足やビジネスにおける優先順位により、セキュリティのベストプラクティスを大規模に順守し、導入することは容易ではありません。 AWS Managed Services （AMS）が大規模にお客様の AWS インフラのセキュリティおよびコンプライアンス体制を強化してきたベストプラクティスをご紹介します。AMS は、モニタリング、インシデント管理、セキュリティ、パッチ適用、バックアップ、コスト最適化にわたって AWS クラウドでの運用上の優秀性を達成するための能動的・予防的・検出的な機能を提供します。これにより、お客様はイノベーションに集中できます。 例えば、Coinhako が AMS を運用パートナーとして AWS に移行した際、CTO の Gerry Eng 氏は次のように述べています。「AMS に標準搭載されている数多くのセキュリティ機能は、我々が独自に適切に展開するには数ヶ月、場合によっては数年かかっていたでしょう。」詳細は ケーススタディ をご覧ください。 AWS におけるクラウドセキュリティ管理 予防（Prevention） 「予防は治療に勝る」と言われています。セキュリティ体制を改善し、問題を予防するための領域には、アイデンティティとアクセス管理（ IAM ）、受信 （Ingress）と送信 （Egress）トラフィックの保護、バックアップおよび災害復旧、そして脆弱性への対処があります。 AWS は AWS IAM とサービスコントロールポリシー（ SCPs ）を組み合わせてクラウドリソースへのきめ細かいアクセス制御を提供しています。AWS は IAM サービスのセキュリティベストプラクティス を公開しています。しかし、お客様がその最適な利用状況を長期にわたって監視・統制することは容易ではなく、結果として不正なアクセスや不要なアクセスを招いてしまうことが少なくありません。AMS を活用することで、IAM の変更が AWS のベストプラクティスや AMS の技術基準に適合しているかを継続的に検証することが可能です。また、AMS はカスタム AWS Config ルールを使用して IAM のガバナンスコントロールのベストプラクティスを実装し、異常または逸脱を積極的に検出・修正します。 受信 （Ingress）と送信 （Egress）トラフィックの観点から、エッジネットワークで AWS WAF （Web アプリケーションファイアウォールサービス）を使用して、Web アプリケーションリソースへ届く HTTP/HTTPS リクエストを検査することができます。AWS WAF は Amazon CloudFront 、 Application Load Balancer （ALB）、 Amazon API Gateway などほとんどの AWS 外部向けサービスとネイティブに統合されています。ネットワーク層では、 AWS Network Firewall を使用してファイアウォールルールを定義し、すべての受信 （Ingress）と送信 （Egress）ネットワークトラフィックをきめ細かく制御できます。Network Firewall は AWS Firewall Manager と連携して、複数の VPC およびアカウントにわたってポリシーを一元的に適用します。AMS は AWS ベストプラクティスを使用して、これらのサービスを継続的にセットアップおよび運用するサポートを提供します。 さらに、定期的なパッチ適用は脆弱性に対する最も効果的な予防策の一つです。 Ponemon Institute の調査によると、「侵害被害者の 60% は、パッチが未適用の既知の脆弱性を悪用されて侵害された」と述べています。OS レベルでは、最新の脆弱性から保護するための完全なパッチ管理のために AWS Systems Manager の Patch Manager サービスを活用できます。継続的な脆弱性管理には、 Amazon Inspector サービスで、OS の脆弱性のスキャン・特定ができます。しかし、パッチスケジュールの設定、パッチコンプライアンスのレポート、および大規模なパッチ失敗への対応は、困難ではあるもののビジネス上の差別化に繋がらないタスクとみなされることがあります。AMS は自動化とベストプラクティスを駆使し、大規模環境においても、これら一連の作業をお客様に代わって実行します。AMS は Inspector またはお客様のツールによって報告された高リスクまたはゼロデイ脆弱性に対処するための臨時パッチ適用も実行できます。また、AMS を活用して Security Technical Implementation Guide （ STIG ）ベンチマークに準拠したセキュリティが強化された OS の Amazon Machine Images（AMI）を構築し、安全な EC2 インスタンスをデフォルトで保護することもできます。 最後に、インシデント時のデータ損失に対して、堅牢なバックアップおよび災害復旧戦略が不可欠です。 AWS Backup と AWS Elastic Disaster Recovery を組み合わせて AWS クラウドのデータを保護できます。大規模な環境において、バックアップ計画の設定とバックアップコンプライアンスの継続的な監視は複雑になることがあります。AMS は継続的なバックアップの監視・管理を支援するだけでなく、ランサムウェア保護プランを含むデータ復旧のビジネスユースケースに対応した複数のバックアップ計画を提供します。定期的なバックアップのテスト・復元は、予期せぬ問題発生時のビジネスサービスのダウンタイムを最小化するための重要な実践です。AMS はインシデント時の平均復旧時間（MTTR）を短縮するためのサービス復旧に関する SLA を提供します。AMS はお客様のチームとともに、侵害インスタンスやランサムウェアイベントなどのシナリオをシミュレートするセキュリティおよび運用重視のゲームデー（模擬訓練）を実施します。 検出（Detection） クラウド環境を継続的に監視して異常や潜在的な悪意ある活動を積極的に検出・封じ込め・修正することは非常に重要です。AWS は、ログやイベントの処理、およびモニタリングを通じて、監査、自動分析、アラーム通知を可能にするさまざまな検知統制を実装するためのサービスを提供しています。例えば、 Amazon GuardDuty は機械学習（ML）ベースの脅威検出サービスで、アクセス関連アクティビティと不正な動作を継続的に監視して AWS アカウントのワークロードを保護します。GuardDuty は Amazon Macie と組み合わせることができます。Macie はデータセキュリティサービスで、ML とパターンマッチングを使用して AWS アカウント内の機密データの検出・保護を行います。 AWS Security Hub CSPM はクラウドセキュリティ体制管理（CSPM）サービスで、セキュリティのベストプラクティスチェックを実行し、AWS およびサードパーティサービスからのアラートを集約し、修復手順を提案します。しかし、多数の AWS アカウントにわたってこれらのアラートを処理し、修復を実施することは、運用上すぐに困難な状況になることがあります。 AMS は Amazon GuardDuty を活用して、お客様が契約しているすべての AWS アカウントの脅威を監視し、そこから生成されるすべてのアラートを 24 時間 365 日体制でレビューします。AMS は GuardDuty アラートを分析する自動化技術を駆使し、誤検知を減らして、初期トリアージ（優先度判定）を行い、インシデント通知の一環として実用的な対応策を提供します。重大な問題については、AMS は積極的にお客様と連携して共同セキュリティ調査を実施し、修復に必要な承認を取得します。AMS は Amazon Macie の検出結果を監視し、お客様に代わって必要な修復を実施することもできます。 モニタリングとインシデント対応（Monitoring and Incident Response） Amazon CloudWatch はオブザーバビリティのための AWS ネイティブの基盤サービスで、インフラ、アプリケーション、およびエンドユーザーモニタリングにわたる機能を提供します。Systems Manager の OpsCenter により、オペレーションスタッフは CloudWatch や AWS Config などのサービスによって特定された運用上の問題を表示・調査・修復できます。Systems Manager の Incident Manager 機能は、自動化された対応計画を使用して重要なアプリケーション問題をより迅速に解決するのに役立ちます。OpsCenter と Incident Manager は、Atlassian Jira や ServiceNow などの ITSM およびチケットシステムと統合して、お好みのツールでインシデントの包括的なビューを提供します。Incident Manager は Amazon Q Developer in chat applications とも連携しており、Slack、Microsoft Teams のようなコラボレーションツールを使用して、インシデントの調査や修復対応を行うことができます。(※1) AMS は、世界各地の複数のサイトに配置されたエンジニアによる 24 時間 365 日のセキュリティ監視とインシデント対応を通じて、クラウドでの運用上の優秀性の達成を支援します。アラートとイベントは AWS Config、Amazon GuardDuty、Amazon Macie、Amazon CloudWatch、 AWS CloudTrail などのネイティブサービスから監視されます。セキュリティインシデント対応（ SIR ）については、AMS は事前定義された National Institute of Standards and Technology （NIST）準拠のランブック（対応手順書）に従い、セキュリティアラートに対して、特定・分析・封じ込め・根絶・復旧の対応を行います。AMS は Systems Manager の OpsCenter を使用してすべての運用項目をログに記録し、AWS サポートケースを通じて通知し、お客様のチームと連携して解決します。Security Incident and Event Management （SIEM）や Endpoint Detection and Response （EDR）などサードパーティまたは自社開発のセキュリティツールを使用している場合、AMS はそれらによって報告された OS および AWS インフラ関連の検出結果を修復する支援も行うことができます。また、 AWS Service Management Connector を ServiceNow や Atlassian Jira などの ITSM ツールと統合して、AMS とのシームレスなインシデント・チケット対応を実現することもできます。(※2) コンプライアンス（Compliance） AWS の責任共有モデルの下、お客様はゲスト OS、アプリケーションソフトウェア、および AWS アカウント内の AWS サービスの設定と選択に関して、セキュリティとコンプライアンスの責任を負います。さらに、ビジネスニーズに応じて幅広いローカル・グローバルのコンプライアンスフレームワークに準拠する必要があり、それらのフレームワークを AWS セキュリティコントロールにマッピングすることは困難な場合があります。 AMS を使用することで、AWS における全体的なセキュリティ体制を強化するだけでなく、必要なコンプライアンスレベルへの到達を加速できます。まず、AMS というサービス自体が、 HIPAA 、 SOC 、 ISO27001 、 FedRAMP 、 IRAP 、 NIST 、 PCI-DSS 、 GDPR など、多くのグローバルなコンプライアンスフレームワーク、規制、セキュリティ基準に適合し、準拠しています（詳細は AWS コンプライアンスセンター を参照）。そのため、AMS によって管理されるクラウド環境は、特定のコンプライアンス要件や規制要件が求められるアプリケーションをホストするのに適しています。 次に、AMS では利用開始初日から、AWS Config を活用することで、CIS、NIST、PCI、HIPAA という、極めて厳格かつ多岐にわたる 4 つのグローバル・セキュリティ・フレームワークに対するお客様のセキュリティ体制を完全に可視化できます。AMS は、厳選された AWS Config Rules をデプロイし、お客様のアカウント内のリソース状態を継続的に監視することで、これらのコンプライアンス基準やフレームワークの要件への準拠を維持します。これらのルールは、ビジネスのニーズに応じて、自動修復を行うか、インシデントやレポートとして通知を行うかのいずれかに設定することが可能です。例えば、AMS では、AMS アカウント内で AWS CloudTrail によるログ記録がデフォルトで有効化されており、これが必要なときにいつでも行えるレポート作成、アラート通知、および監査に利用されます。この設定だけでも、セキュリティ基準である NIST SP 800-53 の監査と責任（AU）コントロールファミリーにおける AU-06/07（a-c, 1-4） や、ISO 27001 のコントロール A.12.4.1-3 といった複数の管理策を満たす上で有効です。 さらに、AMS はコンプライアンス要件を強化するために、OS レベルと AWS アカウントレベルの両方において、中央集権型のログ記録および監査コントロールを実装しています。AWS アカウント内で行われたユーザーアクセスや変更に関する監査レポートは、 Amazon Athena コンソール経由で、AMS が事前構築した厳選されたクエリを使用して簡単に抽出することができます。 レポートとガバナンス（Reporting & Governance） AWS クラウド環境全体におけるセキュリティ体制や潜在的なリスクを測定・追跡するためには、強固なレポート機能とガバナンスの実践が不可欠です。Key-Value のペアを使ってメタデータを作成する AWS Resource Tagging は、監査、自動化、およびコスト配分を通じて、運用上の優秀性を達成するために極めて重要な役割を果たします。例えば、AWS のメタデータやタグの値は任意の AWS ストレージサービスにエクスポートすることができます。これにより、 AWS Glue 、 Amazon Athena 、 Amazon Quick Sight といったサービスを活用して、パッチ適用状況やセキュリティコンプライアンスのカバー率に関するレポート、あるいはその他のダッシュボードを構築できます。 AMS は、OS のパッチ適用レベル、バックアップのカバー率、および高緊急度のインシデントに関するレポートを、毎週・毎月セルフサービスで提供します。また、お客様専任の AMS Cloud Service Delivery Manager（CSDM）と Cloud Architect（CA）が信頼できるアドバイザーとして、月次ビジネスレビューを主導します。このレビューでは、管理されているすべての AWS アカウントを横断した中央集中型の追加レポートが提供されます。月次ビジネスレビューには、 AWS Well Architected Framework の各柱にわたる主要なクラウド運用リスクへの洞察と高緊急度のアラートに対処するための将来的な計画が含まれています。 AMS のタグまたはお客様独自のカスタムタグを強制適用するために、AMS 管理下にある AWS リソースでは、AMS が提供する Resource Tagger ツールを活用できます。監査やレポート作成に加えて、AMS 固有のタグを使用することで、アクセス制御、監視、パッチ適用、バックアップ、および自動修復にわたる自動化アクションが可能になります。この AMS Resource Tagger とお客様のカスタムタグを組み合わせることで、クラウドガバナンスのための強固なタグ付け戦略を構築できます。 セキュリティオンデマンド（Security On-Demand） AMS は、 Operations on Demand （OOD）サービスを通じて、必要なときに拡張セキュリティサポートを提供しています。AMS OOD を活用することで、AWS サービスに関する変更を行い、AWS クラウドにおけるセキュリティ体制をさらに向上させることができます。このサービスには、既知の、あるいは未対策のセキュリティ脅威から保護するためのセキュリティ関連サービスカタログが含まれており、AWS Network Firewall の運用や、サポート終了が迫っているレガシー OS のアップグレードなどに対応しています。 おわりに 本記事では、AWS クラウドにおけるセキュリティ体制を強化するために実装できる、予防・検出・対応の管理を含む、多くの不可欠なセキュリティベストプラクティスを検討しました。また、お客様の AWS クラウド環境を管理することで、求められる「クラウドにおけるセキュリティ」を実装する信頼できるパートナーとして、どのように AMS を活用できるかを説明しました。AMS は、AWS のベストプラクティスを用いた複数のガードレールの実装に加え、24 時間 365 日のセキュリティインシデント対応および復旧を行うことで、クラウドのセキュリティ体制を強化します。さらに、AMS は初日からお客様の AWS アカウントにログ記録、監査、監視に関する多くの必要なセキュリティ統制とベストプラクティスの導入を支援し、コンプライアンスへの取り組みを加速させます。 セキュリティ特有の機能にとどまらず、AMS はインフラや OS の能動的な監視、アラートの自動復旧、コスト最適化、そして継続的なガバナンスの組み合わせにより、大規模なお客様の AWS クラウド環境における運用上の優秀性の達成を支援します。詳細については、 AWS Managed Services の製品ページをご覧ください。 ※1 2025 年 11 月 7 日に AWS Systems Manager Incident Manager は新規のお客様への提供を終了しました。AWS は引き続き Incident Manager のセキュリティと可用性への投資を継続し、既存の Incident Manager のお客様は、すでに Incident Manager が有効化されているアカウントにおいて、これまで通りサービスを引き続きご利用いただけます。 ※2 2026 年 3 月 31 日に AWS Service Management Connector は新規のお客様への提供を終了しました。既存のお客様は、2027 年 3 月 31 日までサービスを引き続きご利用いただけます。2027 年 3 月 31 日以降、AWS Service Management Connector の機能にアクセスすることはできなくなります。AWS パートナーソリューションへの移行、または直接的な SDK 統合の構築をお勧めいたします。 翻訳はシニアオペレーションズマネージャーの木村が担当しました。 原文はこちら です。 Nitin Verma Nitin は、クラウドオペレーション、自動化、セキュリティにおいて 10 年以上の専門知識を持つプリンシパルソリューションアーキテクトです。お客様が運用上の優秀性を達成し、AWS 上でのクラウドジャーニーを加速できるよう支援することを専門としています。Nitin の重点分野には、クラウドアーキテクチャ、IaC（Infrastructure as Code）、DevSecOps、AIOps などの新興テクノロジーが含まれます。 LinkedIn でフォローできます。 Amit Gupta Amit は、インフラストラクチャセキュリティオペレーションおよび AWS Managed Services（AMS）を専門とするシニアセキュリティエンジニアです。サイバーセキュリティにおいて 10 年以上の経験を持っています。セキュリティインシデント対応やセキュリティリスク管理のバックグラウンドを有しています。適切な戦略と設計により、お客様のサイバーセキュリティリスクを最小限に抑えることを支援することに注力しています。 TAGS: AWS Managed Services (AMS) , Cloud Operations , Management and Governance , Security

本稿は、株式会社両備システムズ ガバメントクラウド推進室 岩倉 竜太 氏による寄稿です。 ※本記事でご紹介する効果は、両備システムズの環境における実績であり、すべてのお客様で同等の効果を保証するものではありません。 はじめに みなさん、こんにちは。株式会社両備システムズでガバメントクラウドの構築・運用を担当している岩倉と申します。私たちは、岡山県を基盤に全国の地方自治体の情報システムを支援しており、現在はデジタル庁が提供するガバメントクラウド上で、複数の地方公共団体の業務システムを運用しています。 図表１：株式会社両備システムズ事業紹介 当社は、行政、医療、ヘルスケアなど、地域社会を支える幅広い分野でシステムを提供しています。 私たちがご支援している地方自治体のシステムは、ガバメントクラウドの「共同利用方式」のうち「ネットワーク分離方式」を採用しています。これは、1つのAWSアカウント（LinkedID）を複数の団体で共同利用し、団体ごとにVPC（Virtual Private Cloud）を分離して構成する方式です（図表2）。各団体のリソースはコスト配分タグ（以下、タグ）で識別し、利用状況に応じて費用を按分しています。現在、複数の地方公共団体のシステムを本方式で運用しています。 図表２：ガバメントクラウド共同利用（ネットワーク分離方式）のアーキテクチャ ※本図は考え方を示す概念図であり、実際のシステム構成を示すものではありません。 ガバメントクラウドへの移行が進むにつれ、多くの自治体にとってクラウド利用料の最適化が共通の課題となっています。中でも Amazon EC2 や Amazon RDS といったコンピューティング・データベースの利用割合は大きく、ここに「長期継続割引」（Savings Plans および Reserved Instance）を適切に適用できるかどうかが、コスト最適化の成否を大きく左右します。 一方で、「ネットワーク分離方式では長期継続割引を適用できないのではないか」という声を耳にすることがあります。単独利用方式やアカウント分離方式にはない課題があるなど、適用にあたり検討する要素が多いことは事実です。しかし、AWSの仕様を正しく理解し、利用状況や将来計画を踏まえて長期継続割引を適切に活用することで、ネットワーク分離方式においてもクラウド利用料の削減が期待できます。本記事では、私たちがどのようにこの課題と向き合い、実践してきたのかをご紹介します。 コスト最適化の取組みの経緯 私たちがコスト最適化に本格的に取り組み始めたのは、ガバメントクラウドでの運用を開始し、システム運用が安定した時期からです。移行の初期は、まず安定稼働を最優先に環境を構築し、運用が軌道に乗った段階で、クラウド利用料の最適化の取組みを本格化しました。具体的には、2025年度を検討・準備の期間と位置づけ、2026年度は4月1日から長期継続割引を適用できるよう準備を進めてきました。 自治体情報システムの標準化においては、移行後の運用経費を含めたコストの適正化が重要なテーマとなっています。当社においても、この趣旨を踏まえ、クラウド利用料の継続的な最適化に取り組みました。当社が運用する環境には、原則として24時間365日のサービス提供を前提とする業務システムがあるため、稼働時間の調整だけでなく、長期継続割引の活用も必要と考えました。コスト最適化に向け、Cost Explorerを中心としたコストの可視化・分析、インスタンス等のAWS環境の見直し、そして本記事の主題である長期継続割引の適用に、段階的に取り組んできました。2026年度からは、AWS Cost and Usage Report（CUR）等の利用データを基に、各団体の利用状況を確認しています。また、割引適用後の費用については、契約条件および当社が定める算定方法に基づき、各団体への説明可能性を確保しながら取り扱っています。AWSの各種分析・推奨情報も参考にしながら、アプリケーションの性能要件や運用条件、検証結果を総合的に確認し、最適化方針を判断しています。 長期継続割引適用に向けた課題と解決方策 ネットワーク分離方式ならではの課題 長期継続割引（Savings Plans / Reserved Instance）は、1年または3年の期間にわたり、一定の時間当たり利用額または対象リソースの利用をコミットすることで、オンデマンド料金より低い料金が適用される料金モデルです。ガバメントクラウドでは、デジタル庁のガイドラインに基づき、Amazon EC2についてはCompute Savings Plansを、Amazon RDSについてはReserved InstanceまたはDatabase Savings Plansを、いずれも前払いなし（No Upfront）で利用できます。（購入可能なプランや期間などの詳細は、デジタル庁のGCASガイドに掲載されています。参考として本記事にも一覧を掲載します。） （出典）内閣官房「国・地方デジタル共通基盤推進連絡協議会ワーキングチーム（第10回）」 図表３：ガバメントクラウドにおける長期継続割引の適用方針 ネットワーク分離方式には、単独利用方式やアカウント分離方式とは決定的に異なる難しさがあります。それは、長期継続割引が「アカウント単位」で適用されるという AWS の仕様です。 具体的には、次のとおりです。 ・    長期継続割引は、AWS 側のロジックに基づき、購入条件に合致する利用へ自動的に適用されます。タグを付けて購入した場合でも、タグ単位で割引の適用先を指定することはできません。 ・    Savings Plans の使用率（Utilization）レポートやカバレッジ（Coverage）レポートも、アカウントやリージョン、インスタンスファミリー単位での表示となり、タグ単位（＝団体単位）での内訳は確認できません。 ・    単独利用方式やアカウント分離方式では、AWSアカウント が団体ごとに分かれているため、割引はその団体のアカウントに正確に反映されます。 しかしネットワーク分離方式では、1つの AWSアカウント を複数団体で共有しているため、「この団体に、この割引を」とタグ単位で割り当てることが仕組み上できないのです。 私たちはこの点を正しく理解したうえで、「だから適用できない」と諦めるのではなく、「どうすれば使いこなせるか」という視点で戦略を組み立てました。 長期継続割引適用に向けた戦略と実行 私たちは、長期継続割引の購入を次の検討ステップに沿って進めています。各ステップで、ネットワーク分離方式ならではの難所をどう乗り越えたかをご紹介します。長期継続割引の適用方針は、まず当社で取りまとめたうえで各自治体に説明し、合意を得たうえで進めています。 STEP0：コミット前の最適化 長期継続割引の購入前に、まず不要なリソースの削除やインスタンス構成の見直しなどを実施し、環境の最適化を十分に行います。最適化しないままコミットすると、過大な利用量を前提とした契約となり、無駄なコストを長期間固定化してしまうためです。 また、RDSについては、現行構成をそのまま長期継続割引の対象とするのではなく、費用対効果、性能要件、動作条件および今後の構成変更の可能性を確認しました。そのうえで、本番稼働前の環境については、検証結果を踏まえて第7世代のDBインスタンスファミリーへ変更しています。 このように、長期継続割引の購入を検討する前に、継続利用するリソースと今後変更する可能性があるリソースを整理しました。これにより、最適化後も安定的に利用することが見込まれる範囲を見極め、必要以上のコミットを行わないようにしています。 STEP1：購入量（ベースライン）の決定 次に、どれだけの利用量をコミットするかを決めます。私たちは、Cost Explorerのデータをもとに、毎時の最小利用量であるベースラインを見極め、コミット額を算定しています。具体的には、1時間当たりの利用実績を把握したうえで、ガバメントクラウドの料金体系やGCASガイド等を参照し、購入量を検討しました。 Compute Savings Plansについては、稼働中のインスタンスをタイプ別に把握し、24時間連続して稼働する利用量を基準として、Savings Plans適用後の時間単価を積み上げています。ただし、現在の利用量のすべてを対象とするのではなく、構成変更や利用量の変動があった場合にも継続して利用することが見込まれる範囲をベースラインとしています。 RDSについては、Reserved DB Instanceの購入条件と、共同利用アカウント全体における継続的な利用量を確認しました。本番環境については、DBエンジン、DBインスタンスクラス、リージョン、配置方式および数量等を確認し、第6世代のDBインスタンスファミリーを使用し、継続的に稼働する本番環境の利用量を基に、条件に合致するReserved DB Instanceを購入しています。 Reserved DB Instanceの割引は、特定の団体や特定のDBインスタンスを指定して適用するものではなく、共同利用アカウント内で購入条件に合致する利用へ自動的に適用されます。このため、個別の団体やリソースを基準とするのではなく、共同利用アカウント全体で継続的に利用することが見込まれる本番利用量を基に購入量を決定しました。 なお、本番稼働前の環境は、STEP0で記載した構成の最適化を行うとともに、今後も構成を変更する可能性があります。変更後を含めた継続的な利用量を現時点で確定することが難しいため、RDSに対するDatabase Savings Plansは2026年度の購入対象としていません。 STEP2：長期継続割引の購入オプションの選択 デジタル庁のGCASガイドに従い、Amazon EC2 については Compute Savings Plans を利用します。Compute Savings Plans はインスタンスファミリーやリージョン、OS、対象サービスを跨いで柔軟に適用されるため、将来のモダン化にも対応しやすいという利点があります。RDS についてはReserved Instanceを選択しています。期間は1年を基本とし、前払いなし（No Upfront）で購入しています。期間を1年としているのは、デジタル庁のGCASガイドに沿った判断です。多くの環境では3年先までの運用状況を見通すことが難しいため、まずは1年での購入を基本としています。 STEP3：年に一度の購入オペレーション ガバメントクラウドでは、長期継続割引の利用期間がガバメントクラウド利用権付与兼債務引受契約の期間を超えないようにする必要があります。当社の2026年度の購入においては、GCASで示された購入条件およびAWS上の基準時刻を確認し、4月1日午前9時から9時59分までの日本時間内に購入処理を完了する手順としました。Compute Savings Plansは、将来の開始日時を指定した予約購入（キューイング）が可能であるため、事前に予約内容を登録し、開始日時に購入が処理されるようにしています。一方、Amazon RDSのReserved DB Instanceは予約購入に対応していないため、上記の時間帯に担当者がAWSマネジメントコンソールから購入します。限られた時間内で誤りなく購入できるよう、購入内容の事前確認と当日の実施手順をあらかじめ整理しています。 STEP4：購入後のモニタリングと是正 購入後は、使用率（コミットをどれだけ使い切れているか）とカバレッジ（割引対象の利用のうちどれだけを割引でカバーできているか）を継続的に監視します。先に述べたとおり、これらのレポートはアカウント単位で確認するため、長期継続割引が全体として方針どおりの成果を上げているかをチェックしています。また、AWS Cost and Usage Report（CUR）等を用いて各団体の利用状況を確認し、契約条件および当社が定める算定方法に基づいて、割引適用後の費用を取り扱っています。これにより、各団体への説明可能性と透明性の確保に努めています。 取組みの効果 これらの取組みの結果、私たちは長期継続割引をネットワーク分離方式のもとでも有効に活用し、クラウド利用料の削減を実現しています。これらの取組みにより、対象となるAWS利用料について、長期継続割引適用前の料金との比較で最大20％の削減効果を確認しています。なお、削減効果は利用サービス、稼働状況、構成および為替等の条件により異なります。 また、各団体の利用状況と費用の関係を説明できるようにすることで、コストの透明性向上に取り組んでいます。 持続可能なFinOpsの推進に向けて ガバメントクラウドにおけるコスト最適化は、一度行えば終わりというものではありません。団体の増減、業務システムの更改、AWS の新しいサービスやインスタンスの登場に合わせて、継続的に見直しを続けることが欠かせません。私たちはこれを、FinOps（財務とクラウド運用を密に連携させ、継続的にコストを最適化する取組み）の実践と捉えています。 私たちが最もお伝えしたいのは、ネットワーク分離方式であっても、AWS の仕様を正しく理解すれば長期継続割引は十分に使いこなせる、ということです。「適用できない」という誤解から最適化を諦めてしまうのは、自治体にとっても事業者にとっても大きな機会損失です。 そして、持続可能なコスト最適化を実現するには、自治体と運用管理補助者である事業者が、それぞれの役割を共有し、コスト、安定運用、継続的な改善のバランスを取ることが重要です。こうした協力関係を通じて、説明可能性の高い、持続可能なガバメントクラウド運用を目指します。 本記事が、同じようにガバメントクラウドの共同利用方式でコスト最適化に取り組む事業者や自治体の皆さまにとって、最初の一歩を踏み出すきっかけになれば幸いです。 著者について 岩倉　竜太（株式会社両備システムズ ガバメントクラウド推進室 次長） 2000年入社。自治体向け健康管理システム「健康かるて」シリーズの導入・保守エンジニアとして、特別区、中核市、市町村を担当。ガバメントクラウド先行事業への参画を経て、ガバメントクラウド推進室の立ち上げからAWSを活用したガバメントクラウド環境の構築・運用を担当。現在は自治体のガバメントクラウド移行や運用最適化の推進に取り組んでいる。

概要 RevCommで主に音声認識・音声感情認識・話者分離の研究開発を担当している石塚です。 音声認識モデルのロバスト化を目的にデータ拡張を適用したところ、精度は改善したもののCPU推論速度が低下するという事象に見舞われました。調査した結果、原因は計算量やモデルアーキテクチャによるものではなく、重みの中に残った微小な値（非正規化数 / Denormal）にありました。 本稿では、重み分布の偏りと非正規化数に起因する推論速度低下のメカニズムと、その具体的な回避方法についてまとめます。 1. 背景 クラウドインスタンスのコスト削減や、エッジデバイスでの展開を視野に入れ、1vCPUで高速動作するCPU向け音声認識モデル（Conformer CTC / ONNX Runtime + INT8量子化）を構築しました。 初期ベースモデルは実利用での雑音・残響環境下で認識精度が十分でなかったため、MUSANデータセットのノイズ重畳、およびOpenSLR28の室内インパルス応答を学習時にオンザフライでランダム付加する データ拡張 を適用しました。ベースモデルと、データ拡張を適用して構築したモデル（以下、拡張モデル）について、クリーン・雑音テストセットをそれぞれ音声認識した際のCER（Character Error Rate：文字誤り率）を下記に示します。 モデル CER（クリーンテストセット） CER（雑音テストセット） ベースモデル 8.9% 28.1% 拡張モデル（aug） 7.2% 19.2% データ拡張により過酷な音響条件下での精度の改善が確認できましたが、推論サーバー上でのベンチマーク（AWS c7i.2xlarge で、1プロセス・1スレッドで計測）において予期せぬ速度の低下が発生しました。ベースモデルと拡張モデルのRTF（Real-Time Factor）を下記に示します。 モデル RTF ベースモデル 0.111 拡張モデル（aug） 0.165 Real-Time Factorは、音声認識にかかった時間を音声の長さで割ったもので、大きいほど速度が遅いことを示しています。表から分かる通り、拡張モデルの推論処理速度が約1.5倍遅くなっており、この現象はPyTorch環境でも同様に再現されました。モデル構造・パラメータ数・入力テンソル形状は全く同一であるにもかかわらず、「データ拡張によって学習済み重みの値が変わっただけで推論速度が大幅に低下する」という課題に直面しました。 2. 要因分析：重み分布の偏りと非正規化数（Denormal） 同一構造・入力形状の音声認識モデルなので必要な計算量はまったく変わっていないはずであり、重みの違いだけで速度が低下するのは、本来は起こらないはずの挙動です。そこで、非正規化数（Denormal）の演算に伴うCPUの例外処理が発生している可能性を疑いました。 非正規化数（Denormal）とは IEEE 754形式の単精度浮動小数点数（float32）は、[符号: 1bit] [指数部: 8bit] [仮数部: 23bit]で数値を表現します。 通常、浮動小数点数は効率化のために 「正規化数」として扱われます。正規化数では仮数部の先頭に「暗黙の1」が存在するものとして計算され、表現できる正の最小値は約 （ ） となります。ここで、計算の過程でこの境界値を下回った際、直ちに「0.0」へ切り捨ててしまうと、微小な差分情報が失われ、数値計算に悪影響が出るおそれがあります。これを防ぐ救済措置が「段階的アンダーフロー」です。指数部がすべて0のときは、仮数部に暗黙の1を置かずに数値を扱うことで、 未満の極小値を表現可能にした特殊な値を非正規化数と呼びます。 なぜCPU処理が極端に遅くなるのか 非正規化数は数値精度を保つ代償として、処理速度を著しく犠牲にします。 通常の計算（Fast Path） : FPUやSIMD演算器（AVX2 / AVX-512等）の専用回路により、数サイクルの高速パイプラインで処理。 非正規化数の計算（Slow Path） : 通常の回路では直接処理できず、x86系CPUではマイクロコード例外が発生。ファームウェアによるエミュレーション処理へフォールバックするため、追加オーバーヘッドが発生。 なぜDNN推論に大きく影響するのか 深層学習の推論は膨大な積和演算の連続です。重みテンソル内に非正規化数が大量に含まれると、演算のたびにマイクロコード例外が発生してSIMDユニットのパイプラインが頻繁にストールします。その結果、「計算量は同一であるにもかかわらず、ハードウェアのストール待ちだけで推論時間が跳ね上がる」という現象が生じます。今回のConformer CTCで発生していた性能低下の正体は、まさにこの例外処理の頻発によるものである可能性があります。 Conformer CTCのエンコーダーの重み分布の分析 エンコーダー内部のパラメータを抽出し、重みの絶対値分布（ ）を解析しました。横軸は重みの絶対値の常用対数、縦軸はその値を持つ重みの個数です。 非正規化数の範囲（約 1.18e-38 未満）よりも広く、余裕を持たせる意図で、ここでは閾値を 1e-15 としています。 ベースモデル（青） : 1e-15 を下回るような微小な値の重みは、広域に分散している。 拡張モデル（橙） : 1e-38 付近に鋭いピーク が形成されている。これは float32の正規化可能限界境界であり、大量の重みが非正規化数領域に集中していることを示す。 Initializerごとの微小重みの分布を特定したところ、大半が 入力直後の畳み込み層（subsamplingブロック）の単一の重みテンソル に集中していました。 エンコーダー全体における |w| < 1e-15 の重み数は以下の通りです。 モデル |w| < 1e-15 の非ゼロ重み数 ベースモデル 約19万個 拡張モデル（aug） 約29万個 データ拡張によって広帯域なノイズ成分への反応を抑える方向に学習が進み、不要な成分に対応する重みが微小値へ収束したことで、非正規化数を大量に誘発していたと考えられます。 3. 回避策：微小重みのゼロ化とランタイム設定 非正規化数によるペナルティを回避するには、実質的にゼロとみなせる微小値をハードウェアが直接処理可能な真のゼロ（0.0）へ置換する必要があります。対応策として以下の2通りのアプローチを検証しました。 アプローチ A: ONNX Initializerの直接置換 推論前の前処理として、 1e-15 未満の非ゼロ重みを 0.0 に置き換えた ONNX モデルを新たに保存します。 import numpy as np import onnx from onnx import numpy_helper, TensorProto model = onnx.load( "conformer_ctc_quant.onnx" ) CLEAN_THRESHOLD = 1e-15 for init in model.graph.initializer: if init.data_type in (TensorProto.FLOAT, TensorProto.DOUBLE): w = numpy_helper.to_array(init) mask = (np.abs(w) < CLEAN_THRESHOLD) & (w != 0 ) if mask.any(): w = w.copy() w[mask] = 0.0 init.CopyFrom(numpy_helper.from_array(w, init.name)) onnx.save(model, "conformer_ctc_quant_clean.onnx" ) なお、今回は閾値を 1e-15 と決め打ちして検証しましたが、実際にゼロ化を適用する場合は、精度への影響がないか回帰テストを行って閾値を調整するのが確実でしょう。 アプローチ B: ONNX Runtimeのセッションオプション設定 本記事の検証は ONNX Runtime 1.23.2 / ONNX 1.23.0 を用いています。 モデルファイルを変更せず、推論実行時に ONNX Runtimeのセッションオプションを介してCPUの制御フラグ（FTZ: Flush-To-Zero / DAZ: Denormals-Are-Zero）を有効化します。 import onnxruntime as ort opts = ort.SessionOptions() opts.add_session_config_entry( "session.set_denormal_as_zero" , "1" ) session = ort.InferenceSession( "conformer_ctc_quant.onnx" , opts) 実運用におけるデプロイパイプラインの簡素化の観点では、アプローチ B のランタイム設定が最も簡便です。 注意: PyTorch設定との非連動 : PyTorch の torch.set_flush_denormal(True) を推論前段で実行しても、ONNX Runtimeの実行コンテキストには伝播しないようです。ONNX Runtimeを利用する場合は、必ず session.set_denormal_as_zero オプションを使用する必要があります。 4. 検証結果 約51分間のテスト音声データセットを用いて、RTF、認識精度、およびCPUアーキテクチャ依存性を評価しました。 推論RTF AWS c7i.2xlarge で、1プロセス・1スレッドでベースモデルと拡張モデルのRTFを計測した結果を下記に示します。 モデル デフォルト（設定なし） 重みゼロ化（アプローチ A） set_denormal_as_zero （アプローチ B） ベースモデル 0.111 - 0.013 拡張モデル 0.165 0.013 0.013 拡張モデルのRTFは約13倍、ベースモデルも約9倍、高速化しました。 ベースモデル側も非正規化数の影響を受けていたため、対策後はベース・拡張モデル共に同一のRTF（0.013）に収束しました。 拡張モデルの速度低下の原因は、微小重みの増加であったと考えられます。 認識精度への影響 次に、微小重みのゼロ化が認識精度に与える影響を検証しました。 モデル CER（クリーンテストセット） CER（雑音テストセット） 拡張モデル（変更前） 7.2% 19.2% 拡張モデル（微小重みゼロ化後） 7.2% 19.2% 評価セット全件において、推論結果の文字列は ゼロ化の前後で完全に一致 しました。今回の評価範囲では精度への影響はなく、推論速度の改善のみが得られました。 CPUアーキテクチャによる挙動差異 同一モデルを Intel Xeon および AMD EPYC 環境で実行し、挙動の差異を比較しました（1プロセス・1スレッド測定）。 CPU環境 augのRTF（デフォルト） set_denormal_as_zero 有効時 Intel Xeon Platinum 8488C （ c7i ） 0.165 0.013 AMD EPYC 7R13 （ g6.2xlarge ） 0.023 0.023 AMD EPYC では非正規化数を含む重みであっても例外処理による速度低下が発生せず、デフォルト状態で0.023を達成していました。CPUアーキテクチャによって非正規化数の扱いは異なるため、実行環境を変えた際に推論速度が変わる場合はこの点も疑う余地がありそうです。なお、c7i と g6.2xlarge ではCPU以外も異なるため、厳密な比較ではなく傾向の確認としてご覧ください。 5. まとめ 本稿では、音声認識モデルへのデータ拡張適用後に発生した「計算量は変わらないのに推論速度が大幅に低下する」というトラブルの原因究明と、その回避策について解説しました。 データ拡張に伴う推論遅延の正体は、重みの微小値化によって引き起こされた「非正規化数（Denormal）」によるCPU例外処理でした。この問題は、ONNX Runtimeの session.set_denormal_as_zero オプションを有効化するか、事前に微小重みをゼロ化することで解消できます。また、CPUアーキテクチャによって挙動が異なる点にも注意が必要です。 モデル構造や計算量に変化がないにもかかわらず「学習データや重みを変えただけでCPU推論が不自然に重くなった」という場合、非正規化数による速度低下が潜んでいる可能性があります。 本記事が同様のトラブルに直面したエンジニアの皆様の参考になれば幸いです。 参考情報 Conv2D is very slow on trained weights (vs random weights) – PyTorch Forums How Denormal Floats Slow Down ML Inference Intel oneMKL: Operating on Denormals