No, using dd isn't "placebo."
New volumes created from existing EBS snapshots load lazily in the background.
So, if you don't do something to encourage it to be not-so-lazy, EBS would naturally assume that there's no particular hurry, so it needn't tax its own resources, or those of S3, to load the data quickly.
If your instance accesses data that hasn't yet been loaded, the volume immediately downloads the requested data from Amazon S3, and continues loading the rest of the data in the background.
If you need to ensure that your restored volume always functions at peak capacity in production, you can force the immediate initialization of the entire volume using dd or fio. For more information, see Initializing Amazon EBS Volumes.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-restoring-volume.html
You can even do this with the volume mounted. Since you're only reading from -- not writing to -- the block device, the OS will not notice or see this as a problem.
Since fio can run reads in parallel, it can warm your volume faster than dd but dd will get job done.
If you like progress meters, try pv - pterab /dev/xvdN > /dev/null. (sudo apt-get install pv first.) This will not necessarily be the fastest, but it's solid and more fun to watch, since it gives you current and sustained throughput, percent complete, and an ETA. When it's done, your volume is fully warmed up.
