AWS Console Tour
Navigating the AWS Management Console efficiently: the search bar, Region switcher, CloudShell and Resource Explorer, and when not to use it at all.
The console is where most people meet AWS, and it is genuinely good for exploring, reading state and diagnosing problems. It is a poor place to build anything you intend to keep.
This page covers using it well, and knowing when to stop.
The search bar does almost everything
Pressing / or Alt+S focuses the unified search bar, and it is by far the fastest way to move around. It searches services, documentation, the AWS Marketplace and, usefully, your own resources.
Typing an instance ID, a bucket name or a function name jumps straight to that resource. Typing a partial service name gets you there in three keystrokes, which is quicker than any menu.
Learn this one thing and console navigation stops being a chore.
The Region switcher is the thing to watch
Top right, and it determines which resources you see. Almost every "my resources have disappeared" moment is the wrong Region.
A few services are global and ignore the switcher entirely:
| Global | Regional |
|---|---|
| IAM | EC2, VPC, RDS, Lambda |
| Route 53 | S3 buckets (created in a Region, listed globally) |
| CloudFront | ECS, EKS, most everything else |
| WAF (for CloudFront) |
That S3 row is a common confusion: the bucket list is global, but each bucket lives in a Region and its contents are served from there.
Resource Explorer searches across Regions and resource types at once, which answers "where did I create that?" without switching through each Region manually. It needs enabling first, and is worth doing on day one.
CloudShell
The terminal icon in the top bar opens a browser shell with the AWS CLI already installed and already authenticated as your console identity. No credential configuration, no access keys.
It is genuinely useful:
- Running a quick CLI command without leaving the browser.
- Working from a machine where you cannot install the CLI.
- Verifying what a command does before putting it in a script.
It includes 1 GB of persistent home directory storage per Region, and sessions time out after about 20 minutes of inactivity.
Reading state efficiently
Where the console beats the CLI:
Service dashboards give a visual overview. An ECS service's deployment progress, an RDS instance's Performance Insights graphs, a VPC's resource map, that would take several CLI calls to assemble.
CloudWatch dashboards and Logs Insights are considerably nicer in the browser than through the API.
Cost Explorer is console-only in practice. Ten minutes there answers most "why is the bill high" questions.
Trusted Advisor surfaces idle resources, unattached volumes and security findings in one place.
Tag Editor and Resource Groups
Tag Editor finds resources across Regions and services by tag, and can bulk-apply tags to the results. Retrofitting a missing Owner tag across a few hundred resources is one of the few bulk operations the console does better than scripting.
Resource Groups collect resources matching a tag query into a named view, which is a practical way to see everything belonging to one application.
Keyboard and layout
| Shortcut | Does |
|---|---|
/ or Alt+S | Focus search |
Alt+N | Open the notifications panel |
| Star icon | Pin a service to the sidebar |
Pinning your six most-used services to the favourites bar removes most menu navigation. Recently visited on the console home covers the rest.
The unified settings page sets your default Region, visual mode and language, which is worth doing once.
When not to use the console
This is the part that matters more than any navigation tip.
Never build production infrastructure by clicking. The problems are not hypothetical:
- It is not reproducible. Nobody can recreate the environment, including you in six months.
- It is not reviewable. A change nobody saw is a change nobody checked.
- It is not versioned. There is no record of what changed, when or why.
- It drifts. A console change to Terraform-managed infrastructure is silently reverted on the next apply, or causes a confusing plan.
- It does not scale. Three environments means clicking the same thing three times, slightly differently.
Use Terraform, CloudFormation or CDK for anything that should still exist next week.
Where the console is legitimately the right tool
- Learning. Clicking through a service teaches its shape far faster than reading a schema.
- Reading state and diagnosing. Dashboards, logs, metrics, Cost Explorer.
- One-off account setup that has no API. Authorising a CodeStar connection, enabling MFA on root, activating cost allocation tags.
- Genuine emergencies, where a manual fix now beats a correct fix in twenty minutes. Reconcile it back into code afterwards, promptly.
A practical pattern: explore in the console, then write the Terraform. Clicking through a service to understand it and then codifying the result is a legitimate and efficient workflow. Leaving the clicked version running is not.
Make production read-only
The strongest safeguard available, and it takes five minutes.
With IAM Identity Center, give yourself a read-only permission set for production by default, and a separate administrator one selected deliberately. Browsing production then cannot change it, and making a change is a conscious act of switching roles.
That removes an entire category of accident, the mistaken click in the wrong tab, at the IAM layer rather than relying on care.
Go deeper in this section
| Sub-topic | What you will learn |
|---|---|
| AWS Account Setup | Root hardening, MFA and billing alarms |
| AWS CLI Setup | SSO profiles and the credential chain |
Quick reference
| Task | How |
|---|---|
| Search anything | / or Alt+S |
| Switch Region | Top-right dropdown |
| Open a browser shell | Terminal icon in the top bar |
| Find resources across Regions | Resource Explorer |
| Bulk-tag resources | Tag Editor |
| See spend | Cost Explorer |
| Pin a service | Star icon beside its name |
| Confirm your identity | aws sts get-caller-identity in CloudShell |
Key takeaways
/focuses the search bar and is the fastest navigation in the console.- The Region switcher explains most missing resources. IAM, Route 53 and CloudFront are global.
- Resource Explorer searches across Regions: enable it early.
- CloudShell is pre-authenticated as your console identity, with no keys to configure.
- Cost Explorer and Trusted Advisor are console-first and worth the visit.
- Never build production by clicking. Not reproducible, not reviewable, not versioned, and it causes drift.
- Explore in the console, then write the Terraform.
- Make production read-only by default with a separate admin role.
Check your understanding
Resources that vanished
An engineer created an EC2 instance yesterday and today the console shows none. What is the most likely explanation?
A console change to managed infrastructure
Someone changes a security group rule in the console on infrastructure managed by Terraform. What happens next?
Frequently Asked Questions
Why can't I see my AWS resources in the console?
Almost always the Region selector in the top right. Most AWS services are regional, so the console only shows resources in the currently selected Region, and it can differ between browser sessions or from what a colleague is looking at. IAM, Route 53 and CloudFront are global and always visible. Enabling Resource Explorer lets you search every Region and resource type at once, which answers the question in one step rather than by clicking through Regions.
What is AWS CloudShell and when should I use it?
A browser-based terminal with the AWS CLI preinstalled and already authenticated as your console identity, so there are no credentials to configure. It is useful for running a quick command without leaving the browser, working from a machine where you cannot install the CLI, and checking what a command does before committing it to a script. It provides 1 GB of persistent storage per Region and times out after roughly 20 minutes of inactivity.
Should I build infrastructure in the AWS console?
Not for anything you intend to keep. Console-built infrastructure is not reproducible, not reviewable, not versioned, and it causes drift when it touches resources managed by Terraform or CloudFormation. Use infrastructure as code for anything that should still exist next week. The console is genuinely good for learning a service's shape, reading state, and diagnosing problems. A common and sensible workflow is to explore in the console and then write the Terraform.
What is the fastest way to navigate the AWS console?
Press / or Alt+S to focus the unified search bar, then type a service name or a resource identifier. It searches services, documentation and your own resources, so typing an instance ID or bucket name jumps straight there. Pin your most-used services to the favourites bar with the star icon, and set a default Region in the unified settings. Between them, those three things remove most console navigation.
Which AWS services are global rather than regional?
IAM, Route 53, CloudFront, and WAF when used with CloudFront. Everything else is regional, including EC2, VPC, RDS, Lambda, ECS and EKS. S3 is a partial exception worth knowing: the bucket list is global so all your buckets appear regardless of Region, but each bucket lives in a specific Region and its data stays there. Certificates in ACM are regional, which is why CloudFront requires one issued specifically in us-east-1.
How do I avoid accidentally changing production from the console?
Make production read-only by default. With IAM Identity Center, assign yourself a read-only permission set for the production account and a separate administrator one that you select deliberately when you intend to make a change. Browsing production then cannot modify anything, and a mistaken click in the wrong browser tab fails at the IAM layer rather than succeeding. It takes a few minutes to set up and removes a whole category of accident.