I see your issue is you're hoping QoS will derive it's bandwidth percentages based on the interface's bandwidth statement (70 Mbps) rather than the interface's physical bandwidth (100 Mbps). I'm unsure whether that's a correct assumption since QoS, for actual queue bandwidth allocations, relies on actual congestion and that would only happen when the interface congests at 100 Mbps. But assuming it did use the bandwidth statement (which is might for other platforms and/or IOS versions), it shouldn't really make much of a difference since CBWFQ really uses class bandwidth for assigning queue weights. Of course the bandwidth allocation can be extremely important if some traffic really requires an actual amount of bandwidth, but then you would be better served by using absolute bandwidth rather than percent bandwidth or you'll need to adjust such percentages everytime the interface bandwidth varies.
What should set the bandwidth percentages to your values you expect, and might be even more imporant if the path is limited to 70 Mbps further downstream, would be to use a top level shaper configured for 70 Mbps and your policy subordinate to it.
shape average 70000000
service-policy output shape70M
The shaper might not allow for L2 overhead, so you might actually need to shape a little slower, somewhere between 5 to 15% slower (depends on you average packet size). I find 10% slower a good starting point, i.e.
shape average 63000000