DEV Community: Jonathan Vogel

us-east-1 or Somewhere Closer? How to Pick an AWS Region Without Overthinking It

Jonathan Vogel — Fri, 05 Jun 2026 15:21:21 +0000

A 30-second decision on your very first screen that saves a lot of confusion later.

You sign up for AWS, open the console for the first time, and before you've built anything there's a dropdown in the top-right corner asking you to pick a Region. N. Virginia. Ohio. Ireland. Tokyo. A couple dozen options and no context for what any of them mean or why you'd choose one over another.

So you do what most people do. You leave it on whatever it defaulted to, or you pick one that sounds close, and you move on. Then a week later you come back, switch something, and your S3 bucket is gone. Your EC2 instance is gone. Everything you built looks like it vanished.

Not a good feeling until you realize it's all good, everything's there, you're simply looking in the wrong Region.

I talk to students and AWS beginners who run into this scenario. What's up with the Region drop down and why does it matter? By the end of this post you'll know what a Region is, the four things that go into picking one, why most of them don't matter for you yet, and why your stuff seems to disappear when you switch.

Quick note before we start. If you search around, most Region guidance is written for companies shipping production workloads. The advice is good and I link to the best of it below, but it carries an unspoken assumption: that this choice is heavy and you'd better get it right. For a student on a first project, that framing is backwards. Your Region choice is low-stakes and easy to redo. I regularly get asked by folks getting started with AWS which region to pick. This post is for you.

What a Region actually is

A Region is a physical location in the world where AWS runs a cluster of data centers. US East (N. Virginia) is a real set of buildings in Virginia. Europe (Ireland) is a real set of buildings in Ireland. When you launch an EC2 instance or create an S3 bucket in a Region, your stuff physically lives in that part of the world.

The list of AWS regions continues to grow. In June 2026, AWS runs 39 Regions and 123 Availability Zones around the world, with more announced. You don't need to memorize them. You need to pick one and understand the reasons why people end up in one region or another. The high level reasoning doesn't change even as more regions continue to launch.

The four things that actually matter

AWS publishes a short list of what goes into a Region choice. There are four factors you should be aware of. While it might be worth bookmarking that post, it is aimed at teams choosing a home for a real production workload. Let's walk through the same four factors through a beginner lens.

1. Latency. This is the big one for anything people interact with. The closer a Region is to whoever uses your app, the faster it feels, because the data has less physical distance to travel. A site hosted in Tokyo will feel snappy in Osaka compared to say Toronto. For a student building a portfolio project, "whoever uses your app" is mostly you and whoever clicks the link on your resume, so closer to you wins.

2. Cost. AWS prices the same service differently depending on the Region. The differences come from real-world costs like land, power and taxes in each location. The gaps are real but small at the scale you'll be working at. You can check exact numbers in the AWS Pricing Calculator when it matters. One thing to put out of your mind: free tier limits are account-wide, not Region-specific, so your Region choice won't affect your free tier eligibility.

3. Service availability. AWS rolls new services and features out Region by Region. A smaller Region might not have that brand-new service you read about yet, though it's just as reliable, the newest features simply land in the bigger Regions first. For the core building blocks a beginner uses, EC2, S3, Lambda, RDS, every Region has them (you can check what's where on the Region services list or the Builder Center's visual capabilities page).

4. Compliance and data residency. Some data is legally required to stay inside a specific country or jurisdiction. If you're handling that kind of data, this factor overrides the other three. As a student on a personal project, this almost never applies to you. It's worth knowing it exists, because the day a job hands you regulated data, this becomes the first question you ask, not the last.

Notice the order of who cares about what. A bank cares about compliance first. A game backend cares about latency first. A data-crunching batch job that no human waits on cares about cost first. Right now, you care about latency, which conveniently points to the simplest possible answer.

There's technically a fifth factor AWS publishes for teams with sustainability goals: some Regions run on cleaner energy than others. Don't worry about this as a beginner. If you care about your footprint, you'll have far more impact by turning off resources you're not using than by hunting for a greener Region. This same instinct will help keep your bill lower too!

For your first project, pick the closest one and move on

The beginner shortcut: pick the Region closest to you and stick with it for everything. This move will ensure you don't have to worry about latency for a personal project and give you the services you need as a beginner.

One nuance worth a sentence. A lot of tutorials and AWS examples default to us-east-1 (N. Virginia), and some guides quietly assume you're in it. It's worth noting us-east-1 is often the first Region to get the latest goodies AWS drops, new services tend to start there before they're available anywhere else. If you're following a step-by-step guide and something won't line up, check whether the author is in us-east-1 while you're somewhere else. For your own building, closest-to-you is the better default. For following along with a tutorial, matching the tutorial's Region can save you a headache.

The part that matters more than which Region you pick is picking one and being consistent. Which brings us to the thing that trips up almost everyone.

"But what if I pick wrong?"

You won't and you're not stuck there. If you start in Ohio and later decide Ireland is closer to your users, you spin up fresh resources in Ireland and tear down the old ones. There's no penalty, no lock-in, no big migration task for a personal app with a handful of resources. The companies that agonize over this are moving terabytes of data and thousands of resources, where moving might take a bit more work. You are moving a bucket and an instance. Pick one, learn on it, change your mind freely. The cost of "wrong" at your scale is measured in minutes instead of weeks or months.

Why your bucket "disappeared" (one of the gotchas)

Most AWS resources are Region-scoped. That means a resource you create lives in exactly one Region and shows up only when you're viewing that Region in the console. Each Region is fully isolated from the others, by design, so a problem in one Region can't take down another.

So picture this. You create an EC2 instance in Ireland on Monday. On Wednesday you open the console, the Region dropdown happens to say Ohio, and you go looking for your instance. It's not there. Panic.

Nothing got deleted. You're standing in a different room. Switch to Ireland and your instance is right where you left it.

This is exactly how beginners end up scattering resources without realizing it. You do one tutorial in us-east-1, a class project in us-west-2, and a weekend experiment somewhere else. Now your account has things spread across three Regions. You can't find your stuff, your bill has charges from Regions you forgot you touched, and resources look "missing" when they're just somewhere else.

Future you will be grateful for picking a region and sticking to it in the beginning.

The exception that's worth knowing

A handful of AWS services are global, not Region-scoped, so they look the same no matter what the dropdown says. The ones you'll meet early are IAM (users and permissions), billing (account-wide), and likely Route 53 / CloudFront. So if your IAM users don't change when you switch Regions, that's correct. They're global. Everything else, assume it's tied to a Region until you learn otherwise.

The 30-second decision, as a flow

When deciding on a region, run this in your head.

Is there a legal rule about where this data must live? If yes, pick a compliant Region in that jurisdiction. Done. (As a student, you'll almost always skip this.)
Does a human wait on this app? If yes, pick the Region closest to those people. For a personal project, that's closest to you.
No humans waiting, just background number-crunching? Pick the cheapest Region that has the services you need.
Following a tutorial that assumes a Region? Match it.

Then, the rule that ties it all together. Whatever you pick, use it for everything in this project so your resources don't scatter.

Quick reference

Region decision factor	What it means	Does it matter for your first project?
Latency	Closer Region = faster for users	Yes. Pick closest to you.
Cost	Same service, slightly different price per Region	Barely. Differences are small at your scale.
Service availability	Newer features land in bigger Regions first	No. Core services are everywhere.
Compliance	Data legally bound to a location	Almost never for students. Know it exists.
Consistency	Keep everything in one Region	Yes. This is the one that saves you pain.

Gotcha	Why it happens	What to do
"My resource disappeared"	Resources are Region-scoped; you switched Regions	Switch the dropdown back to the Region you built in
Charges from a Region you forgot	You scattered resources across Regions	Pick one Region and stay in it; clean up the strays
IAM users look the same everywhere	IAM is a global service	That's correct, nothing to fix

What's next

Picking a Region is step one. The next fear most beginners have is the bill. If you've heard the horror stories about surprise AWS charges, read You Deleted Everything and AWS Is Still Charging You next. It walks through what actually keeps costing you after you think you've cleaned up, and how to set a billing alarm so nothing sneaks past you. Pair these two and you've handled the two things that scare people off AWS on day one.

The Region dropdown isn't a test you can fail. Pick the one closest to you, keep everything there, and keep building.

Access Denied: What Every AWS Beginner Gets Wrong About IAM

Jonathan Vogel — Wed, 20 May 2026 19:45:19 +0000

The IAM mental model I wish someone had drawn on a whiteboard for me when I was starting out with AWS.

If you want a video to follow along with this blog, you can find it on the AWS Developers Youtube Channel

I spun up a Lambda function and tried to have it read from an S3 bucket only to get Access Denied.

This wasn't a typo or misconfiguration. I just straight up didn't understand IAM. So I did what every beginner does, I attached AdministratorAccess, the error went away, and I moved on.

What I didn't think about at the time is that I'd just given that Lambda function permission to do anything in my account. Delete databases. Create resources that cost money. Access data across every service it had no business touching. All because it needed to read from one S3 bucket.

I talk to students and developers getting started with AWS all the time, and this is the pattern. Everything goes smooth when you follow the tutorial. When it comes to implementing your own project, you run into a permission blocker. You come up with an easy solution. You slap on AdministratorAccess and now you have a security problem you don't even know about. The Access Denied error was actually trying to help you. It was telling you exactly which permission was missing. You just didn't know how to read it yet.

This post is the mental model I wish I'd had. Once you understand what I'm about to lay out, Access Denied stops being a wall and starts being a useful message.

What IAM Actually Is

IAM stands for Identity and Access Management. Not sure if that name really helps you, let me put it differently.

IAM is the bouncer at the door of every AWS service. Every time anything happens in your account, whether you click a button in the console, your code calls an API, or a Lambda function tries to read from a database, IAM checks two things.

Who are you?
Are you allowed to do this?

If the answer to either question is "no," you get Access Denied. Those two questions are the entire foundation. The rest of this post is about how they get answered.

Users, Roles and Policies

Three concepts make up the whole model when you're getting started.

IAM Users = Employee Badge

An IAM user is a persistent identity. It represents a person who needs to log into the console or use the CLI. It has long-term credentials, a username and password for the console, or access keys for programmatic access.

Think of it like an employee badge. It's yours, it has your name on it, and it works every day until someone revokes it.

IAM Roles = Visitor Pass

An IAM role is temporary. It doesn't belong to anyone permanently. Instead, it gets assumed (borrowed) by whoever needs it at that moment. AWS gives the assumer temporary credentials that expire automatically.

Think of it like a visitor pass at an office. You check in, you get a badge, it works for a few hours, then it stops working.

Rule of thumb. If it's a person logging in, that's a user. If it's a service doing something, a Lambda function, an EC2 instance, another AWS account, that's a role. Roles are how Lambda functions access S3, how EC2 instances talk to DynamoDB and how one AWS account talks to another. The credentials are always short-lived, so there's nothing sitting around that could be stolen.

Policies = Permission Slip

A policy is a JSON document that says "this identity is allowed to do these actions on these resources." You attach policies to users or roles. Without a policy attached, an IAM identity can do nothing. You have to explicitly grant every single permission.

A simple policy looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

This says: allow reading objects from one specific S3 bucket. Nothing else.

The Mental Model

A user or role is who you are. A policy is what you're allowed to do. Identity plus permission. That's the whole thing.

The Least Privilege Principle

This is the one concept that makes everything in IAM make sense. It applies across all of computer security, not just cloud.

Least privilege means: give every identity only the permissions it needs to do its job. Nothing more.

You already saw the wrong version in my story. I gave a Lambda function permission to do everything because it needed to do one thing. AdministratorAccess makes the error go away, but it also means anything in your account can do anything to your account.

That's like giving every employee in a company a key that opens every door because they needed to open one.

The right approach is to figure out exactly which actions your identity needs, on exactly which resources, and grant only that. That Lambda function I mentioned at the start? The policy it actually needed:

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*"
}

One action. One bucket. If that function ever gets compromised, the damage is limited to reading objects from one bucket, not your entire account.

"But figuring out exact permissions sounds like a lot of work." It can take some extra minutes upfront. AWS gives you a tool called IAM Access Analyzer that looks at what your identity actually used over a period of time and generates a scoped policy based on real activity. You let your service run, then Access Analyzer tells you what it actually needed. You don't have to guess.

Your IAM Starter Checklist

I share this with every student setting up a new AWS account. Bookmark it and come back at the end of every project.

1. Lock down your root user

When you first create an AWS account, you start as the root user. Root can do anything, including things no other identity can do, like closing the account entirely. It's the "break glass in case of emergency" identity.

Enable MFA on root immediately. That's multi-factor authentication, so even if someone gets your password, they still can't log in without your second factor. Then stop using root for daily development.

2. Set up daily access

For day-to-day work, create a separate identity. If you're learning on a personal account, an IAM user with MFA works fine. If you're working with a team or thinking about production, IAM Identity Center is the current best practice. It gives you temporary credentials and scales well when you add team members.

3. Use roles for services

When you build things, Lambda functions, EC2 instances, anything running code, use roles. They don't need long-lived access keys. They need roles with temporary credentials.

4. Start with managed policies, then tighten

AWS has pre-built managed policies for common use cases. They're a reasonable starting point when you're learning. As you understand what your application actually needs, narrow the permissions down. You don't have to write perfect policies on day one, but you should be moving toward least privilege over time.

5. Never put access keys in your code

Putting keys directly in source code is a bad idea. They should never be in config files or any variable pushed to Git. Use roles instead. If you ever accidentally push AWS keys to a public repo, rotate them immediately. Bots scan for exposed keys within minutes.

Quick Reference

Step	What to Do	Why
Lock down root	Enable MFA, stop using root daily	Root = key that opens all doors
Set up daily access	IAM user (learning) or Identity Center (teams)	Limits root exposure
Use roles for services	Lambda, EC2 get roles, not users	Temporary credentials, nothing to steal
Start managed, then tighten	Use AWS managed policies first	Don't guess permissions on day one
No keys in code	Use roles, not hardcoded credentials	Bots scan for exposed keys within minutes

What I Tell Students Who Are Afraid of IAM

Every time someone tells me "I just attach AdministratorAccess because IAM is confusing," I tell them the same thing. The confusion comes from not having the mental model. Now you have it.

Users are people. Roles are services. Policies define what any of them can do. Least privilege means only what you need, nothing more. And Access Denied is IAM telling you exactly which permission is missing. Read the error. It's trying to help you.

Next time you get Access Denied, and you will, don't reach for AdministratorAccess. Check the policy. You've got this.

The best time to learn IAM was when you created your AWS account. The second best time is right now.

Click here for more info on AWS Free Tier.

You Deleted Everything and AWS Is Still Charging You

Jonathan Vogel — Fri, 13 Mar 2026 18:33:50 +0000

The AWS cleanup checklist I wish someone had given me when I was starting out with cloud.

I talk to computer science students regularly. There's one fear that comes up more than almost anything else: "I am worried about spinning up stuff in the cloud and charges getting out of control."

I used to feel this. Some time ago, I set up a relational database on RDS, some virtual machines as EC2 instances, an S3 bucket to upload some data. After I was done, I deleted everything on the AWS console. Deleted my database. Terminated my instances. Then I got a bill I wasn't expecting.

Didn't everything get deleted? Literally AWS told me "deleting" in the console. I didn't think anything was running. What happened?

That experience stuck with me. As I work with students building on AWS, I see the exact same thing happen to them. Last semester alone, I heard some version of this story from students.

I'm gonna walk us through what's actually going on and give you a checklist to eliminate this fear when building out on AWS.

What's Actually Charging You After You "Delete Everything"

Here's an example. You delete your RDS instance at the end of a semester project. Makes sense. Project's done. But during deletion, AWS offers to create a final snapshot of your database. It's a checkbox. You probably don't even register that it's there. You click through, the database goes away, and that snapshot sits in your account quietly costing you money.

Same thing with EC2. You terminate your instances and depending on how your volumes were configured, the EBS volumes that were attached don't always get deleted with the instance. They're still there, billing. Invisible unless you know where to look.

And then there's this one that gets people: Elastic IPs. When you terminate an instance, the Elastic IP doesn't get deleted with it. It just sits there, unattached, costing you a few dollars per month. Not huge, but it adds up when you forget about it. That one catches people off guard.

None of this is hidden. It's all documented. But nobody tells you to look for it when you're learning, and the console doesn't wave a red flag that says "hey, you still have billable resources over here."

Why This Frustrates Me

Here's the part that actually gets to me as a Developer Advocate. When a student gets a surprise bill, they don't usually think "I missed a step in my cleanup." They think "AWS secretly charges you even after you delete stuff." They tell their classmates and that becomes the narrative. I've heard it in person, on discord, etc. "Be careful with AWS, they'll charge you for nothing." It's not cool because it can scare people away from learning skills that would genuinely help their careers.

AWS doesn't charge you in mysterious ways. It charges you in specific, predictable ways that nobody taught you to look for. That's a knowledge gap. The purpose of this post is to shed some light on this.

There's a Better Way Now

Here's something I wish existed when I was starting out. AWS now has a free account plan where you get $100 in credits just for signing up, and you can earn up to $200 total by completing activities like launching an EC2 instance or creating a budget. The key part: you literally cannot be billed. There's no scenario where you wake up to a surprise charge. When your credits run out or six months pass, whichever comes first, your account just closes. That's it. No bill.

If you want more flexibility -- say you're working on a longer project or you don't want to risk your account closing mid-semester -- you can choose the paid account plan instead. You still get the same $200 in credits, but your account stays open after they're used up. The tradeoff is that you can be billed beyond your credits, which is exactly why the billing alarm later in this post matters. Set that up on day one and you're covered.

I've been guiding more students toward these options lately and it keeps coming up enough that I'll probably write a dedicated post about it soon.

The Cleanup Checklist

This is what I share with every student I work with now. I tell them to bookmark it and come back to it at the end of every project.

Start With Your Bill, Not Your Console

Before you click around trying to find leftover resources, go to AWS Billing Dashboard from the AWS console. Look at the current month's charges broken down by service. This tells you exactly which services are costing money right now.

If you see a charge for RDS, go check RDS. If you see a charge for EC2, go check EC2. Let this be your map.

Use Resource Explorer

Looking for an exhaustive list of everything going on in your AWS account across all regions?

Instead of clicking through every service console in every region hoping you didn't forget something, Resource Explorer gives you a single search interface across your entire account. All services. All regions. One view.

That last part matters more than you'd think. I've seen students create resources in us-east-1 for a tutorial and us-west-2 for a class project, then only check one region during cleanup and assume everything's gone. Resource Explorer solves that completely. Resource Explorer in the console. If your account is truly clean, you'll see very little. If it's not, you'll see exactly what's still hanging around.

Check the Usual Suspects

Even with Resource Explorer, it helps to know the specific things that catch people. These are the ones I see come up a lot:

Snapshots (EBS and RDS) Check EC2 -> Snapshots and RDS -> Snapshots. Common silent cost I see among students. They get created automatically, often during deletion workflows, and nobody thinks to look for them. These snapshot costs can add up - something like 100 GB could be $5/month.

Unattached EBS Volumes Go to EC2 -> Volumes and filter by state: "available." If a volume shows "available," it's not attached to anything. It's just sitting there being billed.

Elastic IPs Check EC2 -> Elastic IPs. If any are listed and not associated with a running instance, release them.

NAT Gateways If you followed a VPC tutorial with public and private subnets, check VPC -> NAT Gateways. These run about $32/month whether you're pushing traffic through them or not. If you don't need it, delete it.

Set Up a Billing Alarm

This takes two minutes and it's the single most important thing you can do on a new AWS account.

Go to Billing -> Budgets
Create a low budget, say $5 or $10
Set an alert at 80% of that threshold
Add your email

What I Tell Students Who Are Afraid to Start

Every time I meet a student who communicates to me in a way that signals "I'm scared of cloud billing getting out of control," I tell them the same thing. That fear is valid. Every dollar matters when you're a student. Once you understand where surprise charges actually come from, which is a pretty short list, the fear goes away.

The students who get burned are the ones who don't know about snapshots, orphaned volumes, and unattached Elastic IPs. Now you do.

I tell students these three things:

If you want zero billing risk, choose the free account plan when you sign up. You get up to $200 in credits and you cannot be charged. The tradeoff is that your account closes when credits run out or after six months. If you'd rather keep your account open longer, go with the paid plan -- you get the same credits, just set up a billing alarm so nothing sneaks past you.
Set up a billing alarm no matter which plan you pick
Bookmark this checklist and come back to it at the end of every project

Start the account. Build the project. Learn the skills. And when the semester ends, come back to this checklist.

Quick Reference

Check	Where to Look	What to Do
Billing by service	Billing Dashboard -> Bills	See which services are charging you
All resources, all regions	Resource Explorer	Find anything still alive in your account
Snapshots	EC2 -> Snapshots, RDS -> Snapshots	Delete what you don't need
Orphaned EBS volumes	EC2 -> Volumes -> filter "available"	Delete unattached volumes
Elastic IPs	EC2 -> Elastic IPs	Release unassociated IPs
NAT Gateways	VPC -> NAT Gateways	Delete if project is done
Billing alarm	Billing -> Budgets	Set one up before you do anything else

Or to avoid any billing entirely, choose the free account plan when signing up. You still get credits, but you are never billed. Note: when you run out of credits (or 6 months pass, whichever comes first), AWS closes your account.

Click here for more info on AWS Free Tier.

The best time to set up a billing alert was when you created your account. The second best time is right now.