Resources you created minutes ago are missing. docker push to ECR succeeded,
but App Runner's image dropdown in the console is empty. A Lambda you deployed
yesterday is not in the Lambda console. aws s3 ls shows the bucket, but the
service reading it is slow, or a list-services call returns [] on an
account you know is not empty. Nothing errors loudly; things are quietly
"not there".
First weeks on AWS, working half in the console and half in the CLI. The
console's region selector was set to Mumbai (ap-south-1) by hand, but
aws configure was once answered with the tutorial default — us-east-1 — so
every CLI-created resource landed in Virginia while every console-created one
landed in Mumbai. S3 masks the split because its bucket list is global, which
is why "but I can see the bucket!" coexists with an empty Lambda console.
Linked modules: 4.7 (Cloud deployment), 4.6 (CI/CD — the pipeline's region
config).
Almost every AWS console page and CLI call is region-scoped: Lambda, ECR,
App Runner and CloudWatch in ap-south-1 and in us-east-1 are separate worlds
that never list each other's contents. "Missing" resources are almost never
deleted — they are filed under the wrong city. Some pairings are not only
confusing but broken: App Runner can only pull images from an ECR repository
in its own region, so a us-east-1 push can never appear in a Mumbai dropdown.
Confirm the split in two commands: aws configure get region (what the CLI
uses) against the region name in the console's top-right selector — and then
run the failing list command twice, once with --region us-east-1 and once
with --region ap-south-1, and watch the "missing" resource appear.
Pick the one region the project lives in — for Indian users, ap-south-1 — and
move the strays: retag and push images to the Mumbai ECR, recreate the Lambda
there, and delete the wrong-region originals so they cannot bill or confuse
again (WR-109's sweep). Set the CLI to match: aws configure set region ap-south-1. Then pin the region everywhere it is read from: the AWS_REGION
env var in CI workflows, the --region flag in deploy scripts, and the region
field in any service config — so no machine ever falls back to a default you
did not choose.
One project, one region, written down in the README and pinned in
aws configure on day one — the 4.7 setup does this before any resource
exists. Make the console's region selector a reflex glance, the way you check
the branch name before a commit. In every script and workflow, pass the region
explicitly instead of trusting defaults. And when anything seems missing on
AWS, ask "which region am I looking at?" before asking "who deleted it?" —
it resolves most cases in ten seconds.
Q: "A teammate says their pushed image does not appear in App Runner's
dropdown, and their Lambda 'disappeared'. First moves?" Strong answer: ask for
aws configure get region versus the console selector, predict the split
(CLI in us-east-1, console in Mumbai), and prove it with the same list command
run against both regions. Name the two structural facts — most services are
region-scoped, S3's global bucket list hides the problem — and finish with the
discipline: one pinned region per project, explicit --region in automation.
That answer shows debugging method, not memorised trivia.