Ok. Let me offer you some additional pointers here.
1. Whenever I see a dedup command I raise my eyebrows questioningly - are you sure you know how dedup works and is it really what you want?
2. Your subsearch is highly suboptimal considering you're just looking for a single - relatively unique value of the guid. As it is now, you're plowing through all data for given time range, extracting some fields (which you will not use later) with regex and finally only catching a small subset of those initial events.
An example from my home lab environment. If I search
index=mail
| rex "R=(?<r>\S+)"
| where r="1u0tIb-000000005e9-07kx"
over all-time Splunk has to throw the regex at almost 11 millions of events and it takes 197 seconds.
If I narrow the search at the very beginning and do
index=mail 1u0tIb-000000005e9-07kx
| rex "R=(?<r>\S+)"
| where r="1u0tIb-000000005e9-07kx"
The search takes just half a second and scans only 8 events.
Actually, if you had your extractions configured for your events properly, you could just do the search like
index="aws_np" aws_source="MDM" type="Contact"
and it would work. You apparently don't have your data onboarded properly so you have to do it like in your search but this is ineffective.
The same applies to the initial search where you do a lot of heavy lifting before hitting the where command. By moving the raw "200" and "Create" strings to the initial search you may save yourself a lot of time.
3. To add insult to injury - your appended search is prone to subsearch limits so it might get silently finalized and you will get wrong/incomplete results without even knowing it.
4. You are doing several separate runs of the spath command which is relatively heavy. I'm not sure here but I'd hazard a guess that one "big" spath and filtering fields immediately afterwards in order to not drag them along and limit memory usage might be better performancewise.
5. You're statsing only three fields - request_time, output_time and messageGUID. Why extract the text field?
