AWS HealthOmics announces batch run submission, allowing customers to submit up to 100,000 runs of any given workflow in a single request. With this launch, customers can now submit large-scale genomics experiments with thousands of samples without the overhead of submitting and tracking individual runs one by one, reducing overhead and simplifying orchestration. AWS HealthOmics is a HIPAA-eligible service that helps healthcare and life sciences customers accelerate scientific breakthroughs with fully managed bioinformatics workflows.
Batch run submission enables customers to initiate multiple workflow runs with similar parameters simultaneously. All runs in a batch share a common configuration, with the option to override specific parameters for individual runs based on different sample inputs or parameter values. The batch run APIs provide full lifecycle management of batch processing workflows. Customers can use the new batch ID resource to track each submission, easily cancel or delete in bulk, and monitor batch progress. Batch resources enable customers to troubleshoot issues and maintain optimal resource utilization across large-scale automation pipelines.
Batch run operations are now available in all regions where AWS HealthOmics is available: US East (N. Virginia), US West (Oregon), Europe (Frankfurt, Ireland, London), Israel (Tel Aviv), Asia Pacific (Singapore), and Asia Pacific (Seoul). To get started with run batches in HealthOmics workflows, see the documentation.
You can now use Amazon Timestream for InfluxDB in the Mexico (Central), Japan (Osaka), and Brazil (Sao Paulo) AWS regions. Timestream for InfluxDB makes it easy for application developers and DevOps teams to run fully managed InfluxDB databases on AWS for real-time time-series applications using open-source APIs.
Timestream for InfluxDB offers Multi-AZ high availability, read replicas, enhanced durability, and multi-node scaling — giving you flexible deployment options to match your workload as it evolves. Whether you're starting with a single-node setup or scaling to a 15-node Enterprise cluster, you can right-size your infrastructure without re-architecting.
You can create your InfluxDB databases using the Amazon Timestream for InfluxDB console. AWS CLI, or AWS SDKs . Amazon Timestream for InfluxDB is available in the following AWS Regions.
For more information, see the Amazon Timestream for InfluxDB documentation and pricing page.
Actively testing the LTS upgrade in production right now
AWS Security Agent に組み込まれた自動ペネトレーションテストのマルチエージェントアーキテクチャについて解説します。従来は数週間を要していたペネトレーションテストを、専門化された AI エージェント群の連携により自動化し、認証処理、ベースラインスキャン、多段階探索、アサーションベースの検証までを一貫して実行します。単一の脆弱性検出にとどまらず、複数の脆弱性を組み合わせた複雑な連鎖攻撃の検出・検証まで実現する仕組みを紹介します。
2025 年 6 月から 12 月にかけて、キヤノン株式会社のイメージング事業本部様と共に生成 AI ハッカソンを実施しましたので、その取り組みと成果についてご紹介します。
本ブログは 【寄稿】AI民主化に向けた丸紅の取組（丸紅株式会社）の続編です。 みなさん、こんにちは。総合商社を […]
本記事は、Amazon OpenSearch Serverless のハイブリッドマルチアカウントアクセスパターンに関するシリーズのパート 2 です。複数の事業部門が独立して OpenSearch Serverless コレクションを管理するシナリオに対応する分散型アーキテクチャを紹介します。中央ネットワーキングアカウントのカスタムプライベートホストゾーンと Route 53 Profile を活用し、オンプレミスおよびスポークアカウントからのプライベートアクセスを実現します。
本記事では、Amazon Redshift フェデレーテッドアクセス許可と AWS IAM Identity Center を使用して、複数のデータウェアハウスのきめ細かなアクセス許可をスケーラブルに管理する方法を紹介します。Enterprise Data Warehouse (EDW) でセキュリティポリシーを一度定義すれば、Sales や Marketing のコンシューマーウェアハウスに自動適用されるアーキテクチャを解説します。
Vanguard の Financial Advisor Services 部門が、Amazon Redshift のマルチウェアハウスアーキテクチャを活用して分析基盤を変革した事例を紹介します。単一クラスターから、プロビジョンドクラスターと Serverless を組み合わせたワークロード分離アーキテクチャへの移行により、ETL の SLA 遵守率 100%、月間 50 万以上のクエリ対応、BI ダッシュボード 25 倍増を実現しました。さらに、データメッシュアーキテクチャへの進化についても解説します。
This post introduces Claude Tool use in Amazon Bedrock which uses the power of large language models (LLMs) to perform dynamic, adaptable entity recognition without extensive setup or training.
In this post, we walk through how to search for available p-family GPU capacity, create a training plan reservation for inference, and deploy a SageMaker AI inference endpoint on that reserved capacity. We follow a data scientist's journey as they reserve capacity for model evaluation and manage the endpoint throughout the reservation lifecycle.
A resilient auto scaling policy requires metrics that correlate with application utilization, which may not be tied to system resources. Traditionally, auto scaling policies track system resource such as CPU utilization. These metrics are easily available, but they only work when resource consumption correlates with worker capacity. Factors such as high variance in request processing time, mixed instance types, or natural changes in application behavior over time can break this assumption.