AWS CloudShell got a visual editor on 17 August 2026 — and 3 limits that delete your work

Summary. AWS added a built-in visual file editor to AWS CloudShell on 17 August 2026, launched with a single edit command and available in every Region where CloudShell runs. The announcement names four workloads: scripts, infrastructure-as-code, agentic workflows, and AWS Lambda workflows. The AWS CloudShell User Guide, read the same week, sets limits that collide with three of those four. CloudShell VPC environments have no persistent storage at all and delete $HOME on timeout. Any CloudShell session ends after 20 to 30 minutes of inactivity, 10 minutes in AWS GovCloud (US), and the guide states plainly that running processes do not count as interactions. A session that stays busy still dies at roughly 12 hours. Standard environments keep 1 GB per Region on 1 vCPU and 2 GiB of RAM, and that 1 GB is deleted after 120 days without a session in that Region. CloudShell itself carries no additional charge. The guide's own document history has 16 entries and the newest is dated 2 October 2024, so the editor appears in none of them.

What actually shipped

The AWS What's New entry, posted 17 August 2026, describes a GUI editing surface reachable from inside the shell with no setup. AWS lists the capabilities as syntax highlighting, find-and-replace, multi-line selection, copy-paste, and undo-redo. The stated before-state is real friction: editing a file in CloudShell previously meant a terminal editor such as Vim or Emacs, or downloading the file, changing it locally, and re-uploading it.

The edit command is documented. It sits in the pre-installed software table in the CloudShell compute environment page, described as a visual editor supporting navigation, copy-paste, undo-redo, syntax highlighting, multi-line selection, block and line comment toggling, code folding, and find-replace. The Customizing AWS CloudShell page now gives edit .bashrc as a first-class alternative to vim .bashrc. So this is not vapourware, and the friction it removes is genuine.

The gap is between where AWS points the feature and where the environment can hold the work.

The three limits, and which workload each one breaks

AWS names four target workloads in the announcement: "updating a deployment script, modifying an agent steering file, editing an AWS CloudFormation template, or fixing an AWS Lambda function." Set each against the Service quotas and restrictions page.

Limit as documented	Standard CloudShell environment	CloudShell VPC environment	Workload it breaks
Persistent storage	1 GB per Region, in `$HOME`, no additional charge	None. `$HOME` is deleted on timeout or delete	CloudFormation templates and agent steering files edited against private resources
Idle timeout	20–30 minutes; 10 minutes in AWS GovCloud (US)	20–30 minutes; 10 minutes in GovCloud	Agentic runs, because running processes do not count as interaction
Maximum continuous session	About 12 hours, even with constant interaction	About 12 hours	Long deployments and multi-stage IaC applies
Environments per IAM principal	Not capped this way; 10 concurrent shells per Region	2 VPC environments per IAM principal	Parallel work across several VPCs
Storage retention when unused	Deleted 120 days after the last session in that Region	Not applicable; nothing persists	Region-specific scripts kept "just in case"

The first row is the one that matters most and it is the least visible. The limits page carries it as a note: CloudShell VPC environments do not have persistent storage, and the $HOME directory is deleted when the VPC environment times out or when you delete it. A VPC environment is exactly the configuration you reach for when the thing you are editing has to talk to a private subnet — an RDS instance without a public endpoint, an internal load balancer, a VPC-attached Lambda function. That is a large share of real infrastructure work. In that configuration, the new editor writes to a filesystem AWS has told you it will erase, and the erase trigger is 20 to 30 minutes of you not typing.

The second row breaks the agentic case on its own terms. The announcement calls out "modifying an agent steering file", and the CloudShell TOC lists a page for Kiro CLI in CloudShell, so agent work in the shell is intended. But an agent run is a long-running process that produces no keyboard or pointer input. The guide's wording is unambiguous: running processes don't count as interactions. Start a 40-minute agent loop, stop touching the browser tab, and the session that was supposed to supervise it ends first.

The third row is the ceiling nobody hits until they do. A session running continuously for roughly 12 hours ends automatically even when the user is interacting throughout.

Who this actually affects

You are exposed if any of the following is true. You use CloudShell VPC environments and keep working files in $HOME between sessions. You have started running agents or long build steps in CloudShell rather than on an instance. You keep the only copy of a deployment script or CloudFormation template in a CloudShell home directory in a Region you visit rarely.

You are largely fine if you use standard CloudShell environments as a console-adjacent terminal, commit everything to Git, and treat the 1 GB home directory as scratch. That is also what AWS advises: the security best practices page says to store your code securely in a version control system, and to prepare rollback mechanisms before editing shell scripts that affect the shell experience.

The compute ceiling deserves a line of its own. Each CloudShell environment gets 1 vCPU and 2 GiB of RAM with 1 GB of persistent storage. The same guide notes that Docker has limited space in the environment and that large or numerous pre-existing images cause problems. An editor, a container build, and a CDK synth inside 2 GiB is not a comfortable place to put a deployment pipeline.

What to do

Treat the editor as a fast way to fix a file, not a place to keep one. Four concrete changes, all inside the documented behaviour:

Commit before you walk away. In a VPC environment there is no 120-day grace period and no 1 GB of persistence to fall back on — a git push before the tab idles is the only thing standing between your edit and deletion. Standard environments give you more room but the same discipline applies.

Move long-running work off CloudShell. The guide recommends this itself: for terminal-based tasks against an AWS service with more flexible timeouts, launch and connect to an Amazon EC2 instance. An agent loop or a multi-stage Terraform apply belongs there or in a CI runner, not in a browser tab with a 20-minute idle fuse.

Check GovCloud separately. The 10-minute idle timeout in AWS GovCloud (US) is half the commercial figure, and teams that write runbooks against commercial behaviour will find GovCloud sessions gone in a third of the time they expected.

Audit your rarely-used Regions. Anything sitting in a CloudShell home directory in a Region you have not opened a session in is on a 120-day clock. Launching CloudShell in that Region resets it, which is a poor substitute for a repository.

India-specific considerations

Indian teams running console-first operations from Mumbai (ap-south-1) or Hyderabad (ap-south-2) get the same 1 GB per Region and the same timeouts, and the same $0 charge for CloudShell itself — AWS states CloudShell is available at no additional charge, with standard data transfer rates and the cost of any other AWS resources you run still applying. The practical exposure here is organisational rather than technical. Where a small platform team shares operational scripts through a console session instead of a repository, the 120-day deletion clock and the VPC environment's zero-persistence rule turn an informal habit into data loss. For teams handling personal data, the Digital Personal Data Protection Act 2023 makes the location and lifecycle of any file touched during an operational session a question worth answering before it is asked, and a browser-based home directory that AWS deletes on a schedule is a poor place for that answer to live.

What is still unknown

Three things the sources do not settle. The limits page states a monthly usage quota per Region combining all IAM principals but publishes no figure, pointing to the Service Quotas console instead, so the practical ceiling on CloudShell hours is account-specific and not readable from the documentation. The announcement says the editor is available in all Regions where CloudShell is available, but the Supported AWS Regions page defers entirely to the AWS Regional Services List rather than naming Regions, and VPC environments and Docker have historically been limited to certain Regions — so "all Regions where CloudShell is available" is a smaller set than "all AWS Regions" by an amount the page does not quantify.

The third is a documentation problem rather than a product one. The CloudShell User Guide document history contains 16 entries and the most recent is dated 2 October 2024, nearly two years before this launch. The visual file editor appears in zero of them, and the guide's 36-entry table of contents has no page for it — the feature is documented only as a row in a software table and a step in a shell-customisation walkthrough. The same history table still labels the shell's assistant "Amazon Q CLI" while the current table of contents calls it "Kiro CLI in CloudShell". When a service's own change log is two years stale, the limits pages are the only reliable record of what the environment will do to your files, which is exactly why they are worth reading before you trust the editor with anything.

FAQ

Does the CloudShell visual editor cost anything?

No. AWS states that CloudShell is available at no additional charge. You still pay for other AWS resources you run from the session, and standard data transfer rates apply. The editor is part of the shell environment, launched with the edit command, and AWS did not announce separate pricing for it on 17 August 2026.

Do CloudShell VPC environments keep my files between sessions?

No. The AWS CloudShell User Guide states that VPC environments do not have persistent storage and that the $HOME directory is deleted when the environment times out or when you delete it. Standard CloudShell environments are different: they keep 1 GB of persistent storage per Region in the home directory at no additional cost.

How long can a CloudShell session stay open?

A session ends after 20 to 30 minutes without keyboard or pointer interaction, and after 10 minutes in AWS GovCloud (US) Regions. A session that is interacted with continuously still ends automatically at approximately 12 hours. AWS documents both limits on its service quotas and restrictions page for CloudShell.

Will a long-running script keep my CloudShell session alive?

No. The AWS CloudShell User Guide states that running processes don't count as interactions. Only keyboard or pointer input resets the inactivity timer. This matters for the agentic workflows named in the launch announcement, because an agent loop generates no input and the supervising session can end while the process is still running.

What happens to my 1 GB of CloudShell storage if I stop using a Region?

Data is retained in that Region's persistent storage for 120 days after your last session there. After 120 days it is automatically deleted unless you act. Launching CloudShell again in that Region before the deadline prevents removal. Storage in Regions you use regularly is unaffected by inactivity elsewhere.

How much compute does a CloudShell environment get?

Each AWS CloudShell compute environment is assigned 1 vCPU and 2 GiB of RAM, with 1 GB of persistent storage. The environment is based on Amazon Linux 2023. The user guide also warns that Docker has limited space in the environment, and that large or numerous pre-existing images can cause problems.

How many CloudShell VPC environments can one user create?

The service quotas page states a limit of two VPC environments per IAM principal. When creating one, you can choose a maximum of five security groups. Separately, you can run up to 10 shells at the same time in each AWS Region for your account, and quota increases can be requested through the Service Quotas console.

Is the visual file editor covered in the CloudShell user guide?

Only partly. It appears as a row in the pre-installed software table and as a step in the shell-customisation walkthrough. The guide's table of contents has no dedicated page for it, and the document history's 16 entries end at 2 October 2024, so the August 2026 launch is recorded in none of them.

How eCorpIT can help

We review AWS operational tooling the way we review production systems: against the documented quotas, not the launch copy. If your team has drifted into running deployments, agent loops, or IaC edits from console sessions, we map what actually persists, what times out, and what belongs on an instance or in CI instead. eCorpIT is CMMI Level 5 and ISO 27001:2022 certified, and works with AWS as a partner. Book an AWS operations review and we will start with your CloudShell and session-timeout exposure.

For wider context, see our guide to cloud FinOps for Indian teams, and the related analyses of AWS Lambda MicroVMs region and quota gaps, Console-to-Code recording and its documentation contradiction, and IAM Policy Autopilot with Terraform plan files.