As I continued learning AWS, I came across two very useful services: AWS Systems Manager and AWS CloudShell. Both of them make day-to-day cloud operations much easier, especially when managing EC2 instances. This lecture showed me that AWS is not only about launching servers, but also about managing them in smarter and more secure ways.
What is AWS Systems Manager?
AWS Systems Manager, often called SSM, is a service that helps manage servers centrally. Instead of connecting to machines one by one with traditional SSH, Systems Manager allows administrators to access and control EC2 instances directly from AWS. It is especially useful when working with many servers at once.
Why It Feels Useful
One of the simplest but most impressive use cases is being able to open a shell session on an EC2 instance directly from the browser. There is no need to use Git Bash, no need to copy SSH commands, and no need to worry about opening port 22 just for access. That already makes it feel cleaner and more secure.
Another strong feature is the ability to run the same command on one instance or on many instances at the same time. If a team is managing dozens or even hundreds of servers, this becomes extremely practical for patching, restarting services, or checking logs.
Step 1: Launch an EC2 Instance
The lecture starts by launching a normal EC2 instance. The example used an Ubuntu AMI with a free-tier instance type such as t2.micro or t3.micro. A key pair and security group can still be selected during launch, but for this case the key is not the main focus because the connection will happen through Systems Manager.
Step 2: Create an IAM Role for EC2
To let the EC2 instance talk to Systems Manager, the instance needs permission. This is where an IAM role is used. The role is created for the EC2 service, and the required policy attached is AmazonSSMManagedInstanceCore. Without this permission, the instance will not be able to show up properly inside Session Manager.
Step 3: Attach the Role to the Instance
After creating the role, it needs to be attached to the EC2 instance. This is done from the EC2 actions menu by modifying the IAM role. Once attached, the instance gets the permission needed to communicate with Systems Manager.
Step 4: Connect Through Session Manager
In AWS Systems Manager, there is an option called Session Manager. From there, I can start a session, select the instance, and open a shell directly in the browser. It feels similar to SSH, but much simpler from an operations point of view. Inside the session, I can run commands normally, switch to root, check the operating system, and manage the server.
Why This is Better Than Traditional SSH in Some Cases
With Session Manager, I do not need to depend on SSH keys for everyday access. I also do not need to open SSH access in the security group just to log in. That reduces some manual work and can improve security in certain situations. For cloud operations, this is a very practical approach.
Step 5: Use Run Command
The next feature shown in the lecture is Run Command. This allows commands or scripts to be sent to one or more instances without opening a shell session manually. The selected document for this was AWS-RunShellScript. Once selected, commands can be added line by line and then executed on chosen instances.
For example, I could run a basic update command, list files inside a directory, or even run a longer shell script. After execution, Systems Manager shows whether the command succeeded, and the output can be viewed directly from the AWS interface.
Managing Multiple Servers
One important idea here is scale. If instances are tagged properly, the same command can be applied to all matching servers. That means instead of connecting to machines one by one, a single action can handle an entire group. This is where Systems Manager starts to feel like a real operations tool, not just a convenience feature.
Other Things Inside Systems Manager
The lecture also mentions that Systems Manager includes more than just shell access and run command. It also has areas related to compliance, change management, parameter storage, CloudWatch integration, operations center, and incident management. Even though not all of them were used in this lesson, it showed me that Systems Manager is a much broader service for cloud operations.
What is AWS CloudShell?
The second part of the lecture focused on AWS CloudShell. CloudShell is a browser-based terminal provided by AWS. The biggest advantage is that AWS CLI is already installed and configured there. That means I do not need to install the AWS CLI on my own machine or set up access keys just to run commands from the browser.
Why CloudShell is Convenient
With CloudShell, I can directly run AWS commands like listing EC2 instances or checking S3 buckets. Since it already works with the currently logged-in AWS user, it removes some setup friction. For quick testing, troubleshooting, or command practice, this is extremely handy.
CloudShell and Amazon Q Together
Another useful part is how CloudShell can work with Amazon Q Developer. If I do not remember a command, I can ask Amazon Q for help, get the suggested command, and run it right away in CloudShell. So in one browser session, I have the AWS console, a terminal, and an AI assistant all together.
Main Lesson I Took From This
This lecture made me realize that being a DevOps engineer is not just about knowing one way to access a server. There are multiple tools available depending on the situation: SSH, Systems Manager, AWS CLI, CloudShell, and AI assistants like Amazon Q. The important thing is to understand what each tool is good for and use the right one when needed.
Final Thoughts
AWS Systems Manager and CloudShell both felt very practical to me. Systems Manager showed me a safer and more scalable way to access and control EC2 instances, while CloudShell showed how easy AWS CLI work can become when the environment is already prepared.
Together, these tools make AWS operations feel more modern, centralized, and efficient. For me, this lecture was a good reminder that in cloud engineering, knowing the management tools is just as important as knowing how to launch the server itself.
Back to Blogs