A separate instance of AWS (or Google Cloud or Azure) would keep the boarding groups confined to one database, and you would only need the single button on MDE to point to that instance. That is the setup they currently have. You can't see the groups anywhere else in the app. Its trivial to route a button on an app to another site/DB. I would have done it separately because you can set the resources to peak in the periods around park open and then dial it back for the rest of the day, and not have to worry about potentially compromising the rest of the system due to the peak load.
There are only 4 points of data passed between MDE proper and the boarding groups:
1) Do you have a valid scanned in ticket?
2) Are you in the park?
3) Who is in your party?
4) Are you already in a boarding group?
3 of the 4 only have to be checked a single time - when you are put in a group - and only have to be passed one way. For a SQL query, thats actually a super simple check and very little data. I'd actually be shocked if the groups aren't a separate DB, because once they stop the groups here, they can reuse them for another ride in the future if its standalone.
Since the groups go in order, the BG DB itself would be simple - each group is 100 or whatever, and it contains the Magic Band RFID# and the number you scanned in numerically. Much, much less complicated than the FastPass database is since people can go in and out of those and change times all over the place.