AWS What's New Digest

Appearance

2026年04月02日 ​

[Simple Email Service] Amazon SES Mail Manager adds new features for enhanced security and email processing ​

概要 ​

Amazon SES Mail Managerが受信処理とセキュリティを強化する新機能を追加しました。Ingress EndpointでのオプションTLS（STARTTLS）と相互TLS（mTLS）サポート、およびRule ActionにLambda呼び出しとBounceを追加しています。

変更内容・新機能の詳細 ​

主な変更点は以下の通りです。

  • Ingress EndpointでのオプションTLS（STARTTLS）: STARTTLSを「オプション」として設定可能になり、STARTTLS未対応の旧来システムからの接続を許容しつつ、対応システムではTLSでの接続を利用できます。これにより、既存のメールインフラからの移行時の互換性が向上します。

  • Ingress Endpointでの相互TLS（mTLS）サポート: クライアント証明書による認証を利用できるようになり、証明書ベースの強固な認証と接続元の識別が可能です。mTLSを利用することで送信元のなりすまし防止や接続ポリシーの強化が図れます。

  • ルールアクション: Invoke Lambda function: ルールセットから直接AWS Lambda関数を呼び出せるようになりました。メール受信時に本文やヘッダー等を含むイベントをLambdaに渡して、カスタム処理（コンテンツ解析、フィルタリング、転送、保存、外部API連携など）を行えます。これにより中間の処理パイプラインをシンプルに構築できます。

  • ルールアクション: Bounce: 受信時にRFC準拠のSMTP応答で送信サーバへバウンスを返すことが可能になりました。取り込み前に即時拒否/バウンスを返すことで不要な処理コストを削減し、送信側へ適切な配信エラー情報を伝えられます。

対応リージョン: これらの機能はAmazon SES Mail Manager提供リージョンのほとんどで利用可能ですが、Middle East (UAE) と Middle East (Bahrain) では未提供です。

影響範囲・利用シーン ​

  • 対象ユーザー: メール配信運用者、SRE/運用チーム、メールインフラを移行/統合するクラウドエンジニア
  • 利用シーン: 旧来システムからのMail Manager移行時の互換性確保（STARTTLS未対応クライアントの受け入れ）
  • 利用シーン: 高セキュリティ環境でのクライアント認証（mTLS）による送信元認証強化
  • 利用シーン: 受信メールのカスタム処理（Lambdaを使った解析、分類、保存、外部連携）をルール内で完結させるワークフロー
  • 運用効果: 事前にRFC準拠のSMTPバウンスを返すことで不要な処理を削減し、配信エラーの明示化や配信品質管理が容易になる
  • 移行効果: STARTTLSをオプション化することで段階的な移行が可能になり、ダウンタイムや互換性問題を低減

技術的な注意点 ​

  • IAM権限: Mail ManagerからLambdaを呼び出す場合は、Lambdaのリソースポリシーや実行ロールでSES（またはMail Manager）からのInvokeを許可する必要があります。Lambda側で外部リソースにアクセスする場合は追加の権限が必要です。
  • リージョン制限: ほとんどのSES Mail Manager提供リージョンで利用可能ですが、Middle East (UAE) と Middle East (Bahrain) では未対応です。導入前に利用リージョンを確認してください。
  • 証明書管理: mTLSを利用する場合はクライアント証明書の発行・管理・失効手続きが必要です。証明書のライフサイクル管理や信頼チェーンの運用設計を行ってください。
  • セキュリティ: STARTTLSを「オプション」にすると暗号化が強制されなくなるため、可能な限りTLS必須かつmTLSを併用することを推奨します。オプション設定は互換性のための一時措置と考えてください。
  • コスト: Lambda呼び出しや追加の処理に伴うLambda実行時間・呼び出し回数、ログ保存などの追加費用が発生します。バウンスで処理を減らせる一方、ルールの実行内容によりコストが変動します。
  • 運用/テスト: 新しいルールアクションやTLS設定を有効化する前にステージング環境で受信フローの動作確認（メール本文/ヘッダーの渡し方、エラー時の挙動、バウンス応答内容）を行ってください。

参考情報 ​

[ECS] Amazon ECS announces Managed Daemons for ECS Managed Instances ​

概要 ​

Amazon ECSがManaged Daemons for ECS Managed Instancesを発表しました。これにより、セキュリティ・オブザーバビリティ・ネットワーキングなどのエージェントをアプリケーションデプロイと独立してクラスタ上のManaged Instancesに一元的に配置・管理できます。

変更内容・新機能の詳細 ​

Managed Daemonsは、ECSのManaged Instances向けに「インスタンス単位で正確に1つだけ」起動されるデーモンタスクを提供します。クラスタで1つ以上のManaged Instances用のキャパシティプロバイダーに対してデーモンを作成すると、ECSは各インスタンスに対してデーモンタスクを1つずつ配置し、アプリケーションタスクを配置する前にデーモンが稼働していることを保証します。これによりログ収集、トレース、メトリクス収集、セキュリティエージェント、ネットワークエージェント等の横断的機能を確実に提供できます。デーモンはインスタンスのライフサイクルに結び付いた独立プロセスとしてオーケストレーションされ、プラットフォーム管理者がアプリケーションチームと独立して管理できます。デーモンの更新時には、ECSが既存インスタンスをドレインして更新済みデーモンを持つ新しいインスタンスをプロビジョニングし、サービスタスクの置換はサーキットブレーカーやロールバック機能を含めて自動的に行われ、全ワークロードでのカバレッジを維持します。利用開始はAWS Console、CLI、CloudFormation、SDKで行え、デーモンタスク定義にコンテナイメージ等を指定してデーモンを登録します。本機能はすべてのAWSリージョンで利用可能で、追加料金はなくデーモンが消費する通常のコンピュートリソース分だけ課金されます。

影響範囲・利用シーン ​

  • 対象ユーザー: プラットフォーム/クラウド基盤管理者、SRE、セキュリティ/オブザーバビリティチーム
  • 利用シーン: ログ集約・トレース・メトリクス収集やセキュリティエージェント、ネットワークプロキシなどクロスカッティング機能を必ず全インスタンスに展開したい場合
  • 運用効果: エージェントのライフサイクルをアプリケーションから切り離して管理できるため、デプロイとバージョンアップの簡素化、インスタンス単位での確実なカバレッジ、リソース利用効率の向上（一インスタンスあたり1タスク）
  • 可用性への影響: デーモンの更新はインスタンスドレインと置換を伴うため、更新計画策定が必要だが、ECSのサーキットブレーカー/ロールバックでサービス継続性を高められる
  • コスト影響: 追加料金は発生しないが、デーモンタスクが消費するCPU/RAM分の標準的なコンピュートコストは発生する

技術的な注意点 ​

  • IAM権限: ecs:RegisterTaskDefinition、ecs:CreateService/カスタムCreateDaemon相当操作、ecs:UpdateCluster、autoscaling/EC2管理や関連リソースに対する権限が必要（具体的な最小権限は導入前にポリシーを確認してください）
  • リージョン制限: 発表では「全AWSリージョンで利用可能」と明記されていますが、導入前にターゲットリージョンでのドキュメント確認を推奨します
  • 互換性: 対象はECS Managed Instances（Managed Instancesキャパシティプロバイダー）向けの機能です。Fargateや外部インスタンス（external）には適用されません
  • リソース割当: デーモンタスクは通常のタスクと同様にCPU/メモリを消費します。アプリケーションのリソース競合を避けるためにタスク定義で適切にリソースを予約・制限してください
  • 更新時の挙動: デーモンのバージョン更新は既存インスタンスのドレインと新規インスタンス投入で行われ、サービスタスクの置換が発生します。ローリング更新戦略や可用性ウィンドウを考慮した実行計画を作成してください
  • コスト: 機能自体に追加料金はありませんが、増加するインスタンス数やデーモンタスクのリソース消費により総コストは増加する可能性があります
  • 監視/ロギング: デーモンタスクの健全性やリソース使用状況を適切に監視するためのメトリクス/ログ収集を事前に設計してください

参考情報 ​

[General] Amazon SageMaker Data Agent now supports geo-specific inference for Japan and Australia ​

概要 ​

Amazon SageMaker Data Agentが日本（東京）とオーストラリア（シドニー）向けのジオ特化型推論（JP-CRIS、AU-CRIS）をAmazon Bedrock経由でサポートします。これにより、該当リージョンのData Agentからの推論要求は各国の地理内で処理され、データ主権要件に対応できます。

変更内容・新機能の詳細 ​

今回の更新では、SageMaker Data AgentがAmazon Bedrockのクロスリージョン推論プロファイル（JP-CRIS, AU-CRIS）を利用して、日本（ap-northeast-1/東京）およびオーストラリア（ap-southeast-2/シドニー）内で推論リクエストを完結させることが可能になりました。Data AgentはSageMaker Unified StudioのNotebookおよびQuery Editor内で、会話形式によるデータ探索、Python/SQLコード生成、トラブルシューティング、解析支援を行います。JP-CRIS/AU-CRISを有効にすると、推論トラフィックはAWS Global Network経由で各国の設定された地理範囲内にルーティングされ、国外への推論処理やパブリックインターネット経由のデータ転送を回避します。金融、医療、パブリックセクターなどデータ所在制約が厳しい業界でも、Data Agentの機能をフルに利用しつつデータレジデンシー要件に対応できます。利用開始は、対応リージョンでSageMaker Unified Studioのプロジェクトを開き、NotebookまたはQuery EditorでData Agentを使用するだけです（詳細はUser Guide参照）。

影響範囲・利用シーン ​

  • 対象ユーザー: SageMakerでのデータ探索・分析や自動コード生成を行うデータサイエンティスト、MLエンジニア、SRE/運用チーム
  • 利用シーン: 機密データを扱うNotebookやQuery Editorからの対話的なデータ探索・モデル推論、規制対応が必要な分析ワークフロー
  • 運用効果: 推論トラフィックが国内（または指定地理）内で完結するため、データ主権・コンプライアンス要件を満たしつつ遅延の低減とセキュリティ向上が期待できる
  • 規制対応: 金融・医療・公共部門などでデータレジデンシー要件を満たす助けとなる

技術的な注意点 ​

  • IAM権限: SageMakerおよびBedrockへの呼び出し権限（およびData Agent関連の役割やポリシー）を事前に確認・付与してください
  • リージョン制限: ジオ特化推論は現時点でアジアパシフィック（東京）およびアジアパシフィック（シドニー）向けに提供されています。その他リージョンでは同等の動作が利用できない可能性があります
  • コスト: Data Agentの利用自体に加え、Amazon Bedrockのモデル推論料金や関連するAPIコール料が発生します。推論回数やモデル種別に応じたコスト見積もりを事前に行ってください
  • ネットワーク/データ転送: 推論はAWS Global Network上でジオ内にルーティングされますが、内部的なインフラやクロスAZ/クロスリージョンの設計によりデータ転送費用や遅延特性が変わる可能性があります。重要なコンプライアンス要件は社内の法務/セキュリティチームと確認してください
  • 依存サービス/互換性: Data AgentはAmazon Bedrockを利用する構成です。Bedrockでサポートされるモデル・エンドポイントポリシーに依存します。既存のワークフローとの統合時は互換性を確認してください

参考情報 ​

[Govcloud Us] AWS VPC Encryption Controls now available in AWS GovCloud (US) Regions ​

概要 ​

AWS VPC Encryption ControlsがAWS GovCloud (US-East, US-West) リージョンで利用可能になりました。VPC内およびVPC間の転送トラフィックについて可視化・監査・強制的なハードウェアベースの暗号化（AES-256）を簡単に有効化できます。

変更内容・新機能の詳細 ​

VPC Encryption Controlsは既存のVPCに対して有効化することで、トラフィックフローの暗号化状況を監視し、プレーンテキスト通信を許しているリソースを検出できます。また、AWS Fargate、Network Load Balancer、Application Load Balancer、最新のEC2 Nitroインスタンスなど複数のVPCリソース間のネットワーク経路に対して自動かつ透過的にハードウェアベースのAES-256暗号化を有効にし、暗号化を強制します。加えて、VPCピアリング、Transit Gatewayピアリング、AWS Cloud WANを用いたリージョン間トラフィックにも追加レイヤの透過的な暗号化が適用されます。これにより、アプリケーション層の暗号化と組み合わせてHIPAA、PCI DSS、FedRAMP、FIPS 140-2など厳格なコンプライアンス要件への準拠を支援します。管理者は中央で機能をオンにして、監査ログを生成・活用することでコンプライアンス報告や運用管理を容易に行えます。

影響範囲・利用シーン ​

  • 対象ユーザー: 政府機関・規制対象組織のセキュリティ/コンプライアンス担当者、クラウドネットワーク/インフラエンジニア
  • 利用シーン: VPC内／VPC間トラフィックの暗号化状況の監査、既存環境への暗号化強制、コンプライアンス証跡の生成
  • 運用効果: プレーンテキスト通信の早期検出と自動暗号化により、監査対応工数削減と暗号化ポリシーの一貫性向上が期待できる

技術的な注意点 ​

  • IAM権限: 機能の有効化・設定にはVPC関連やセキュリティ管理のIAM権限が必要です。事前に必要なAPIアクション・権限を確認してください。
  • リージョン制限: 本リリースはAWS GovCloud (US-East) および AWS GovCloud (US-West) に対応しています。一般リージョンの可用性は別途確認してください。
  • コスト: 記載のない追加料金が発生する可能性があります。利用前に料金ドキュメントを確認してください。
  • 互換性/制約: ハードウェアベースのAES-256暗号化は対象となるリソース（例: NitroベースのEC2、Fargate、NLB、ALBなど）に対して透過的に適用されますが、全ての古いインスタンスやサードパーティネットワーク機能が対象とは限りません。事前に環境でのサポート状況を確認してください。
  • 監査ログ/証跡: 機能は監査ログを生成しますが、ログの保存先・フォーマット（CloudWatch Logs / CloudTrail 等）や保持ポリシーは運用者が設定・確認する必要があります。
  • 暗号化の補完関係: VPCレベルの透過的暗号化は通信路の保護を強化しますが、アプリケーション層のエンドツーエンド暗号化（TLS等）を置き換えるものではありません。規格要件（FIPS等）の適合性については、組織側で最終確認してください。

参考情報 ​

[CloudFront] Amazon CloudFront now supports SHA-256 for signed URLs and signed cookies ​

概要 ​

Amazon CloudFrontが署名付きURLおよび署名付きCookieの生成にSHA-256ハッシュをサポートしました。従来のSHA-1に代わり強化された署名アルゴリズムを選択できます。

変更内容・新機能の詳細 ​

CloudFrontは署名付きURLおよび署名付きCookieを生成する際に、Hash-Algorithm=SHA256（URLの場合）またはCloudFront-Hash-Algorithm=SHA256（Cookie属性の場合）を指定することでSHA-256を使用した署名を行えるようになりました。既存の署名でハッシュアルゴリズムを明示しないものは引き続きSHA-1を使用するため後方互換性があります。SHA-256の採用により衝突検出性が向上し、SHA-256を必須とするセキュリティ／コンプライアンス要件への対応が容易になります。本機能はすべてのCloudFrontエッジロケーションで利用可能で、使用に伴う追加料金は発生しません。開発側では、署名生成ロジックやライブラリを更新してHash-Algorithmクエリパラメータ／Cookie属性を付与し、SHA-256ハッシュ（およびそれに対応する署名処理）で署名を生成する必要があります。なお、署名方式（鍵の種類やサイズ）に関する要件は従来の安全慣行に従っており、例えばRSAを用いる場合は2048ビット以上の鍵長を推奨します。

影響範囲・利用シーン ​

  • 対象ユーザー: CloudFrontでプライベートコンテンツを配信している開発者、SRE、セキュリティ/コンプライアンス担当者
  • 利用シーンまたは効果: 法規制や社内規程でSHA-256以上のハッシュを要求するケース、署名の強度を上げてコンテンツアクセス制御の安全性を高めたい場合
  • 運用効果: 署名の強化により改ざんや衝突攻撃に対する耐性が向上し、監査・コンプライアンス対応が容易になる
  • 互換性影響: 既存の署名を明示的に変更しない限り挙動は変わらず後方互換（指定がなければSHA-1を継続使用）

技術的な注意点 ​

  • IAM権限: 署名を生成する際に使用するプライベートキーやKMSを利用する場合は、該当キーへのアクセス権限（IAMポリシー）が必要です
  • リージョン制限: すべてのCloudFrontエッジロケーションで利用可能（リージョン制限なし）
  • コスト: SHA-256署名の利用に追加料金は発生しません
  • 実装上の注意: 署名付きURLではHash-Algorithm=SHA256クエリパラメータ、署名付きCookieではCloudFront-Hash-Algorithm=SHA256属性を明示的に追加する必要があります。独自実装やサードパーティライブラリを使用している場合は署名生成コードを更新してください
  • 互換性/移行: 指定がない既存のURL/CookieはSHA-1を使い続けるため段階的移行が可能です。SHA-256へ移行する際はクライアントや配信コードの検証を行ってください
  • 暗号設定の推奨: SHA-256に合わせて公開鍵署名（例: RSA）を使う場合は鍵長を2048ビット以上にするなど、現在のベストプラクティスに従ってください

参考情報 ​

[RDS] Amazon RDS for Oracle now supports cross-account snapshot sharing with additional storage volumes ​

概要 ​

Amazon RDS for Oracleは、追加ストレージボリュームを持つDBインスタンスのスナップショットをAWSアカウント間で共有できるようになりました。これにより、最大256 TiBまで拡張したストレージ構成を保ったままスナップショットの共有・コピー・復元が可能になります。

変更内容・新機能の詳細 ​

追加ストレージボリューム機能は、プライマリボリュームに加えて最大3つの追加ボリューム（各最大64 TiB）を割り当てすることで、データベースストレージを最大256 TiBまで拡張できます。本リリースにより、こうした追加ストレージを持つRDS for Oracleのデータベーススナップショットを別AWSアカウントへ共有（cross-account snapshot sharing）できるようになりました。共有されたスナップショットは、ターゲットアカウント内の許可されたユーザーにより別のDBインスタンスへ復元したり、同一または別リージョンへコピーしたり、別のIAM権限下で独立したバックアップとして保存できます。重要な点として、スナップショットは元のインスタンスのストレージレイアウト（追加ボリュームの構成を含む）を保持しており、復元時もその構成が再現されます。本機能はすべてのAWS商用リージョンで利用可能で、AWS Management Console、AWS CLI、AWS SDKから利用できます。関連操作としては ModifyDBSnapshotAttribute（共有設定）、CopyDBSnapshot（コピー）、RestoreDBInstanceFromDBSnapshot（復元）等のAPI/CLI操作が該当します。

影響範囲・利用シーン ​

  • 対象ユーザー: DB管理者、データベースエンジニア、SRE/運用チーム、セキュリティ・コンプライアンス担当者
  • 利用シーン: コンプライアンスに応じた隔離されたバックアップ環境の構築、運用障害の切り分けのため本番スナップショットを別アカウントへ復元して検証、クロスアカウントでの災害対策・バックアップ運用
  • 運用効果: ストレージ構成（追加ボリューム）を保持したまま安全にアカウント間でスナップショットを受け渡せるため、分離された検証環境での問題解析やコンプライアンス要件を満たすバックアップ分離が容易になる

技術的な注意点 ​

  • IAM権限: スナップショット共有にはソース側でModifyDBSnapshotAttribute等の権限が必要。ターゲット側で復元やコピーを行うにはrds:RestoreDBInstanceFromDBSnapshotやrds:CopyDBSnapshot等の権限が必要です。
  • 暗号化/KMS: 暗号化スナップショットをクロスアカウントで扱う場合はKMS CMKのキー政策やキーの共同使用（鍵ポリシー／グラント）を正しく設定する必要があります。暗号化スナップショットはそのままでは直接共有できないため、キー共有またはコピー時に新しいCMKで再暗号化する運用が必要です。
  • スナップショットの種類: 自動スナップショット（自動バックアップ）では直接共有できないため、共有対象は通常は手動で作成したDBスナップショット（manual snapshot）になります。必要に応じて手動スナップショットを作成してください。
  • リージョン制限: 本機能は全てのAWS商用リージョンで利用可能と発表されていますが、リージョン間でのコピーはCopyDBSnapshotの利用やリージョン指定が必要です。
  • コスト: スナップショットのコピーやターゲットアカウントでの保存は保存容量に対する料金が発生します。復元するとDBインスタンスの稼働コスト（インスタンスタイプ・ストレージ課金等）が発生します。
  • 運用上の留意点: 共有されたスナップショットは元のストレージレイアウト（追加ボリューム構成）を保持しますが、ターゲットで復元する際に利用可能なインスタンスタイプやストレージ上限を満たしていることを確認してください。特に大容量構成（数十TiB〜100TiB超）ではリソース要件を事前検証すること。
  • CLI/API例: スナップショット共有は aws rds modify-db-snapshot-attribute --db-snapshot-identifier <id> --attribute-name restore --values-to-add <target-account-id>、コピーは aws rds copy-db-snapshot --source-db-snapshot-identifier <arn> --target-db-snapshot-identifier <new-id> --source-region <region> 等を使用します。

参考情報 ​

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

Copyright © 2026