Its good your upgrading to 10M (as seen in one of your comments) but one thing I'd also consider is instituting QoS at least on the router/firewall level for your RDP traffic. RDP isn't as touch with bandwidth as it is with latency, something QoS helps with.
We have a 6Mbit connection that was close to saturation between offsite backups and, general traffic and RDP. We noticed by implementing QoS on our firewall (running IPCop for about 150+ users) that RDP issues have almost completely gone away.
Our priority setup is similar to this;
VPN - Highest
RDP - High
SFTP - High
Email - Medium
Web - Low
Everything else - Very Low
Now instead of fighting with everything, RDP only has to deal with VPN and SFTP on priority. It cut down on the random disconnects and slowness to the point where I get complaints once every few months instead of multiple times a day.
Working on the assumption that download time (and therefore bandwidth usage) is your limiting factor, I would make the following suggestions:
Firstly, choose m1.large instances. Of the three 'levels' of I/O performance (which includes bandwidth), the m1.large and m1.xlarge instances both offer 'high' I/O performance. Since your task is not CPU bound, the least expensive of these will be the preferable choice.
Secondly, your instance will be able to download far faster than any site can serve pages - do not download a single page at a time on a given instance, run the task concurrently - you should be able to do at least 20 pages simultaneously (although, I would guess you can probably do 50-100 without difficulty). (Take the example of downloading from a forum from your comment - that is a dynamic page that is going to take the server time to generate - and there are other users using that sites bandwidth, etc.). Continue to increase the concurrency until you reach the limits of the instance bandwidth. (Of course, don't make multiple simultaneous requests to the same site).
If you really are trying to maximize performance, you may consider launching instances in geographically appropriate zones to minimize latency (but that would require geolocating all your URLs, which may not be practical).
One thing to note is that instance bandwidth is variable, at times you will get higher performance, and at other times you will get lower performance. On the smaller instances, the variation in performance is more significant because the physical links are shared by more servers and any of those can decrease your available bandwidth. Between m1.large instances, within the EC2 network (same availability zone), you should get near theoretical gigabit throughput.
In general, with AWS, it is almost always more efficient to go with a larger instance as opposed to multiple smaller instances (unless you are specifically looking at something such as failover, etc. where you need multiple instances).
I don't know what your setup entails, but when I have previously attempted this (between 1 and 2 million links, updated periodically), my approach was to maintain a database of the links adding new links as they were found, and forking processes to scrape and parse the pages. A URL would be retrieved (at random) and marked as in progress on the database, the script would download the page and if successful, mark the url as downloaded in the database and send the content to another script that parsed the page, new links were added to the database as they were found. The advantage of the database here was centralization - multiple scripts could query the database simultaneously and (as long as transactions were atomic) one could be assured that each page would only be downloaded once.
A couple of additional points of mention - there are limits (I believe 20) on the number of on-demand instances you can have running at one time - if you plan to exceed those limits, you will need to request AWS to increase your account's limits. It would be much more economical for you to run spot instances, and to scale up your numbers when the spot price is low (maybe one on-demand instance to keep everything organized, and the remaining, spot instances).
If time is of higher priority than cost to you, the cluster compute instances offer 10Gbps bandwidth - and should yield the greatest download bandwidth.
Recap: try few large instances (instead of many small instances) and run multiple concurrent downloads on each instance - add more instances if you find yourself bandwidth limited, move to larger instances if you find yourself CPU/memory bound.
Best Answer
I can't speak for Windows instances, but I will presume that their base characteristics are fairly similar to Linux instances.
Your estimate for bandwidth usage is 100 simultaneous video downloads (I am not sure if you mean downloading the file or streaming the video - I will assume the latter). If we take a stream rate of 512kbps, you need about 51Mbit/s or 6.5MB/s.
EC2 instances differ in their I/O performance (which includes bandwidth). There are 3 levels of I/O performance: low, moderate, and high. Keep in mind, though, that disk I/O (i.e. from EBS volumes) also is bandwidth dependent. You can only really consider bandwidth within the EC2 network (as it will be completely variable over the Internet).
Some typical numbers to quantify 'low', 'medium', and 'high' (different sources quote different numbers for theoretical values, so they might not be completely accurate).
High: Theoretical: 1Gbps = 125MB/s; Realistic (source): 750Mbps = 95MB/s
Moderate: Theoretical: 250Mbps; Realistic (source, p57): 80Mbps = 10MB/s
Low: Theoretical: 100Mbps; Realistic (from my own tests): 10-15Mbps = 1-2MB/s
(There is actually a 'very high' level as well (10Gbps theoretical) but that applies only to cluster compute instances only).
A further point of mention is the degree of variation. On smaller instances, there is more variability in performance as the physical components are shared between more virtual machines. Regardless, you can expect around +/-20% variation in your performance (sources: 1, 2, 3). In your case (as per the assumptions/calculations at the top), you may need peak bandwidth of 13MB/s (double 6.5MBps, since disk I/O is also network limited). If you are transferring lower bandwidth content, you should be able to use an instance with 'moderate' I/O performance (see the instance types page), if your calculations result in a higher bandwidth requirement, you will need an instance with 'high' I/O performance. Simply streaming the data should not be CPU or memory bound, but sustaining 100 simultaneous connections will probably require at least a medium sized instance - and if bandwidth is a concern, based on the above, a large instance would be a safer bet).
I would recommend benchmarking the servers you launch to see if they meet your (calculated) needs. Launch two instances (of the same type) and run
iperfon each using the instances' private IP addresses - you will need to open port 5001 in your security group if you run it with the default settings). Additionally, most tests outside of the EC2 network show results of between 80-130Mbps (large instances) - although such numbers are not necessarily meaningful.A CDN would be better suited to your needs, if your setup permits it. S3 appear to have a limit around 50MB/s for bandwidth (at least from a single instance) as per this article, but that is higher than what you should require (S3 does not support streaming). Cloudfront would be better suited to your task (as it is designed as a CDN) and supports 1000Mbps=125MB/s by default (source) with higher bandwidth available on request and can stream content as well)