The Secret Life of AWS: The Console and the CLI

Two ways to work with AWS — and why one of them doesn't scale

#AWS #CloudComputing #AWSSeries

Margaret is a senior software engineer. Timothy is her junior colleague. They meet in a grand Victorian library in London — and in every episode, they work through the tools, ideas, and infrastructure that power modern software. Today, Timothy logs in for the first time.

Episode 4

Timothy arrived with his laptop open before he sat down, which was new. He had always been someone who preferred paper — notebook, pen, the physical act of writing as thinking. The laptop on the table between them felt like a statement.

"I created an account," he said.

Margaret looked at the screen. "And?"

"And I logged in." He turned the laptop to face her. "And then I sat there for quite a long time, not entirely sure what I was looking at."

The AWS Management Console filled the screen — the familiar grid of service icons, the navigation bar, the region selector in the top right corner, the quiet suggestion of enormous complexity held just barely at bay by a layer of careful interface design.

Margaret regarded it for a moment.

"What did you click first?" she asked.

"EC2," he said. "Because it was familiar. I knew what it was." He paused. "And then I saw the options available on the left-hand side and I closed the laptop and made a cup of tea."

"A reasonable response," Margaret said.

Two Doors Into the Same House

"There are two primary ways to work with AWS," Margaret said. "The Console — what you have here — and the CLI. The command line interface. They can both do most of the same things. They talk to the same underlying services. The results are identical." She paused. "The difference is not what they do. The difference is what they teach you, and what habits they build."

"The Console is visual," Timothy said. "The CLI is text."

"That is the surface difference. The deeper difference is this — the Console is optimised for exploration. It is designed for someone who wants to understand what exists, what options are available, what a service looks like. It is a map." She looked at him. "The CLI is optimised for precision and repetition. It is designed for someone who knows what they want and needs to do it reliably, quickly, and — crucially — in a way that can be written down."

"Written down."

"Automated. Scripted. Repeated exactly, without variation, without the possibility of a misclick." She folded her hands. "This is the distinction that matters most. Everything you do in the Console is manual. You click a button, fill a field, make a choice. It works. But it exists only in that moment — there is no record of the exact steps you took, no way to repeat them precisely, no way to hand them to a colleague and say — do exactly this."

Timothy was quiet. "That sounds like it matters more than it sounds."

"It matters enormously," Margaret said. "And most people don't feel it until something goes wrong."

The Console's Seduction

"Let me show you something," Margaret said. She reached across and navigated to the EC2 launch wizard — the sequence of screens that walks a user through creating a new virtual server. Instance type. AMI. Storage. Security group. Key pair. The Console presented each choice in a clean, guided interface, with helpful descriptions and sensible defaults highlighted.

"Launch an instance," she said. "Walk through it."

Timothy worked through the screens carefully, reading each option, making reasonable choices. Four minutes later he had a running EC2 instance — a small one, the kind used for testing, available in the free tier.

"That was not as difficult as I expected," he said.

"No," Margaret agreed. "It never is, the first time." She looked at the screen. "Now. Tell me exactly what you just did. Not in general terms — exactly. Every choice you made, every field you filled, every default you accepted."

Timothy opened his mouth. Then closed it.

"The instance type," he started. "t2.micro. And the AMI was — Amazon Linux, I think. Or possibly Ubuntu. I'm not entirely certain which I selected." He frowned. "The security group — I created a new one. With the default rules, I believe. And the storage —" He stopped. "I accepted whatever the default was."

"So if this instance were to fail tonight," Margaret said, "and you needed to replace it exactly — you could not."

"Not exactly, no."

"And if a colleague needed to create an identical environment — you could not give them the steps."

"I could give them the general steps," Timothy said. "But not the exact configuration."

"Which in a production environment," Margaret said, "is the difference between a recoverable situation and a very difficult evening." She settled back. "The Console did not fail you. You followed it correctly and it produced what you asked for. But the Console kept no record. The knowledge of what you built lives only in your memory, which is already imperfect, six minutes after you built it."

Timothy looked at the running instance on the screen with a slightly different expression than before.

"It felt like I knew what I was doing," he said.

"It always does," Margaret said. "That is the Console's particular seduction. It makes complex things feel manageable by presenting them one step at a time. Which is genuinely valuable — for learning, for exploration, for understanding what options exist." She paused. "It becomes a problem when it substitutes for understanding. When you follow the wizard and arrive at a result without being able to explain, precisely, how you got there."

The CLI — Uncomfortable at First

"Open a terminal," Margaret said.

Timothy pulled up a terminal window, the cursor blinking against the dark background with the particular patience of something that had been waiting a long time.

"The AWS CLI is installed separately from the Console — a few minutes of setup, credentials configured once, connection tested. It is not complicated, but it is not automatic." She paused. "Once it is done, however, you are in. And then — you type what you want."

She leaned forward and typed a single command:

aws ec2 describe-instances

The terminal returned a wall of JSON — structured, precise, and not immediately friendly.

Timothy looked at it. "That is a great deal of text."

"It is every instance in your account, described in complete detail. Every field. Every value. Every choice that was made at creation, preserved exactly." She looked at him. "The Console showed you a dashboard. The CLI showed you the truth."

"The truth is quite verbose."

"The truth often is," Margaret said. "But it is addressable. You can filter it, format it, pipe it into other commands. You can ask it specific questions and get specific answers. And — more importantly — you can reverse the direction."

She typed again:

aws ec2 run-instances \
  --image-id ami-0abcdef1234567890 \
  --instance-type t2.micro \
  --key-name my-key-pair \
  --security-group-ids sg-0abcdef1234567890 \
  --count 1

"Those values — the image ID, the security group — come from your account, looked up in advance. The command itself is the point." She looked at him. "This launches an EC2 instance. Exactly like the wizard you just completed. But this command can be saved. It can be shared. It can be put in a script and run a hundred times with identical results. It can be reviewed by a colleague, checked for errors, stored in version control alongside your application code." She paused. "It is not a series of clicks that disappear the moment you make them. It is a record. An instruction. A reproducible act."

Timothy read the command carefully. "Every parameter is explicit."

"Every parameter is explicit," Margaret agreed. "Nothing is hidden in a default you accepted without reading. Nothing is a choice you made and forgot. The command is the configuration. The configuration is the command."

What the Console Is Actually For

"I don't want you to leave here thinking the Console is wrong," Margaret said. "It isn't. It is the right tool for specific things, and I use it regularly."

Timothy looked up. "For what?"

"Exploration. When AWS releases a new service and I want to understand what it offers — I use the Console. When I need to see the current state of something at a glance — costs, running instances, alarms — I use the Console. When I am teaching someone what a service looks like before they touch the CLI — I use the Console." She looked at him. "What I do not use it for is building. For creating resources that will matter. For making changes to anything I would need to explain, repeat, or recover from."

"So the Console is for looking," Timothy said. "The CLI is for doing."

Margaret considered that. "That is slightly too clean a division. But as a starting principle — yes. The Console shows you the world. The CLI changes it, in ways you can document and defend."

"And if someone uses only the Console?"

"Then their infrastructure exists in a state that only they fully understand, held together by memory and habit, impossible to reproduce reliably and difficult to hand off." She paused. "It works — until it doesn't. And when it doesn't, it fails in the most inconvenient possible way."

Infrastructure as Code

"There is a third thing," Margaret said. "We will not go deep on it today — it deserves its own discussion. But I want to name it, because it is where the CLI's logic leads."

"Go ahead."

"If the CLI is valuable because it makes infrastructure changes explicit and repeatable — text that can be saved, shared, and version controlled — then the natural next step is to describe your entire infrastructure as text. Not commands you run one at a time, but a complete description of what should exist, handed to a tool that makes it so." She looked at him. "CloudFormation. Terraform. The idea that your infrastructure is something you write — a document, a specification, a thing that can be reviewed, tested, and deployed as reliably as application code." She paused. "From infrastructure as something you do, to infrastructure as something you define. We will get there. But it starts here — with the understanding that clicks don't scale, and that anything worth building is worth writing down."

Timothy was quiet for a moment. "That's a significant shift."

"It is the shift," Margaret said simply.

Before Next Time

He closed the laptop, finally — the EC2 instance still running somewhere in a data center in a region he had selected somewhat arbitrarily, a choice that would matter more than he yet understood, billing quietly at a rate that would amount to almost nothing but was nevertheless real.

Timothy looked at the screen. Reached for the Console, then stopped. Looked at her.

"CLI," he said.

"CLI," she agreed.

He found the command, checked it twice, ran it. The instance terminated. The billing stopped. The configuration — such as it was — vanished, unrecorded, a lesson in itself.

"Next time," he said, at the door, "I'll write the command first."

"Next time," Margaret said, "you'll understand why that matters."

She watched him go, then turned back to the quiet library, the cursor still blinking in the open terminal on her own screen, waiting with its customary patience for the next instruction.

Next episode: IAM — Identity and Access Management. Who gets to do what, and why getting this wrong is the most expensive mistake in AWS. Timothy meets permissions for the first time, and discovers that "just give it full access" is not a policy.

Aaron Rose is a software engineer and technology writer at tech-reader.blog.

Catch up on the latest explainer videos, podcasts, and industry discussions below.

Search This Blog

Tech-Reader.blog