Skip to content

2026年07月09日

[Config] AWS Config now supports 191 additional managed rules

概要

AWS Configが191件の追加マネージドルールをサポートしました。AIワークロード(Amazon Bedrock、SageMaker等)とコアインフラ(ECS、EKS、RDS、Redshift、S3、CloudTrailなど)に対するガバナンス適用範囲が拡張されています。

変更内容・新機能の詳細

今回の拡張でAWSが管理する191個のマネージドルールが追加され、暗号化設定、ログ記録、有料公開アクセスの禁止、ネットワークセキュリティ、データ保護、運用ベストプラクティス(例:監査ログ、MFA/パスワードポリシー、バックアップ設定、削除保護)などを自動で評価できます。主な特徴は以下の通りです。

  • 対象サービス:Amazon Bedrock、SageMaker、ECS、EKS、RDS、Redshift、S3、CloudTrailなど多数のサービスに跨るルールを追加。
  • ルールの内容:リソースがKMSで暗号化されているか、CloudTrailがS3データイベントを捕捉しているか、S3バケットの公開アクセスが禁止されているか、ECS/EKSの実行設定(非特権コンテナ、ログ有効化、ネットワークモード等)などを評価。
  • 配備方法:個別のマネージドルールとしてデプロイ可能なほか、Conformance Packにまとめて適用することも可能。AWS Configレコーダーとデリバリーチャンネルが有効であれば評価が実行されます。
  • 運用面:これらのマネージドルールはAWSがメンテナンスするため定義の更新や追加チェックがAWS側で提供される一方、ルールごとに自動修復(Remediation)が利用可能な場合は、適切なIAMロールやSystems Manager/Lambdaの設定が必要。
  • 適用リージョン:各ルールは、当該サービスが利用可能なAWSリージョンで使用可能(リージョンに依存するサービス固有のルールあり)。 追加されたルールは例としてBEDROCK_~、SAGEMAKER_~、ECS_~、RDS_~、S3_~など多岐に渡り、AIモデルの実行分離・ネットワーク隔離やストレージ・データベースの暗号化・監査ログ出力などをカバーします。

影響範囲・利用シーン

  • 対象ユーザー: クラウドセキュリティチーム、ガバナンス/コンプライアンス担当、SRE/運用チーム、AI/MLプラットフォーム管理者
  • 利用シーン: 組織のセキュリティ基準・コンプライアンス要件に基づく設定の継続的監査(例:S3の公開設定チェック、RDS/Redshiftの暗号化チェック、Bedrock/SageMakerのネットワーク分離チェック)
  • 運用効果: 手動監査の削減と設定逸脱の早期検出、自動修復と組み合わせることで是正時間の短縮、AIワークロードとコアインフラ両面のガバナンス強化

技術的な注意点

  • IAM権限: マネージドルールを作成/変更するには config:PutConfigRule、config:PutConformancePack、config:PutRemediationConfigurations 等の権限が必要。自動修復を使う場合はSSM/Lambdaを実行するIAMロールが別途必要。
  • リージョン制限: ルールは該当サービスが利用可能なリージョンのみで利用可能。Bedrock等、一部サービスは提供リージョンが限定されるため注意。
  • コスト: AWS Configのルール評価は評価回数に応じた課金対象。ルール数増加に伴い評価コストが上昇する可能性があるため見積が必要。
  • 前提: AWS Configレコーダーとデリバリーチャンネル(S3等)が有効であること。ルールによっては対象リソースのログやCloudTrail、CloudWatch Logsが有効であることが評価要件。
  • 互換性/競合: 既存のカスタムルールや他のマネージドルールと重複チェックが発生する可能性があるため、適用前にルール間の重複や冗長を確認すること。
  • 運用影響: 初回評価や頻繁な評価でAPI呼び出しが増えるためレート制限や監査ログ量の増加に留意。
  • KMS/暗号化関連: CMKを利用するルールはキーのリージョン、キー・ポリシー、キーローテーション設定に依存するため事前確認が必要。
  • 自動修復: Remediationを有効化する際は、修復用のIAMロールに適切な権限が付与されているか確認。

参考情報


[General] AWS Builder Center Now Offers Free Sandbox Environments

概要

AWS Builder Centerが、対象ワークショップから直接リクエストできる無料の時間制限付きサンドボックス環境を提供開始しました。個人のAWSアカウントやクレジットカード不要で、実習用に事前プロビジョニングされたAWSアカウントに安全にアクセスできます。

変更内容・新機能の詳細

サンドボックス環境は各ワークショップ向けに事前プロビジョニングされた一時的なAWSアカウントで、アクティベーションから8時間利用可能(その後自動クリーンアップ)です。利用者は自身のAWSアカウントや課金手段を用意する必要がなく、リソースのデプロイ、コード実行、実験を安全に行えます。各ユーザーは週に1回(毎週日曜日にリセット)サンドボックスをリクエストでき、ほとんどの環境はリクエストから約15分以内に利用可能となります。提供はローンチ時点で対象ワークショップの一部から開始され、順次対象ワークショップが拡大されます。設計上、学習・ハンズオン用途を想定しており、長期保存・本番利用を目的としたリソース保持は想定されていません。

影響範囲・利用シーン

  • 対象ユーザー: ハンズオン学習者、トレーニング受講者、講師、技術検証を素早く行いたい開発者やSRE
  • 利用シーン: ワークショップやラボでのハンズオン(リソース作成・コード実行・サービス検証)
  • 運用効果: 受講者ごとのアカウント準備不要によりセットアップ工数と障壁が低減し、学習到達までの時間短縮が期待できる
  • コスト削減効果: 受講者側のクレジットカードや個人アカウントによる予期せぬ課金リスクが解消される
  • 制限による影響: 利用時間が8時間に制限されるため、長時間の連続作業や永続環境が必要な演習には不向き(ワークショップ設計の変更が必要な場合あり)

技術的な注意点

  • IAM権限: 利用者側でのAWSアカウント作成やIAM設定は不要。ただしBuilder Centerへのサインインやワークショップ上の認証フローが必要になる可能性がある
  • リージョン制限: 記載の詳細なし。ワークショップ/サンドボックスごとに利用可能リージョンやサービスが制限される可能性があるため、ワークショップの案内を確認してください
  • コスト: サンドボックス自体は無料提供。ただしワークショップ外で別途有料サービスや追加機能を要求する場合は別途課金の可能性あり(基本はAWS管理の一時環境で課金リスクは低い)
  • データ永続性: 8時間経過後に自動でクリーンアップされるため、重要なデータや成果物は外部にエクスポートして保存する必要あり
  • 利用頻度制限: 1ユーザーあたり週1回(毎週日曜日にリセット)。複数回の連続利用は制限される
  • 制限・注意: 対象は「選択されたワークショップ」のみ。全ワークショップで即時利用できるわけではないため、事前に該当ワークショップの可否を確認してください

参考情報


[Security Hub] AWS Security Hub now offers Network Scanning to identify publicly reachable resources

概要

AWS Security Hubに新機能「Network Scanning」が追加され、インターネットから実際に到達可能なリソース(パブリックIP、VM、ロードバランサー等)と到達可能なポート/サービスを検出してSecurity Hubのファインディングとして報告します。既存の設定ベースの到達可能性検出を補完し、実際のインターネット到達性を確認できます。

変更内容・新機能の詳細

Network Scanningはインターネット側からプローブを実行して、環境内の実際に到達可能なエンドポイントを検出します。検出対象にはパブリックIPアドレス、仮想マシン、ロードバランサーが含まれ、AWSとAzureの両環境にまたがって探索します。到達可能なポートごとに、発見されたポート番号とそこに応答するサービス(例: HTTP、SSHなど)を証拠として含むSecurity Hubのファインディングが生成されます。これらのファインディングはSecurity Hub Exposuresによって既存のファインディングやリソース構成と自動的に相関付けされ、より広範なリスク評価を可能にします。従来の「設定から推測される到達可能性(セキュリティグループ/ルート等)」とは異なり、Network Scanningは実際のネットワーク到達性を確認するため、誤検出の削減や実運用での露出把握に有用です。

影響範囲・利用シーン

  • 対象ユーザー: セキュリティチーム、クラウド運用(SRE/クラウドエンジニア)、コンプライアンス担当者
  • 利用シーンまたは効果: パブリックに公開されているサービスの実際の露出確認、未許可のサービス公開や誤設定の早期検出、脆弱性スキャンやインシデント対応時の優先順位付け
  • 運用効果: 設定上は安全でも実際に到達可能なサービスを検出できるため、優先的な対処や攻撃面削減の意思決定が迅速化される
  • クロスクラウド対応の利点: AWSとAzureを横断して外部から確認できるため、マルチクラウド環境における一貫した露出管理が可能

技術的な注意点

  • IAM権限: Security Hubの設定変更やファインディング生成を行うための適切なIAM権限が必要です。Network Scanningやクラウド連携の有効化に関する権限を事前に確認してください。
  • リージョン制限: 提供リージョンは段階的に拡大される可能性があります。利用前に公式ドキュメントで対応リージョンを確認してください。
  • コスト: Network Scanningの利用に伴う追加料金や、生成されるファインディングの取り込み・保持に関連するコストが発生する可能性があります。料金ページを確認してください。
  • スキャンの性質: スキャンはインターネット側からのプローブであるため、監視機器やIDS/IPSに検知される可能性があります。第三者所有のリソースをスキャンする場合は必ず許可を得てください。
  • Azure連携: Azure環境の検出にはAzure側の連携設定(認証情報や権限付与)が必要になる可能性があります。認証情報の管理と最小権限原則を守って設定してください。
  • 誤検知とノイズ: 実際の応答を確認するため誤検知は減るが、メンテナンス中のサービスや一時的な応答によりノイズが発生することがあります。検出ルールとアラート閾値を運用に合わせて調整してください。
  • ログ/証拠: 各ファインディングには発見したポートとサービスの証拠が含まれるため、トリアージや調査に利用できます。ファインディングの保管・アクセス制御を検討してください。

参考情報


[Redshift] Amazon Redshift RG instances now available on the trailing track

概要

Amazon RedshiftがGravitonベースのRGインスタンス(rg.4xlarge、rg.xlarge)をトレーリングトラック(P201)でサポート開始しました。安定重視の本番環境向けトラックでGravitonのコスト/性能メリットを利用できます。

変更内容・新機能の詳細

2026年7月7日付で、Amazon Redshiftのトレーリングトラック(P201)上でrg.4xlargeおよびrg.xlargeインスタンスタイプが利用可能になりました。トレーリングトラックはリーディングトラックで実績のあるバージョンを本番安定稼働向けに提供する仕組みです。RG(Graviton)インスタンスはAWS Gravitonプロセッサを活用し、RA3インスタンスと比較して最大でクエリ性能が2.4倍、vCPU当たりの価格が約30%低いとされています。既存クラスタのリサイズ(または新規クラスタ作成)により、AWS Management Console、AWS CLI、またはAWS SDKを使ってrg.4xlarge/rg.xlargeへ移行できます。詳細な互換性や手順は「Amazon Redshift cluster versions」のドキュメントを参照してください。

影響範囲・利用シーン

  • 対象ユーザー: Redshiftを本番環境で運用するデータエンジニア、SRE、BIチーム
  • 利用シーン: 安定性を優先する本番クラスターでのコスト最適化とクエリ性能改善(バッチ/分析クエリ、ダッシュボード、ETL処理)
  • 運用効果: vCPUコスト低減とクエリの高速化によりクエリ実行時間短縮とコスト削減が期待できるため、スケール設計やインスタンスタイプ見直しによるTCO改善が可能

技術的な注意点

  • IAM権限: クラスタ作成・変更には redshift:CreateCluster、redshift:ModifyCluster 等の権限が必要です。事前にIAMポリシーを確認してください。
  • クラスタバージョン/トラック: トレーリングトラック(P201)上での提供です。対象クラスタがP201にあるか、移行可能なクラスタバージョンかを確認してください(クラスタバージョンの互換性を要確認)。
  • リージョン制限: 記事では一般提供開始日を示していますが、リージョンごとのロールアウト状況は異なる可能性があります。利用前に対象リージョンでの可用性を確認してください。
  • リサイズ/ダウンタイム: インスタンスタイプ変更は操作方法(エラスティックリサイズ/クラシックリサイズ/再作成)によりダウンタイムや所要時間が異なります。本番移行時はメンテナンスウィンドウやバックアップを計画してください。
  • ストレージ/機能差異: RG(Graviton)インスタンスはRA3等と異なるリソース特性(CPUアーキテクチャ、ローカルストレージ/管理ストレージの挙動等)を持つ場合があります。ワークロードによっては性能差が異なるため、移行前に検証クラスターでベンチマークを行ってください。
  • コスト: vCPU当たりの価格低減がアナウンスされていますが、総コストはインスタンス数、ストレージ、データ転送などで変わります。見積りと比較検証を行ってください。

参考情報


[General] Amazon Aurora DSQL change data capture (CDC) Is now generally available

概要

Amazon Aurora DSQL の Change Data Capture(CDC)が一般提供(GA)になりました。データベースの挿入・更新・削除イベントを自動的にキャプチャして Amazon Kinesis Data Streams にストリーム配信でき、イベント駆動アーキテクチャやデータ統合に利用できます。

変更内容・新機能の詳細

Aurora DSQL CDC は、INSERT/UPDATE/DELETE の結果を変更イベントとして自動的に取得し、インフラ管理なしに Amazon Kinesis Data Streams へ配信します。配信されたイベントは AWS Lambda のトリガーや Amazon Data Firehose 経由での Amazon S3、Amazon Redshift、Amazon OpenSearch Service への投入に利用できます。AWS によれば CDC ストリーミングはデータベースのワークロード性能に影響を与えないよう設計されており、Aurora DSQL が利用可能な全リージョンで GA 提供されます。AWS Free Tier を利用してAurora DSQLを試すことが可能です。なお、配信先や処理フロー(Kinesis のシャード数、Firehose のバッファ設定、Lambda の並列性など)は用途に応じて設計が必要です。

影響範囲・利用シーン

  • 対象ユーザー: データベース開発者、データエンジニア、マイクロサービス設計者、SRE/運用チーム
  • 利用シーン: マイクロサービス間のデータ同期、イベント駆動処理のトリガー(Lambda)、変更履歴のアーカイブや分析用途への取り込み(S3/Redshift/OpenSearch via Firehose)
  • 運用効果: データ変更をリアルタイムに他システムへ伝播できるため、レイテンシの低い連携や近リアルタイム分析、ETL の簡素化が可能になる

技術的な注意点

  • IAM権限: Aurora から Kinesis/Data Firehose へ書き込むための IAM ロール/権限(PutRecord/PutRecords/Firehose:PutRecord 等)を適切に設定してください
  • リージョン制限: Aurora DSQL が提供されているリージョンで利用可能です。利用可否は各リージョンのサービス一覧を確認してください
  • コスト: Aurora DSQL の利用(Free Tier 対象あり)に加え、Kinesis Data Streams のシャード課金や API リクエスト、Data Firehose の配信コスト、データ保存先(S3/Redshift/OpenSearch)の料金が発生します。設計時にトラフィック量とシャード数を見積もってください
  • パフォーマンス: AWS は「ゼロ影響を目標」としていますが、実運用ではスループットやレイテンシ、Kinesis シャードの制限、Firehose のバッファ設定により振る舞いが変わります。負荷試験とモニタリング(CloudWatch)を行ってください
  • データ整合性と順序: イベント配信の整合性・順序保証は Kinesis の特性に依存します。厳密な順序や exactly-once が必要な場合は設計で補償処理や重複排除を検討してください
  • 運用設定: 配信先の設定(Kinesis ストリーム名、シャード数、Firehose 宛先設定、Lambda トリガーのハンドリング)を事前に定義する必要があります

参考情報


[Govcloud Us] Amazon Connect Customer now supports forecasting, planning, and scheduling for Tasks and Emails

概要

Amazon Connect Customer が Tasks(タスク)と Emails(メール)についても予測・キャパシティプランニング・エージェントスケジューリングをサポートしました。これにより、Voice/Chat/Tasks/Emails を横断した統合的な勤務計画と最適化が可能になります。

変更内容・新機能の詳細

新機能は各チャネルの特性(同時処理可能数、処理時間の分布:数分〜数か月、チャネルごとのサービスレベル要件など)を考慮して、統合的なフォーキャスト(需要予測)とスタッフ配置スケジュールを生成します。例えば、通話対応と並行してメール問合せやケース処理を行うエージェントがいる場合、これらの作業を合算して必要なFTE(フルタイム換算)やシフトを算出できます。Connect Customer のエージェントスケジューリング機能と連携し、チャネル間のリソース配分を効率化して一貫したサービスレベルを維持します。機能は Amazon Connect のエージェントスケジューリングが利用可能なすべてのリージョンで提供されます。

影響範囲・利用シーン

  • 対象ユーザー: コンタクトセンター運用チーム、ワークフォースプランナー、カスタマーサポートマネージャー
  • 利用シーン: 複数チャネル(音声・チャット・タスク・メール)を横断する需要予測とシフト作成、エージェントのクロスチャネル割当て最適化
  • 運用効果: サービスレベルの均一化、過剰・過少配置の削減によるコスト最適化、長期タスクや並列作業を考慮した現実的なスケジューリングが可能に

技術的な注意点

  • IAM権限: Connect のスケジューリング/予測機能を操作するための適切な Amazon Connect 管理権限が必要です(ドキュメントで必要なポリシーを確認してください)
  • リージョン制限: Amazon Connect の「エージェントスケジューリング」がサポートされているリージョンで利用可能です。利用予定リージョン(商用リージョンおよび GovCloud)での対応状況を事前に確認してください
  • コスト: 機能利用自体や追加の API 呼び出し、保存するログやデータ処理に伴う料金が発生する可能性があります。詳細は Amazon Connect の料金ページを確認してください
  • 前提・設定: 正確な予測のために各チャネル(Voice/Chat/Tasks/Emails)での過去実績データ、作業時間分布、同時処理数(コンカレンシー)設定、サービスレベル目標(SLO)やスキル設定を整備しておく必要があります
  • 運用上の注意: 長期間にわたるタスク(数週間〜数か月)のモデリングや、エージェントのクロスチャネル可用性設定(どのチャネルを同時に処理可能か)を正しく反映させることが重要です

参考情報

AI要約はOpenAI APIによって生成されています。