AWS Toolkit for JetBrains: CloudFormation and Lambda inside the IDE

An AWS panel inside the IDE, not another console

The AWS Toolkit for JetBrains is a plugin for JetBrains IDEs that makes it easier to write applications built on Amazon Web Services, and the supported IDE list is broad, all JetBrains IDEs 2023.3 and later. The plugin is published on the JetBrains marketplace under the identifier 11349, and the README links that listing alongside badges for the build status, code coverage on Codecov, downloads, the published version and a SonarCloud quality gate. The stated reason for open sourcing it is participation: the project says it is open source because the team wants you involved, and it names the channels, issues, feature requests, pull requests and code reviews. For a developer, the practical effect is that the AWS surface of a project, the resources, the templates, the functions and the buckets, appears as part of the IDE rather than as a browser tab you keep switching to.

The prerequisites are the adoption cost

Before the plugin does anything you need an AWS account, a user within that account, and an access key for that user. That is the baseline. If you also want the serverless features, the AWS Toolkit to do serverless application development and to run and debug AWS Lambda functions locally, the README adds three more prerequisites, the AWS CLI, Docker and the AWS SAM CLI, and it points at the installation guide in the AWS Toolkit user guide as the place where setting up all of these is covered. That is a meaningful list of things to install before the plugin is useful, and it is the part of the setup most likely to cause friction, since Docker in particular is often the piece that a corporate laptop policy gets in the way of. The local Lambda execution environment is provided by the SAM CLI rather than by the plugin itself, which is the point to internalise, because the plugin delegates the heavy lifting and inherits that dependency's behaviour.

Four ways to authenticate, and they are not equivalent

The authentication options are the decision that matters most, because they determine what the plugin can see and what it stores. You can connect using static credentials, using a credential process, using AWS Builder ID or using AWS SSO. The static key path is the traditional one and the least interesting, since it means a long lived access key sitting in your machine. The credential process delegates to an external command, which suits teams that already have a mechanism for short lived credentials. AWS SSO is the enterprise route, where identity comes from the same provider that already issues access to the console, and Builder ID sits in between as an AWS hosted identity. The plugin does not appear to force one of these over the others, so the choice is yours, and it should be made deliberately rather than accepting whichever credential the IDE happens to find first, because the Resource Explorer, the stack tooling and the bucket browser all inherit whatever the active credential can reach.

CloudFormation is where the depth is

The CloudFormation section is the most substantial part of the plugin, and it is powered by the CloudFormation Language Server. On the authoring side you get language support for CloudFormation YAML and JSON templates, with syntax validation, auto-completion, hover documentation and go-to-definition, plus static validation with real-time diagnostics and error highlighting from cfn-lint and CloudFormation Guard. The stack management side adds a CloudFormation Explorer tool window for browsing stacks, resources and change sets, a stack view with tabs for Overview, Resources, Events and Outputs, and a Resource Explorer for searching live resource types and their properties so you can add them to a template. The validation and deployment side is the part that changes how a team works. You can create a change set to validate a template for deployment readiness and get diagnostics back, review resource-level and property-level changes in a side-by-side JSON diff, see drift annotated inline where a resource has changed outside CloudFormation, and execute or delete change sets straight from the diff view. Drift detection in particular is close to impossible to build yourself well, and having it next to the template is the reason to install the plugin.

Lambda: run it here, invoke it there, ship it

The AWS Lambda features cover four separate jobs. Run and debug local Lambda functions lets you step through a function in a Lambda-like execution environment provided by the SAM CLI. Invoke remote Lambda functions uses a shareable run-configuration, so the same setup can be handed to a colleague. Package and deploy handles building a Lambda function zip and creating the remote function. Sync SAM-based applications keeps a local application in step with what is deployed. The SAM features support Java, Python, Node.js and .NET Core, and the Python ones are available in both PyCharm and IntelliJ as long as the Python plugin is installed, which is a detail that catches people out when they install the toolkit into IntelliJ IDEA and find the Python features missing. Many of these features need the SAM CLI installed, and the README points at the SAM website for that. CloudWatch Logs gets a smaller treatment, the ability to view and search your log streams, which is a convenience rather than a feature.

Services, paid tiers and the experimental bucket

Amazon S3 is covered for viewing and managing buckets and for uploading and downloading files. Amazon RDS and Redshift are covered by connecting to databases with temporary credentials issued through IAM or Secrets Manager, so you do not have to copy and paste a password into a connection dialog, which is a genuine improvement on doing it by hand. Both of those database features carry a condition that is easy to skim past, because the note says the database features require using a paid JetBrains product. That is a licensing boundary rather than a technical one, and it decides the plugin for anyone on a free IDE. The README also groups a set of features under an Experimental Features heading, which is the usual signal that behaviour there may change between releases, and the general section carries one honest limitation of its own, since the AWS Resource Explorer does not represent all resources in your account, only a sub-set of the resource types the plugin supports.

Preview builds and the shape of the repository

There is a second distribution channel in the form of opt-in Early Access Preview builds, which are built automatically. You opt in by adding the EAP repository URL to the IDE's plugin repository list, through Plugins, the gear icon, Manage Plugin Repositories, and then checking for updates:

https://plugins.jetbrains.com/plugins/eap/aws.toolkit

That is the sensible route if you want the newest features, and the stable releases are the ones to stay on otherwise. The release record shows a steady cadence with a pre-release candidate for 4.8 on 2026-09-02, 4.8 on 2026-09-10 and a 4.9-SNAPSHOT prerelease on 2026-10-08, and the last push to the main branch was on 2026-10-08 with the repository not archived. The licence is Apache 2.0. The tree shows a Gradle Kotlin build with a settings.gradle.kts and a separate kotlinResolution.settings.gradle.kts, a buildSrc directory, a plugins directory, detekt rules for Kotlin static analysis, Qodana configurations, ui-tests, testdata, a designs directory, marketplaceGifs, and a .changes directory for the changelog entries, plus a REPOLAYOUT.md that documents how the repository is laid out. Installing from source is documented in CONTRIBUTING.md rather than in the README, which is a sensible place for it.

Editorial conclusion

AWS Toolkit for JetBrains fits a team that writes CloudFormation templates and runs Lambda functions on a daily basis and wants validation, drift awareness and change set review inside the editor rather than in a separate console. It is the wrong choice for a developer who never touches AWS from the IDE, since the plugin's value is the AWS specific tooling, and it is a poor fit if you only have a free JetBrains IDE, because the database features are documented as requiring a paid product. Before you install it, decide which credential mode you will use, static keys, the credential process, Builder ID or SSO, because that choice determines what the plugin can reach, and remember that the local Lambda debugging path additionally needs Docker and the SAM CLI on your machine.

Frequently asked questions

Official sources

1. aws/aws-toolkit-jetbrains on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases