AWS CloudShellは30分で切れる──その制限を前提に設計すべき理由

1人アドベントカレンダー2025 19日目。

CloudShellは、踏み台サーバ等を用意せずにAWS CLIを実行できる便利なツールです。

私もよく使うのですが、ちょっとした作業はいいのですが重たい作業をするとセッション切れの問題が起こり使えなくなります。

今回は、それでもCloudShellを使いたい! 時のために、工夫した話です。

はじめに

AWS CloudShell は、
「ブラウザからすぐに AWS CLI が使える」便利な環境です。

一方で、使い始めてしばらくすると必ず気づく制限があります。

CloudShell のセッションは、一定時間で切れます（おおよそ 30 分）。

本記事では、この制限下でも使いたい場合、

30 分で切れる前提で、どう使うべきか

という設計・運用の観点で整理します。

CloudShell の 30 分制限とは

CloudShellは、一定時間操作がない、
あるいは長時間実行される処理があると、
セッションが自動的に終了します。

• 処理途中でも切れる
• 実行中のスクリプトは容赦なく止まる
• 再接続しても、プロセスは復元されない

これはAWSの仕様です。

ありがちな使い方（そして起きる問題）

本番環境やそれに準ずる環境でバッチ等を用意するまででもないようなデータの集計等を行いたい場合、例えば下記のようなことをしたくなる場合があります。

• DynamoDBの全件Scan/バックアップ検証
• CloudWatch Logsの大量取得
• S3/DynamoDBのデータ移行
• 1時間以上かかるバッチの手動実行

限られたIAMでしか操作ができない（ローカルのAWS CLIが使えない）けど、バッチ処理をデプロイするほどでもない調査フェーズで対応したい場合にCloudShellでの操作が視野に入ってきます。

30 分経って、途中で切れる

ところが、CloudShellの場合は、重たい処理になると途中でセッションが切れて処理は中断されてしまいます。
「どこまで終わったか分からない」状態になります。

問題は「制限」ではなく「前提のズレ」

ここで重要なのは、

CloudShell が悪いわけではない

という点です。

CloudShell はそもそも、

• 短時間の調査
• 設定確認
• コマンドの試行
• 軽い運用作業

を目的とした環境です。

長時間・再実行が難しい処理を任せるサービスではありません。

このため、この制限を考慮して、利用することを考えなくてはいけません。

CloudShell に向いていること

CloudShellが得意なのは、次のような作業です。

• AWS CLI のワンショット実行
• describe / list 系の確認
• IAM / 設定の即時チェック
• 小さな検証スクリプトの実行
• 「まず試す」ための叩き台

応答が早い操作（セッション切れを気にせず、30分以内で終わる前提の作業）には、非常に向いています。

CloudShell に向いていないこと

逆に、次のような用途には向いていません。

• 全件処理・大量データ処理
• 途中再開ができないバッチ
• 数十分〜数時間かかる処理
• 本番データの一括移行
• 失敗時のリトライが必要な作業

よくある誤解

「途中まで終わっているはず」

→ CloudShellは
状態管理をしてくれません。

CloudShell自体は、途中からの再開をサポートしていません。

「もう一回やればいい」

全件処理の場合、
二重実行・不整合の原因になります。

セッションが切れると最初からやり直しになるため、繰り返し実行しても完了しません（たまたま30分以内に処理が終われば成功しますが、運任せです）。

「Enter を押せば延命できる」は幻想

「実行中に空行で Enter を押せば、操作としてカウントされるのでは？」

私も最初そう思いましたが、結論から言うと意味がありません。

なぜ Enter が効かないのか

ポイントは**「どこに入力が届いているか」**です。

実行中のプロセスがある場合：

• Enter を押す → 入力は実行中プロセスに送られる
• シェル（bash）は入力を受け取らない
• CloudShell側から見ると → 「シェルへの操作なし」

つまり、Enter を押しても"操作あり"としてカウントされません。

※AWS公式のAWS CloudShell の Service Quotas と制限: シェルセッションでも、実行中のプロセスは、*操作数としてカウントされません。*と書かれています。

では、どう設計すべきか

ポイントはシンプルです。

CloudShellは「作業環境」ではなく「操作端末」として利用する

• 処理は別の場所で走らせる
• CloudShell からは「確認作業」「調査作業」だけ行う

長時間処理は「止まらない場所」に任せる

• EC2
• ECS / Fargate
• Step Functions
• Lambda（分割できる場合）
• Batch / Glue

CloudShellはトリガー役に徹します。

それでもCloudShellで作業したかったときにやったこと

「長時間処理は別基盤へ」が正論なのは分かっていましたが、
調査・検証フェーズではCloudShellで作業したい場面もありました。

その際に意識したのは、

途中で切れても、壊れないこと

です。

出力は必ずS3に書き出す

処理結果をローカルに持たず、
一定件数ごとにS3に出力するようにしました。

• CloudShellが切れても成果は残る
• 再実行しても二重処理になりにくい

処理は最初から「再開前提」で分割する

全件を一度に処理するのではなく、

• 対象を範囲で分割
• 1回の実行が30分以内に終わる粒度に調整

「途中から再開できる」ことを前提にしました。

並列化して「時間制限内」に収める

可能な処理は並列実行し、
CloudShellの制限時間内で完走できるようにしました。

重要なのは、

CloudShellを延命することではなく、
CloudShellが切れても成立する形に寄せること

でした。

DynamoDB設計の失敗と学びでも書きましたが、
「後から何とかする」ではなく「最初から制限を前提にする」という考え方は、ツールを問わず共通しています。

まとめ

CloudShellの30分制限は、CloudShellがブラウザベースで手軽にAWS CLIコマンドを実行できる環境として提供されていると考えると、真っ当な仕様です。

この前提で利用するようにするのが良いと思います。

• 短時間で終わる作業は CloudShell
• 長時間・重要な処理は別の実行基盤

この線引きを最初から意識しておくことで、
CloudShell はとても安全で便利な道具になります。

EC2を用意したり停止し忘れたりする作業コストやリスクよりも、CloudShellで実行することのメリットのほうが高い場合もあると思います。

※ 余談ですが、CloudShellはコンソールにログインしたユーザーのクレデンシャルで実行されるため、特に何も準備しなくとも「誰が何を実行したか」がCloudTrail上で明確になりやすいメリットもあります。

おわりに

無料で、特にセッティングせずとも、AWSコンソールからAWS CLIがすぐに実行できるCloudShellはとても便利なツールです。

制限を分かった上で、手軽に利用できる環境をより安全に使えるので、ぜひ利用してみてください。

明日は「AIで会社HPを作って1年運用してわかったこと」を書く予定です。

📚 1人アドベントカレンダー2025 全記事一覧

---

megusunu

🐦 X (@megusunu)
🧶 megusunuLab（ハンドメイド）
🏢 Wells合同会社