Disclaimer: Keep in mind I am neither a lawyer nor a PCI QSA.
After doing more research - I'm convinced that using Drupal Commerce with authorize.net AIM (which is the method used by the authorize module that comes with the commerce kickstart profile) should land you directly into SAQ-D in almost all cases (do not pass go, do not collect $200).
This means you need all the things above plus much more management and policy on your end (or your clients end). It wouldn't be feasible for a small company without a huge budget for a custom project.
Here is the best/most robust explanation i've found of which SAQ to use in one place.
To reduce the scope of the CDE using Authorize.net, one would need to integrate with SIM (offsite form generation) to use SAQ-A, or DPM (direct post) to use SAQ-EP. This assumes you can say yes to the entire list of qualifications i.e. only take payment online, no POS etc. The latter option offers more customization but is more work.
This module looks like it will allow you to do so with Drupal Commerce, but I have done no testing or verification.
Looks like smaller budget clients should be briefed on PCI (always) and plan to use the off-site methods such as Authorize.net SIM or Paypal WPS where the form is generated by the CC processing organization's servers, and never touches your environment. This way your environment should be out of scope with proper configuration.
Here is a (albeit pretty old) thread from authorize.net development forum that has some general and scalable config insights I found very useful.
Here is another (1 year old) white paper that sets forth a framework for PCI compliance on AWS in general. Some of these pieces are not applicable to just a Drupal Commerce server, but still interesting and good.
Any more thoughts still welcome.