みなさん､こんにちは｡ソリューションアーキテクトの杉山です｡今週も 週刊AWS をお届けします｡ 先週の木曜日､金曜日に AWS Summit Japan 2026 を開催しました｡台風が近づいていた中ではありましたが､多くのお客様にご来場いただきました｡ブースでたくさんのご相談を頂きましたが､AI 活用でどのような利便性があるのか､また､どういった仕組みでガバナンスを担保できるのか､という観点で質問を頂きました｡AWS Summit のセッションは､ オンデマンド視聴 が開始されています｡当日視聴が難しかった方も､キーノート､AWS セッション､お客様事例などをぜひご覧いただき次の一歩につながるヒントを得ていただければ幸いです｡ それでは､先週の主なアップデートについて振り返っていきましょう｡ 2026年6月22日週の主要なアップデート 6/22(月) Amazon Connect Customer が Agentic CX designer (NLX) のプレビュー版を提供開始 Amazon Connect Customer は､AI を活用したセルフサービス体験を設計・展開するためのノーコードキャンバス「Agentic CX designer (NLX)」のプレビュー版を提供開始しました｡ビジネスチームがコードを書かずに､エージェント型 AI と､本人確認や決済処理などの正確なアクションが求められるフローを組み合わせた音声・デジタル体験を構築できます｡また､通話中に顧客の Web/モバイルアプリをリアルタイムで操作できる Live Sync 機能も同時にプレビュー提供されます｡例えば､AI エージェントとホテル予約を通話している中で､会話内容に基づいて画面が同期して移動し､ホテルの予約を自動的に行うことがやりやすくなる仕組みです｡なお、プレビュー期間中は、ご自身のユースケースに合わせて精度などを検証いただくことが可能です｡ AWS Network Firewall がデフォルト drop action を更新し接続信頼性を改善 AWS Network Firewall は､新規作成するすべてのファイアウォールポリシーで､stateful action のデフォルトを “Application drop established (bidirectional)” から “Application drop established (server-directed only)” に変更しました｡この変更により､TCP window updates､keep-alives､resets などの正当なサーバーからクライアントへの TCP 制御パケットが誤ってドロップされることがなくなり､診断が困難だった断続的な接続障害を回避できます｡既存のポリシーには影響がなく､新規ポリシー作成時に自動的に適用されます｡ AWS Lambda MicroVMs で分離実行環境を提供開始 AWS Lambda MicroVMs を発表しました｡これはユーザーや AI が生成したコードを安全に実行するためのサーバーレスコンピューティング環境です｡VM レベルの分離､ほぼ瞬時の起動と再開速度､最大 8 時間の状態保存機能を提供します｡米国東部 (バージニア､オハイオ)､米国西部 (オレゴン)､アジアパシフィック (東京)､欧州 (アイルランド) で利用可能です｡従来の Lambda 関数がリクエストに応じて自動的にスケールするのに対し､MicroVMs は run-microvm API を呼んだ回数だけ MicroVM が 1 個ずつ起動し､各 MicroVM に専用の HTTPS エンドポイントが割り当てられます｡この「1 エンドポイント＝1 台」という特性を活かせば､ユーザーやセッションごとに独立した実行環境を割り当て､起動・サスペンド・終了のライフサイクルをアプリケーション側で自在に制御できるため､AI エージェントのコード実行サンドボックスやインタラクティブな開発環境のように「状態を保ったまま長時間使い続ける」ユースケースにうまくフィットします｡一方で従来の Lambda 関数は短時間・ステートレスなリクエストを大量にさばく用途に強いので､ワークロードの性質に応じて両者を使い分けるのがおすすめです｡なお､クォータは同時実行数ではなくアカウント・リージョンあたりの合計メモリ量で管理され､run-microvm API のレート制限はデフォルトで 5 TPS（バースト 5）です｡多数の環境を一度に立ち上げたい場合は､あらかじめサスペンド状態でプレウォームしておくと安定して払い出せます｡これらのクォータは Service Quotas コンソールから上限緩和を申請できます｡ 6/23(火) Claude Tag が AWS Marketplace の Claude Enterprise でベータ版として利用可能に Anthropic は､Claude Tag のベータ版を AWS Marketplace 経由で Claude Enterprise を利用する顧客向けに提供開始しました｡Claude Tag は､Slack チャネル内で @Claude とタグ付けすることで､チームメンバーが Claude にタスクを委任できる新機能です｡チャネルごとにアクセス権限と予算を設定でき､Claude は接続されたチャネルの文脈を記憶しながら､ツールやデータ､コードベースにアクセスできます｡管理者は Claude 管理コンソールで約 1 時間でエージェント ID をプロビジョニングし､チャネルごとにスコープを設定します｡ Amazon GuardDuty AI-powered investigations で脅威対応を加速 (Preview) Amazon GuardDuty に AI-powered investigations 機能 (Preview) が追加されました｡この機能は GuardDuty の findings とアカウントを自動的に分析し､真の脅威と誤検知を数分で見分けることができます｡過去 90 日間の関連アクティビティ､影響を受けるリソース､脅威インテリジェンスを knowledge graph を使って分析します｡これまで､GuardDuty の findings を手動で調査するには時間がかかり､アラート疲れ (alert fatigue) の原因となっていました｡AI-powered investigations により､数分で自動分析が完了します｡また､CLI コマンドを含む具体的な修復手順を提供してくれるため､対応のアクションが素早くなります｡ Amazon CloudWatch Logs がマネージド syslog 取り込みに対応 Amazon CloudWatch Logs が VPC エンドポイント経由での syslog 直接取り込みに対応しました｡ファイアウォール､ルーター､スイッチ､Linux サーバーからエージェントをインストールせずに syslog メッセージを CloudWatch Logs へ送信できます｡RFC 5424､RFC 3164､Cisco FTD/ASA の各フォーマットに対応し､facility､severity､hostname､appName などの構造化フィールドを自動的に抽出します｡PrivateLink に対応していて､Direct Connect や Site-to-Site VPN の Private 通信も可能となっています｡ 6/24(水) Amazon CloudWatch でダッシュボードのタグ機能をサポート Amazon CloudWatch がダッシュボードのタグ機能をサポートしました｡これにより､ダッシュボードをチーム､プロジェクト､環境などのカテゴリで整理し､タグベースでアクセス制御を実装できます｡PutDashboard API が Tags パラメータに対応したほか､TagResource､UntagResource､ListTagsForResource API がダッシュボード ARN をサポートし､1つのダッシュボードに最大50個のタグを設定できます｡CloudFormation と AWS Resource Explorer にも対応しており､追加コストなしで CloudWatch が利用可能な全リージョンで提供されます｡ Amazon Route 53 Global Resolver が AWS アカウント間での DNS View 共有をサポート Amazon Route 53 Global Resolver が､AWS Resource Access Manager (AWS RAM) を使用して DNS View を他の AWS アカウントと共有できるようになりました｡Route 53 Global Resolver は､リモート拠点やオンプレミス環境から AWS 上の Private Hosted Zone とパブリックドメインの両方を解決できる､インターネット到達可能な DNS リゾルバーです｡この機能により､consumer アカウントは自身の Route 53 Private Hosted Zone を共有された DNS View に関連付けることで､所有権を移譲せずに owner の Global Resolver を通じて全 AWS リージョンで名前解決できます｡DNS View 共有は追加料金なしで､Route 53 Global Resolver がサポートされている全リージョンで利用できます｡ AWS IoT Device SDK for Swift の一般提供開始 AWS IoT Device SDK for Swift が一般提供 (GA) を開始しました｡Swift 開発者は macOS 12+､iOS 16+､tvOS 16+､Linux 上で AWS IoT サービスを利用した IoT アプリケーションをネイティブに構築できるようになります｡SDK は MQTT 5 プロトコルをサポートし､AWS IoT Device Shadow､Jobs､Fleet Provisioning の統合クライアントを提供します｡iOS と tvOS では TLS 1.3 に対応しており､最新のセキュリティ標準でデータを保護します｡Swift Package Manager 経由でインストールできます｡ Amazon EC2､AMI ガバナンス強化のための AMI Watermarks 機能を発表 Amazon EC2 が AMI Watermarks 機能を発表しました｡この機能により､Private AMI にカスタム識別子を埋め込み､AMI の系譜追跡とガバナンスポリシーの実施が可能になります｡ウォーターマークは AMI のコピーや派生 AMI 作成時に自動的に引き継がれ､リージョン間コピーやアカウント共有でも保持されます｡Allowed AMIs 機能と組み合わせることで､承認されたウォーターマークを持つ AMI のみからインスタンスを起動するよう制限できます｡全 AWS リージョンで追加料金なしで利用可能です｡ 6/25(木) AWS Network Firewall が VisionHeight のマネージド脅威インテリジェンスルールをサポート AWS Network Firewall が VisionHeight 社の 2 つの新しいマネージドルールグループをサポートしました｡AWS Marketplace 経由で利用できる Zero-Day Threat Protection と Noisy Scanners and Tor Protection により､公開ブロックリストに掲載される数週間前に悪意ある IP インフラストラクチャを先制ブロックし､Tor 出口ノードや高頻度スキャンソースからの通信を遮断してファイアウォールログのノイズを削減します｡VisionHeight の Pulse テレメトリーに基づく独自の脅威インテリジェンスを活用でき､日次更新により最新の脅威情報を反映します｡ それでは､また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です。

G-gen の本間です。BigQuery の自動化機能であるスケジュールドクエリ（Scheduled queries）を解説します。 概要 スケジュールドクエリとは ユースケース 料金 主な機能と特徴 スケジュール設定 クエリ結果の書き込み 書き込み方式の概要 DML を使用した書き込み 宛先テーブルを指定した書き込み ランタイムパラメータの利用 権限と IAM ロール クエリの実行主体 スケジュール作成者に必要な権限 クエリ実行主体に必要な権限 注意点と制限事項 毎正時（00分）指定における重複実行のリスク 実行遅延の可能性 概要 スケジュールドクエリとは スケジュールドクエリ（Scheduled queries） とは、BigQuery において SQL クエリの実行を自動化し、指定したスケジュールで繰り返し実行できる機能です。 日本語の公式ドキュメントでは「スケジュールされたクエリ」と表記されていますが、当記事では実務でも馴染みのある「スケジュールドクエリ」で表現を統一します。 データ分析の現場では、毎日特定の時間に集計レポートを作成したり、1 時間ごとに生データを集計用テーブルに書き込んだりするタスクが頻繁に発生します。スケジュールドクエリを使用することで、外部のオーケストレーションツールやサーバーを用意することなく、BigQuery 単体でこれらのバッチ処理を自動化できます。 またスケジュールドクエリは、BigQuery Data Transfer Service（以下、DTS）の仕組みをベースに提供されています。そのため、内部的には DTS の転送設定として管理されます。 参考 : クエリのスケジューリング 参考 : BigQuery Data Transfer Service の概要 BigQuery の詳細は、以下の記事を参照してください。 blog.g-gen.co.jp ユースケース スケジュールドクエリは、以下のようなユースケースに役立ちます。 毎日深夜に、前日分のログデータを集計して日次レポート用テーブルを更新する 1 時間ごとに、生データから不要なカラムを除外したクレンジング済みテーブルを作成する 定期的に特定のクエリを実行し、結果を別のデータセットにあるテーブルへエクスポートする 料金 スケジュールドクエリ自体の機能利用に対する追加料金は発生しません。無料で使用できます。 ただし、スケジュールによって実行された SQL クエリがスキャンしたデータ量に応じて、通常の BigQuery クエリ料金（オンデマンド料金または容量制料金）が発生します。また、クエリ結果を保存するテーブルのストレージ料金も通常通り発生します。 参考 : BigQuery の料金 主な機能と特徴 スケジュール設定 クエリを実行する頻度は柔軟に設定できます。2026年6月現在、以下のような指定方法がサポートされています。 スケジュールの種類 詳細 事前定義された頻度 分、時間、日、週、月 カスタムスケジュール App Engine Cron 形式による柔軟な日時指定 オンデマンド スケジュールなし（任意のタイミングで手動実行） カスタムスケジュールを使用することで、「毎月第 1 月曜日の朝 9 時（1st monday of month 09:00）」や「毎日 10 時から 14 時の間、30 分おき（every 30 minutes from 10:00 to 14:00）」といった複雑なスケジュールにも対応できます。 参考 : クエリのスケジューリング - スケジュールされたクエリを設定する クエリ結果の書き込み 書き込み方式の概要 スケジュールドクエリの代表的なユースケースは、先述の通りログの定期的な集計や、データマートの作成（ELT 処理）です。そのため、スケジュール実行されたクエリの処理結果は、別のテーブル（ターゲットテーブル）に書き出して保存するのが一般的です。 スケジュールドクエリで処理したデータをターゲットテーブルに書き込むには、主に2つの方法があります。1つは SQL 文内で DML（データ操作言語）を使用する方法、もう1つはスケジュールの設定で「クエリ結果の宛先テーブル」を指定する方法です。 DML を使用した書き込み クエリの SQL 文内に INSERT 、 UPDATE 、 DELETE 、 MERGE などの DML を直接記述して、テーブルのデータを操作します。複雑な条件でのデータ更新や、複数テーブルに対する柔軟な処理を行う場合に適しています。 参考 : データ操作言語（DML）を使用してデータを更新する 宛先テーブルを指定した書き込み クエリには SELECT 文のみを記述し、スケジュール設定画面で「クエリ結果の宛先テーブル」オプションを有効化して書き込み先を指定する方法です。この機能を使用する場合、ターゲットテーブルへの書き込みモードとして以下の 2 つから動作を選択します。 モード 動作 テーブルの上書き（ WRITE_TRUNCATE ） 既存のターゲットテーブルのデータをすべて削除し、今回のクエリ結果で完全に置き換えます。 テーブルへの追加（ WRITE_APPEND ） 既存のターゲットテーブルのデータを保持したまま、今回のクエリ結果を末尾に追記します。 ランタイムパラメータの利用 スケジュールドクエリでは、クエリの実行予定時間を動的に表すランタイムパラメータを SQL 文中で使用できます。 利用可能なランタイムパラメータは以下の 2 つです。 パラメータ 説明 @run_time クエリが実行される予定のタイムスタンプ（UTC） @run_date クエリが実行される予定の日付（UTC） これらを SQL の WHERE 句などに使用することで、「実行時点の前日分のデータだけを抽出する」といった動的な処理ができます。これにより、スケジュール実行のたびに毎回同じデータ全体を無駄にスキャンしたり、処理したりすることを防ぐことができます。 以下の SQL は、実行時点の「前日分」のデータだけを抽出する動的なフィルタリングの例です。 SELECT user_id, COUNT (event_id) AS event_count, @run_date AS summary_date FROM `my-project.raw_data.events` WHERE -- イベント発生日（event_date）が「実行日の前日」であるデータを抽出 event_date = DATE_SUB(@run_date, INTERVAL 1 DAY) GROUP BY user_id なお @run_date や @run_time は UTC（協定世界時）で評価されます。日本時間（JST）を基準とした厳密な日次バッチ処理を行う場合は、SQL 内でタイムゾーンの変換（ DATE(@run_time, 'Asia/Tokyo') など）を考慮して設計してください。 参考 : クエリのスケジューリング - 利用可能なパラメータ 権限と IAM ロール クエリの実行主体 スケジュールドクエリには、「スケジュールを設定・管理するプリンシパル（ユーザー）」と「指定した時間に実際にクエリを実行するプリンシパル」の2つが関与します。 スケジュールドクエリを実行するプリンシパルは、デフォルトでは スケジュールを設定したユーザー となります。 この状態で運用を続けると、ユーザーの異動や退職によってアカウントが削除されたり、権限が変更された際に、クエリが失敗する原因になり得ます。 そのため、本番環境の運用では、 サービスアカウントをクエリの実行主体として指定 することが推奨されます。これにより、スケジュールを設定したユーザーが異動して権限が変更されたり、退職してアカウントが削除されてもスケジュールドクエリに影響が出ないため、安全に運用できます。 BigQuery の認証・認可の詳細は、以下の記事を参照してください。 blog.g-gen.co.jp スケジュール作成者に必要な権限 スケジュールの設定画面を操作し、ジョブを登録するユーザーには以下の権限が必要です。 目的 必要な IAM ロール 割り当て対象 スケジュールの作成と管理 BigQuery 管理者（ roles/bigquery.admin ） プロジェクトレベル サービスアカウントの割り当てと選択 サービスアカウントユーザー（ roles/iam.serviceAccountUser ） サービスアカウント閲覧者（ roles/iam.serviceAccountViewer ） 実行を委譲する サービスアカウント クエリ実行主体に必要な権限 バックグラウンドで実際にクエリを実行し、データの読み書きを行うアカウントやサービスアカウントには、以下の権限を付与します。 目的 必要な IAM ロール 割り当て対象 クエリの実行 BigQuery ジョブユーザー（ roles/bigquery.jobUser ） プロジェクトレベル ソースデータの閲覧 BigQuery データ閲覧者（ roles/bigquery.dataViewer ） プロジェクトまたはデータセットレベル（抽出元） ターゲットへの書き込み BigQuery データ編集者（ roles/bigquery.dataEditor ） プロジェクトまたはデータセットレベル（書き込み先） BigQuery の仕様として、「BigQuery データ編集者（ roles/bigquery.dataEditor ）」ロールにはデータの閲覧権限も含まれています。そのため、データの抽出元と書き込み先が同じデータセット内で完結する場合や、プロジェクトレベルでBigQuery データ編集者ロールを付与する場合は、ソースデータに対して別途「BigQuery データ閲覧者（ roles/bigquery.dataViewer ）」ロールを付与する必要はありません。プロジェクトやデータセットをまたいで処理を行う場合のみ、抽出元のデータセットに対して閲覧権限を付与してください。 参考 : クエリのスケジューリング - 必要な権限 注意点と制限事項 毎正時（00分）指定における重複実行のリスク スケジュールを「毎時 00 分（例 : 09:00）」など、「正時」のタイミングに設定すると、内部的なトリガーが複数回起動してしまい、同一のクエリが重複して実行される事象が稀に発生します。 結果として、追記モード（ WRITE_APPEND ）の際にデータが二重に取り込まれてしまうリスクがあります。これを防ぐため、公式ドキュメントでも 08:58 や 09:03 など、 正時から数分ずらしたスケジュールを設定すること が推奨されています。 参考 : クエリに関する問題のトラブルシューティング - スケジュールされたクエリが重複して実行される 実行遅延の可能性 スケジュールドクエリの基盤である DTS の仕様上、秒単位での厳密な実行タイミングが保証されているわけではありません。リソース状況等により、実際の実行時刻に遅延（Pending）が発生する可能性がある点に留意して設計してください。 また、Google Cloud の一般的なベストプラクティスとして、「クエリ A の完了を待ってからクエリ B を実行する」といった依存関係の制御や、高度なエラーハンドリングが必要なワークロードにおいては、スケジュールドクエリではなく、Dataform や Cloud Workflows といった専用のワークフロー管理サービスの利用が推奨されています。 参考 : ワークロードのスケジュールを設定する 参考 : Dataform の概要 参考 : ワークフローの概要 本間 優太郎 (記事一覧) クラウドソリューション部 クラウドエンジニアリング2課 北海道在住 2026年6月に G-gen にジョイン。前職では社内SE、Sler としてアプリ/インフラ開発業務に従事。アプリ/インフラ双方の経験をベースに現在はGoogle Cloudの学習を進めている。 好きなことは子供と遊ぶこと、ゲームをすること。

2026 年 6 月 22 日、私たちは AWS Lambda 内の新しいサーバーレスコンピュートプリミティブである AWS Lambda MicroVMs を発表しました。これは、ユーザーまたは AI によって生成されたコードを、分離されたステートフルな実行環境で実行できるようにするものです。仮想マシンレベルの分離、ほぼ瞬時の起動および再開、そして環境のライフサイクルと状態に対する直接的な制御を得ることができ、インフラ管理や複雑な仮想化技術に関する専門知識は不要です。Lambda MicroVMs は  Firecracker によって支えられており、これは毎月 15 兆回以上の Lambda 関数呼び出しを支えている軽量仮想化技術と同じものです。 なぜこの機能が求められるのか ここ数年で、新しいクラスのマルチテナントアプリケーションが登場しており、それらはすべて共通して「各エンドユーザーに専用の実行環境を提供し、アプリケーション開発者が書いていないコードを安全に実行する」という要件を持っています。AI コーディングアシスタント、インタラクティブなコード実行環境、データ分析プラットフォーム、脆弱性スキャナー、そしてユーザー提供スクリプトを実行するゲームサーバーなどがこのパターンに該当します。現在、このような機能を構築するには難しい選択を迫られます。仮想マシンは強力な分離を提供しますが、起動に数分かかります。コンテナは数秒で起動できますが、共有カーネル構造のため、信頼できないコードを安全に隔離するには大幅な追加の強化が必要です。Function as a Service はイベント駆動型のリクエスト・レスポンス型ワークロードに最適化されていますが、ユーザー操作間で環境状態を保持する必要がある長時間のインタラクティブセッションには適していません。その結果、開発者はパフォーマンスと分離性のトレードオフを受け入れるか、あるいは低遅延な体験を提供しつつ分離実行を実現するために、カスタム仮想化基盤を構築・運用するための大規模なエンジニアリングリソースを投入するかの選択を迫られます。これは高度な専門知識を要求する取り組みであり、本来構築しようとしているプロダクト開発からエンジニアリング時間を奪ってしまいます。 Lambda MicroVMs はまさにこのギャップを埋めるために設計されています。各 MicroVM は、単一のエンドユーザーまたはセッションに対して専用の隔離環境を提供し、迅速に起動し、セッション期間中はメモリとディスク状態を保持し、ユーザーが離席すると低コストのアイドル状態へと一時停止します。同じ Firecracker 技術がすでに AWS Lambda 関数を支えているため、同サービスが大規模運用で培ってきた運用成熟度をそのまま継承できます。 試してみましょう 私はまず AWS Lambda コンソールにアクセスし、左側のナビゲーションメニューに新しく表示された「Lambda MicroVMs」を開きました。最初に MicroVM Image を作成する必要があります。 Flask Web アプリとその Dockerfile を zip ファイルにまとめ、それを Amazon Simple Storage Service (Amazon S3) バケットへアップロードしました。 私の Flask API – app.py import logging from flask import Flask, jsonify app = Flask(__name__) logging.basicConfig(level=logging.INFO) @app.route("/") def hello(): app.logger.info("Received request to hello world endpoint") return jsonify(message="Hello, World!") if __name__ == "__main__": app.run(host="0.0.0.0", port=5000) 私の Dockerfile FROM public.ecr.aws/lambda/microvms:al2023-minimal RUN dnf install -y python3 python3-pip && dnf clean all WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY app.py . EXPOSE 5000 CMD ["gunicorn", "--bind", "0.0.0.0:5000", "app:app"] MicroVM イメージを作成するために、以下のコマンドを使用しました。 aws lambda-microvms create-microvm-image \ --code-artifact uri=<path/to/s3/artifact.zip> --name <VM_image_name> \ --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \ --build-role-arn <IAM role ARN> 上記のように、AWS コンソールから MicroVM Image を作成することも可能です。コマンドを実行すると、Lambda は zip を取得し、Dockerfile を実行してアプリケーションを初期化し、実行中のディスクおよびメモリ状態を Firecracker スナップショットとして取得します。ビルドログはリアルタイムで Amazon CloudWatch にストリーミングされ、ロググループは /aws/lambda/microvms/<image-name> に記録されます。イメージの準備が完了すると、その Amazon リソースネーム (ARN) とバージョン番号がコンソールに表示されます。 aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:<region>:<acct>:microvm-image:my-image \ --execution-role-arn arn:aws:iam::<acct>:role/MicroVMExecutionRole \ --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}' 起動は AWS コンソールまたは CLI からも実行できます。私はイメージ ARN とアイドルポリシーを指定しました。このポリシーでは、15 分間操作がない場合に自動的にサスペンドし、次のリクエストで自動的に再開するよう設定されています。ネットワーク設定は不要でした。Lambda は MicroVM に一意の ID を割り当て、専用のエンドポイント URL を返し、私の Flask アプリがすでに起動した状態の新しい MicroVM を開始しました（スナップショットから復元されたためです）。起動が完了した時点で、私の Flask アプリはすでに稼働していました。完全に初期化済みのコンピュート環境を得るまで、API コールはわずか 1 回です。 トラフィック送信のために、CLI で短時間有効な認証トークンを生成し、それを X-aws-proxy-auth ヘッダーとして通常の HTTPS リクエストに付与しました。リクエストはただちに私の Flask アプリへ到達しました。その後、Micro VM をアイドル状態のまましばらく放置すると、しきい値を超えた時点でサスペンドされ、メモリとディスクの状態はスナップショットとして保存されました。その後再びリクエストを送信すると、アプリケーションの状態を完全に保持したまま再開されました。クライアント側から見ると、停止は一切発生していないように見えます。 仕組み 内部的には、Lambda MicroVMs はこれまで単一の AWS コンピュートサービスでは提供されていなかった 3 つの能力を統合しています。第 1 は仮想マシンレベルの分離であり、これは Firecracker によって実現されています。各セッションは専用の MicroVM 内で実行され、カーネルやリソースはユーザー間で共有されません。そのため、あるユーザーが提供した信頼できないコードはその実行環境内に閉じ込められ、他の環境や基盤システムへアクセスすることはできません。第 2 は高速な起動および再開です。この仕組みは「イメージ→起動（image-then-launch）」モデルです。MicroVM Image は、DockerfileとAmazon S3 にパッケージされた zip アーティファクトを指定して作成されます。Lambda は Dockerfile を実行し、アプリケーションを初期化した後、その実行状態（メモリおよびディスク）を Firecracker スナップショットとして取得します。このイメージから起動されるすべての MicroVM は、コールドブートではなく事前初期化済みスナップショットから復元されるため、起動およびアイドル復帰の両方がほぼ瞬時に行われます。数 GB 規模のインタラクティブセッションであっても、ユーザーにとって十分に応答性のある速度で復帰します。第 3はステートフル実行です。実行中の MicroVM は、ユーザーセッション中にメモリ・ディスク・実行中プロセスの状態を保持します。アイドル状態では MicroVM はサスペンドされ、メモリとディスク状態を維持したまま保存され、トラフィック再開時に復元されます。インストール済みパッケージ、ロード済みモデル、作業中ファイルセットは再開時にそのまま利用可能です。MicroVM は最大 8 時間の総実行時間をサポートし、アイドル状態は設定可能な時間で自動サスペンドできます。これにより、数分で完了する脆弱性スキャン、数時間実行されるデータ分析アプリケーション、長時間アイドルを含むインタラクティブ開発環境など、多様なユースケースを容易に構築できます。MicroVM は事前初期化スナップショットから起動されるため、初期化時にユニークなデータ生成、ネットワーク接続、または一時データのロードを行うアプリケーションは、互換性のためサービス提供のフックとの統合が必要になる場合があります。 Lambda MicroVMs は AWS Lambda 内の新しいリソースであり、専用のAPI 体系を持ちます。Lambda 関数はイベント駆動型のリクエスト／レスポンス処理に最適であり、Lambda MicroVMs はユーザーまたはセッションごとに隔離された実行環境で信頼できないコードを実行する必要があるマルチテナントアプリケーション向けに設計されています。両者は相互に補完関係にあります。イベント駆動のバックエンドには Lambda 関数を使用し、隔離実行が必要な処理には Lambda MicroVMs を呼び出す構成が可能です。アプリケーションはそのまま持ち込み、実行環境はサービス側が提供します。 今すぐご利用いただけます AWS Lambda MicroVMs は現在、米国東部 (バージニア北部・オハイオ)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (東京) リージョン で利用可能です。アーキテクチャは ARM64 に対応し、MicroVM あたり最大 16 vCPU、32GB メモリ、32GB ディスクをサポートします。アイドル状態の MicroVM は API による明示的停止、またはライフサイクルポリシーによって自動的にサスペンドでき、実行コストを削減しつつ状態を保持したまま高速再開が可能です。料金の詳細は AWS Lambda 料金ページ を参照してください。 開始するには AWS Lambda コンソール にアクセスするか、 Lambda MicroVMs 製品ページ をご覧ください。ドキュメントは Lambda ドキュメント（Developer Guide） を参照してください。 原文は こちら です。