Cloud9 is a full browser-based IDE with many AWS integrations and built in support for over 40 languages. It’s particularly great for working with Lambda functions, and provides an easy way to test and iterate on them in the same environment as production.
Cloud9, an IDE Built For AWS
Cloud9 is a pretty good IDE in its own right, but you’re probably already thinking that your local Visual Studio Code setup is better.
While a local IDE might be more convenient, Cloud9 has it beat in a few areas. First, it runs on EC2, and you’re given full terminal access to the instance with the AWS CLI preinstalled. In a corporate environment, having your developer’s environments deployed in the cloud under your control is a very cool feature. You can deploy multiple Cloud9 environments to one server under subfolders.
Basic AWS integration aside, Cloud9 really excels for Lambda development. It’s actually the same text editor that you find on the function properties page, except Cloud9 has one great feature that makes it far better—local testing. You can test your function in nearly the same environment that it would run in production, even being able to locally test how your function behaves behind an API Gateway. If you want to test the function in Lambda itself, there’s a 1-click button to deploy your code to the $LATEST Lambda version and test it in a real environment, complete with a development API Gateway configured to run your updated function. The experience is pretty seamless.
Even if you’re using Git and SAM to manage your Lambda deployments, Cloud9 can still prove useful just for the ability to test functions so easily. The integrated terminal makes it easy to work with Git from the Cloud9 environment.
On top of this, Cloud9 also supports collaborative coding. Multiple users can be logged in to the same environment and work on code at the same time. Other IDEs have this feature, but Cloud9’s pair programming feature is integrated with AWS’s account management tools and also works well for Lambda development.
Setting Up an Environment
Head over to the Cloud9 product page and click “Create Environment”. Give it a name and description, then click next.
For the environment settings, choose to create a new instance for the environment. If you’ve got your own server, you can enter in SSH details for it instead, and use that at no additional charge. You’ll probably want to edit the environment directory that Cloud9 installs to, if you’re setting up multiple environments.
You’ll also want to make sure the Cost-saving setting is set to something reasonable, so that the instance won’t continue running long after you (and everyone else) leaves the IDE. Around 30 minutes or an hour is fine.
You can also configure the VPC and subnet settings here, though currently you can’t deploy Cloud9 in a private subnet.
Click next to review your settings, and (if everything looks good) create your environment. You’re then brought to a new page, where it may take a bit to create the environment for the first time. Within a minute or so, you’re connected and brought to the Cloud9 start screen where you can switch to a dark mode if you’d like.
The first thing you should do is verify that your AWS region is set correctly from the “AWS Settings” category in the editor settings. It should launch with whatever region you use as your default, but it doesn’t display in the header like most other AWS services, so it’s good to double check.
Once that’s checked, you’re ready to get started. From the “AWS Resources” tab in the far right sidebar, you can edit Lambda functions directly. You can click the “λ+” button in the menu to create a new Lambda function.
Give it a name, then click through the Lambda setup. If you’re configuring this function with an API Gateway, you’ll want to specify a name for the gateway used for testing, which permits debugging using the API Gateway as the entrypoint rather than direct execution.
If you’ve already got a Lambda function you’d like to edit, you can, instead, import an existing function into the environment for editing.
Once your function is loaded, it appears in the sidebar in its own folder. Open up index.js or whatever your entrypoint is, and edit the code as you see fit.
When you want to test, save your code, and click the “Run” button. You have a few options here:
Local testing, which runs the Lambda function on the same machine as the environment Remote testing, which runs the Lambda function in the same environment it would run in production Local API Gateway testing, which runs it locally as an API Remote API Gateway testing, which creates a runs a new real API Gateway with the cloud9- prefix and connects to the Lambda function
These options alone make Cloud9 great for working with Lambda functions. The ability to easily test functions locally gives Cloud9 an edge over local IDEs. Running locally means you won’t have to bother updating the Lambda function’s $LATEST release; this enables multiple developers to develop and test the same function without running into conflicts.
Of course, if you want to test remotely, you’ll need to update the $LATEST release. This shouldn’t affect your production functions, assuming you’ve set them up properly with versioned releases and a “Production” alias pointing towards the latest version. It makes rollbacks easy, and enables new functions to be rolled out slowly over the course of an hour, making sure no issues arise in production.
Editing Lambda functions directly like this and managing the code releases through Lambda versions is a perfectly valid and simple way to work with them. However, some companies may prefer to use their existing source control for Lambda, and deploy updates through a CI/CD pipeline using SAM configuration to define the function stack. This is certainly a more complicated (although better) setup, but each deployment still creates a new Lambda version, so even in this environment you can use Cloud9 for testing. When you’re ready to make updates, you need to push changes to Git. Luckily, Cloud9 has a built-in terminal you can use for this purpose.
