---
title: Understanding AWS EBS Permissions.
author: Victor Olmedo
date: 2026-08-02
tags:
  - AWS
  - Security
  - SecurityX
  - Cloud
  - IAM
  - EBS
---

# Understanding AWS EBS Permissions

## Introduction

Amazon Elastic Block Store (EBS) provides storage for workloads like EC2's running in Amazon Web Services (AWS). EBS allows you to take frequent snapshot of these volumes to support disaster recovery. Most people assume that the ebs permissions are only managed through the ec2 api's, but that is not 100% accurate. Although a majority of interaction is done through the ec2 api like `ec2:CreateSnapshot` or `ec2:CreateVolume`, there is also the `ebs:` api prefix. EBS direct api's allow the application to read snapshot data at the block level. Because of this, it is important to review and carefully grant this prefix according to least privilege. 

# What is a Snapshot Block 

An EBS snapshot contains blocks of data copied from an EBS volume or another supported data source. A block is a freagment of the data contained in the snapshot. Instead of requireing an application to create and attach a new EBS volume, the EBS direct APIs allow the application to work with snapshot blocks directly. 
For example, a backup acpplication can compare two related snapshots and retrieve only the block that changed. However, this block-level access also creates security concerns. 

# Why the permissions are sensitive

A malicious actor might be able to retrieve underlying snapshot data block by block if they have `ebs:` permissions even though they might not have `ec2:CopySnapshot` or a similar ec2 api prefix.
For example, imagine that an IAM role cannot create a volume from a snapshot. If the user has ebs:ListSnapshotBlocks and ebs:GetSnapshotBlock, the user could list the snapshot blocks, obtain block tokens, and retrieve the underlyng data. Although it is not a straight forward and easy task for the malicious actor, the person can enumarate and reconstruct your data with some minimal assistance. 
For further context, here is my take on the workflow. The actor locates the ebs volume by running ebs:ListSnapshotBlocks. They then receive block indexes and temp block tokens. They run ebs:GetSnapshotBlock and download the data from each block. They are then able to reconstruct and analyze the disk data. Once the data has been reconstructed, the actor could then look inside all files like your .ssh file or your .env files where it is common to have credentials.

# Applying Least Privilege

Organizations should separate EBS api permissions according to the role being performed. Access should be limited to approved snapshot resources as much as possible. To assist in this, you can tailor your IAM policy with snapshot resource ARN's and condition based on resource tags. Tagging alone is not the solution if the same principal has the authority to add the required approval tags. Another way to mitigate this is to involve the KMS service in some capacity.
I recommend that organizations monitor the use of the ebs:GetSnapshotBlock api because it represents access to the actual contents of a snapshot.

# Conclusion

The `ebs:` service prefix contains 6 permissions, but those permissions provide powerfull block-level access to EBS snapshot.
Read permissions:
- ebs:ListSnapshotBlocks
- ebs:ListChangedBlocks
- ebs:GetSnapshotBlock

Write permissions:
- ebs:StartSnapshot
- ebs:PutSnapshotBlock
- ebs:CompleteSnapshot

The most important point to this blog is that these permissions should be controlled and treated as data-access permissions rather thatn simple snapshot-management permissions. Restricting ec2 actions alone may not fully protect your organizations snapshot data. It is a good practice to review your permissions often and remove things that are over permissive.