Cross-Account AMI Revocation: The Day Our Server Wouldn’t Come Back

This document is not theory. This is a real-life AWS problem that hits when you least expect it — usually during a rebuild, incident, or scale-out.

If you’ve ever used a shared AMI from another AWS account, this is for you.

What problem are we solving?

You are running EC2 instances created from an AMI shared by another account. Everything works fine… until:

• The instance is terminated ❌
• The AMI owner revokes access 🔒
• You try to relaunch the instance
• AWS says: “AMI not found / Not authorized”

Now what?

First, let’s demystify this (beginner-friendly)

What is an AMI?

An AMI (Amazon Machine Image) is a template for launching EC2 instances:

• OS
• Pre-installed software
• Configuration

Think of it as a golden snapshot.

What is cross-account AMI sharing?

One AWS account (Client / Vendor / Central IT) shares an AMI with your account.

You can:

• ✅ Launch EC2 from it
• ❌ NOT own it
• ❌ NOT control its lifecycle

This is where trouble begins.

The Real-Life Incident (what actually happened)

Here’s the exact flow (very common):

1. Client shared an AMI with our AWS account
2. We launched EC2 instances using that AMI
3. Everything ran fine for weeks/months
4. We terminated an instance (maintenance / cleanup / scale down)
5. A few days later, client revoked AMI access
6. We tried to relaunch EC2
7. 💥 Failed — AMI no longer accessible

At this point:

• EC2 = gone
• AMI = gone (for us)
• Auto-scaling = broken
• Rebuild = blocked

“But the instance was already running once…”

This is the biggest misconception.

❗ Launching an EC2 does NOT make a copy of the AMI

When you launch:

• EC2 references the AMI ID
• Ownership stays with the source account

Once access is revoked:

• You cannot launch new instances
• Terminated EC2 is irrecoverable

Can we retrieve the AMI after revocation?

Short answer: ❌ No

Once AMI access is revoked:

• You cannot see
• You cannot copy
• You cannot recreate

AWS has no backdoor here.

“So are we completely doomed?”

Not always. It depends on what you did BEFORE revocation.

Let’s break it down.

Scenario 1: You created your own AMI earlier (YOU ARE SAFE)

If you had done this earlier 👇

Shared AMI → EC2 → Create Image (your account)

Then:

• 🎉 You own the new AMI
• 🎉 Client revocation doesn’t affect you
• 🎉 You can relaunch EC2 anytime

👉 Best practice: Always create your own AMI the moment you launch from a shared AMI.

Scenario 2: Instance still running (LIMITED OPTIONS)

If:

• EC2 is still running
• AMI access already revoked

You might still save yourself:

Option A: Create AMI from the running instance

EC2 → Actions → Image and templates → Create Image

This sometimes works, sometimes fails (depends on snapshot permissions)

Option B: Manual rescue (last resort)

• SSH into instance
• Backup configs, binaries, app data
• Build new instance from scratch

Painful, but better than nothing.

Scenario 3: Instance terminated AND AMI revoked (GAME OVER)

At this point:

• No AMI
• No EC2
• No snapshot access

Your only option: 👉 Rebuild manually or request AMI re-share from the owner

How to NEVER face this problem again

Rule #1: Never depend directly on a shared AMI

Treat shared AMIs as temporary installers, not production assets.

Rule #2: Copy the AMI immediately

After first launch:

Shared AMI → Copy AMI → Your Account → Your Region

Rule #3: Write this in documentation (seriously)

If AMI sharing is part of your workflow, document:

• AMI source account
• Owner
• Backup AMI ID
• Copy date

Rule #4: Add this checklist before termination

Before terminating any EC2:

• Is this instance created from a shared AMI?
• Do we own a copy of that AMI?
• Is auto-scaling using a shared AMI?

Mental model to remember

If you don’t own the AMI, you don’t own your recovery.