As a cloud administrator/engineer/developer, you might have used the AWS CLI most of the time to create, update, delete, or manage your AWS resources. It’s a powerful and developer-friendly tool to interact with AWS. The AWS service APIs are so cool and working with them using CLI helps you to understand them in a much better way compared to using the services via the AWS management console.
Unfortunately, using AWS CLI need a one-time setup and sometimes it needs you to refresh your keys after expiry. You must run ‘AWS Configure’ to set up the CLI on your local terminal. Configuring AWS CLI requires you to save your access keys on your computer and god forbid if any bad actor gets your access keys, it can be disastrous. Moreover, if you have to use multiple AWS accounts, reconfiguring the CLI or even setting the AWS configure profile would be a tedious, time-consuming job sometimes. And say, if your access keys have a TTL then setting them up again and again is a little frustrating.
AWS CloudShell is there for the rescue.
Note: We cannot completely avoid using access keys. For local development work, you might still need access keys. For example, setting up AWS plugin on the IDE.
Let’s learn about it and see how can we use AWS CloudShell and increase productivity.
What is AWS CloudShell?
AWS CloudShell is a browser-based shell that you can access directly from your AWS management console.
CloudShell pre-authenticates the access on the shell which runs on an Amazon Linux computing environment. It provides pre-installed developer tools, browser-based download and upload options, and persistent storage between multiple login sessions to the shell. If you don’t want to persist your session data, you can always delete the /home directory and clean up the resources after using CloudShell.
CloudShell Features
1. Support of Multi Shell Environment:
CloudShell support all different shells that you are familiar to work with. For example, you can very easily switch between ‘Bash’ to ‘Powershell’ to “Z Shell”. See below:
2. Development Tools:
It comes with many pre-installed utilities for developers like -
- 1. AWS CLI
- 2. Python
- 3. Node
- 4. npm
- 5. git
- 6. bash Utilities
- 7. pip, sudo, zip, and many more.
3. CloudShell Environment Resources:
When CloudShell is launched, a computing environment is assigned with the following resources -
- 1 vCPU (Virtual central processing unit)
- 2 GiB RAM
- 1 GB of persistent storage
The persistent storage of up to** “1 GB in each AWS region”** at no additional cost. Storage is available in the $HOME directory and it’s private for the user.
IMPORTANT: Storage is regional. For example, data stored in ‘us-east’ will not be available if you switch the region and start a CloudShell session in ‘us-west’.
The data in the persistent storage in any region will last for 120 days from the last session. After 120 days, the data automatically deleted from the region.
4. CloudShell Security
The following security features are available to the users -
- Permission management — Using Identity & Access Management
- Shell management — Auto stop and recycle user inactive session after 20–30 mins. All active sessions can last for a maximum of 12 hours.
- Safe Paste is enabled default — For the multiline paste, safe paste notifies users if they want to review the script for malicious scripts and take any action execution.
5. Command Size
The maximum command size in AWS CloudShell is 65412 Characters. For commands longer than 65412, we can create a shell command script file or a Python script to run the commands -
6. Network Access & Data Transfer
- Egress — Traffic to the internet is allowed.
- Ingress — no access to inbound ports from the Internet.
- IAM administrators can create a custom policy using the
“AWSCloudShellFullAccess” managed policy as a template to manage the action of IAM users/roles/federated identities in the CloudShell.
“putCredentials” — Without “putCredentials”, the user would need to manually configure their credentials using the “AWS Configure” command to access AWS resources.
This CloudShell permission would allow the user to use the CloudShell environment however, explicit permission will be required for the user to access the AWS services from Cloudshell. For example, if the user does not have permission to list S3 buckets then “aws s3 ls” won’t work. An explicit permission policy would be required to be attached to the identity in the IAM console.
CloudShell In Action
Click Here to see cloudShell in action.
Conclusion
Based on my experience working with AWS CloudShell, I believe it is a convenient and secure way for AWS users to manage their resources using a browser-based CLI environment. Its pre-installed tools, persistent environment, integration with AWS services, and secure isolation from the user’s local machine make it an advantageous option over the traditional AWS CLI for managing and monitoring AWS resources. Additionally, I appreciate that it provides a seamless experience and eliminates the need for local installations. The automatic credential forwarding also allows users to focus on their work without worrying about configuring their CLI, setting environment variables, or updating their access keys after the session expiry.
Have you personally used AWS CloudShell, and if so, what is your experience been like? Are there any specific advantages or features that you find particularly helpful?
Top comments (0)