You're going to want to stick with creating/ordering Network Policies to do what you're trying to do. Just use the one default Connection Request Policy that is wide open, and then secure via the NPs.
You can "divide the two" as you say, by limiting each Network Policy you've created with sufficient conditions, such that in combination, multiple conditions together achieve your objectives. It looks like you've specified only one condition on each policy - network group membership. As you've discovered, this won't work. When your RADIUS-enabled device asks your RADIUS server to authenticate your user, the RADIUS server forwards the users' credentials to AD, which successfully matches the credentials (cause they're vague at this point), and returns a positive to the RADIUS server, which in turn tells the device to allow the authentication. I'm forgetting all the proper RADIUS lingo here - but basically that's what's happening.
So, stack another condition (or more) onto your policy to get what you want. Sounds like you want the switch policy to work with users in the Domain\NetworkGroup, and only on your switches (these requests should never come from your ASA's IP, or some printer or user workstation or whatever). Under conditions, look under the RADIUS client section - ClientFriendlyName, or ClientIPv4Address, for example. If the conditions include that the request is coming only from one of your predefined switch IPs or names, it won't "authenticate" requests coming from your ASA IP.
Do the same for your vpn policy too. You should be good from there. You may want to start with clean Network Policies though. I don't think you're going to be able to use the settings to update non-compliant clients without some more work (and whole other policy type too).
Also, you can look at your RADIUS logs if you want more info on what its actually doing. I believe they're under system32\logfiles. You may have to enable it on your NPS server, if its not already. You can google for tools to help you read the log files, as they're not really user friendly. In a pinch, MS has an article that lists all the fields, in order. Look for the tools though (IASlogviewer? or something like that?).
Best Answer
Looking around a bit I think you might want to approach this a bit differently. Let Amazon services do the OTP heavy lifting and only reach back to your AD for that small part of things.
Method seems to be first set up Amazon Directory Services to use your AD: http://docs.aws.amazon.com/directoryservice/latest/ad-connector/what_is.html
Enable/configure multi-factor authentication on that: http://docs.aws.amazon.com/directoryservice/latest/ad-connector/connect_mfa.html
Then come back and point your Amazon Workspaces at the Amazon Directory Services instance you just set up: http://docs.aws.amazon.com/workspaces/latest/adminguide/registration.html
I've done none of this, but on paper this looks like it might be easier than what you're contemplating, instead.