本記事は、2026 年 6 月 22 日に公開された Run isolated sandboxes with full lifecycle control: AWS Lambda introduces MicroVMs を翻訳したものです。翻訳は Solutions Architect の齋藤 拓巳が担当しました。 本日、AWS Lambda MicroVMs を発表します。これは AWS Lambda 内の新しいサーバーレスコンピューティングプリミティブで、ユーザーや AI が生成したコードを分離されたステートフルな実行環境で実行できます。 仮想マシンレベルの分離、ほぼ瞬時の起動と再開、環境のライフサイクルと状態の直接制御が可能で、インフラストラクチャの管理や複雑な仮想化技術の専門知識は不要です。 Lambda MicroVMs は Firecracker を基盤としています。これは、月間 15 兆回を超える Lambda 関数の呼び出しを支えてきた軽量仮想化技術と同じものです。 この機能が求められる背景 ここ数年、新しい種類のマルチテナントアプリケーションが登場しています。これらのアプリケーションはすべて、エンドユーザーごとに専用の実行環境を提供し、アプリケーション開発者が書いていないコードを安全に実行する必要があるという共通点を持っています。AI コーディングアシスタント、インタラクティブなコード環境、データ分析プラットフォーム、脆弱性スキャナー、ユーザー提供のスクリプトを実行するゲームサーバーなどがこのパターンに該当します。現在この機能を構築するには、難しい選択を迫られます。仮想マシンは強力な分離を提供しますが、起動に数分かかります。コンテナは数秒で起動しますが、カーネル共有アーキテクチャのため、信頼できないコードを安全に封じ込めるには大規模なカスタムのセキュリティ強化が必要です。Functions as a Service はイベント駆動型のリクエスト・レスポンスワークロードに最適化されていますが、ユーザーとのインタラクション間で環境の状態を保持する必要がある長時間実行のインタラクティブセッション向けには設計されていません。その結果、開発者はパフォーマンスと分離のトレードオフを受け入れるか、エンドユーザーに低レイテンシーの体験を提供しながら分離された実行を実現するために、カスタム仮想化インフラストラクチャの構築と運用に多大なエンジニアリングリソースを投資するかの選択を迫られます。これは深い専門知識を必要とし、本来構築しようとしているプロダクトからエンジニアリング時間を奪う取り組みです。 Lambda MicroVMs は、まさにこのギャップを埋めるために専用設計されています。 各 MicroVM は、単一のエンドユーザーまたはセッションに対して独自の分離された環境を提供し、高速に起動し、セッションの間メモリとディスクの状態を保持し、ユーザーが離席した際には低コストのアイドル状態に一時停止します。 同じ Firecracker テクノロジーが既に AWS Lambda Functions の基盤となっているため、このスタックを大規模に運用してきたサービスの運用成熟度をそのまま活用できます。 試してみましょう まず、AWS Lambda コンソールに移動すると、左側のナビゲーションメニューに Lambda MicroVMs が表示されるようになっています。最初に MicroVM イメージを作成する必要があります。 Flask ウェブアプリとその 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= --name \ --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \ --build-role-arn 上の画像のように、AWS コンソールで MicroVM Image を作成することもできます。 コマンドを実行すると、Lambda が zip を取得し、Dockerfile を実行し、アプリケーションを初期化して、実行中のディスクとメモリの状態の Firecracker スナップショットを取得しました。 ビルドログは /aws/lambda/microvms/ 配下の Amazon CloudWatch にリアルタイムでストリーミングされ、イメージの準備が完了すると、 Amazon Resource Name (ARN) とバージョン番号とともにコンソールに表示されました。 aws lambda-microvms run-microvm \ --image-identifier arn:aws:lambda:::microvm-image:my-image \ --execution-role-arn arn:aws:iam:::role/MicroVMExecutionRole \ --idle-policy '{"maxIdleDurationSeconds":900,"suspendedDurationSeconds":300,"autoResumeEnabled":true}' 起動は AWS コンソールまたは CLI からも行えます。 ここでは、イメージ ARN と、15 分間操作がないと自動的にサスペンドし、次のリクエストを受信すると自動的にレジュームするよう設定したアイドルポリシーを渡しました。 ネットワークの設定は不要です。 Lambda は MicroVM に一意の ID を割り当て、専用のエンドポイント URL を返し、新しい MicroVM を起動します。この MicroVM はスナップショットからレジュームされるため、Flask アプリはすでに実行された状態になっています。 実際、起動が完了した瞬間には Flask アプリはすでに動作していました。 たった 1 回の API 呼び出しで、完全に初期化されブートストラップされたコンピューティング環境が手に入ります。 トラフィックを送信するために、CLI で短期間有効な認証トークンを生成し、 X-aws-proxy-auth ヘッダーを使用して通常の HTTPS リクエストに添付しました。 リクエストはすぐに Flask アプリに到達しました。 その後、MicroVM をサスペンドのしきい値を超えてアイドル状態にしたところ、MicroVM はサスペンドされ、メモリとディスクの状態がスナップショットとして保存されました。 次に別のリクエストを送信すると、アプリケーションの状態が完全に保持されたまま再開されました。 クライアント側からは、一時停止が発生したことはまったくわかりませんでした。 仕組み 内部的には、Lambda MicroVMs は、これまで単一の AWS コンピューティングサービスでは同時に提供されていなかった 3 つの機能を実現しています。 1 つ目は、Firecracker による仮想マシンレベルの分離です。 各セッションは専用の MicroVM で実行され、ユーザー間でカーネルやリソースが共有されることはありません。 そのため、あるユーザーが提供した信頼されていないコードはそのユーザーの実行環境内に封じ込められ、他の環境や基盤システムへのアクセスはできません。 2 つ目は、高速な起動と再開です。 このモデルは「イメージを作成してから起動する」方式です。Dockerfile と Amazon S3 に zip アーティファクトとしてパッケージ化されたコードを提供して MicroVM Image を作成すると、Lambda が Dockerfile を実行し、アプリケーションを初期化し、実行中の環境のメモリとディスクの状態の Firecracker スナップショットを取得します。 そのイメージから起動される後続のすべての MicroVM は、コールドブートではなく事前に初期化されたスナップショットから再開されるため、起動とアイドル状態からの再開の両方でほぼ瞬時の起動レイテンシーを実現します。 数ギガバイト規模のインタラクティブセッションでも、エンドユーザーが快適に操作できるほど素早くオンラインに復帰します。 3 つ目は、ステートフルな実行です。 実行中の MicroVM は、ユーザーのセッション全体を通じてメモリ、ディスク、実行中のプロセスを保持します。 アイドル期間中、MicroVM はメモリとディスクの状態をそのまま維持したままサスペンドでき、トラフィックが到着すると再開されます。 インストール済みのパッケージ、ロード済みのモデル、作業中のファイルセットは、ユーザーがセッションを再開した際にすぐに利用可能です。 MicroVM は最大 8 時間の合計実行時間をサポートし、設定可能なアイドル時間の後に自動的にサスペンドできるため、数分で完了するソフトウェア脆弱性スキャン、数時間実行されるデータ分析アプリケーション、長時間のアイドル期間を伴うインタラクティブなコーディングセッションなど、多様なプロダクトを簡単に構築できます。 Lambda MicroVMs は事前に初期化されたスナップショットから起動されるため、初期化時に一意のコンテンツを生成したり、ネットワーク接続を確立したり、一時的なデータをロードしたりするアプリケーションでは、互換性のためにサービスが提供するフックとの統合が必要になる場合があります。 Lambda MicroVMs は AWS Lambda 内の新しいリソースであり、独自の API を備えています。 Lambda Functions は引き続きイベント駆動型のリクエスト・レスポンスワークロードに最適な選択肢であり、Lambda MicroVMs はマルチテナントアプリケーション向けに特化して構築されています。具体的には、各エンドユーザーやセッションに対して、ユーザーまたは AI が生成したコードを実行するための独立した分離環境を提供する必要があるアプリケーションに適しています。 この 2 つは互いを補完する関係にあります。 イベント駆動型のバックボーンに Lambda Functions を使用しているアプリケーションは、信頼できないコードを分離して実行する必要があるステップで Lambda MicroVMs を呼び出すことができます。 お客様がアプリケーションを持ち込み、サービスが実行環境を提供します。 提供開始 AWS Lambda MicroVMs は、米国東部 (バージニア北部、オハイオ)、米国西部 (オレゴン)、欧州 (アイルランド)、アジアパシフィック (東京) の各 リージョン で本日より利用可能です。ARM64 アーキテクチャ上で、MicroVM あたり最大 16 vCPU、32 GB のメモリ、32 GB のディスクを提供します。 アイドル状態の MicroVM は、API 呼び出しによる明示的なサスペンド、またはライフサイクルポリシーによる自動サスペンドが可能で、完全な状態を保持したまま高速に再開できるため、実行コストを削減できます。 料金の詳細は AWS Lambda の料金ページ をご覧ください。 開始するには、 AWS Lambda コンソール にアクセスするか、 Lambda MicroVMs 製品ページ で詳細をご確認ください。 ドキュメントについては、 Lambda MicroVMs デベロッパーガイド を参照してください。 著者について Micah Walter Micah Walter は、ニューヨーク市地域およびその他の地域のエンタープライズのお客様を支援するシニアソリューションアーキテクトです。クラウドへの移行のあらゆる段階で、エグゼクティブ、エンジニア、アーキテクトに対してアドバイスを行っており、サステナビリティと実践的な設計に深く注力しています。余暇には、アウトドアや写真撮影、家中を走り回る子どもたちを追いかけて楽しんでいます。 翻訳者について 齋藤 拓巳 ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。AWS Lambda や Amazon API Gateway などのサーバレスのサービスが好きです。

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） を参照してください。 原文は こちら です。

こんにちは！サイオステクノロジーの貝野です。 今回は、keycloak を用いて簡単な SSO 認証を行うまでの手順をご紹介します。 keycloak を使うと様々なアプリケーションとやサービスと連携することができますが、今回は簡単なテストアプリを用いて SSO 認証を実現してみます。 環境構成・インストール 下記の構成で keycloak の構築を行いました。 テストアプリは python OS：RHEL9 (AWS 上) keycloak のバージョン：26.6.63 (検証時点での最新バージョン) Java のバージョン：OpenJDK21 またインストールの手順については、過去の記事 ( keycloak インストール時につまずいた話 ) にてご紹介しているため、こちらも併せて見ていただければと思います。 簡単な手順としては、下記の通りとなります。 Java 関連パッケージ (openjdk および openjdk-devel) をインストール https://www.keycloak.org/downloads から keycloak (tar.gz 形式) をダウンロード ダウンロードしたパッケージを、任意のディレクトリ配下に展開 # tar -xvf keycloak-26.6.63.tar.gz -C bin/kc.sh bootstrap-admin user で管理者アカウント作成 bin/kc.sh start-dev を実行 http://[ホスト名もしくは IP アドレス]:8080/admin へアクセス ※4 で作成したユーザ名とパスワードでログイン レルムの作成 Keycloak では、レルムという単位でユーザ、アプリケーションを管理します。 デフォルトでは master というレルムがありますが、今回はテストアプリ用に新しいレルムを作成します。 画面左側より Manager realms → Create realm を押下します。 Realm name に新しく作成するレルム名を入力し、Create を押下します。 1 の画面に戻るため、今作成したレルムが追加されていることを確認します。 ユーザの作成 新しく作成されたレルムにはユーザが存在しません。 そこで、新しくユーザを作成します。 画面左側より Users → Create new user を押下します。 ※左上の Current realm が、先ほど作成したレルムになっているか確認して下さい。 Username を入力し、Create を押下します。 保存が完了したら、下記の様な画面が表示されます。 次に、Credentials タブを押下します。 Set password を押下します。 パスワードを設定し、Save を押下します。 keycloak の設定 (クライアントの作成) テストアプリ用に新しいクライアントを作成します。 画面左側より Clients → Create client を押下します。 ※左上の Current realm が、先ほど作成したレルムになっているか確認して下さい。 Client ID、Name (任意) を入力し、Next を押下します。 Client Authentication を ON にし、Next を押下します (テストアプリが keycloak に対しクライアント認証を行うために必要な設定となります)。 Valid redirect URIs、Web origins をそれぞれ下記のように入力し、Save を押下します。 ・Valid redirect URIs: http://xxx.xxx.xxx.xxx:5000/callback (認証時のリダイレクト先 URL) ・Web origins: http://xxx.xxx.xxx.xxx:5000 (keycloak へのリクエストを許可する URL) 保存が完了したら、下記の様な画面が表示されます。 【ここからテストアプリ用の作業】 次に、Credentials タブを押下します。 Client Secret の内容をコピーします。 デフォルトでは非表示となっているため、目のマークを押下して内容を表示します (コピーした内容は、後ほどテストアプリで使用します)。 Credentials テスト用アプリ (app.py) の作成 app.py というファイルを作成し、下記の内容を記述します。 ★行を、任意の内容に変更してください。 from flask import Flask, url_for, session, redirect from authlib.integrations.flask_client import OAuth app = Flask(__name__) app.secret_key = 'random-secret-string' # --- 設定項目 --- KEYCLOAK_IP = "xxx.xxx.xxx.xxx" ★IP アドレス CLIENT_ID = "testapp1" ★アプリの名称 CLIENT_SECRET = "xxxxxxxxxxxxxxxxxxxxxxx" ★コピーした Client secret の内容 REALM = "test realm1" ★作成したレルム名 # ---------------- oauth = OAuth(app) keycloak = oauth.register( name='keycloak', client_id=CLIENT_ID, client_secret=CLIENT_SECRET, server_metadata_url=f'http://{KEYCLOAK_IP}:8080/realms/{REALM}/.well-known/openid-configuration', client_kwargs={'scope': 'openid profile email'}, ) @app.route('/') def index(): user = session.get('user') if user: return f'Hello, {user["name"]} !! ログアウト ' return 'テストアプリ Keycloakでログイン ' @app.route('/login') def login(): redirect_uri = url_for('auth', _external=True) return keycloak.authorize_redirect(redirect_uri) @app.route('/callback') def auth(): token = keycloak.authorize_access_token() session['user'] = token.get('userinfo') return redirect('/') @app.route('/logout') def logout(): session.pop('user', None) return redirect('/') if __name__ == '__main__': app.run(port=5000) 動作確認 ターミナルで、上記で作成したアプリを起動します。 # python app.py * Serving Flask app 'app' * Debug mode: off WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead. * Running on all addresses (0.0.0.0) * Running on http://127.0.0.1:5000 * Running on http://xxx.xxx.xxx.xxx:5000 Press CTRL+C to quit http://xxx.xxx.xxx.xxx:5000 と入力すると、下記の画面が表示されます。 ※xxx.xxx.xxx.xxx には IP アドレス等を入力してください。 Username or email、Password に、先ほど作成したユーザ、パスワードをそれぞれ入力し、 Sign In を押下します。 ※初回ログイン時、パスワード変更の画面が表示されます。 この動作はユーザ作成時の設定によって異なる場合がありますが、この点についての詳細は別の記事で説明させていただきます。 同様に、ユーザのアカウント情報をアップデートする旨の画面が表示されるため、Email、First name、Last name をそれぞれ入力し、Submit を押下します。 下記の「Login success!」の画面が表示されれば、認証成功です！ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Keycloak を用いた簡単な SSO 認証 first appeared on SIOS Tech Lab .