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.
st1 Optimized Throughput (also mechanical) HDD volume has > 3x the performance for < 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
The bottom line, though, is that your experience will be highly correlated to your workload.
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 > /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.