, a mighty CLI for AWS

Some people strongly prefer the CLI (source: Imgur)

As the cloud has grown in popularity, AWS has become the undisputed market leader, powering many of the internet giants and setting the pace for the wide range of cloud services. The challenge for DevOps is to keep up with that pace so they can understand the growing number of services and their associated features.

DevOps often wonder about the best ways to manage quick-growing AWS infrastructures. They question whether they should use the graphical user interface (GUI, a.k.a. the AWS console) or the command line interface (CLI, starting with AWS’s own aws-cli)? Or maybe a mix of both?

There is another option to proposes to simplify the work of DevOps :, a new open source CLI for AWS written in Go. The project got praise from AWS superstar Jeff Barr and attracted more than 2.5k stars on GitHub in just a few months. In this blog, I’ll explain why my company Wallix built and why we think the tool can help DevOps, as many tweets suggest.

A Love/Hate Relationship with GUIs

AWS provides many services

Usually, sysadmins hate GUIs. The Linux Foundation considers them for novices. But could AWS Console be the exception? The Console clearly presents the full range of available services, and, depending on the service, provides advanced wizards to help manage the features of a given service. We do appreciate the Console, especially for infrequent actions because the graphical visualization is very helpful. But repeating tasks takes time and can easily frustrate advanced users.

Even at Step 6 using AWS Console, we haven’t created our instance yet.

With the GUI, it is hard to script actions, keep notes for oneself, or collaborate with a colleague about a particular operation. Remember the last time you instructed a colleague (or your mother) over the phone while navigating web interfaces? Needless to say, it’s a very frustrating process.

The Burden of the aws CLI

A CLI, on the other hand, is fantastic for all actions that are performed regularly. Once the aws CLI is setup, it can perform any action without requiring you to login manually or use a mouse.

For example, this command suffices to launch a t1.micro instance:

We could argue that it’s hard to remember the Amazon Machine Image (AMI) identifier or the keypair, but a shell alias would do the job. We could simply search for the right security group:

and grep the GroupId from the input, which looks by default like:

While this approach feels much more sophisticated than using AWS Console, it is not always efficient. The aws CLI requires a constant switch from input: Series of command lines are intertwined with extracting information from previous output or editing snippets of JSON. Some open source alternatives exist, but they barely change the syntax of operations, adding coloring, completions and other niceties.

Tools, such as AWS’s own CloudFormation, are helpful for preparing a stack. But writing Templates is a separate task that can’t replace many simple commands. We once witnessed AWS experts struggling to find resources created by a CloudFormation template using the aws CLI. Grokking the right id in the middle of kilobytes of JSON is not an easy task. In the end, we had to resort to using the GUI.

Enter is an alternative CLI for AWS that values simplicity over exhaustivity. It aims to perform 90 percent of tasks much more easily by changing the definitions of commands. is not just a “front-end” to aws-cli. It is a new CLI implemented in Go using the official AWS Go SDK. The project is fully open source project and released under the Apache license. As of now, supports the following AWS services: IAM, EC2 (including ELBv2), S3, Route53, RDS, SQS, SNS, Cloudfront, Cloudwatch, CloudFormation and Lambda. Even more services will be added in the near future.

The project was started by the Innovation team at my company, Wallix, stemming from our own needs. Wallix is the de facto sponsor for the project, but ultimately is a community project and welcome all contributions.

The Benefits of is modeled after popular tools, such as git, and most commands are in the form of:

For exemple, the following are all valid commands:

The main principles behind include:

  • Smart defaults to minimize cloud knowledge;
  • Output that is readable by humans or parsable by machines;
  • Local copy of the infrastructure model is stored as a RDF graph, which enables users to study the graph and perform computations locally. highlights the reuse of the same verbs (such as list, create, delete), which results in a small (and easy to remember) command surface. The syntax is unified across all services. For example, you can type:

instead of

Getting Started with is available at GitHub. We provide pre-built binaries and Homebrew packages for macOS:

Alternatively, building this yourself is very easy if you have Go installed on your system:

At first launch, automatically gets your credentials and default region if the official aws-cli is setup. Also, don’t forget to install the autocompletion for bash or zsh.

Exploring AWS Infrastructure provides many features and refinements to help DevOps navigate through their AWS infrastructure. The two main commands are list and show. For each type of resources, tries to provide meaningful information first.

Listing Objects enables to list all existing AWS resources, like users, security groups or instances:

When the terminal is not wide enough, columns are truncated automatically and a warning message indicates the hidden columns:

You can sort and filter content easily:

Output format is customizable. By default, the output appears in tables that are easily read by humans (the output is a valid markdown, and can be piped to other tools, such as pandoc). You can choose instead csv, json or tsv:

A distinctive feature of is the ability to work from a local copy of the infrastructure graph, stored as a RDF graph. This approach enables you to perform complex queries locally. Also, the use of a standard format enables you to reuse existing tools to query the graph, such as Protégé, which was developed at Stanford. Having a local graph enables to easily query your infrastructure even without internet access:

Getting Resources Details

You can get the details of any kind of resource using the show command:

This command will display the properties of the cloud resource, as well as its relations with other resources. For example, for an instance, it will show its Virtual Private Cloud (VPC), subnet and related objects, information about mounted volume, keypair and its security group(s).

Properties and values will differ depending on the type of AWS resource:

One-Liners and Templates is a great tool for listing and exploring your cloud resources. But it also provides a powerful templating engine, which supports the cloud infrastructure operations (creation, update or deletion of resources).

One-Liners templates can either be used through one-liner shortcut commands or with file scripts. To create an instance or a keypair or any other entity, you only need to type a simple command: does not require any additional parameters right away to create an instance or perform other actions. Instead will input for the missing parameters and provide autocompletion along the way.

Let’s first create a keypair to enable to further connect via SSH to instances we will create next (user input is in bold): merges input from the command-line, user input and configurable defaults (for example, the image and instance type), and asks for confirmation before applying any modification to the infrastructure.

Now, we can easily create an instance using our brand new keypair:

We can use another command, ssh, to directly login to that instance:

There is no need to pass keys as arguments, since they are stored locally, nor to specify the username as makes it own guess. The devil is in the detail, and strives to get the User Experience of CLIs right.

Beyond shortcuts, there are powerful new features at your fingertips. If you read carefully the output for previous commands, you noticed that each successful action has a revert id. Indeed, most of templates (one-liners or full scripts) can be reverted very easily.

Like git, maintains a log of all operations performed:

And like commits, operations can be reverted easily:


Up to now, we used templates that contain a single command (one-liner). Templates are a generalization and a succession of commands:

The following features are added to chain commands together:

  • A command result can be stored in a value by using the syntax value = command, and the value can be later recalled as $value;
  • Template parameters are missing values in command arguments. They will be input at runtime and are written between braces, such as {instance.image} from the example above.

Templates are a very powerful feature. For example, they make it easy to complete tasks, such as:

To launch a template, you can use either repo: for the official repository awless-templates, a URL, or a local file:

Try it for yourself!

Better yet, you will be able to use awless revert that we introduced earlier in this article to remove all the resources that are created by the template (instances, security group, target group, load balancer, etc.).

Note that the template implementation is still preliminary and might evolve with additional changes before reaches version 1.0. After that point, all language revisions will come with migration assistants.

Summary of commands

Remember that you can get help on all features by typing:

The following tables list the main command verbs and template verbs:

Just the Beginning 0.1.0 released today, following more than 20 alpha releases since the project publicly launched in January 2017.

The project is a work-in-progress. We expect to improve in many ways, including supporting more AWS services and features for each service. You’re welcome to file or upvote existing GitHub issues if your favorite service is (still) missing.

Our roadmap this year will focus on the following aspects:

  • 0.2.0 — Working with multiple regions. Using the local graph to suggest resources in their proper region, and switch them easily.
  • 0.3.0 — Improving the scripting language. We plan to define a formal semantics, and introduce type-checking of templates that will catch errors before performing any actual query to AWS (including as a dry run).
  • 0.4.0 — Leveraging the local graph to run (complex) queries on the global infrastructure.

We welcome you to contribute and help us spread the word! And to stay up-to-date on the latest news about, follow us on Twitter at @awlessCLI.

Software Maker

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store