We wish to reproduce results from a paper published in 2014 that used the
m3.2xlarge
instance type. If we run that today would it have the same specs? If not is there a way to find documentation on what the differences would be? In particular:
- RAM differences
- networking speed differences
- cpu differences e.g. faster core i7 cpu's..
- Changes to disk types (ssd vs sata) and access times
Best Answer
The nominal performance and specifications of any given instance class don't change over time.
The specs are exactly what defines the instance class.
When new combinations of memory, processor, disk (ephemeral, where applicable), and network are introduced, that's a new instance class. The older classes are sometimes relegated to the "previous generation" designation (such as is the case with m1 and m2 -- they're still available, but not mentioned on the front page -- you have to look for them).
Changes to the actual performance will vary somewhat due to relatively small variations in the underlying hardware, such as in the fact that m3 instances are specified as being equipped with Intel Xeon E5-2670 v2 (Ivy Bridge) 2.5 GHz processors, but may be eqipped with Xeon E5-2670 (Sandy Bridge) 2.6 GHz processors.
That aspect may or may not make a significant difference -- it's conceivable that the hypervisor may "steal" the extra cycles if you're on a 2.6 GHz system, since the published speed is 2.5 GHz... but this isn't documented. In some older instance classes, where a VM was deployed on hardware dramatically faster than the published specs, the hypervisor would do exactly that, limiting the available processor cycles to what you were actually paying for, which led some people to conclude -- quite incorrectly -- that their cycles were being stolen by "noisy neighbors."
Some instance classes support both PV and HVM virtualization, and this also could have a performance impact within the same instance class. This is not a wildcard, however, since you know what kind of image you're booting when the instance is launched, and this doesn't change if the instance is stopped and started. The actual hardware a give instance runs on typically does change each time you stop and start an instance -- a stopped instance is not actually allocated a slot on a physical host (hence the reason the are not billable). The host hardware is allocated each time the instance starts. There is no way to determine conclusively whether a running instance that has been stopped and restarted has actually changed to a new host, unless the processor type has changed or the instance had a scheduled maintenance event attached to it before the stop/start (in which case, you should always land on new hardware and the scheduled maintenance event disappears)... but the documentation suggests that remaining on the same host across stop/start is statistically unlikely.