2025/5/16 9:00:00 ~ 2025/5/19 9:00:00 (JST)
最近の発表
Amazon Lightsail now supports IPv6 connectivity over AWS PrivateLink
Amazon Lightsail は IPv6 専用およびデュアルスタックのプライベートリンクインターフェイス VPC エンドポイントをサポートするようになりました。AWS PrivateLink は可用性が高くスケーラブルなサービスで、VPC をサービスやリソースに VPC 内にあるかのようにプライベートに接続できます。\n 以前は、Lightsail は IPv4 のみの VPC エンドポイントを使用した PrivateLink 経由のプライベート接続をサポートしていました。本日のリリースにより、お客様は IPv6 のみ、IPv4 のみ、またはデュアルスタック VPC エンドポイントを使用して VPC と Lightsail の間にプライベート接続を確立し、パブリックインターネットを経由せずに Lightsail にアクセスできるようになりました。 Lightsail は、Lightsail をサポートするすべての AWS リージョンで PrivateLink を使用した接続をサポートしています。PrivateLink を使用して Lightsail にアクセスする方法の詳細については、ドキュメントを参照してください。
AWS Entity Resolution is now available in 2 additional regions
本日より、AWS Entity Resolution が AWS カナダ (中部) およびアフリカ (ケープタウン) リージョンで利用できるようになりました。AWS Entity Resolution を使用すると、組織は複数のアプリケーション、チャネル、データストアに保存されている顧客、製品、ビジネス、または医療関連の記録を照合してリンクすることができます。エンティティ解決や ML の専門知識がなくても、柔軟でスケーラブルで、既存のアプリケーションにシームレスに接続できるマッチングワークフローを使用すれば、数分で開始できます。\n 今回の発表により、AWS Entity Resolution ルールベースの ML を利用したワークフローが、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、カナダ (中部)、アジア太平洋 (ソウル)、アジアパシフィック (シンガポール)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、ヨーロッパ (フランクフルト)、ヨーロッパ (アイルランド) の 12 の AWS リージョンで一般的に利用できるようになりました。ヨーロッパ（ロンドン）、アフリカ（ケープタウン）。 詳細については、AWS エンティティ解決をご覧ください。
AWS Config rules now available in additional AWS Regions
追加の AWS Config ルールが 17 の AWS リージョンで利用できるようになりました。AWS Config ルールは、希望の設定に合わせて AWS リソースの設定を自動的に評価し、AWS リソースの設定を評価、監査、評価するのに役立ちます。\n リソースがルールに違反すると、AWS Config ルールはそのリソースを非準拠と評価し、Amazon EventBridge を通じて通知を送信できます。AWS Config にはマネージドルールが用意されています。マネージドルールとは、AWS リソースが一般的なベストプラクティスに準拠しているかどうかを評価するために AWS Config が使用する定義済みのカスタマイズ可能なルールです。 今回の拡張により、AWS Config はアフリカ (ケープタウン)、アジアパシフィック (香港)、アジアパシフィック (ハイデラバード)、アジアパシフィック (ジャカルタ)、アジアパシフィック (ジャカルタ)、アジアパシフィック (クアラルンプール)、アジアパシフィック (メルボルン)、アジアパシフィック (大阪)、カナダ (カルガリー)、ヨーロッパ (ミラノ)、ヨーロッパ (パリ)、ヨーロッパ (パリ)、ヨーロッパ (ストックホルム)、ヨーロッパ (サラゴサ)、ヨーロッパ (ジラゴサ) のルールを管理しました。リッヒ）、中東（バーレーン）、中東（テルアビブ）、中東（UAE）、南米（サンパウロ） AWS リージョンごとの AWS アカウントでのルール評価ごとに課金されます。詳細については、AWS Config の料金ページをご覧ください。AWS Config ルールの詳細については、当社のドキュメントをご覧ください。
AWS CodePipeline now supports Deploy Spec file in EC2 deploy action
AWS CodePipeline が EC2 Deploy アクションの Deploy Spec ファイル設定をサポートするようになり、ソースリポジトリでデプロイパラメータを直接指定できるようになりました。EC2 Deploy アクションに Deploy Spec ファイル名またはデプロイ設定のいずれかを含めることができるようになりました。このアクションは YAML 形式のデプロイスペックファイルを受け入れ、既存の CodeDeploy AppSpec ファイルとの互換性を維持します。\n 大規模な EC2 デプロイのデプロイデバッグエクスペリエンスも強化されました。以前は、お客様はアクション実行ログのみを使用して複数のインスタンスにわたるデプロイステータスを追跡していました。これらのログにはデプロイの詳細が包括的に示されますが、大規模なデプロイでは特定のインスタンスのステータスを追跡することは困難でした。新しいデプロイ監視インターフェースでは、個々の EC2 インスタンスのステータス情報がリアルタイムで表示されるため、障害が発生したインスタンスを特定するために詳細なログを検索する必要がなくなります。この改善により、複数の EC2 インスタンスを対象とするデプロイのトラブルシューティングが効率化されます。 EC2 デプロイアクションの使用方法の詳細については、ドキュメントをご覧ください。AWS CodePipeline の詳細については、当社の製品ページをご覧ください。これらの新しいアクションは、AWS GovCloud (米国) リージョンと中国リージョンを除き、AWS CodePipeline がサポートされているすべてのリージョンで利用できます。
AWS CodePipeline now supports deploying to AWS Lambda with traffic shifting
AWS CodePipeline では、AWS Lambda へのアプリケーションのデプロイを簡素化する新しい Lambda デプロイアクションが提供されるようになりました。この機能により Lambda 関数のリビジョンをシームレスに公開でき、複数のトラフィックシフト戦略をサポートしてより安全なリリースを実現できます。\n 本番環境のワークロードでは、線形デプロイパターンとカナリアデプロイパターンのどちらを使用しても、ソフトウェア更新を自信を持ってデプロイできるようになりました。この新しいアクションは CloudWatch アラームと統合され、自動ロールバック保護を実現しています。指定したアラームがトラフィックシフト中にトリガーされた場合、システムは自動的に変更内容をロールバックして影響を最小限に抑えます。 この Lambda Deploy アクションをパイプラインで使用する方法の詳細については、ドキュメントをご覧ください。AWS CodePipeline の詳細については、当社の製品ページをご覧ください。これらの新しいアクションは、AWS GovCloud (米国) リージョンと中国リージョンを除き、AWS CodePipeline がサポートされているすべてのリージョンで利用できます。
Amazon Cognito now supports OIDC prompt parameter
Amazon Cognito は、Cognito マネージドログインの OpenID Connect (OIDC) プロンプトパラメータのサポートを発表しました。Managed Login では、完全管理型のホスト型サインインおよびサインアップエクスペリエンスが提供され、お客様は会社やアプリケーションのブランドに合わせてカスタマイズできます。この新機能により、よくリクエストされる 2 つのプロンプト値 (再認証シナリオ用の「login」と、サイレント認証状態チェック用の「none」) をサポートすることで、お客様は認証フローをより正確に制御できます。これらのプロンプトパラメータはそれぞれ、ユーザーに再認証を求めるか、既存のセッションを利用するように求めるかをアプリケーションで指定できるため、セキュリティとユーザーエクスペリエンスの両方が向上します。今回の起動により、ユーザープールがフェデレーションサインイン用に構成されている場合に、Cognito は select_account プロンプトと同意プロンプトをサードパーティの OIDC プロバイダーに渡すこともできるようになりました。\n 「login」プロンプトにより、アプリケーションは既存の認証済みセッションを維持したまま、ユーザーに明示的に再認証を要求できるようになりました。これは、機密情報にアクセスする直前やトランザクションを実行する直前など、さらに新しい認証検証が必要な場合に特に役立ちます。’none’ プロンプトでは認証状態をサイレントチェックできるので、アプリケーションでは再認証を行わずに、ユーザーが既にアクティブな認証セッションを持っているかどうかを確認できます。このプロンプトは、同じユーザープールを共有する複数のアプリケーションにシームレスなシングルサインオンエクスペリエンスを実装する場合に便利です。 この機能強化は、Amazon Cognito が利用可能なすべての AWS リージョンの Essentials または Plus レベルのお客様が Amazon Cognito マネージドログインで利用できます。これらの認証フローの実装の詳細については、Amazon Cognito のドキュメントをご覧ください。
Amazon Data Lifecycle Manager now supports (IPv6) in the AWS GovCloud (US) Regions
Amazon Data Lifecycle Manager では、新規および既存のエンドポイントにインターネットプロトコルバージョン 6 (IPv6) アドレスを使用するオプションをお客様に提供できるようになりました。IPv6 に移行するお客様は、ネットワークとクライアントが使用するプロトコルに応じて、IPv4 と IPv6 の両方をサポートするネットワーク上で Data Lifecycle Manager のデュアルスタックエンドポイントを実行することで、ネットワークスタックを簡素化できます。\n お客様は Amazon Data Lifecycle Manager ポリシーを作成して、EBS スナップショットと EBS でバックアップされた Amazon マシンイメージ (AMI) の作成、保存、管理を自動化します。このポリシーでは、作成されたリソースを AWS リージョン間で自動的にコピーしたり、EBS スナップショットを EBS スナップショットアーカイブ階層に移動したり、高速スナップショット復元を管理したりすることもできます。また、お客様は、プリスクリプトとポストスクリプトを使用して、アプリケーションと整合性のとれた EBS スナップショットの作成と保持を自動化するポリシーを作成できます。また、アカウントや AWS 組織を包括的に保護するためのデフォルトポリシーを作成することもできます。 すべての AWS 商用地域でサポートされている IPv6 対応の Amazon データライフサイクルマネージャーが、AWS GovCloud (米国) リージョンでも利用できるようになりました。 Amazon Data Lifecycle Manager エンドポイントを IPv6 用に設定する方法の詳細については、当社のドキュメントを参照してください。
Amazon SageMaker - move project across domain units
本日、Amazon SageMaker と Amazon DataZone は、顧客がプロジェクトをあるドメインユニットから別のドメインユニットに移動できるようにする新しいデータガバナンス機能を発表しました。ドメインユニットを使用すると、お客様はビジネスユニット/チームレベルの組織を作成し、ビジネスニーズに合わせて認証ポリシーを管理できます。お客様は、ドメインユニットにマッピングされたプロジェクトを、ドメインユニット階層内の新しいドメインユニットの下に整理できるようになりました。プロジェクトの移動機能では、顧客がプロジェクトの所有ドメインユニットを変更できるようにすることで、ビジネスイニシアチブや組織の変化に合わせてチーム構造の変更を反映させることができます。\n Amazon SageMaker または Amazon DataZone 管理者であれば、最上位ドメインの下にドメイン単位 (営業、マーケティングなど) を作成し、既存のプロジェクトを新しい所有ドメイン単位に移動してカタログを整理できるようになりました。その後、ユーザーはポータルにログインして、自分のビジネスユニットまたはチームに関連するドメインユニット別にカタログ内のアセットをブラウズしたり検索したりできます。 ドメインユニットのプロジェクト移動機能は、Amazon SageMaker と Amazon DataZone が利用できるすべての AWS リージョンで利用できます。 詳細については、Amazon SageMaker にアクセスし、移行プロジェクトのドキュメントから始めてください。
AWS Blogs
Amazon Web Services ブログ (日本語)
- 【開催報告】AWS Direct Connect ⼤阪第2ロケーション開設記念イベント を開催しました！！（2025年4月14日）
- AWS Customer Carbon Footprint Tool の算出方法論の更新
AWS Open Source Blog
AWS Cloud Operations Blog
AWS Big Data Blog
- LaunchDarkly が効率とスケーリングを実現するために Amazon MWAA に移行した経緯
- Amazon Redshift と Amazon S3 アクセスグラントの統合を使用して、エンタープライズデータアクセスを簡素化しましょう
AWS Database Blog
- マルチテナント向けの Amazon DynamoDB データモデリング — パート 3
- マルチテナント向けの Amazon DynamoDB データモデリング — パート 2
- マルチテナント向けの Amazon DynamoDB データモデリング — パート 1
AWS Machine Learning Blog
- Amazon Q Business でカスタムプラグインをセットアップし、Amazon Cognito で認証してバックエンドシステムとやり取りする
- RAG ベースのシステムの幻覚を検出
- AWSの機械学習がスクーデリア・フェラーリHPのピットストップ分析をサポート
- シームレスな AWS 統合による SiMa.ai Edgematic によるエッジ AI 開発を加速