Are spokes logically limited to 100 Mbps or physically limited? (An example of the former, interface running at gig, but WAN provider only providing 100 Mbps.) If the latter, you don't need to also shape them for 100 Mbps.
BTW, for your remote QoS, most routers would allow you to match and mark in egress classes too. I.e. you have the option of not needing your input policy.
To your question of should you have a child policy for your HQ tunnels - if you want to prioritize transmission and/or drops, when and if there's HQ tunnel egress congestion - the answer is yes. (NB: this is contrary to Georg's recommendation, but otherwise a shaper, alone, at least the later implementations, might only FIFO all your traffic.)
Also BTW, on some routers I'm unsure that Cisco's shapers always account for L2 overhead. If a shaper doesn't appear to be doing so, set it about 15% slower than the nominal bandwidth (to allow for typical L2 overhead).
Another BTW, when matching DSCP tags like:
class-map match-any D3_PREC3
match ip dscp af31
match ip dscp af32
match ip dscp af33
match ip dscp cs6
match ip dscp cs3
match ip precedence 6
Matching IPPrec 6 will also match DSCP CS6. Also, if you match IPPrec 3, it will match CS3, AF31, AF32 and AF33. (Remember IPPrec is the first 3 bits of the DSCP.)
Lastly, when matching NBAR's SSH, that includes SCP.
I also suggest, when setting up a QoS policy, start with everything in class-default using FQ. Only place traffic in other classes that really, really need it. Also don't forget, besides guaranteeing better service to some classes, much can often be accomplished by decreasing priority to some traffic. Also know how you manage drops can be almost as crucial as how you manage bandwidth. (The last is because of your using something like your:
class class-default
queue-limit 1600 packets
as too large queue limits can be counter productive.)
