2025/10/24 9:00:00 ~ 2025/10/27 9:00:00 (JST)
最近の発表
Amazon EC2 Auto Scaling now supports predictive scaling in six more regions
お客様は、アジア太平洋 (ハイデラバード)、アジア太平洋 (メルボルン)、イスラエル (テルアビブ)、カナダ西部 (カルガリー)、ヨーロッパ (スペイン)、ヨーロッパ (チューリッヒ) の 6 つの地域で Auto Scaling グループ (ASG) の予測スケーリングを有効にできるようになりました。予測スケーリングを使うと、今後の需要に備えて ASG をプロアクティブにスケールアウトできます。これにより、アプリケーションの応答性を確保しながら、容量を過剰にプロビジョニングする必要がなくなり、EC2 のコストを削減できます。サポートされているすべての AWS パブリックリージョンと AWS GovCloud (米国) リージョンのリストを確認するには、ここをクリックしてください。\n 予測スケーリングは、ビジネス再開時の早朝の急上昇など、需要の急激な変化パターンが繰り返し発生するアプリケーションに適しています。過去のパターンから学習し、予測される需要に先立ってインスタンスを起動するので、インスタンスがウォームアップする時間が与えられます。予測スケーリングは、ターゲットトラッキングやシンプルスケーリングなどの既存の Auto Scaling ポリシーを強化して、リアルタイムのメトリクスと過去のパターンの両方に基づいてアプリケーションをスケーリングできるようにします。「予測のみ」モードを使用すると、予測スケーリングが ASG とどのように連携するかをプレビューできます。 予測スケーリングは、AWS コマンドラインインターフェイス (CLI)、EC2 自動スケーリング管理コンソール、AWS CloudFormation、AWS SDK を通じてスケーリングポリシータイプとして利用できます。詳細については、EC2 Auto Scaling ドキュメントの「予測スケーリング」ページをご覧ください。
今回のローンチにより、Amazon VPC 到達可能性アナライザーと Amazon VPC ネットワークアクセスアナライザーが AWS GovCloud (米国西部) と AWS GovCloud (米国東部) の両方のリージョンで利用できるようになりました。\n VPC Reachability Analyzer では、ネットワーク構成を分析することで、仮想プライベートクラウド (VPC) 内のソースリソースとターゲットリソース間のネットワーク到達可能性を診断できます。たとえば、Reachability Analyzer は、VPC ルートテーブルに欠落しているルートテーブルエントリを特定するのに役立ちます。このエントリが、AWS 組織のアカウント B の別の EC2 インスタンスに接続できないアカウント A の EC2 インスタンス間のネットワーク接続を妨げている可能性があります。 VPC Network Access Analyzer を使用すると、AWS リソースへの意図しないネットワークアクセスを特定できるため、セキュリティとコンプライアンスのガイドラインを満たすのに役立ちます。たとえば、ウェブアプリケーションからインターネットへのすべてのパスがファイアウォールを通過していることを確認し、ファイアウォールを迂回するパスを検出するスコープを作成できます。 詳細については、VPC 到達可能性アナライザーと VPC ネットワークアクセスアナライザーのドキュメントをご覧ください。料金については、Amazon VPC 料金ページの「ネットワーク分析」タブを参照してください。
Aurora DSQL now supports resource-based policies
Amazon Aurora DSQL はリソースベースのポリシーをサポートするようになり、Aurora DSQL リソースのアクセスコントロールを簡素化できるようになりました。リソースベースのポリシーでは、ID とアクセス管理 (IAM) プリンシパルと、それらが Aurora DSQL リソースに対して実行できる特定の IAM アクションを指定できます。リソースベースのポリシーでは、Block Public Access (BPA) を実装することもできます。これにより、Aurora DSQL パブリックまたは VPC エンドポイントへのアクセスをさらに制限できます。\n リソースベースのポリシーの Aurora DSQL サポートは、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (大阪)、アジアパシフィック (東京)、アジアパシフィック (ソウル)、ヨーロッパ (アイルランド)、ヨーロッパ (ロンドン)、ヨーロッパ (パリ)、ヨーロッパ (フランクフルト) の AWS リージョンで利用できます。開始するには、Aurora DSQL リソースベースのポリシーに関するドキュメントをご覧ください。
AWS Transfer Family now supports changing identity provider type on a server
AWS Transfer Family では、サービスを中断することなくサーバーの ID プロバイダー (IdP) タイプを変更できるようになりました。この強化により、ファイル転送ワークフローにおける認証管理をより柔軟に制御できるようになり、変化するビジネス要件に迅速に対応できるようになります。\n AWS Transfer Family では、SFTP、FTP、FTPS、AS2、およびウェブブラウザベースのインターフェイスを介したフルマネージド型のファイル転送が可能です。今回のローンチにより、SFTP、FTPS、FTP、FTP サーバーのサービスマネージド認証、Active Directory、カスタム IdP 設定を動的に切り替えることができるようになりました。これにより、ダウンタイムなしで認証移行を実施し、進化するコンプライアンス要件に対応できるようになります。 IDP タイプの変更は、サービスが利用可能なすべての AWS リージョンで利用できます。詳細については、『Transfer Family ユーザーガイド』を参照してください。
New Amazon CloudWatch metrics to monitor EC2 instances exceeding I/O performance
本日、Amazon は 2 つの新しい Amazon CloudWatch メトリクスを発表しました。これにより、アプリケーションが EBS ボリュームがアタッチされた EC2 インスタンスの I/O パフォーマンス制限をいつ超えたかを把握できます。この 2 つのメトリックス、インスタンス EBS IOPS 超過チェックとインスタンス EBS スループット超過チェックは、駆動される IOPS またはスループットが、インスタンスがサポートできる最大 EBS IOPS またはスループットを超えているかどうかをモニタリングします。\n これら 2 つの新しいメトリクスをインスタンスレベルで使うと、インスタンスの EBS 最適化制限を超えることから生じるアプリケーションパフォーマンスの問題をすばやく特定して対応できます。ワークロードが EC2 インスタンスの EBS 最適化 IOPS またはスループットの制限を超えている場合、これらのメトリックスは 0 (パフォーマンスを超えていない) または 1 (パフォーマンスを超えた) を返します。Amazon CloudWatch では、これらの新しいメトリックスを使用してカスタマイズされたダッシュボードを作成し、通知するアラームを設定したり、これらのメトリックスに基づいてアクションを自動的に実行したりできます。たとえば、より大きなインスタンスサイズや、より高い EBS 最適化制限をサポートする別のインスタンスタイプへの移行などです。 インスタンス EBS IOPS 超過チェックおよびインスタンス EBS スループット超過チェックメトリックスは、EBS ボリュームがアタッチされたすべての Nitro ベースの Amazon EC2 インスタンスで、デフォルトで 1 分間隔で追加料金なしで利用できます。これらのメトリクスには、AWS GovCloud (米国) リージョンや中国リージョンを含むすべての商用 AWS リージョンの EC2 コンソール、CLI、または CloudWatch API を介してアクセスできます。これらの CloudWatch メトリクスの詳細については、EC2 CloudWatch メトリクスのドキュメントをご覧ください。
AWS Lambda increases maximum payload size from 256 KB to 1 MB for asynchronous invocations
AWS Lambda は、非同期呼び出しの最大ペイロードサイズを 256 KB から 1 MB に増やしました。これにより、お客様はデータを分割、圧縮、または外部化することなく、イベント駆動型のワークロード用に、より豊富で複雑なペイロードを取り込むことができます。お客様は、Lambda API を直接使用するか、Amazon S3、Amazon CloudWatch、Amazon SNS、Amazon EventBridge、AWS Step Functions などのさまざまな AWS サービスからプッシュベースのイベントを受け取ることによって、Lambda 関数を非同期で呼び出します。\n 現代のクラウドアプリケーションでは、スケーラブルなイベント駆動型アーキテクチャを構築するために、AWS Lambda の非同期呼び出しとさまざまな AWS サーバーレスサービスとの統合への依存度が高まっています。これらのアプリケーションでは、多くの場合、大規模な言語のモデルプロンプト、テレメトリシグナル、機械学習出力用の複雑な JSON 構造など、豊富なコンテキストデータを処理する必要があります。非同期呼び出しの最大ペイロードサイズが 1 MB に増加したことで、開発者は詳細なユーザープロファイルから完全なトランザクション履歴までの包括的なデータを 1 つのイベントに含めることでアーキテクチャを合理化でき、複雑なデータチャンキングや外部ストレージソリューションが不要になります。 この機能は通常、すべての AWS 商用リージョンと AWS GovCloud (米国) リージョンで利用できます。お客様は Lambda の呼び出し API を使用して最大 1 MB の非同期呼び出しペイロードの送信を開始できます。お客様には、非同期呼び出しごとに 1 つのリクエストに対して、最初の 256 KB の料金が請求されます。個々のペイロードサイズが 256 KB を超えると、最大 1 MB の 64 KB のチャンクごとに 1 つの追加リクエストが課金されます。詳細については、Lambda の非同期呼び出しに関するドキュメントと AWS Lambda の料金表をご覧ください。
Amazon SageMaker Unified Studio supports Amazon Athena workgroups
Amazon SageMaker Unified Studio を使用するデータエンジニアとデータアナリストは、既存の Amazon Athena ワークグループに接続してクエリを実行できるようになりました。この機能により、データチームは既存の Athena ワークグループのデフォルト設定とプロパティを使用して SageMaker Unified Studio で SQL クエリを実行できます。Athena ワークグループはクエリのアクセス管理とコスト制御に使用されるため、データエンジニアやデータアナリストは Athena ワークグループを SQL 分析コンピュートとして再利用することで時間を節約できます。また、データ使用量の制限を維持したり、チームやプロジェクトごとにクエリの使用状況を追跡したりできます。 \n SageMaker Unified Studio 内の SQL 分析用のコンピューティングを選択する場合、お客様は新しい Athena コンピューティング接続を作成するか、既存の Athena ワークグループに接続するかを選択できます。開始するには、SageMaker Unified Studio に移動し、「コンピューティングを追加」を選択し、「既存のコンピューティングリソースに接続」を選択します。次に、既存の Athena ワークグループへの接続を作成して保存します。これで、この新しいコンピューティングを SageMaker Unified Studio クエリエディターで SQL クエリを実行できるようになりました。 SageMaker Unified Studio 内の Athena ワークグループへの接続は、SageMaker Unified Studio がサポートされているすべての地域で利用できます。 詳細については、『SageMaker 統合スタジオガイド』と『Athena ワークグループガイド』を参照してください。
AWS Blogs
Amazon Web Services ブログ (日本語)
- Customer Carbon Footprint Tool の拡張: スコープ 3 を含めた追加の排出カテゴリが利用可能になりました
- AWS Weekly Roundup: Kiro ウェイティングリスト、EBS Volume Clones、EC2 Capacity Manager など (2025 年 10 月 20 日)
- AWS Backup マルチパーティ承認を使用して信頼性を高める方法
- 株式会社リネア様の AWS 生成 AI 事例:GraphRAGで実現するサプライチェーンリスク検知と管理への取り組み
AWS Startup ブログ (日本語)
AWS Big Data Blog
- Amazon SageMaker のカスタムサブスクリプションワークフローでデータガバナンスを促進
- AWS Lake Formation と統合された EKS 上の Amazon EMR を使用して、アイスバーグテーブルへのきめ細かなアクセスコントロールを実装します。
AWS Compute Blog
AWS DevOps & Developer Productivity Blog
AWS for Industries
Artificial Intelligence
Open Source Project
AWS CLI
AWS CDK
Amplify for Android
Amplify UI
- @aws-amplify/ui-vue@4.3.6
- @aws-amplify/ui-svelte@1.0.0
- @aws-amplify/ui-react-storage@3.13.1
- @aws-amplify/ui-react-notifications@2.2.13
- @aws-amplify/ui-react-native@2.6.3
- @aws-amplify/ui-react-liveness@3.4.7
- @aws-amplify/ui-react-geo@2.2.12
- @aws-amplify/ui-react-core-notifications@2.2.12
- @aws-amplify/ui-react-core@3.4.6
- @aws-amplify/ui-react@6.13.1