Amazon EBS Type for MySQL Replication Server
Your "distribution master" -- assuming it is running MySQL Server, not a specialized program specifically for directly replicating  binlogs -- cannot "just get data from Master and replicate to the Slave when gets connection" and relay the incoming events to downstream replicas.  It will also be keeping a copy of the entire data set and processing the replication events, keeping its local copy in sync before sending the events downstream.  

It will, therefore, need to have as much I/O capacity as needed in order to keep up with the master.

The question of whether sc1 Cold Storage (mechanical) HDD EBS volumes offer sufficient capacity in both write throughput and IOPS is not a question that can be answered in general. 

The answer depends entirely on your workload.

There is nothing in sc1 that is intrinsically incompatible with MySQL, but a 500 GiB sc1 volume has a baseline throughput of only 6 MiB/s and a burst throughput of 40 MiB/s.  There is a reason it is marketed as "cold storage," and a reason it is inexpensive.

An st1 Optimized Throughput (also mechanical) HDD volume has > 3x the performance for &lt; 2x the price of sc1 so is a somewhat safer bet.  I have recently begun testing st1 volumes for binary log and relay log storage on some non-critical replicas -- with the datadir still on gp2 SSD volumes -- and have not been seeing any replication lag nor taxing of these volumes according to the CloudWatch metrics nor significant iowait... but binary logs and relay logs are, of course, largely sequential write and read, which puts them within the design parameters of both st1 and sc1.

The bottom line, though, is that your experience will be highly correlated to your workload.

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html



Remember also that if you create a volume of any storage class from an EBS snapshot (such as when you are testing different storage classes -- a snapshot made from one type of volume can be used to create a volume of a different type) that you will see degraded performance until the volume is warmed up.

Assuming the volume is /dev/xvdf, this might look like dd if=/dev/xvdf obs=1M | pv -pterab &gt; /dev/null ... followed by a few hours of waiting.  Don't try to optimize a warmup with fio or a large block sizes on smaller instances -- you'll DoS your own instance if you hit a stretch of already warmed-up blocks and the volume's read throughput spikes significantly above the available network bandwidth on the instance's Ethernet interface.  If this happens, the instance will fail its health checks.