Cloud9

Browser-based IDE with a terminal and built-in AWS CLI pre-configured

AWS Cloud9 is a browser-based integrated development environment that provides a full Linux terminal, code editor, and pre-installed AWS CLI in a managed EC2 instance, making it ideal for developing, running, and debugging serverless applications without local setup. Because it runs on EC2, it has direct network access to VPCs and AWS services, and its IAM instance profile grants temporary credentials automatically - no access key configuration needed.

How Cloud9 Works: EC2 Instance Behind a Browser

Every Cloud9 environment is backed by an EC2 instance (you choose the type) or an existing EC2/SSM-managed instance. The browser IDE connects via AWS Systems Manager Session Manager - there is no need to open SSH (port 22) to the instance.

Component	Description
EC2 instance	Runs the Cloud9 IDE server and your code
SSM agent	Handles secure tunnel from browser to instance (no SSH required)
Instance profile	Provides temporary AWS credentials via instance metadata
AWS managed temporary credentials	Rotated automatically every 5 minutes when using managed credentials
EBS volume	Persistent storage for your code and environment between sessions
Auto-hibernate	Optional: instance stops after 30 minutes of inactivity to save cost

💡

Cloud9 managed temporary credentials are scoped to common development actions but do not include all IAM permissions. For actions like creating IAM roles or accessing specific services, you may need to assign a custom instance profile with the required permissions, disabling managed credentials.

Access Control and Collaboration

Cloud9 supports real-time collaborative editing - multiple users can edit the same files simultaneously with shared terminals, similar to Google Docs for code.

Access Type	How It Works	Use Case
Owner	IAM user/role that created the environment	Primary developer
Member (read/write)	Another IAM identity granted access via Cloud9 console	Pair programming, teaching
Member (read only)	Observer can view but not edit or run	Code review, monitoring

Access control requirements for Cloud9:

bash

# Minimum IAM policy to use Cloud9
{
  "Effect": "Allow",
  "Action": [
    "cloud9:GetUserPublicKey",
    "cloud9:DescribeEnvironments",
    "cloud9:ListEnvironments",
    "cloud9:GetUserSettings",
    "cloud9:UpdateUserSettings",
    "iam:GetUser",
    "iam:ListUsers"
  ],
  "Resource": "*"
}

# To create environments
{
  "Effect": "Allow",
  "Action": "cloud9:CreateEnvironmentEC2",
  "Resource": "*",
  "Condition": {
    "StringEquals": {"cloud9:InstanceType": ["t3.micro", "t3.small"]}
  }
}

⚠️

Cloud9 environments are owned by an IAM user (not a role). If the owning IAM user is deleted, the environment becomes inaccessible. For team environments, consider ownership patterns carefully or use shared role-based access.

Developing and Debugging Lambda Functions

Cloud9 has built-in integration with the AWS Toolkit, enabling local Lambda invocation and step-through debugging without deploying to AWS first.

Feature	Description
Local invoke	Run Lambda function locally using SAM CLI inside Cloud9
Step-through debug	Set breakpoints and inspect variables in Lambda code
Remote invoke	Invoke deployed Lambda directly from Cloud9 IDE
Import function	Pull existing Lambda function code into Cloud9 editor
Deploy from IDE	Deploy SAM/CloudFormation stack from the IDE

💡

Cloud9 pre-installs SAM CLI, AWS CLI v2, Docker, Git, and common runtimes (Node.js, Python, Java, .NET). This eliminates the "works on my machine" problem for Lambda development across teams.

Networking: VPC Access and Private Resources

By default, Cloud9 creates the EC2 instance in a public subnet to allow browser connectivity. For accessing private resources (RDS, internal APIs), choose a VPC and subnet during environment creation.

Network Config	When to Use	Requirements
Public subnet (default)	No VPC resources needed	Default VPC is sufficient
Private subnet (no internet)	Access private resources, no public IP needed	SSM VPC endpoint required for connectivity
Private subnet (with NAT)	Access private resources + internet	NAT Gateway in public subnet

When using a private subnet without internet access, the instance connects to AWS services via VPC endpoints. The following endpoints are required for Cloud9 to function:

bash

# VPC endpoints required for Cloud9 in private subnet
# com.amazonaws.region.ssm
# com.amazonaws.region.ssmmessages
# com.amazonaws.region.ec2messages
# com.amazonaws.region.s3 (gateway endpoint)
# com.amazonaws.region.cloud9 (for environment metadata)

🎯

Interview Focus Points

1How does Cloud9 connect to the underlying EC2 instance - does it require SSH?
2What are AWS managed temporary credentials in Cloud9 and what are their limitations?
3How does Cloud9 access control work - can multiple users share an environment?
4How would you use Cloud9 to develop and debug a Lambda function locally?
5What networking configuration is needed to use Cloud9 in a private subnet?
6What is the auto-hibernate feature and when should it be enabled?
7How does Cloud9 differ from CloudShell for AWS development workflows?