I believe Eric Evans wrote, "Models are neither right nor wrong; they are simply more or less useful". The question is, which model helps you solve the problem in a clean way. By just referring to the names of a number of classes, it is impossible for others to determine which model would help you solve your problem.
But as to the why should you choose one model over the other:
If one entity (A) does not make sense to load outside the context of a different entity (B), then entity A should probably be aggregated inside entity B. Also, nobody should reference A in this case.
Just because there is a relationship between your entities doesn't necessarily mean that they should be aggregated.
As an example on an aggregate, I once worked at writing an online job site. One of the features was that a person to create a CV, and companies could search for CVs. A CV would contain a list of competencies (A competency in this context mean something like, "I am higly skilled in .NET. I have used it for 12 years, last in 2012). It does not make sense to load a competency in itself. In only makes sense in the context of a CV. Though you could search for CVs matching certain competency requirements, the result would not be a list of competencies, but a list of CVs meeting the required competencies. So in this example, the CV was an aggregate root.
But are terms like 'Application Group', 'Application', and 'Configuration' really part of your domain, or is it part of your infrastructure? I'm not saying that they couldn't. Depend of course entirely on the nature of the application you are working on. But it does sound a lot like system infrastructure in my ears.