AWS Toolkit for VS Code: two extensions, three auth paths, and a Lambda debugger that needs SAM CLI

Two extensions from one repository: AWS Toolkit covers infrastructure and Amazon Q covers AI assistance

The repository at aws/aws-toolkit-vscode contains the source for two distinct VS Code extensions that publish to separate Marketplace listings. AWS Toolkit, with extension ID AmazonWebServices.aws-toolkit-vscode, connects VS Code to AWS infrastructure: it handles resource browsing, Lambda debugging, CloudFormation template authoring, EC2 and ECS terminal access, and CloudWatch log search. Amazon Q, with extension ID AmazonWebServices.amazon-q-vscode, is the AI coding assistant side and covers features that were previously shipped under the CodeWhisperer name, which the repository topics still reference.

The two are built from a single monorepo organized as npm workspaces. The packages/ directory holds each extension's code and the plugins/ directory holds supporting tooling including a custom ESLint plugin. Version 4.17.0 of AWS Toolkit shipped on 2026-10-05, and the last commit reached the repository on 2026-10-06. Both extensions are distributed under the Apache-2.0 license.

The separation matters for installation decisions. A developer who needs to browse S3 buckets, run an EC2 terminal, or debug Lambda functions needs AWS Toolkit. Someone who wants AI-assisted code completion inside VS Code needs Amazon Q. A developer working on serverless projects with both needs will likely install both, since neither bundles the other.

Finding and installing the two extensions from the VS Code Marketplace

Both extensions install from the VS Code Marketplace and are not bundled with each other. AWS Toolkit is listed at marketplace.visualstudio.com under AmazonWebServices.aws-toolkit-vscode, and its Quick Start guide is linked from that listing. Amazon Q is listed separately under AmazonWebServices.amazon-q-vscode with its own Quick Start guide. The repository README links to both Quick Starts, but the homepage field in the repository points to the Amazon Q listing, which means visitors following the repository homepage land on the Amazon Q page.

Documentation after installation comes from several sources. A User Guide lives at docs.aws.amazon.com/console/toolkit-for-vscode/welcome and covers usage across the Toolkit's feature set. A credential-specific FAQ and troubleshooting guide is at docs/faq-credentials.md in the repository, a dedicated location that signals authentication problems are frequent enough to warrant a separate file. The CloudFormation Language Server has its own dedicated documentation at docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/ide-extension.html.

There is no command-line install path documented for end users in the repository. The Marketplace listings are the documented starting point for both extensions.

Three authentication methods and what each one connects to

After installing AWS Toolkit, the first required step is connecting to an AWS account, and three paths exist. IAM credentials use long-term access keys and are the direct path for developers whose accounts are configured with IAM users and access keys. IAM Identity Center, also called SSO in the feature list, suits organizations that route AWS access through a central identity provider. AWS Builder ID is a third account type that Amazon operates independently of standard AWS accounts.

The choice of method affects what is reachable. IAM credentials and IAM Identity Center connect to specific AWS accounts and let the Toolkit browse resources in those accounts. AWS Builder ID is the path for Amazon Q features that work without an AWS account, meaning a developer can use Amazon Q's code assistance without AWS access or billing. The README does not list every feature gate behind each method, so which Toolkit features require which auth type is not fully documented in the repository.

Connecting to a CodeCatalyst Dev Environment uses the Toolkit's credential flow, but CodeCatalyst manages its own account separately from standard AWS IAM accounts. An expired session or a misconfigured credential causes the connection to fail, and the troubleshooting guidance is in docs/faq-credentials.md rather than inline in the README.

Lambda debugging depends on SAM CLI as a prerequisite, and CloudFormation authoring uses the Language Server

SAM CLI is the runtime behind Lambda local debugging in AWS Toolkit. The extension connects to the SAM CLI binary that the developer installs separately, and without that binary on the system path, the Lambda debugging feature is unavailable. The README links to the SAM CLI repository at github.com/aws/aws-sam-cli. Developers who prefer a terminal-only workflow can invoke SAM CLI directly from the command line to test Lambda functions locally without VS Code involved, which is the practical alternative for CI pipelines or for developers not using VS Code.

Template authoring in VS Code goes through the CloudFormation Language Server, which brings syntax checking, autocompletion, and validation to CloudFormation YAML and JSON files as they are edited in the editor. The Language Server also supports deploying templates from within VS Code. That integration has its own documentation at docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/ide-extension.html rather than in the main repository README.

Both features depend on valid credentials being connected through the authentication flow described above. A disconnected session prevents both Lambda invocations and CloudFormation deploys that are initiated from VS Code.

Open Terminal drops a shell into EC2 or ECS without leaving the editor

Two operational commands in AWS Toolkit address running infrastructure rather than development workflows. Open Terminal puts a shell from a live EC2 instance or ECS task container into VS Code's integrated terminal, which avoids switching to a separate SSH client or navigating to the AWS Console for a quick operational check. EC2 instances and ECS tasks are both named as supported targets. The underlying connection mechanism and the specific IAM permissions required beyond the base authentication flow are not documented in the repository.

Search Log Group brings CloudWatch log querying into VS Code's interface. The README gives it one line of description with no detail on filter syntax, time ranges, pagination, or result limits. A developer who needs detailed control over CloudWatch Logs Insights queries would need to evaluate the Toolkit's search interface against their actual requirements before relying on it, since the repository does not describe the query operators supported.

Both commands fail if credentials are expired or if the target resource is in a region not connected in the current session. The docs/faq-credentials.md file covers credential-related failure patterns but does not address resource-level access errors caused by insufficient IAM permissions.

The test suite requires Xvfb, and the Dockerfile's Node.js 10.x install looks outdated

Contributing to either extension means running tests that require a graphical display. The Dockerfile at the repository root sets up Ubuntu with Xvfb, sets DISPLAY=:99.0, and runs tests with the command `xvfb-run npm test --silent`. VS Code extensions run inside an Electron process during testing, and Electron needs a display server. A headless Linux machine without Xvfb cannot run the full test suite.

The same Dockerfile installs Node.js using `curl -sL https://deb.nodesource.com/setup_10.x | bash -`, which installs Node.js 10.x. The root package.json's postinstall script uses the -ws flag and workspace-scoped npm commands, so the Dockerfile appears to be an older CI image that was not updated to match the repository's current workspace configuration. A contributor setting up a local environment should treat the Dockerfile's system-level dependencies (xvfb, libgtk-3-0, libnss3, libasound2) as a reference for required packages on Linux, but not treat the Node.js version in it as the current requirement.

The package.json includes separate test targets: test, testWeb, testE2E, and testInteg, each scoped across workspaces. Running all of them locally requires the full Xvfb environment the Dockerfile describes.

Apache-2.0 license, the scan-licenses script, and the pre-release tagging approach

Both extensions are distributed under the Apache License, Version 2.0. The repository carries a LICENSE file, a NOTICE file, and a pre-generated LICENSE-THIRD-PARTY attribution document for third-party dependencies. Anyone redistributing a modified build needs to regenerate that attribution file if dependencies change. The README documents the regeneration steps:

npm run scan-licenses

# Or run directly
./scripts/scan-licenses.sh

The first command runs through npm's workspace scripts; the second calls the shell script directly. Both produce two outputs: LICENSE-THIRD-PARTY for distribution attribution, and licenses-full.json for the complete license data across all dependencies.

The release cadence visible in the repository shows a mix of pre-release and versioned tags. Pre-release tags such as pre-stepfunctions-execution and pre-retrigger-ci appeared on 2026-10-06, the same day as the last push. AWS Toolkit 4.17.0 shipped as a versioned release on 2026-10-05. That pattern suggests individual features ship through pre-release tags before being folded into a numbered Toolkit release. Contributors watching the repository should distinguish between those pre-release tags and actual user-facing releases when evaluating upgrade timing.

The repository also includes CONTRIBUTING.md for contribution guidelines and a CODE_OF_CONDUCT.md, and the README's feedback section points to three separate GitHub issue templates covering bugs, feature requests, and general guidance questions.

Editorial conclusion

Install AWS Toolkit for VS Code when you need a browsable view of AWS resources, local Lambda debugging with SAM CLI, CloudFormation template validation, or an EC2 or ECS terminal inside VS Code. Skip it when you need a CI-pipeline-only workflow without VS Code running, when you need a JetBrains integration, or when you want to invoke Lambda functions locally without installing the editor at all, in which case SAM CLI at github.com/aws/aws-sam-cli is the direct path. Before treating a credential failure as an extension bug, check docs/faq-credentials.md in the repository, since authentication issues have their own documented troubleshooting path.

Frequently asked questions

Official sources

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