この記事はHTアドベントカレンダー25日目の記事です。メリークリスマス🎄

TL;DR

初めての re:Invent 参加で「AIエージェントによるSaaS運用自動化」「マルチクラウドのコスト可視化（FOCUS）」「ECS Observability」の3テーマを重点的に吸収
AIエージェントを使うことで、SaaSのノイジーネイバー検出やテナント移行が自然言語で進む世界を体験。本番投入には権限設計と誤操作対策が必須
マルチクラウドのコスト管理では、FOCUS によって各クラウドのバラバラな請求データを共通形式で扱い、ビジネス指標と組み合わせて分析できる利点を再認識
Observability では、技術メトリクスよりもまず「ビジネスへの影響」を重視
振り返ると、Breakout よりも Workshop / Chalk Talk / Expo にもっと時間を割くべきだったという反省が大きい
記事の最後で、自分の環境で試したいこと（運用エージェント、FOCUS 導入、ビジネスメトリクス可視化）を整理

はじめに

インフラエンジニアをしている宮田です。今年12月にラスベガスで開催された AWS re:Invent に初めて参加してきました。

行く前は「YouTubeで録画が見られるし、本当にラスベガスまで行く価値あるのかな?」と思っていましたが、実際に参加してみるとその考えは大きく変わりました。Workshop、GameDay、Chalk Talk のような参加型セッションはそもそも録画が公開されませんし、AWSのエンジニアや同じような課題を抱える参加者と議論したり、その場で手を動かしたりする体験は現地ならではの価値がありました。

この記事ではre:Inventで参加したセッションのうち、SaaS運用自動化、マルチクラウドコスト管理、コンテナObservabilityという3つのテーマについて書きます。どれも複数プロダクトを運用している環境だと、多かれ少なかれ悩んでいる部分じゃないかなと思います。

1. AIエージェントによるSaaS運用の自動化

セッション: Agents meet SaaS operations: A natural fit (Workshop)

概要

このWorkshop は6グループに分かれており、私が参加したグループは担当のAWS エンジニア1人と参加者 3 人の構成でした。

テーマは複数の顧客でインフラを共有するpool型のSaaS環境で、大量のリクエストを送ってくる顧客（ノイジーネイバー）を探し出し、その顧客を専用インフラに分離するsilo型へ移行する作業を、Amazon Q Developerと自然言語で対話するだけで実行するという内容でした。

図: Workshopで使われたマルチテナントSaaSの3層アーキテクチャ構成

Workshopのアーキテクチャは、マルチテナントSaaSを3層構造で実現しています：

【Webレイヤー（共有）】

CloudFront ＋ S3 で全テナント共通のフロントエンドを提供

【アプリケーションレイヤー（Pool型 / Silo型）】

Pool型（Basic/Demo tier）：
共有の API Gateway → Lambda → DynamoDB で複数テナントをホスト（コスト効率は高いがノイジーネイバーが出やすい）
Silo型（Platinum tier）：
テナント専用の API Gateway → Lambda → DynamoDB を用意し、分離性とパフォーマンスの予測可能性を高める

【コントロールプレーン】

テナント管理（テナント情報、tier管理、認証・認可）
リソースプロビジョニング
使用状況の追跡とノイジーネイバー検出、移行判断

セッションの内容

1. ノイジーネイバーの自動検出

q chatコマンドまたはkilo cliコマンドでAmazon Qを起動し、以下の自然言語で質問するだけで分析を依頼することができます。

Detect noisy neighbours using natural language queries with Amazon Q

Qが自動的にツールを呼び出してテナント一覧を取得し、CloudWatch ログを分析し、その結果として以下の違反テナントが検出されました。これらの結果が数分以内に自動で集計・出力されるのを見て、実運用での適用可能性を強く感じました。

検出結果サマリー：

分析期間: 過去24時間

BASIC Cellの総リクエスト数: 169,244件

検出基準: 総リクエストの40%以上 または 500件/時間以上の注文

違反が検出されたテナント：

リクエスト割合での違反:

TENANT_AAA (DEMO tier) - 26,430 requests (15.6%) / 4,710 orders/hour

TENANT_BBB (DEMO tier) - 26,343 requests (15.6%) / 4,731 orders/hour

TENANT_CCC (BASIC tier) - 26,249 requests (15.5%) / 4,701 orders/hour

注文数での違反（500件/時間超過）:

TENANT_EEE (BASIC): 750 orders/hour

TENANT_FFF (BASIC): 723 orders/hour

TENANT_III (BASIC): 672 orders/hour

TENANT_MMM (DEMO): 636 orders/hour

TENANT_NNN (BASIC): 615 orders/hour

推奨アクション：

BASIC tierのノイジーネイバー → PLATINUM tierへの移行を推奨

DEMO tierのノイジーネイバー → 対応方針の確認が必要

実際のチャットログを見る

> Detect noisy neighbours using natural language queries with Amazon Q

> Rule used: 

> Good as gold! Got a decent mix of tenants here - looks like we've got 7 BASIC tier tenants, 7 DEMO tier tenants, and 2 PLATINUM tier tenants...

Now let me check the CloudWatch logs to see which of these buggers are being noisy neighbours.

🛠️  Using tool: describe_log_groups from mcp server awslabs.cloudwatch-mcp-server
🛠️  Using tool: execute_log_insights_query from mcp server awslabs.cloudwatch-mcp-server

## NOISY NEIGHBOUR DETECTION RESULTS

Analysis Period: Last 24 hours
Total API Requests in BASIC Cell: 169,244
Detection Criteria: >40% of total requests OR >500 orders per hour

### VIOLATIONS DETECTED:

REQUEST PERCENTAGE VIOLATIONS
1. TENANT_AAA (DEMO tier)
   • 26,430 requests (15.6% of total)
   • 4,710 orders per hour

2. TENANT_BBB (DEMO tier)  
   • 26,343 requests (15.6% of total)
   • 4,731 orders per hour

3. TENANT_CCC (BASIC tier)
   • 26,249 requests (15.5% of total)  
   • 4,701 orders per hour

{省略)

ORDERS PER HOUR VIOLATIONS (>500 threshold):
All four tenants above are also massively exceeding the 500 orders per hour limit!

Additional tenants exceeding orders threshold:
• TENANT_EEE (BASIC): 750 orders/hour
• TENANT_FFF (BASIC): 723 orders/hour  
• TENANT_III (BASIC): 672 orders/hour
• TENANT_MMM (DEMO): 636 orders/hour
• TENANT_NNN (BASIC): 615 orders/hour

### RECOMMENDATIONS:
For BASIC tier noisy neighbours: RECOMMEND migration to PLATINUM tier
For DEMO tier noisy neighbours: Need guidance on how to proceed

2. 詳細分析

特定のテナントについて、以下の自然言語でさらに深掘りできます。

Show me the endpoint usage breakdown for tenant TENANT_NNN

Qがエンドポイント別の使用状況を分析した結果:

エンドポイント使用内訳（TENANT_NNN / 過去24時間）：

総リクエスト数: 3,831件

エンドポイント別の内訳：

GET /products - 3,164 requests (82.6%) - 商品閲覧が大半

GET /orders - 390 requests (10.2%) - 注文確認

PUT /orders/{id} - 150 requests (3.9%) - 注文更新

POST /orders - 75 requests (2.0%) - 新規注文

その他（ユーザー管理、商品登録など）- 52 requests (1.4%)

分析結果：

このテナントは商品閲覧に特化したトラフィックパターン（82.6%）を示しており、通常のECサイト利用パターン（多くの閲覧、少数の注文）に合致しています。異常なパターンは見られません。

実際のチャットログを見る


> Show me the endpoint usage breakdown for tenant TENANT_NNN

> Right, let me break down the endpoint usage for tenant TENANT_NNN over the last 24 hours.

🛠️  Using tool: execute_log_insights_query (trusted) from mcp server awslabs.cloudwatch-mcp-server

ENDPOINT USAGE BREAKDOWN:

Total Requests: 3,831

1. GET /products - 3,164 requests (82.6%)
   • Crikey, this tenant's really keen on browsing products!

2. GET /orders - 390 requests (10.2%)
   • Checking orders regularly

3. PUT /orders/{id} - 150 requests (3.9%)
   • Updating existing orders

4. POST /orders - 75 requests (2.0%)
   • Creating new orders

5. DELETE /users/{id} - 20 requests (0.5%)
6. POST /users - 20 requests (0.5%)
7. POST /products - 12 requests (0.3%)

ANALYSIS:
• This tenant is heavily product-focused (82.6% of traffic)
• Normal e-commerce pattern: lots of browsing, some ordering
• No concerning patterns - just a busy shopper!

3. 移行の実行

検出結果に基づいて以下の自然言語で実際に移行を実行します。

Migrate high-usage Basic-tier customers to the Platinum tier.

Qが移行を実行し、以下の結果が得られました：

移行結果サマリー：

テナントID: TENANT_CCC

移行元: BASIC tier (shared cell)

移行先: PLATINUM tier (dedicated cell)

ステータス: 開始済み

この移行による効果：

✅ 高負荷テナント専用のPLATINUM Cellを作成

✅ 共有BASIC Cellから26,249リクエスト（18%の負荷）を削減

✅ 残りのBASIC tierテナントのパフォーマンス向上

✅ 顧客により良い分離性と専用リソースを提供

このように自然言語での指示だけで複雑なインフラ移行作業が実行できました。
ただし実行前にはユーザーの承認が必要で誤操作を防ぐ仕組みが組み込まれています。

実際のチャットログを見る


> Migrate high-usage Basic-tier customers to the Platinum tier.

> Rule used: 

> migrate tenant TENANT_CCC to PLATINUM tier

> Right, let's migrate that noisy neighbour to their own PLATINUM cell!

🛠️  Using tool: TenantMgmt___MigrateTenant from mcp server agentcore-saasapp-mcp
Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> Sweet as! Migration has been initiated for tenant TENANT_CCC from BASIC to PLATINUM tier.

MIGRATION STATUS: Started
• Tenant ID: TENANT_CCC
• From: BASIC (shared cell)
• To: PLATINUM (dedicated cell)

This will:
✅ Create a dedicated PLATINUM cell for this high-demand tenant
✅ Remove 26,249 requests (18% load) from the shared basic cell
✅ Improve performance for remaining basic tier tenants
✅ Give this customer better isolation and dedicated resources

学んだこと/印象に残ったこと

ルールファイルで誰でも運用できる設計

エージェントの判断基準をMarkdown形式のルールファイルで定義できるため、非エンジニアでも運用ルールを記述できます。例えば「総リクエストの40%以上を消費するテナントを検出」「PLATINUM移行を推奨（ユーザー承認必須）」といったルールを自然言語で書けるのがシンプルで良かったです。

誤操作防止の重要性

営業チーム向けエージェントではDeleteTenantツールを明示的に除外するなど、権限制御が細かく設定されていました。こういった配慮がないと、意図しないリソース削除が起きてしまうので注意が必要だと感じました。

Slack連携で属人化解消

「過去24時間でエラー率が高いリソースは？」といった質問を毎回CloudWatchで調べるのではなく、Slackで自然言語で聞けるようになればチーム全体で情報共有しやすくなり運用の属人化解消につながりそうです。

実務にどう活かせそうか

クラウド運用において、「過去24時間でエラー率が高いリソースは？」のような質問に答える際、毎回管理コンソールで調べているのですが、これを自然言語で聞けるような仕組みを検討していきたいです。
ただし、いきなり本番環境で実行可能なエージェントを導入するのはリスクが高いため、まずはread-only権限のエージェントから試していければと思います。分析と推奨だけを行い、実際のアクション（リソース変更など）は必ず人間が承認する形で進められればと考えています。

あと、エージェントを入れる場合、Bedrockのトークン課金、AgentCore Runtime実行課金、Lambda、CloudWatch Logs Insightsクエリ課金などの料金も調べて、コストに見合うかを見極める必要があると感じました。

2. マルチクラウドのコスト可視化

セッション: Achieve multicloud FinOps visibility (Chalk Talk)

概要

Chalk Talk形式で、30人ほどの規模でスピーカーと参加者が対話しながら進めるセッションでした。

マルチクラウド環境におけるコスト管理の課題として、「クラウドごとに請求データの形式や用語が異なる」ことが大きな障壁である点が強調され、これを解決するアプローチとして FOCUS（FinOps Open Cost and Usage Specification） が中心的に議論されました。

冒頭でスピーカーが「マルチクラウドで一番大変なことは？」と問いかけた際、参加者からは「データフォーマットがバラバラ」「クラウドごとにメタデータや用語が違う」といった声が多く上がり、共通課題として認識されていました。

セッション中、スピーカーはFOCUSのダッシュボードを使って説明していました。

図: セッション中に表示されたFOCUSのダッシュボード

セッションの内容

1. FOCUS の概要の説明

FOCUS は FinOps Foundation が主導するオープン仕様で、複数クラウドのコスト／使用量データを共通スキーマで扱うための標準です。

プロジェクトは Linux Foundation での立ち上げを経て、現在は FinOps Foundation によって管理されています。

AWS、Azure、Google など複数のハイパークラウドベンダーが、この仕様の採用を公式に支持しており、各社が自社の請求データを FOCUS 形式で提供する取り組みを進めています。

2. セキュリティのベストプラクティス

スピーカーが会場に「Management Accountでコストデータを扱うべきか？」と質問したら、複数の人が一斉に「No！」と回答しました。専用のFinOpsアカウントを作るべきという話で、コスト分析のためのデータをManagement Accountに集めるのは避けるべきだ、という内容でした。

3. ビジネスメトリクスとの結合デモ

QuickSightに「顧客数」「注文数」などのビジネスデータを持ち込み、FOCUSのコストデータと結合するデモがありました。

例：「クラウド支出 vs 顧客あたりコスト」を可視化して、「コストは増えたけど顧客あたりコストは20%削減できた」という説明ができるようになります。

学んだこと/印象に残ったこと

業界標準化の動き

マルチクラウドのコスト可視化が業界標準として整備されつつあるのは驚きでした。AWS、Azure、Googleのような大手がOSSコミュニティに参加しているらしく、それだけFinOpsが重要視されているようです。

ビジネスメトリクスとの結合の重要性

技術的なコストデータだけじゃなくて、ビジネスデータと組み合わせると、経営層への説明がしやすくなると感じました。「コストが増えた」じゃなくて「効率が上がった」って説明できるのが大きいです。

実務にどう活かせそうか

FOCUSの導入検討について

CloudFormationテンプレートが提供されているので、まずはAWS単体でFOCUSデータを可視化する仕組みづくりの検討から始められればと思います。

マルチアカウント環境・マルチクラウドでの活用について

我々は複数プロダクトでマルチアカウント/マルチクラウドでリソース管理しているので、この仕組みをコスト可視化に使えそうです。アカウントやクラウドをまたいでコスト分析できる仕組みを作っていければと思います。

ビジネスメトリクスとの統合について

「顧客あたりのLLMコストやコンピュートコスト」とか「トランザクション1件あたりのコンピュートコスト」みたいな指標を出せれば、ビジネス側との会話もしやすくなると思います。単に「コスト削減しました」じゃなくて、「ビジネス価値に対してこれだけ効率化しました」って説明できるようにしたいです。

3. ECS の Observability パターンと設計

セッション: Amazon ECS observability patterns and design decisions (Chalk Talk)

概要

Chalk Talk形式で、ECSでのObservabilityのベストプラクティスについて、スピーカーと参加者が対話しながら進めるセッションでした。ログの構造化、ビジネスメトリクスの重要性、ECSでのログ実装パターン、Application Signalsの導入方法などについて議論しました。

セッションの内容

1. ビジネスメトリクスの重要性

スピーカーが会場に「システムの一番大事なメトリクスは何だと思う？」って質問していました。参加者からは「レスポンス時間」「CPU使用率」「メモリ使用率」「エラー率」といった技術メトリクスが挙がっていました。私もレスポンス時間やメモリ使用率は大事かなとその時は考えていました。

しかし、スピーカーは「まず考えるべきは、そのアプリが何のために作られたか。そのような技術メトリクスも大事だけど、ビジネス成果のメトリクスをもっと重視すべき」って話していて、下記のような例を挙げていました：

CPUが80%になっててもビジネスに影響が出てない → 緊急度は低い
CPUが50%でもビジネスメトリクス（注文数とか）が落ちてる → これは重大インシデント

2. ECSでのログ実装パターン

awslogs driver（デフォルト）: 一番シンプル。non-blockingがデフォルトで、ログ送信が失敗してもアプリは止まらない
FireLens: もっと柔軟にログをルーティングしたいとき。サイドカーコンテナとして動いて、メタデータも追加で取れる

3. Application Signalsの導入

Java、Python、.NETで使えるauto-instrumentation機能です。Pythonなら5行のコードでinstrumentationできるという説明がありました。

セッション中、私は「ECSでも簡単にAPMを有効化できるのか？」と疑問を持っていました。セッション終了後にスピーカーに直接聞いてみたところ、「EKSとLambdaは簡単だけど、ECSはまだtask definitionに環境変数追加したりとか、ステップが結構ある。でも一回やればそんなに難しくないよ」という回答でした。
正直なところ、このあたりは今後もう少し簡単にしてほしいと感じました。EKSやLambdaと同じくらいの手軽さで有効化できるようになれば、ECSでのAPM活用も一気に進みそうです。

学んだこと/印象に残ったこと

自分のログ設計が間違っていなかった安心感

セッション中、スピーカーがホワイトボードに以下のようなECSのObservabilityベストプラクティスを図示してくれました。

図：セッション中にホワイトボードに描かれた構成図

これにより、ECSのObservabilityベストプラクティス（FireLensによる柔軟なログルーティング、JSON構造化ログ、non-blockingの思想、Application Signalsによるトレーシング）が、今自分が検討していた設計とほぼ一致していて、ほっとしました。

ビジネスメトリクスファースト

CPU使用率やメモリ使用率などのメトリクスが異常でも、結局「で、ビジネスにどう影響してんの？」って観点だとユーザー影響は少ない可能性もあります。マルチテナントSaaS環境でもアラートが発生してから「どのユーザーにどのような影響があったか」を調べているのが現状で、これをリアルタイムでモニタリングできるようになると良いなと思いました。

実務にどう活かせそうか

このセッションで一番印象に残ったのは「ビジネスメトリクスファースト」って考え方です。今までCPU使用率とかメモリ使用率みたいな技術メトリクス中心に監視してたんですが、ビジネスへの影響とかユーザー体験を重視した監視の仕組みを作っていきたいです。

基盤の整備について

Application Signals（APM）の導入検討: ECSでのApplication Signals導入は、AWSが今後もっと簡単にしてくれるのを期待しつつ進めるのが吉

ビジネスメトリクスの可視化について

今まであまり意識できていなかったビジネスメトリクスについて、以下の指標をリアルタイムでモニタリングできる仕組みを検討していきたいです：

ビジネス影響指標:

トランザクション成功率（時間帯別、顧客別）- ユーザーが実際に処理を完了できているか
ユーザー環境でのエラー発生率（どの顧客で多いか、どのエンドポイントか）- ユーザー満足度への直接的な影響
ピークタイムの応答時間 - ビジネスクリティカルな時間帯でのパフォーマンス

ユーザー体験指標:

CloudWatch RUM（Real User Monitoring）の導入検討 - 実際のユーザーブラウザでのページロード時間やJavaScriptエラーを計測できればと思います
API応答時間のパーセンタイル分析（P50, P95, P99）- 一部のユーザーだけが遅延を経験していないかを把握したいです

これらをダッシュボードで可視化して、ビジネス側にリアルタイムで共有できるようにしたいです。技術チームだけじゃなくて、営業やカスタマーサクセスチームも見られるようなダッシュボードにできればいいなと思います。

AIエージェントとの統合について

セッション1とも関連しますが、エージェント経由でメトリクス確認できるようにするのも有用そうです。例えば：

「過去1時間で顧客Aのエラー率が急増している理由は？」
「現在パフォーマンスが低下している顧客はどこ？影響範囲は？」

みたいな質問に自然言語で答えられるエージェントを作れれば、障害対応も早くなるし、ビジネスへの影響範囲もすぐ把握できるようになりそうです。

反省：もっとできたこと

3つのセッションに参加して多くの学びがありましたが、振り返ってみると「もっとできたこと」もたくさんありました。

次回はWorkshopやChalk Talkにより多くの時間を割きたい

上記で紹介した3つのセッション以外にも、複数のBreakout Sessionに参加していました。しかし、振り返ってみると、Breakout Sessionは数日以内にYouTubeで公開される（字幕付きで） ため、現地参加者の反応を見たいなどの特別な理由がない限り、参加する優先度は低かったかもしれません。

録画で見られる内容に貴重な現地時間を使うより、その時間を以下のような「現地でしかできないこと」に費やすべきでした：

Workshop: 手を動かしながら学べる（録画なし）
Chalk Talk: スピーカーや参加者と対話する（録画なし）
Expo: 展示ブースで製品の話を聞く
ネットワーキング: AWS Community Buildersや同じ課題を持つ人と交流

次回はセッション登録の段階で「このセッションは録画を待てば十分か？それとも現地参加に価値があるか？」を判断基準にしたいです。

Expoをもっと活用すべきだった

もう一つの大きな反省は、Expo（展示ブース）を見て回る時間が少なかったことです。

Expoには日本では話を聞く機会の少ない企業が多数出展していました。例えば：

グローバルなSaaSベンダー
クラウドセキュリティ企業
データ分析・可視化ツール
最新のObservabilityツール

こういった企業のブースでは、単なる製品紹介だけでなく「顧客がどんな課題を抱えていて、この製品が何を解決したのか」といった具体的なユースケースを聞けます。これはプロダクト設計にも活かせる貴重な情報です。

特に同じような課題（マルチテナント運用、コスト最適化、Observability強化など）に対して、他社がどのようなソリューションを使っているのかを知るチャンスでした。次回はExpoに半日〜1日は時間を確保したいです。

セッション中に質問できなかった

自分の英語が伝わるか不安でセッション中には質問せずに、終了後にスピーカーのところへ個別に話を聞きに行く、という動き方をしていました。
ただこのやり方だと、スピーカーが忙しかったり、他の参加者の列ができていたりして待ち時間が長くなり次のセッションに影響する場面もありました。

一方で非ネイティブの参加者も含めて多くの人がセッション中に普通に質問していました。完璧な英語でなくても意図が伝われば十分だなと思いました。Chalk Talkはもともと「質問・議論するための場」なので、次回はもっと積極的にその場で質問していきたいと感じました。

おわりに

反省点はいくつかありますが、それを踏まえても現地参加には大きな価値がありました。

録画では得られない体験

最初は「YouTubeで録画を見られるし、わざわざラスベガスまで行く価値あるのかな」と半信半疑だったのですが、考えが変わりました。Workshop、GameDay、Chalk Talkは録画が公開されませんし、現地では以下のような体験ができます。これは録画では絶対に得られない体験です。

手を動かしながら学べる
ホワイトボードを囲んでチームで議論できる
その場でスピーカーに質問できる
参加者同士で知見を交換できる

学んだことで試したいこと

Amazon Q Developer/CloudWatch MCPサーバーを使った運用エージェント → read-onlyエージェントから試す
FOCUSのようなコスト関係サービスの検討・検証 → マルチクラウドのコスト可視化
Observabilityにおけるビジネスメトリクス可視化（トランザクション数、処理成功率、顧客別エラー率）

ビジネス価値の観点から

今回学んだ内容は、単なる技術トレンド紹介にとどまらず、運用コストの削減、障害対応時間の短縮、ビジネスインパクトの可視化といった、直接的なビジネス価値に結びつくものばかりでした。特に、AIエージェントによる運用自動化は、人手不足が課題となるこれからの運用現場において重要な選択肢になっていくと感じています。

これらを実装するとビジネスチームやアプリチームにとっては以下のようなメリットがあるため、優先度を考えながら検討できればと思います。

どの機能にどれだけコストがかかっているか見える: これまで「AWS全体でいくら」みたいな粒度でしか見えていなかったのが、「この機能のこのAPIでこれだけかかっている」というレベルで分かるようになります。そうすると、新機能を作るときの優先順位とか、価格設定を考えるときの材料になります
障害対応が早くなる: エージェントが初動調査や影響範囲の特定を手伝ってくれれば、その分カスタマーサクセスチームが早く顧客対応できるようになります
技術チームとビジネスチームの会話がしやすくなる: 技術的な問題がビジネスにどう影響しているのかが見えるようになれば、お互いの状況が理解しやすくなって、連携もスムーズになるはずです

初めての re:Invent 参加でしたが、反省点も含めて本当に貴重な経験になりました。技術的な知識だけじゃなくて「AIエージェントによる運用の自動化」や「ビジネスメトリクスファーストの考え方」のような今後の仕事の進め方に影響を与える学びが多かったです。

来年また行けるなら、今回の反省を活かして積極的にWorkshopやExpoに時間を使いたいと思います。

この記事が同じような環境でインフラ運用している人やre:Invent に行こうか迷っている人の参考になれば嬉しいです。