本日の主なトピック

#

• Amazon CloudWatch: OpenTelemetry (OTel) メトリクスのネイティブサポート（パブリックプレビュー）を開始し、OTLP 形式で直接メトリクスを送信可能に。
• Amazon ECS: セキュリティや監視エージェントを一元管理できる「Managed Daemons」を発表し、アプリケーションから独立したエージェント運用を実現。
• AWS Direct Connect: CloudFormation によるリソースのプロビジョニングをサポートし、ネットワーク構成の自動化とコード管理が可能に。
• Amazon Lightsail: 最大 72 vCPU の「コンピュート最適化インスタンス」を提供開始し、計算集約型のワークロードに対応。
• Amazon SageMaker Data Agent: 日本とオーストラリアにおいて、Amazon Bedrock を介した地理特定インフラによる推論をサポート。

AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11

¥3,520

Amazonで見る

---

AWS Direct Connect が AWS CloudFormation のサポートを開始

#

投稿日: 2026年03月31日

AWS Direct Connect now supports AWS CloudFormation - AWS

aws.amazon.com

何ができるようになったのか

#

AWS Direct Connect リソースを AWS CloudFormation を使用してプロビジョニングできるようになりました。これにより、Direct Connect のトポロジー全体を CloudFormation テンプレートで定義し、他の AWS リソースと同様にコードとして管理（Infrastructure as Code）することが可能になります。

自動化できるリソースには、接続（Connections）、仮想インターフェース（Virtual Interfaces）、Direct Connect ゲートウェイ、リンクアグリゲーショングループ（LAG）、BGP ピアリング設定などが含まれます。

何が嬉しいのか

#

• 再現性と一貫性: テンプレートを使用することで、環境の複製が容易になり、手動設定によるミスを削減できます。
• バージョン管理: ネットワーク構成をコードとして Git 等で管理し、変更履歴を追跡できます。
• ドリフト検出: 実際の構成がテンプレートの定義から外れていないかを自動で検出し、構成の整合性を維持できます。

これまでとどう変わるのか

#

• これまで: Direct Connect の構築や設定変更は、マネジメントコンソールからの手動操作、または AWS CLI / SDK を用いたスクリプト作成が必要であり、他のインフラリソースとの一元管理が困難でした。
• これから: CloudFormation を通じて、サーバーやデータベースなどのリソースと同じワークフローで Direct Connect をプロビジョニングし、スタックとして一括管理できるようになります。

具体的なユースケース

#

• マルチアカウント・マルチリージョン環境における Direct Connect ゲートウェイと仮想インターフェースの標準的な展開。
• CI/CD パイプラインに組み込んだ、ネットワーク構成の自動テストとデプロイ。
• 災害復旧（DR）環境におけるネットワークインフラの迅速な再構築。

---

Amazon CloudWatch が OpenTelemetry メトリクスのネイティブサポートを開始（パブリックプレビュー）

#

投稿日: 2026年04月02日

Amazon CloudWatch now supports OpenTelemetry metrics in public preview - AWS

aws.amazon.com

何ができるようになったのか

#

Amazon CloudWatch が、OpenTelemetry (OTel) メトリクスのネイティブサポートを開始しました（パブリックプレビュー）。これにより、カスタム変換ロジックや追加ツールを介さず、OpenTelemetry Protocol (OTLP) を使用してメトリクスを直接 CloudWatch に送信できるようになります。また、PromQL を使用してこれらのメトリクスをクエリすることも可能です。

何が嬉しいのか

#

• 標準プロトコルの直接利用: ベンダーに依存しない OTLP をそのまま利用できるため、アプリケーションコードのポータビリティが向上します。
• 統合された分析: OTel によるカスタムメトリクスと、70以上の AWS サービスから出力される標準メトリクスを、同一のダッシュボードやアラームで PromQL を用いて一元管理できます。
• 高度な機能の適用: OTel メトリクスに対しても CloudWatch の異常検知機能が利用可能で、静的なしきい値を設定することなく異常を自動特定できます。

これまでとどう変わるのか

#

• これまで: OTel メトリクスを CloudWatch で扱うには、ADOT (AWS Distro for OpenTelemetry) コレクターなどのエージェントを介して CloudWatch 形式に変換して送信する必要がありました。
• これから: OTLP 形式で直接送信が可能になり、エージェント構成の簡素化や、PromQL による柔軟なクエリ操作が標準機能として提供されます。

具体的なユースケース

#

• EKS 上のマイクロサービスとオンプレミスサーバーの両方から OTel メトリクスを直接 CloudWatch に集約し、インフラ全体のレイテンシやリソース使用率を PromQL で可視化する。
• 新しく提供される「Query Studio」を使用して、PromQL で複雑なメトリクス計算を行い、そのままダッシュボードやアラームを作成する。

---

Amazon ECS がマネージドインスタンス向け「Managed Daemons」を発表

#

投稿日: 2026年04月01日

Amazon ECS announces Managed Daemons for ECS Managed Instances - AWS

aws.amazon.com

何ができるようになったのか

#

Amazon ECS において、セキュリティ、オブザーバビリティ、ネットワーキングなどのエージェントを中央で管理・デプロイできる「Managed Daemons」が発表されました。これは ECS Managed Instances（EC2 上で動作する ECS 起動タイプ）を対象としており、アプリケーションのデプロイとは独立して、コンテナインフラ全体にソフトウェアエージェントを配置できます。

何が嬉しいのか

#

• 確実なエージェント配置: ECS が各インスタンスに必ず1つのデーモンタスクを配置し、アプリケーションタスクが開始される前にデーモンが稼働していることを保証します。
• 運用の分離: プラットフォーム管理者は、アプリケーションチームの作業に干渉することなく、セキュリティスキャナやログ収集エージェントの更新やバージョン管理を行えます。
• リソースの最適化: 1インスタンスあたり1つのデーモンタスクのみが実行されるため、リソース消費を最小限に抑えつつ、全ワークロードをカバーできます。

これまでとどう変わるのか

#

• これまで: デーモン型のエージェントを実行する場合、ECS の「DAEMON」スケジューリング戦略を使用してサービスを作成していましたが、アプリケーションのデプロイフローと密接に関連していたり、インスタンスの起動タイミングとの厳密な制御が難しい場合がありました。
• これから: Managed Daemons により、エージェントのライフサイクルがアプリケーションから完全に切り離され、インフラ全体の基盤機能としてより確実に、かつ簡単に管理できるようになります。

具体的なユースケース

#

• 全てのコンテナインスタンスでセキュリティ監視エージェントを強制的に実行させ、アプリケーションが起動する前に監視が開始されていることを担保する。
• ログ収集エージェントのバージョンアップを、個別のアプリケーションサービスに影響を与えることなく、クラスター全体に対して一括で実施する。

---

Amazon Lightsail が最大 72 vCPU のコンピュート最適化インスタンスを提供開始

#

投稿日: 2026年04月02日

Announcing compute-optimized instance bundles for Amazon Lightsail - AWS

aws.amazon.com

何ができるようになったのか

#

Amazon Lightsail において、最大 72 vCPU を搭載した「コンピュート最適化インスタンス」の提供が開始されました。7 種類のサイズが用意されており、IPv6 専用およびデュアルスタックのネットワークタイプを選択可能です。WordPress、Amazon Linux、Ubuntu、Windows などの既存のすべてのブループリントをサポートしています。

何が嬉しいのか

#

• 高い CPU パフォーマンス: 専用の CPU リソースが割り当てられるため、バーストを気にすることなく、常にフルパワーの処理能力を必要とする計算集約型のワークロードを実行できます。
• Lightsail の簡便さはそのまま: 複雑な EC2 の設定を必要とせず、事前構成済みのブループリントを使って、高性能なサーバーを数クリックで立ち上げられます。
• 幅広い用途に対応: ビデオエンコーディング、科学的モデリング、ゲームサーバー、CPU 集約型の機械学習推論など、これまで Lightsail ではリソース不足だった用途にも対応可能になります。

これまでとどう変わるのか

#

• これまで: Lightsail は主に小規模な Web サーバーや開発環境向けであり、高い CPU パフォーマンスを継続的に必要とするワークロードには、より複雑な EC2 への移行が必要になることが一般的でした。
• これから: Lightsail の使いやすさを維持したまま、大規模なコンピュートリソースを手軽に利用できるようになります。

具体的なユースケース

#

• 大規模なアクセスを捌くハイパフォーマンスな Web サーバーやアドサーバーの構築。
• 分散分析やバッチ処理など、短時間で大量の CPU 演算が必要なタスクの実行。
• 低レイテンシで高い処理能力が求められる専用のマルチプレイヤーゲームサーバーの運用。

---

Amazon SageMaker Data Agent が日本とオーストラリアでの地理特定インフラをサポート

#

投稿日: 2026年04月01日

Amazon SageMaker Data Agent now supports geo-specific inference for Japan and Australia - AWS

aws.amazon.com

何ができるようになったのか

#

Amazon SageMaker Data Agent において、Amazon Bedrock を介した日本およびオーストラリア向けの「クロスリージョン推論プロファイル」がサポートされました。これにより、東京リージョン（Asia Pacific (Tokyo)）およびシドニーリージョン（Asia Pacific (Sydney)）からの推論リクエストが、それぞれの国内のインフラで処理されるようになります。

何が嬉しいのか

#

• データ主権の遵守: 推論リクエストが自国内の地理的境界内で処理されることが保証されるため、厳しいデータ residency（居住性）要件を持つ組織でも安心して Data Agent を利用できます。
• コンプライアンス対応: 金融、ヘルスケア、公共セクターなど、データの国外転送が制限されている規制の厳しい業界において、AI を活用したデータ探索や分析が容易になります。

これまでとどう変わるのか

#

• これまで: Data Agent の背後で動作する Bedrock モデルの推論リクエストは、場合によっては他のリージョンにルーティングされる可能性があり、厳密な国内処理を求める要件への対応が課題となることがありました。
• これから: 日本国内（東京）またはオーストラリア国内（シドニー）の推論プロファイル（JP-CRIS / AU-CRIS）を指定することで、AWS グローバルネットワークを通じつつも、地理的な制限を維持したまま AI 機能を利用できます。

具体的なユースケース

#

• 日本国内の金融機関が、顧客データを扱うノートブック内で Data Agent を使用し、安全に SQL コード生成やデータ分析を行う。
• 公共機関において、機密性の高いデータのトラブルシューティングを Data Agent の対話型インターフェースを通じて自国内で完結させる。

---

Amazon Bedrock が AWS GovCloud (米国) リージョンで構造化出力をサポート

#

投稿日: 2026年04月01日

Amazon Bedrock now supports structured outputs to AWS GovCloud (US) Regions - AWS

aws.amazon.com

何ができるようになったのか

#

Amazon Bedrock の「構造化出力（Structured Outputs）」機能が、AWS GovCloud (米国) リージョンでも利用可能になりました。これにより、基盤モデルが JSON スキーマに準拠した一貫性のある、機械可読な形式で回答を返すことが保証されます。

何が嬉しいのか

#

• 信頼性の向上: モデルの回答が指定したスキーマに厳密に従うため、後続のシステムや API 連携においてパースエラーが発生するリスクを大幅に軽減できます。
• 運用負荷の軽減: カスタムのバリデーションロジックや、フォーマットエラーによるリトライ処理を減らすことができ、開発効率とアプリケーションの堅牢性が向上します。
• 高度なコンプライアンス: 厳格なセキュリティとデータ処理要件が求められる政府機関や規制業界のワークロードにおいても、予測可能な出力形式を活用した AI アプリケーションの構築が可能になります。

これまでとどう変わるのか

#

• これまで: GovCloud 上で Bedrock を利用する場合、モデルの出力形式を制御するためにプロンプトエンジニアリングに頼る必要があり、稀に発生する形式の揺らぎがシステム連携の障害になることがありました。
• これから: JSON スキーマや厳密なツール定義を用いることで、モデルが必ず指定通りの構造で回答を返すように制御でき、安定した運用が可能になります。

具体的なユースケース

#

• 政府機関のドキュメントから特定のフィールド（日付、金額、担当者など）を抽出し、データベースに直接保存するワークフロー。
• 厳格な API スキーマに従ったツール実行（Function Calling）を、GovCloud 上のセキュアな環境で自動化する。

---

Amazon CloudWatch が CloudFront ログなどの自動有効化をサポート

#

投稿日: 2026年04月02日

Amazon CloudWatch expands auto-enablement to Amazon CloudFront logs and 3 additional resource types - AWS

aws.amazon.com

何ができるようになったのか

#

Amazon CloudWatch において、Amazon CloudFront の標準アクセスログ、AWS Security Hub の CSPM 検出ログ、および Amazon Bedrock AgentCore のメモリとゲートウェイのログとトレースの「自動有効化（auto-enablement）」がサポートされました。有効化ルールを設定することで、既存および新規作成されるリソースに対して、手動設定なしで自動的にテレメトリ収集を開始できます。

何が嬉しいのか

#

• 一貫したモニタリングの保証: 新しいリソースが作成されるたびに手動で設定する必要がなくなり、監視の漏れを防げます。
• 標準化の容易さ: 組織全体、特定のカウント、またはタグベースのリソースに対してルールを適用できるため、セキュリティチームなどが一元的にログ収集の標準を強制できます。
• 運用負荷の軽減: 大規模な環境において、多数のリソースに対するテレメトリ設定の管理が大幅に簡素化されます。

これまでとどう変わるのか

#

• これまで: CloudFront や Security Hub などのログを CloudWatch Logs に送信するには、リソースごとに個別に設定を行う必要があり、設定の自動化にはカスタムスクリプトや AWS Config 等の組み合わせが必要でした。
• これから: CloudWatch のコンソールや API から有効化ルールを定義するだけで、対象リソースのテレメトリ収集が自動的に構成されます。

具体的なユースケース

#

• セキュリティチームが、組織内の全アカウントで作成されるすべての CloudFront ディストリビューションのアクセスログを、自動的に中央の CloudWatch Logs に集約する。
• Bedrock エージェントを使用する開発チームが、個々のエージェント設定を意識することなく、トレース情報を常に収集可能な状態にする。

---

Amazon CloudWatch が EKS 向け「OTel Container Insights」をリリース（プレビュー）

#

投稿日: 2026年04月02日

Amazon CloudWatch launches OTel Container Insights for Amazon EKS (Preview) - AWS

aws.amazon.com

何ができるようになったのか

#

Amazon CloudWatch において、OpenTelemetry (OTel) を活用した Amazon EKS 向け「Container Insights」がパブリックプレビューとして提供開始されました。従来の Container Insights の機能をベースに、OpenTelemetry Protocol (OTLP) を使用してより詳細なメトリクスを収集し、Kubernetes メタデータやカスタムラベルを含む最大 150 個の記述的ラベルを自動的に付与します。

何が嬉しいのか

#

• 深い可視性: オープンソースおよび AWS コレクターから収集された豊富なメトリクスにより、クラスター、ノード、ポッドの状態をより多角的に把握できます。
• 柔軟な分析: 収集されたメトリクスは、インスタンスタイプや AZ、チーム名などのカスタムラベルでフィルタリング・集計が可能です。また、PromQL を用いた高度なクエリも実行できます。
• ハードウェアの自動検出: NVIDIA GPU、EFA、AWS Trainium、Inferentia などの高速化コンピューティングハードウェアを自動的に検出し、モニタリング対象に含めます。

これまでとどう変わるのか

#

• これまで: EKS の Container Insights は、主に専用のエージェント（CloudWatch Agent や Fluent Bit）を通じて収集された特定のメトリクスセットに依存していました。
• これから: OTel の標準プロトコルと豊富なラベル付けにより、より標準的かつ柔軟なモニタリング環境が、EKS Add-on を通じてワンクリックで導入可能になります。

具体的なユースケース

#

• 開発チームやビジネスユニットごとのカスタムラベルを使用して、複雑な EKS 環境のリソース使用状況を細かく分析する。
• GPU や専用アクセラレータを使用する AI/ML ワークロードの稼働状況を、特別な設定なしで Container Insights ダッシュボードから監視する。

---

Amazon ElastiCache Serverless が IPv6 およびデュアルスタック接続をサポート

#

投稿日: 2026年04月02日

Amazon ElastiCache Serverless now supports IPv6 and dual stack connectivity - AWS

aws.amazon.com

何ができるようになったのか

#

Amazon ElastiCache Serverless において、従来の IPv4 に加え、IPv6 およびデュアルスタック（IPv4 と IPv6 の同時利用）接続がサポートされました。キャッシュ作成時に、ネットワークタイプとして IPv4、IPv6、またはデュアルスタックから選択できるようになります。

何が嬉しいのか

#

• IPv6 移行の柔軟性: デュアルスタック接続を利用することで、既存の IPv4 アプリケーションとの互換性を維持しながら、段階的に IPv6 への移行を進めることができます。
• IPv4 アドレスの節約: IPv6 専用サブネットを利用可能になるため、枯渇が課題となる IPv4 アドレスを消費せずにキャッシュリソースを構築できます。
• コンプライアンス対応: 組織や規制によって求められる IPv6 採用の要件を満たすことができます。

これまでとどう変わるのか

#

• これまで: ElastiCache Serverless は IPv4 接続のみに対応しており、IPv6 環境からの接続や IPv6 専用サブネットでの利用には制限がありました。
• これから: ネットワーク構成の選択肢が広がり、最新の IPv6 ベースのインフラ構成に Serverless キャッシュをシームレスに統合できるようになります。

具体的なユースケース

#

• IPv6 専用の VPC サブネットで動作するマイクロサービスから、ElastiCache Serverless に低レイテンシで接続する。
• 段階的なインフラの IPv6 化プロジェクトにおいて、デュアルスタック接続を利用してダウンタイムなしで接続方式を切り替える。

---

Research and Engineering Studio on AWS (RES) 2026.03 がリリース

#

投稿日: 2026年03月26日

Research and Engineering Studio on AWS 2026.03 is now available - AWS

aws.amazon.com

何ができるようになったのか

#

AWS 上でセキュアな研究・開発環境を管理するためのオープンソースポータル「Research and Engineering Studio (RES)」の最新版 2026.03 がリリースされました。このアップデートでは、管理制御の強化、ファイルシステムのサポート拡大、セッション管理の改善が行われています。

主な変更点：

• FSx for ONTAP の柔軟な統合: 複数の FSx for ONTAP ボリュームを個別に RES ファイルシステムとしてオンボード可能になりました。
• DCV トークンの有効期限設定: セッションファイルの有効期間を長く設定できるようになり、長時間の作業に対応しました。
• ログインページのカスタマイズ: アカウント管理やヘルプドキュメントへのリンクを最大3つまで追加可能になりました。
• 仮想デスクトップ（VDI）の運用改善: 管理者がエラー状態の VDI を「Sessions」ページから直接再起動できるようになりました。

何が嬉しいのか

#

• 管理の柔軟性: ストレージ構成やポータルのカスタマイズ性が向上し、組織固有の要件に合わせやすくなりました。
• ユーザー体験の向上: VDI のトラブルシューティングが迅速化され、ユーザーはワンクリックでセッションスケジュールをデフォルトに戻せるなど、利便性が高まっています。

これまでとどう変わるのか

#

• これまで: FSx for ONTAP の追加や VDI のエラー対応において、管理者の操作に制約があったり、ユーザーの手間がかかる場面がありました。
• これから: より細かな制御と、ポータル上でのダイレクトな操作により、研究開発環境の運用負担が軽減されます。

具体的なユースケース

#

• 大規模な解析データを保持する複数の FSx for ONTAP ボリュームを、研究者グループごとに切り分けて RES に提供する。
• 組織独自の利用規約やマニュアルへのリンクをログインページに配置し、ガバナンスを強化する。
• 接続エラーが発生した研究者の VDI セッションを、管理者が即座にリセットして業務を再開させる。

---

Amazon WorkSpaces Applications がマルチセッションフリートの「ドレインモード」をサポート

#

投稿日: 2026年04月02日

Amazon WorkSpaces Applications improves multi-session fleet management - AWS

aws.amazon.com

何ができるようになったのか

#

Amazon WorkSpaces Applications のマルチセッションフリートにおいて、「ドレインモード（drain mode）」が利用可能になりました。このモードを有効にすると、対象のインスタンスは新規のユーザーセッションを受け付けなくなりますが、接続中の既存セッションは中断されることなく継続できます。

何が嬉しいのか

#

• ユーザー体験の維持: メンテナンスやパッチ適用、スケールダウンを行う際、作業中のユーザーを強制終了させることなく、インスタンスを段階的に空にすることができます。
• 運用の円滑化: 新規の接続は自動的に他の利用可能なインスタンスに誘導されるため、システムの安定性を保ちながら管理作業を進められます。
• コスト最適化: 低コストなマルチセッション環境の利点を活かしつつ、リソースの整理や更新をシームレスに実施できます。

これまでとどう変わるのか

#

• これまで: インスタンスのメンテナンスや削除を行う際、アクティブなユーザーセッションを考慮しながら手動で調整するか、あるいはセッションを強制的に切断する必要があり、ユーザー業務への影響が避けられない場合がありました。
• これから: ドレインモードにより、既存ユーザーの作業完了を待ちつつ、新規流入を止めるという洗練されたフリート管理が可能になります。

具体的なユースケース

#

• セキュリティパッチ適用のためにインスタンスを入れ替える際、ドレインモードを設定して徐々にユーザーを新しいインスタンスへ移行させる。
• 業務時間終了後にフリートを縮小（スケールダウン）する際、作業が残っているユーザーを阻害せずに不要なインスタンスを特定し、空になったものから削除する。

---

AWS Deadline Cloud がキューごとのジョブスケジューリングモード設定をサポート

#

投稿日: 2026年04月02日

AWS Deadline Cloud now supports configurable job scheduling modes for queues - AWS

aws.deadline.cloud

何ができるようになったのか

#

2D/3D グラフィックスのレンダリング管理サービス「AWS Deadline Cloud」において、ジョブスケジューリングモードをキューごとに設定できるようになりました。以下の3つのモードから選択可能です。

• Priority FIFO (デフォルト): 優先度が高く、提出時間が早いジョブから順にワーカーを割り当てる。
• Priority Balanced: 同じ優先度レベル内のすべてのジョブに対して、ワーカーを均等に分配する。
• Weighted Balanced: 優先度、エラー数、提出時間、タスク数などのパラメータに基づいて重み付けを行い、ワーカーを分配する。

何が嬉しいのか

#

• 迅速なフィードバック: 「Priority Balanced」や「Weighted Balanced」を選択することで、先行する大きなジョブの完了を待たずに、新しく提出したジョブのレンダリング結果（の一部）をすぐに確認できるようになります。
• リソース配分の最適化: 複数のアーティストやプロジェクトが同じキューを共有している場合、リソースを独占されることなく、公平にレンダリングを進めることができます。

これまでとどう変わるのか

#

• これまで: 常に「Priority FIFO」が適用されていたため、優先度が同じ大規模なジョブが先に提出されていると、後から提出された小さなジョブの処理が開始されるまで長時間待たされることがありました。
• これから: アーティストの好みに応じてスケジューリング挙動を調整でき、イテレーション（試行錯誤）のサイクルを高速化できます。

具体的なユースケース

#

• 映画の最終レンダリング（大規模ジョブ）が走っている最中に、カットの微調整を確認したいアーティストが、同じキューに小規模なテストレンダリングを投げ、即座に結果を確認する。
• 複数のエラーが発生しているジョブの優先度を「Weighted Balanced」で自動的に下げ、健全なジョブの進行を優先させる。

---

ニュージーランド・オークランドで AWS Direct Connect 100Gbps 専用接続の提供を開始

#

投稿日: 2026年04月02日

AWS Direct Connect announces 100G expansion in Auckland, New Zealand - AWS

aws.amazon.com

何ができるようになったのか

#

ニュージーランドのオークランドにある Datacom Orbit DH6 データセンターの AWS Direct Connect ロケーションにおいて、100Gbps 専用接続の提供が開始されました。これにより、中国を除くすべてのパブリック AWS リージョン、AWS GovCloud リージョン、および AWS Local Zones へのプライベートな直接ネットワークアクセスが可能になります。

何が嬉しいのか

#

• 超高速・低遅延: 100Gbps という広帯域により、大規模なデータ転送やリアルタイム性の高いアプリケーションにおいて、より一貫性のあるネットワーク体験が得られます。
• 高度なセキュリティ: MACsec 暗号化機能に対応しており、物理的なレイヤーでのデータ保護が可能です。
• ニュージーランド国内での選択肢拡大: ニュージーランド国内で 100Gbps 接続と MACsec に対応した 2 番目の Direct Connect ロケーションとなります。

これまでとどう変わるのか

#

• これまで: オークランド近郊の当該ロケーションではより低速な接続オプションが中心でしたが、今回の大容量化により、急増するデータトラフィックやハイブリッドクラウド需要に余裕を持って対応できるようになります。
• これから: 現地の企業や組織は、パブリックインターネットを介さない、極めて高速かつセキュアな専用回線を自国国内から直接利用できるようになります。

具体的なユースケース

#

• 大容量のメディア資産やゲノムデータなどを, オンプレミス環境から AWS リージョンへ高速に同期・転送する。
• 規制の厳しい業界において、MACsec による暗号化を施した 100Gbps 回線を用いて、機密性の高いワークロードをクラウドへ延伸する。

---

Amazon SES Mail Manager が TLS/mTLS 認証や Lambda 連携などの新機能を追加

#

投稿日: 2026年04月01日

Amazon SES Mail Manager adds new features for enhanced security and email processing - AWS

aws.amazon.com

何ができるようになったのか

#

Amazon SES Mail Manager において、セキュリティ強化とメール処理の柔軟性を高める以下の新機能が導入されました。

• Ingress Endpoint でのオプション TLS および mTLS サポート: STARTTLS をオプションとして設定可能になり、証明書ベースの相互 TLS (mTLS) 認証にも対応しました。
• 新しいルールアクション「Invoke Lambda function」: ルールセットから直接 AWS Lambda 関数を呼び出し、カスタムのメール処理ワークフローを実行可能になりました。
• 新しいルールアクション「Bounce」: 送信元サーバーに対して RFC 準拠の SMTP 応答（バウンス）を返せるようになりました。

何が嬉しいのか

#

• レガシーシステムとの互換性: STARTTLS をサポートしていない古いシステムからの接続を維持しつつ、モダンなセキュリティ制御を導入できます。
• 高度なセキュリティ: mTLS により、証明書を用いたより厳格な認証をメールの受信エンドポイントで実現できます。
• カスタム処理の簡素化: Lambda との直接連携により、受信したメールの内容に基づいた独自のフィルタリングやデータ抽出、外部システム連携を容易に構築できます。

これまでとどう変わるのか

#

• これまで: SES Mail Manager で高度なカスタム処理を行うには、一度 S3 に保存してから別のトリガーで処理するなどの構成が必要でした。また、接続時の認証オプションも限定的でした。
• これから: 受信パイプラインの中で直接 Lambda を実行したり、特定の条件で即座にバウンスを返したりできるようになり、メールインフラの管理効率が向上します。

具体的なユースケース

#

• 特定のドメインからのメール受信時にのみ Lambda を起動し、添付ファイルを自動的に解析して業務システムに登録する。
• 認証済みの特定のサーバーからの接続のみを mTLS で許可し、内部ネットワークのリレーサーバーとして利用する。
• 条件に合致しない不要なメールに対して、即座に SMTP バウンス応答を返して処理を拒否する。

Reply by Email