Skipping “what is a cloud IDE,” this chapter builds the vocabulary you need before touching architecture: how a Cloud9 environment is actually composed and connected.

An Environment Is a Directory, Not Just an IDE Window

A Cloud9 environment is fundamentally a specific directory on a compute resource, paired with the browser-based IDE that presents it. The IDE itself is a thin client rendering files, a terminal, and a debugger UI — the actual file system, running processes, and installed tools all live on the backing compute resource, not inside the browser. This distinction matters because it explains why closing a browser tab doesn’t lose your work: the environment keeps existing (and, for EC2-backed environments, the instance keeps running or hibernating) independently of whether anyone currently has a browser open to it.

Two Environment Types: EC2 and SSH

Cloud9 supports two fundamentally different backing models. An EC2 environment provisions and manages a dedicated Amazon EC2 instance on your behalf, pre-installed with the Cloud9 SSM agent that the IDE communicates with. An SSH environment instead connects to any existing server you already control — on-premises, in another cloud, or an EC2 instance you manage yourself — over a standard SSH connection, meaning Cloud9 doesn’t own or provision the compute at all in that mode.

Automatic Hibernation, Not Automatic Deletion

An EC2-backed Cloud9 environment can be configured to automatically stop its underlying instance after a period of inactivity — this hibernates the instance to save cost, it does not delete the environment or its files, which live on the instance’s persistent EBS volume. The next time someone opens the IDE, Cloud9 automatically restarts the instance before reconnecting, at the cost of a short startup delay.

The browser-based editor is only the visible tip of a small stack of coordinated services and processes.

Why SSM Instead of Direct SSH for EC2 Environments

For EC2-backed environments, Cloud9 deliberately routes IDE traffic through AWS Systems Manager Session Manager rather than requiring a directly reachable SSH port. This means the instance’s security group doesn’t need an inbound rule opening port 22 to any source at all — connectivity is brokered entirely through the SSM service, which itself is authorized by IAM, collapsing what would otherwise be a network-security decision into an identity-and-access decision instead.

The AWS Toolkit Integration Layer

A Cloud9 environment ships with the AWS Toolkit pre-integrated, giving direct access to browse and interact with other AWS services — S3 buckets, Lambda functions, CloudFormation stacks — from inside the same IDE window, without needing to separately configure AWS CLI credentials, since the environment already runs under an IAM role or the identity of the connecting user.

graph TD
    Browser[Developer Browser] -->|HTTPS| IDE[Cloud9 Web IDE]
    IDE -->|SSM Session| Agent[SSM Agent on EC2 Instance]
    Agent --> FS[Project File System - EBS]
    Agent --> Term[Terminal Process]
    IDE --> Toolkit[AWS Toolkit]
    Toolkit --> S3[Amazon S3]
    Toolkit --> Lambda[AWS Lambda]
    IAM[AWS IAM] -.authorizes.-> IDE
    IAM -.authorizes.-> Agent
        

A keystroke in the browser and a running process on a remote instance are two very different things — here’s how Cloud9 keeps them in sync.

Real-Time File and Terminal Synchronization

When you edit a file in the browser, changes are transmitted incrementally over a persistent connection to the Cloud9 server process running on the backing instance, which writes them to the actual file on disk. Terminal sessions work similarly in reverse: keystrokes sent from the browser are relayed to a real shell process running on the instance, and that shell’s output is streamed back to render in the browser’s terminal panel — the terminal you see genuinely is the remote machine’s shell, not a simulation.

Collaborative Editing Internals

When an environment is shared with multiple members, Cloud9 broadcasts editing events (cursor position, text changes) to every connected participant’s browser in real time, so two developers can see each other’s cursors and edits live in the same file — functioning much like collaborative document editors, but operating on a real shared file system and shell rather than a document abstraction.

Debugger Integration

For supported languages, Cloud9’s debugger attaches to the actual running process on the backing instance, setting breakpoints and stepping through execution exactly as a local IDE debugger would — the debugging experience is remote in location but not reduced in capability, since the process being debugged is real and running with real data.

An environment has a life story of its own — created, used, hibernated, and eventually decommissioned.

The EC2 Environment Lifecycle

Creating an EC2 environment provisions a new EC2 instance from a Cloud9-managed image, attaches an EBS volume for persistent project storage, and installs the SSM agent and Cloud9 server process automatically. After a configurable idle period, the instance can automatically stop (hibernate) to save cost, while the EBS volume and its contents persist independent of the instance’s running state. Reopening the IDE triggers an automatic instance start before reconnecting.

sequenceDiagram
    participant Dev as Developer
    participant Console as Cloud9 Console
    participant EC2 as EC2 Instance
    participant EBS as EBS Volume
    Dev->>Console: Create environment
    Console->>EC2: Provision instance
    EC2->>EBS: Attach persistent volume
    Dev->>EC2: Work in IDE
    Note over EC2: Idle timeout reached
    EC2->>EC2: Auto-stop (hibernate)
    Dev->>Console: Reopen environment
    Console->>EC2: Auto-start instance
    EC2-->>Dev: Reconnect IDE session
        

Environment Sharing and Membership Changes

Adding a member to a shared environment grants that IAM identity access at a chosen permission level without creating a separate copy of the environment — everyone works against the same underlying file system and instance. Removing a member immediately revokes their access, and ownership changes propagate the same way, all without requiring the environment itself to be recreated.

Environment Deletion

Deleting an EC2 environment terminates its backing instance and its associated resources; unless the project’s files were pushed to a separate persistent store like a Git repository, deleting the environment deletes the work along with it — a straightforward but easy-to-overlook consequence of the environment being a real, disposable instance rather than an abstract project record.

Performance in Cloud9 is a function of instance sizing, network latency, and how many people share one environment — not something that scales automatically like a serverless service.

Instance Sizing for Workload Demands

Because an EC2 environment’s compute, memory, and IOPS are all determined by the underlying instance type, resource-intensive workloads — large compilations, running local databases, heavy test suites — require deliberately choosing a larger instance type, exactly as they would for any EC2-based workload. Cloud9 does not automatically resize an instance to match load; under-provisioning shows up as a genuinely slow build or a frozen terminal, not a gracefully degraded experience.

Network Latency and Perceived Responsiveness

Because keystrokes and terminal output travel over the network round-trip between browser and instance, developers on high-latency connections will notice a small but real lag compared to editing locally. Choosing an AWS Region geographically close to the development team minimizes this round-trip time and is the single most effective lever for perceived editor responsiveness.

Shared Environment Contention

Because all members of a shared environment run against the same underlying instance, CPU- or memory-intensive work by one member (a heavy build, a long-running test suite) can degrade responsiveness for everyone else connected to that same environment — a trade-off inherent to the shared-instance model that dedicated per-developer environments avoid entirely.

You may likeAmazon Aurora→

Choosing SSH Environments to Reuse Existing Capacity

Teams with already-provisioned, appropriately sized compute — an existing EC2 fleet, an on-premises development server — can point Cloud9 at that existing infrastructure through an SSH environment rather than provisioning new, separately billed EC2 instances purely for IDE access.

A Cloud9 environment’s reliability profile follows the reliability profile of a single EC2 instance — which shapes exactly what teams need to plan for.

Single-Instance Availability Model

An EC2-backed environment runs on a single instance in a single Availability Zone; there’s no automatic multi-AZ failover the way a managed database might offer. If that instance or its Availability Zone experiences an issue, the environment becomes unavailable until the underlying problem resolves or the environment is recreated from persisted data.

Snapshotting the EBS Volume for Recovery

Because Cloud9’s persistent project storage is a standard EBS volume, standard EBS snapshot practices apply directly — periodic snapshots (manual or automated through AWS Backup) give a recovery point independent of the Cloud9 service itself, protecting against accidental deletion or corruption beyond what version control alone would catch.

Treating Cloud9 as a Development Tool, Not Production Infrastructure

Cloud9 environments are explicitly a development-time tool, not something that should sit in a production request path. Reliability planning for Cloud9 is therefore about protecting developer productivity and work continuity — through source control discipline and volume backups — rather than about the uptime guarantees expected of a customer-facing production service.

Because a Cloud9 environment often has direct access to project source code, cloud credentials, and running processes, its security model deserves the same attention as any production system.

IAM Governs Both Console Access and Environment Membership

Two separate IAM-governed layers control Cloud9 access: account-level IAM policies determine who can create, view, or manage environments at all, while environment-level membership determines who specifically has access to a given environment’s files and terminal, and at what permission level (read-only, read-write, or owner).

No Inbound Ports Required for EC2 Environments

Because EC2 environment connectivity is brokered through SSM rather than direct SSH, the backing instance’s security group does not need an open inbound port for IDE access — a meaningfully smaller network attack surface than a traditional remote development server that must expose SSH publicly.

Shared Environments Need Deliberate Permission Discipline

Because every member of a shared environment can potentially reach whatever IAM role or credentials are available on that instance, granting environment membership should be treated with the same care as granting access to a shared production credential — read-only membership for reviewers, read-write reserved for active contributors.

Because an EC2 environment is, underneath, a real EC2 instance, most useful observability comes from standard EC2 tooling rather than Cloud9-specific metrics.

Standard EC2 Metrics Apply Directly

CloudTrail for Environment and Membership Auditing

Actions like environment creation, deletion, and membership changes are captured in CloudTrail, giving administrators a record of who created which environments and who was granted access to them — useful both for cost attribution and for security review of who could reach a given project’s code.

Cost Visibility Through Standard Billing Tools

Because Cloud9 EC2 environments bill as ordinary EC2 instances and EBS volumes, standard AWS Cost Explorer and billing alarms apply directly, letting teams track and alert on Cloud9-related spend the same way they would for any other EC2 workload, including tagging environments by team or project for cost allocation.

“Deployment” here means choosing environment type, instance size, and Region — decisions that shape both cost and day-to-day experience.

Region Selection

Cloud9 environments are created in a specific Region; choosing one close to the development team minimizes network latency for editing and terminal responsiveness, while some teams also weigh Regional availability of other services their project depends on.

Planning a Transition Given the New-Customer Closure

Because Cloud9 is closed to new customers, teams currently building new development workflows should evaluate AWS’s suggested alternatives — the AWS IDE Toolkits for popular local editors, or AWS CloudShell for lightweight browser-based command-line access — against their specific collaborative-editing and always-available-environment needs before committing further investment into new Cloud9 environments.

Pattern: SSH Environments for Bring-Your-Own-Compute

Rather than always provisioning a new EC2 instance, pointing Cloud9 at existing, appropriately sized infrastructure through an SSH environment lets a team standardize on the IDE experience without duplicating compute spend for machines that already exist.

Pattern: Idle Timeout Tuned to Team Working Hours

Configuring the automatic-hibernation idle timeout to match a team’s actual working pattern — short for a team with predictable hours, longer for a globally distributed team with staggered activity — balances cost savings against the friction of frequent cold-start reconnections.

Only existing customers can continue creating and using Cloud9 environments as normal; the service is no longer available for onboarding entirely new customers, and AWS has published guidance pointing toward the AWS IDE Toolkits or AWS CloudShell as alternatives for new projects.

Nothing is lost — the project files live on a persistent EBS volume separate from the instance’s running state. When the instance auto-stops due to inactivity, the volume and its contents remain intact and are reattached automatically when the environment is reopened.

No — EC2 environments connect through AWS Systems Manager Session Manager rather than a direct SSH connection, so no inbound port needs to be opened on the instance’s security group for the IDE to function.

Yes, as long as the backing EC2 instance is sized appropriately for that workload — Cloud9 doesn’t automatically scale instance resources, so a resource-heavy project needs a deliberately chosen larger instance type, exactly as it would running directly on EC2.

Yes — shared environments support real-time collaborative editing among members, though because everyone shares the same underlying instance, heavy resource use by one member can affect responsiveness for others connected at the same time.

AWS Cloud9’s real architecture is simpler than it might first appear: a browser-based editor streaming keystrokes and terminal I/O to a real, persistent compute resource, brokered securely through IAM and, for EC2 environments, AWS Systems Manager instead of open network ports. That simplicity is exactly what makes it powerful for consistent, low-setup development environments — and understanding it clearly is also what makes the trade-offs honest: a single-instance availability model, a service closed to new customers, and a genuine need for source-control discipline since the environment itself is not a backup strategy.

You may likeAmazon Macie→