本日の主なトピック #
- Smithy-Java フレームワークの GA: 仮想スレッドを活用したタイプセーフな Java SDK 生成が可能になりました。
- Amazon S3 のセキュリティベストプラクティス: 新規バケットで SSE-C がデフォルトで無効になり、意図しない暗号化設定を防止します。
- Amazon Verified Permissions: エイリアスや名前付きポリシーをサポートし、マルチテナント環境での管理が大幅に簡略化されました。
- Amazon WorkSpaces Personal: PrivateLink VPC エンドポイントごとに一意の DNS 名を割り当て可能になり、マルチアカウント展開時の競合を回避します。
- Amazon FSx for OpenZFS: AWS アジアパシフィック（メルボルン）リージョンで新たに利用可能になりました。
¥3,520 Amazonで見る![AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11](https://m.media-amazon.com/images/I/61ftnZ09WvL._SY522_.jpg)
AWS運用入門 改訂第2版 押さえておきたいAWSの基本と運用ノウハウ [AWS深掘りガイド] 単行本（ソフトカバー） – 2025/7/11
Smithy-Java クライアントフレームワークが一般公開（GA）されました #
投稿日: 2026年04月06日
何ができるようになったのか #
Smithy モデルからタイプセーフなクライアントやスタンドアロンクラスを生成するためのオープンソース Java フレームワーク「Smithy-Java」が一般公開（GA）されました。Java 21 の仮想スレッド（Virtual Threads）を基盤として構築されており、ブロッキングスタイルの API を提供しながら、従来の複雑な非同期オルタナティブに匹敵するパフォーマンスを実現しています。
何が嬉しいのか #
エンタープライズユーザーから要望の多かった「プロダクション・グレードの Java SDK 生成」が可能になります。非同期パターンの使用に伴う認知負荷やメンテナンスコストを削減しつつ、高いパフォーマンスを維持できます。また、プロトコルの柔軟性（AWS SigV4 や主要な AWS プロトコルのサポート）や、コード生成なしで Smithy サービスを呼び出せるダイナミッククライアント機能も備えています。
これまでとどう変わるのか #
- これまで: Smithy を使用して Java クライアントを生成する場合、複雑な非同期パターンの実装や、メンテナンスの負担が大きい SDK の利用が必要になることがありました。
- これから: Java 21 の仮想スレッドを活用したシンプルなブロッキング API により、開発効率とパフォーマンスを両立した SDK 生成が可能になります。
具体的なユースケース #
- Smithy エコシステムに投資している組織における Java SDK の自動生成
- プロトコルに依存しない開発が必要なチーム
- サーバースタブを生成して新しいサービスを構築する開発者
Smithy は、サービス、リソース、操作、およびそれらがどのように相互作用するかを定義するための、Amazon のインターフェイス定義言語（IDL）です。 主な特徴は以下の通りです。
- プロトコルにとらわれない設計
- クライアント、サーバー、ドキュメントの自動生成をサポート
- 柔軟な拡張性
Amazon FSx for OpenZFS が AWS アジアパシフィック（メルボルン）リージョンで利用可能に #
投稿日: 2026年04月06日
何ができるようになったのか #
Amazon FSx for OpenZFS が、AWS アジアパシフィック（メルボルン）リージョンで利用可能になりました。これにより、メルボルンリージョンを利用するユーザーは、OpenZFS ファイルシステム上に構築された、完全に管理された共有ファイルストレージを作成できるようになります。
何が嬉しいのか #
OpenZFS の強力な機能（スナップショット、データクローニング、圧縮など）を、ミリ秒未満のレイテンシーとマルチ GB/s のスループットで利用できます。ハイパフォーマンスなワークロードに対しても、コスト効率の高い共有ファイルストレージを簡単に導入・スケーリングできます。
これまでとどう変わるのか #
- これまで: メルボルンリージョンでは Amazon FSx for OpenZFS を直接利用できず、他のリージョンを利用するか、別のストレージソリューションを検討する必要がありました。
- これから: メルボルンリージョン内で、ネイティブな OpenZFS 機能を備えたフルマネージドな共有ファイルストレージを低遅延で利用可能になります。
具体的なユースケース #
- メルボルンリージョンで稼働するハイパフォーマンスコンピューティング (HPC)
- データベースやメディア処理など、高いスループットと低遅延が求められるアプリケーション
- OpenZFS の機能を活用した高速なデータクローンやスナップショットによる開発・テスト環境の構築
Amazon RDS for Oracle が Oracle Management Agent (OMA) バージョン 24.1.0.0.v1 をサポート #
投稿日: 2026年04月06日
何ができるようになったのか #
Amazon RDS for Oracle で、Oracle Management Agent (OMA) のバージョン 24.1.0.0.v1 がサポートされました。これにより、Oracle Enterprise Manager (OEM) Cloud Control 24ai Release 1 を使用して、RDS for Oracle データベースインスタンスを監視および管理できるようになります。
何が嬉しいのか #
最新の OEM 24ai のウェブベースツールを利用して、Oracle データベースの統合的な監視と管理が可能になります。OMA は Oracle Management Service (OMS) と通信し、詳細なモニタリング情報を提供します。
これまでとどう変わるのか #
- これまで: OEM 24ai Release 1 を使用しているユーザーは、RDS for Oracle インスタンスとの互換性がない古いエージェントバージョンを使用するか、最新機能の利用が制限されていました。
- これから: バージョン 24.1.0.0.v1 の OMA をインストールすることで、最新の OEM 24ai スタックとの連携が正式に可能になります。
具体的なユースケース #
- Oracle Enterprise Manager 24ai を使用して、オンプレミスと AWS 上の Oracle データベースを一元管理する。
- 最新のエージェントバージョンによるパフォーマンス監視とセキュリティ管理の強化。
Amazon Verified Permissions がポリシーストアのエイリアス、名前付きポリシー、およびポリシーテンプレートをサポート #
投稿日: 2026年04月06日
何ができるようになったのか #
Amazon Verified Permissions において、ポリシーストアのエイリアス、名前付きポリシー、および名前付きポリシーテンプレートがサポートされました。これにより、システム生成の ID ではなく、人間が読める名前（エイリアスや名前）を使用してポリシーやストアを管理・参照できるようになります。
何が嬉しいのか #
マルチテナントアプリケーションの開発において、テナント ID に基づくエイリアスを割り当てることで、ID とポリシーストアの対応表を維持する必要がなくなります。また、認可ロジックを管理する際にも、意味のある名前でポリシーを参照できるため、管理の簡素化とミス防止につながります。
これまでとどう変わるのか #
- これまで: ポリシーストアや個々のポリシー、テンプレートを参照するには、AWS が自動生成した ID を使用する必要がありました。開発者はテナント ID とポリシーストア ID のマッピングテーブルを別途管理する必要がありました。
- これから: テナント識別子に基づくエイリアスを直接 API コールで使用でき、ポリシーにも任意の名前を付けられるようになるため、マッピング管理が不要になります。
具体的なユースケース #
- マルチテナント SaaS アプリケーションにおける、テナントごとの認可ポリシーの簡素な管理
- 大規模なアプリケーションでの認可ロジックの可読性向上とメンテナンスの効率化
Amazon WorkSpaces Personal が PrivateLink 用の一意の DNS 名をサポート #
投稿日: 2026年04月06日
何ができるようになったのか #
Amazon WorkSpaces Personal で、各 AWS PrivateLink VPC エンドポイントに対して一意で公開解決可能な DNS 名が提供されるようになりました。インターフェイス VPC エンドポイントごとに、グローバルにユニークな AWS 管理の DNS 名が割り当てられます。
何が嬉しいのか #
マルチアカウント環境や集中型 DNS インフラストラクチャを持つ企業において、DNS 名の衝突（名前解決の競合）を避けて WorkSpaces を複数の VPC やアカウントに展開できるようになります。セキュリティの分離を維持しつつ、トラフィックを適切にルーティングできます。
これまでとどう変わるのか #
- これまで: 全てのエンドポイントで共有される汎用的な DNS 名が使用されていたため、異なるアカウントで個別のインターフェイス VPC エンドポイントを使用する際に DNS 名の衝突が発生し、展開が制限される場合がありました。
- これから: 各エンドポイントに一意の DNS 名が自動的に割り当てられるため、衝突を回避できます。また、これらはプライベート IP に解決されるため、セキュリティも維持されます。
具体的なユースケース #
- 集中型 DNS を使用している大規模エンタープライズでのマルチアカウント展開
- 異なる VPC やアカウント間での WorkSpaces ディレクトリの分離と管理
- 複雑な Route 53 設定なしでの PrivateLink を介したセキュアなアクセス
Amazon S3 が新しいバケットセキュリティのベストプラクティス（SSE-C のデフォルト無効化）を適用開始 #
投稿日: 2026年04月06日
何ができるようになったのか #
Amazon S3 は、新しいセキュリティベストプラクティスとして、全ての新しい汎用バケットに対して「顧客提供のキーによるサーバーサイド暗号化 (SSE-C)」をデフォルトで無効にする設定の展開を開始しました。既存のバケットについても、SSE-C 暗号化オブジェクトが存在しないアカウントでは、新しい書き込みリクエストに対して SSE-C が無効化されます。
何が嬉しいのか #
デフォルトで SSE-C を無効化することで、誤って複雑な暗号化設定が適用されるのを防ぎ、セキュリティの管理性を高めます。SSE-C を既に使用しているアカウントやバケットには影響を与えないため、既存のワークロードはそのまま維持されます。
これまでとどう変わるのか #
- これまで: 新しいバケット作成時、SSE-C は特に制限されておらず、明示的に設定すれば利用可能でした。
- これから: 新規バケットではデフォルトで SSE-C が無効になります。SSE-C を使用していない既存のアカウントでも、新規書き込みに対してデフォルトで無効化されます。
具体的なユースケース #
- セキュリティポリシーの統一と、意図しない暗号化方式の利用防止
- バケット作成時のセキュリティデフォルト値の自動強化