AWS What's New Digest

Appearance

2026年04月09日 ​

[General] Amazon EC2 Capacity Manager now supports tag-based dimensions ​

概要 ​

Amazon EC2 Capacity Managerがリソースのタグを基準としたディメンションに対応しました。タグ（カスタム最大5キーとデフォルト提供タグ）や新しい "Account Name" ディメンションでキャパシティメトリクスをグループ／フィルタできます。

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

今回の追加により、EC2 Capacity ManagerはコンソールおよびAPIでタグ値を使ってキャパシティメトリクスをグループ／フィルタ可能になりました。主なポイントは以下の通りです。

  • カスタムタグキー: 最大5つのカスタムタグキー（例: environment, team, cost-center）を有効化してメトリクスのディメンションとして利用可能。
  • 組み込みディメンション: 既存の Region、Instance Type、Availability Zone に加え、新しい Account Name ディメンションが追加され、組織横断の解析でアカウント識別が容易に。
  • デフォルト提供タグ: EC2 Auto Scaling group name、EKS cluster name、EKS Kubernetes node pool、Karpenter node pool の4つがデフォルトで利用可能。
  • データエクスポート: 新規に作成するS3データエクスポートに、選択したタグデータを追加のカラムとして含められる（既存エクスポートには自動的には反映されない）。
  • 対象リソース/用途: On-Demand、Spot、Capacity Reservationsのキャパシティ監視・最適化に対応。
  • 実行方法: Capacity ManagerのSettings→Manage tag keysから有効化、またはAWS CLIで設定可能。
  • リージョン: EC2 Capacity Managerが利用可能な全リージョンで本機能が利用可能。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド運用エンジニア、SRE、コスト管理チーム、プラットフォーム運用チーム
  • 利用シーン: タグ単位（環境・チーム・コストセンター等）でのキャパシティ監視、スポット/予約/オンデマンド混在環境の最適化、組織横断でのアカウント別キャパシティ分析
  • 運用効果: タグに基づくより細かい集計・フィルタリングで無駄なリソースやキャパシティ不足を特定しやすくなり、レポートやS3エクスポートでコスト配分・責任範囲の可視化が向上する

技術的な注意点 ​

  • IAM権限: Capacity Managerの設定変更やタグの表示には該当するEC2/Capacity Managerの権限が必要（例: EC2の読み取り権限、Capacity Manager設定操作権限）。組織横断で見る場合はOrganization/AssumeRoleの権限も検討してください。
  • リージョン制限: 発表によれば、EC2 Capacity Managerが利用可能な全リージョンで提供。リージョン未提供の場合は当該リージョンでの利用不可。
  • コスト: 機能自体の利用に直接の追加料金は明記されていませんが、S3へのエクスポートやログ保存、追加API呼び出しに伴う通常のS3/CloudWatch/APIコストが発生します。
  • タグ/エクスポートの挙動: 有効化できるカスタムタグキーは最大5キー。デフォルトで提供される4つのタグは既に含まれる。タグ列は“新規に作成する”S3エクスポートにのみ追加され、既存エクスポートには自動的には反映されません。
  • 運用上の注意: タグ命名や付与ルールを整備しておかないと、タグ値のばらつきで期待する集計ができなくなるため、事前にタグポリシー／ガバナンスを確認してください。

参考情報 ​

[SageMaker] SageMaker HyperPod now supports gang scheduling for distributed training workloads ​

概要 ​

Amazon SageMaker HyperPodのタスクガバナンスにギャングスケジューリング機能が追加され、分散トレーニングジョブで必要な全てのPodが揃うまで実行を開始しないことで、部分実行による無駄な計算リソース消費やデッドロックを防げるようになりました。

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

HyperPodのタスクガバナンスに「ギャングスケジューリング」が導入されました。これは分散学習で複数のPodが協調して動作するケース（例: Horovod、PyTorch Distributed、MPIベースのワークロード等）で、ジョブ内の全てのPodが所定の待ち時間内に準備できない場合、該当ワークロードを取り下げ（pull back）て自動的に再キューイングする仕組みです。管理者はHyperPodコンソール上で以下の主な設定を調整できます: Pod準備待ち時間（タイムアウト）、ノード障害発生時の挙動、クラスタが混雑している場合にワークロードを一度に1件だけアドミットするかどうか（デッドロック回避）、および再試行のスケジューリング方式。これにより、部分的にPodが起動したまま進捗が止まる状況によるリソースホールドや他ジョブのブロッキング、不要なコスト増加を抑制できます。現時点ではEKSオーケストレータを使用するHyperPodクラスタで利用可能で、適用リージョンはUS East (N. Virginia)、US East (Ohio)、US West (N. California)、US West (Oregon)、Asia Pacific (Mumbai)、Asia Pacific (Singapore)、Asia Pacific (Sydney)、Asia Pacific (Tokyo)、Asia Pacific (Jakarta)、Europe (Frankfurt)、Europe (Ireland)、Europe (London)、Europe (Stockholm)、Europe (Spain)、South America (São Paulo)です。

影響範囲・利用シーン ​

  • 対象ユーザー: データサイエンティスト、機械学習エンジニア、クラスタ管理者（SageMaker HyperPod上で分散トレーニングを実行するユーザー）
  • 利用シーン: 分散トレーニング（複数Pod/ノード間での同期通信が必要なモデル学習）で、全Podが揃うまでジョブ開始を遅延させたい場合や、部分実行によるリソース浪費・デッドロックを防ぎたい場合
  • 運用効果: 不完全なジョブ実行による無駄なインスタンス起動を減らし、クラスタの安定性向上とコスト効率化を期待できる（ただし待ち時間設定によりジョブ遅延が発生する可能性あり）

技術的な注意点 ​

  • オーケストレータ制限: 現在はEKSオーケストレータを使用するHyperPodクラスタでのみ利用可能です
  • リージョン制限: US East (N. Virginia), US East (Ohio), US West (N. California), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Jakarta), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Stockholm), Europe (Spain), South America (São Paulo)で提供
  • IAM権限: HyperPodコンソールやタスクガバナンス設定を変更するには、SageMakerおよび対象EKSクラスタに対する適切なIAM権限／RBAC権限が必要です（管理者ロールでの操作を推奨）
  • コスト: 直接の追加料金は報告されていませんが、ギャングスケジューリングによりジョブが待機する時間が増えると総実行遅延が発生し、再試行や待機によるスケジュール影響で間接的なコスト・SLAsへの影響が出る可能性があります。逆に部分実行による無駄なインスタンス利用は削減できます。
  • 運用設定: タイムアウト、ノード障害時の挙動、1件ずつのアドミット（デッドロック回避）、再試行ポリシーなどをコンソールで調整可能。設定値によってはスループットと待ち時間のトレードオフが生じます
  • 互換性: Pod間通信を必要とする分散トレーニングフレームワークとは相性が良い一方、シンプルな単一Podジョブや別のスケジューリングポリシーを前提とするワークロードでは効果が限定的です
  • 注意点: 取り下げられたワークロードは自動的に再キューされるため、再試行ポリシーとクラスタ容量を監視して長期的なキュー残が発生しないよう運用設計してください

参考情報 ​

[General] Amazon IVS Real-Time Streaming now supports redundant ingest ​

概要 ​

Amazon IVS Real-Time Streamingが冗長イングest（redundant ingest）をサポートしました。2台のエンコーダから同一ステージへ並列送信し、自動フェイルオーバーでソース障害やファーストマイルのネットワーク障害からライブ配信を保護します。

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

冗長イングest機能により、2つのソースエンコーダ（同一または別拠点）から同じIVS Real-Timeのステージへ同時に配信でき、IVS側で自動的にフェイルオーバーを行います。これによりエンコーダ故障や送信元ネットワークの一時的な断絶が発生しても、視聴者側への配信を継続できます。想定されるユースケースはライブイベント、24/7配信、シームレスな放送継続が必須の場面です。低遅延・リアルタイム配信の特性は維持される設計で、導入はIVSコンソールもしくはコントロールAPIから行います（詳細はリージョン対応状況を確認してください）。運用面ではエンコーダ間で映像・音声のコーデック、解像度、ビットレート、キーフレーム間隔等を揃えることが重要で、フェイルオーバー時の画質・同期差異を最小化できます。

影響範囲・利用シーン ​

  • 対象ユーザー: ライブ配信エンジニア、放送事業者、イベント運営者、24/7ストリーミングを行うSRE/運用チーム
  • 利用シーン: 大規模イベントやスポーツ中継、24時間チャネル、視聴者離脱を避けたい商用配信（決済／広告連動）などの高可用性が要求されるライブ配信
  • 運用効果: ソースエンコーダやファーストマイル障害からの自動化された復旧により視聴中断を低減し、視聴者維持・SLA遵守を支援
  • 導入効果: 冗長構成により配信信頼性が向上し、手動切替の必要性を削減して運用負荷を軽減

技術的な注意点 ​

  • IAM権限: IVSのステージおよびストリーム管理を行うための権限（IVSのコントロールAPI/コンソール操作に必要なIAMロール/ポリシー）を事前に確認・付与してください
  • リージョン制限: 機能提供はリージョン依存です。利用可能かどうかはAWSリージョンの提供状況ページおよびIVSコンソールで確認してください
  • コスト: 追加コストの可能性があります（エンコーダ2系の運用コスト、冗長なアップロードによるデータ転送量増加、IVS側の料金項目）。料金は使用量とリージョンで変わるため事前に確認してください
  • エンコーダ設定: 両エンコーダでコーデック、解像度、フレームレート、キーフレーム間隔などを整合させること。設定差異は切替時の映像乱れや音声ずれを引き起こす可能性があります
  • 運用/監視: CloudWatch等でフェイルオーバーや接続状態を監視し、アラートを設定してください。フェイルオーバー動作は事前にテストしておくことを推奨します
  • 互換性/制約: 使用するエンコーダや送信プロトコル（RTMP/RTMPS等）によってセットアップ手順が異なる場合があります。詳細はIVSのRTMP ingestドキュメントを参照してください
  • テスト運用: 本番導入前にフェイルオーバーシナリオ（片方のエンコーダ停止、ネットワーク断等）を検証し、視聴体験への影響を評価してください

参考情報 ​

[EKS] Amazon EKS managed node groups now support EC2 Auto Scaling warm pools ​

概要 ​

Amazon EKSのマネージドノードグループがEC2 Auto ScalingのWarm Poolsに対応しました。事前に初期化済みのインスタンスを保持することで、スケールアウト時のノード起動遅延を短縮します。

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

Warm Poolsは、OS初期化、ユーザーデータ実行、ソフトウェア構成が完了したEC2インスタンスをプールとして保持します。EKSマネージドノードグループで有効にすると、Auto Scalingがスケールアウトする際にインスタンスはCold startを再実行せずにWarm Poolから直接アクティブ化されるため、ノードのプロビジョニング遅延が大幅に短縮されます。Warm Pool内のインスタンスはStopped（低コストだが起動時間が長い）またはRunning（高コストだが遷移が速い）として構成可能で、スケールイン時にインスタンスを削除せずプールへ戻す「reuse on scale-in」も有効化できます。Cluster Autoscalerとの互換性があり、追加設定なしで動作します。API、AWS CLI、コンソール、CloudFormationでCreateNodegroupまたはUpdateNodegroupConfigにwarmPoolConfigを追加して有効化できます。既存のマネージドノードグループでWarm Pools未設定のものは影響を受けません。使用可能リージョンはEKS提供リージョン（中国（北京）と中国（寧夏）は除く）となります。

影響範囲・利用シーン ​

  • 対象ユーザー: クラウド/プラットフォームエンジニア、Kubernetes運用者、SRE、バーストトラフィックを扱うアプリケーション開発者
  • 利用シーン: バーストトラフィック対応（短時間でノード追加が必要な場面）、起動時間が長い初期化スクリプトや大規模なソフトウェア依存関係を持つワークロード、タイムクリティカルな処理を行うジョブのスケールアウト
  • 運用効果: ノード起動遅延の短縮によりスケールアウトの応答性が向上し、オートスケーリングによるスロットルやサービス低下を低減できる
  • コスト影響: Runningモードは継続的なインスタンス料金が発生、Stoppedモードはコンピューティング料金を抑えられるが遷移が遅くなるため運用コストと応答性のトレードオフが発生

技術的な注意点 ​

  • IAM権限: EKSの作成/更新権限（eks:CreateNodegroup、eks:UpdateNodegroupConfig等）と、EKSがAuto Scalingリソースを操作するためのサービスロール/サービスリンクドロールが必要です。CloudFormation/CLIで操作するユーザーにも対応する権限を付与してください。
  • リージョン制限: ほとんどのEKS提供リージョンで利用可能ですが、中国リージョン（北京: Sinnet、寧夏: NWCD）は未対応です
  • コスト: RunningモードはEC2インスタンスの通常料金が継続して発生します。StoppedモードはCPU課金は発生しないがEBSやElastic IP等のリソース料金は継続する点に注意してください。プールサイズが大きいと追加コストが増加します。
  • 互換性: Cluster Autoscalerと追加設定なしで連携します。既存のノードグループは自動的に変更されないため、Warm Poolを使うにはCreate/Update時にwarmPoolConfigを設定する必要があります。
  • 導入手順の注意: 有効化はEKS API/CLI/コンソール/CloudFormationで行います。CloudFormationではCreateNodegroup/UpdateNodegroupConfigにwarmPoolConfigパラメータを追加してください。StoppedとRunningの特性（遷移時間・コスト）を踏まえて設定を選択してください。
  • 障害時の挙動: Warm Poolからの遷移はCold startより速いが、Stopped→Runningの起動時間は存在します。初期化済みとはいえアプリケーションレベルの健全性確認は継続することを推奨します

参考情報 ​

[Bedrock] Amazon Bedrock AgentCore Browser adds OS-level interaction capabilities ​

概要 ​

Amazon Bedrock AgentCore BrowserにOSレベルの操作機能が追加され、Chrome DevTools Protocol(CDP)だけでは扱えないマウス操作や印刷ダイアログ、ネイティブのシステムアラート、キーボードショートカットなどを自動化できるようになりました。全てのAgentCore Browserインスタンスでデフォルト有効です。

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

新機能はブラウザのビューポート外も含めたOS座標での操作をサポートし、以下を提供します：マウス操作（click, move, drag, scroll）、キーボード操作（type, press、Ctrl+A/Ctrl+P等のショートカット）、およびデスクトップ全体のスクリーンショット。これによりCDPが扱えない印刷ダイアログやネイティブアラート、コンテキストメニュー（右クリック）やドラッグ＆ドロップ等の複雑なUI操作、画面全体のビジョンベース解析が可能になります。技術的にはAgentCore BrowserのAPI経由でOS座標（ピクセル単位）を指定して入力イベントを発行し、内部でホストOSの入力／キャプチャ機能に橋渡しします。CDPによるDOM操作やページ内スクリプト実行は引き続き利用可能で、必要に応じてCDPとOSレベル操作を組み合わせてワークフローを構築します。機能はAgentCore Browserが提供されている全14リージョンの全インスタンスでデフォルト有効です。

影響範囲・利用シーン ​

  • 対象ユーザー: AIエージェント開発者、テスト自動化エンジニア、LLMを用いたWeb操作ツールを開発する組織
  • 利用シーン: 印刷ダイアログやネイティブ認証ダイアログを含むブラウザ自動化テスト、右クリックやドラッグ操作を伴う複雑UIの自動操作、ドキュメント管理ワークフロー（ファイル印刷や保存）、画面全体を見て判断するビジョンベースAIエージェント
  • 運用効果: CDPだけでは対処できなかったネイティブダイアログやOS領域外の操作を自動化できるため、E2Eテストの網羅性向上・ヒューマン介入の削減・LLMベースの自動化精度向上が期待できる
  • リスク/ガバナンス影響: OSレベル操作は強力だがポテンシャルで機密データや外部アプリに影響を与えうるため、権限管理と監査・サンドボックス運用が重要

技術的な注意点 ​

  • IAM権限: AgentCore/Bedrockの実行権限に加え、AgentCore Browserの操作API利用に必要な権限設定を確認してください（最小権限の原則を適用すること）
  • リージョン制限: 本機能はAgentCore Browserが利用可能な以下14リージョンでデフォルト有効です: US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Asia Pacific (Seoul), Canada (Central)
  • コスト: AgentCore Browserの実行時間やインスタンス利用に基づく料金が発生します。OSレベル操作によりテストやエージェントの実行時間が増えるとコストが上昇する可能性があります
  • 互換性: CDPベースの操作と併用可能。ただしヘッドレス実行や環境差（X11/Wayland/Windows/macOS相当の実装差）による動作差異がありうるため、ターゲット環境での検証が必要です
  • セキュリティ/プライバシー: OSレベル入力とフルデスクトップキャプチャは機密情報を含む可能性があるため、ログ・スクリーンショットの保管とアクセス制御、データマスキングのポリシー適用を推奨します
  • 運用上の注意: 座標指定はOS座標（画面ピクセル）で動作するため、マルチモニタや解像度の違い、ウィンドウ位置の変化に対する堅牢性設計（ウィンドウ検出やレイアウト確認）を行ってください
  • フォールバック: 一部ケースではCDPによるDOM操作や待機戦略と組み合わせて、冪等で安定したワークフローを設計してください

参考情報 ​

[Workspaces] Amazon WorkSpaces Advisor now available for AI-powered troubleshooting ​

概要 ​

Amazon WorkSpaces Advisorは、ジェネレーティブAIを利用してAmazon WorkSpaces Personalの構成や診断データを解析し、問題の特定と実行可能な修復手順を提示する管理者向けトラブルシューティング機能です。コンソールから利用可能で、MTTR短縮とVDI運用の効率化を目指します。

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

WorkSpaces AdvisorはWorkSpaceの構成情報や診断データをAIで解析し、サービス復旧やパフォーマンス最適化のための実行可能な推奨事項を提示します。主な機能は次のとおりです：

  • 問題の特定: WorkSpaceの状態や構成、診断情報（接続状態、セッション情報、エラーなど）をもとに異常や誤設定を検出します。
  • 推奨アクション: 再起動、再作成、設定変更、ネットワークやディレクトリ設定の確認など、具体的な復旧手順や優先度付きの対処案を提示します。
  • ワークフロー効率化: 管理コンソールから直接アクセスでき、問題調査に必要な情報を集約して提示することで、調査時間と手作業を削減します。
  • 対応範囲: 公表された内容ではAmazon WorkSpaces Personal向けに設計されており、すべての商用リージョン（WorkSpacesが提供されるリージョン）で利用可能です。 運用上は、Advisorが提示する診断結果を踏まえて管理者が最終判断を行い、必要に応じて既存の管理操作（再起動・再構築・設定変更等）を実行します。

影響範囲・利用シーン ​

  • 対象ユーザー: Amazon WorkSpacesを運用・管理するシステム管理者、VDI運用チーム、SRE
  • 利用シーン: WorkSpaceの接続障害やパフォーマンス劣化時の迅速な原因特定と復旧作業、定常的なプロアクティブ診断・最適化
  • 運用効果: トラブルシューティングの時間短縮（MTTR低減）、エンドユーザーの利用性向上、運用負荷の軽減（手作業による調査を削減）

技術的な注意点 ​

  • IAM権限: WorkSpacesコンソールとAdvisorにアクセスするためのWorkSpaces管理権限が必要です。最低でもworkspacesに関するDescribe系や操作系（例: DescribeWorkspaces、RebootWorkspace、RebuildWorkspace等）の許可を含むIAMポリシーを確認してください。
  • リージョン制限: 公表では「Amazon WorkSpacesが提供されるすべての商用リージョン」で利用可能とされています。AWS GovCloudや中国リージョンは対象外となる可能性があるため、利用前にリージョン提供状況を確認してください。
  • データ処理／プライバシー: AdvisorはWorkSpaceの設定・診断情報を解析してAI推論を行います。診断データやメタデータの取り扱い（送信先、保持期間、ログ保存）についてはユーザーガイドやプライバシー関連ドキュメントを確認し、センシティブデータの扱いに注意してください。
  • コスト: 公表記事では専用の追加料金は明記されていませんが、診断ログの保存や連携する監視・ログサービス（CloudWatch Logs、S3など）を利用した場合は別途費用が発生する可能性があります。導入前に料金ページと関連サービスのコストを確認してください。

参考情報 ​

[Opensearch Service] Amazon OpenSearch Service now supports Graviton4 based i8ge instances ​

概要 ​

Amazon OpenSearch ServiceがGraviton4ベースのi8ge（ストレージ最適化）インスタンスをサポート開始しました。従来のGraviton2ベースのIm4gnに比べて計算性能とローカルNVMeストレージ性能が大幅に向上しています。

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

i8geインスタンスはAWS Graviton4プロセッサを採用した最新世代のストレージ最適化インスタンスで、従来のGraviton2ベースIm4gnインスタンスに対して最大で約60%の計算性能向上を実現します。第3世代AWS Nitro SSD（ローカルNVMe）を搭載し、TB当たりのリアルタイムストレージ性能が最大約55%向上、ストレージI/Oレイテンシは最大約60%低減、I/Oレイテンシのばらつき（変動）は最大約75%低減とされています。AWS Nitro SystemによりCPUの仮想化処理、ストレージ、ネットワーク機能を専用ハードウェア／ソフトウェアにオフロードし、性能とセキュリティを向上させます。i8geは最大18xlargeサイズ、インスタンスローカルストレージは最大45 TBまで利用可能で、ネットワーク帯域は112.5 Gbpsとストレージ最適化インスタンス群で最も高い帯域を提供します。OpenSearchの全バージョンおよびElasticsearch（オープンソース）7.9/7.10をサポートします。対応リージョンは US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt), Europe (Ireland), Europe (Stockholm), Asia Pacific (Malaysia), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney) です。リージョンごとの料金・提供状況は価格ページで確認してください。

影響範囲・利用シーン ​

  • 対象ユーザー: ストレージ集約型の検索・ログ解析・観察性プラットフォームの運用者、データ検索エンジンを高速化したいSREやプラットフォームエンジニア
  • 利用シーン: 大規模ログインジェストと低遅延検索が求められるELK/OpenSearchクラスター、タイムシリーズデータのリアルタイム分析、高IOPSを必要とするワークロード
  • 運用効果: クエリ応答時間とインデックス/検索スループットの改善、I/Oレイテンシ低下によるスローダウンやガベージの抑制、ノード当たりのデータ保持量増加によるクラスタ規模最適化が期待できる

技術的な注意点 ​

  • IAM権限: 新しいインスタンスタイプの利用にはOpenSearch Serviceクラスタ作成／更新の権限が必要（iam:PassRoleやes:CreateElasticsearchDomain等の権限を確認）
  • リージョン制限: 利用可能リージョンは記事記載の10リージョンのみ。東京リージョン（ap-northeast-1）など未対応リージョンがあるため、導入前にリージョン提供状況を確認してください
  • サービス互換性: OpenSearchの全バージョンとElasticsearch（オープンソース）7.9/7.10をサポート。マネージドサービス上の互換性は確保されているが、プラグインやカスタム設定がある場合は事前検証を推奨
  • インスタンスサイズ・ストレージ: 最大サイズは18xlarge、ローカルNVMeストレージは最大45 TB。ローカルストレージのためスナップショットやデータ保護戦略（スナップショットのS3保存など）を設計すること
  • パフォーマンス注意点: Nitro SSD（ローカルNVMe）の特性により高スループット・低レイテンシを得られるが、ノード障害時の再配置やデータ復旧設計（レプリケーション、シャード配置）を適切に行うこと
  • コスト: 新世代インスタンスは性能向上と引き換えに時間単価が上がる可能性があるため、TCOを評価のうえ適切なインスタンスタイプとクラスタ構成を選定してください
  • 既存クラスタ移行: インスタンスタイプ変更はブルーグリーンやローリングアップデートでダウンタイムを最小化して実施することを推奨

参考情報 ​

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

Copyright © 2026