I think on your first diag, the Service becomes more important. In that case I would show Service B is served by Node A or perhaps if the Technology Service purpose is to be a “High Availability” layer then it would just be the one service serving both apps.
If there is a real dependency between the two Nodes, I think the aggregation is a less intuitive way to show this dependency (aggregation being a “may contain” rel type).
As drawn, the fact of the aggregation does imho create a derived relationship from App B to Node A (technically). I wouldn’t myself draw it this way because that it probably not what an infrastructure person would actually “mean” even if it correct archimate. Where the node is specialized to system s/w it is probably ok, but when it just represents a processing platform conceptually, it breaks down somewhat.
Id also say that Service A and Service B are likely the same service in this case (eg resilient database service?) - so if this were eg Oracle RAC Db the service is “one thing” from an app perspective looking down to the technology. Maybe the language of archimate does not permit a service to be served by more than one node? That said formally I guess one should be using tech interface but the diagrams simply get too messy. I note Gerbers diagram has service only being realised by one node, but in this case he has used node to represent a “physical” VM and hence that is true. If the node itself represented a part of a two node database cluster, then this would offer up a single “service” or interface that allows the application tier not to care that things are actually physically distributed across multiple nodes/machines and thus that service is probably realised by two interfaces.
But back to the core question, the derived relationship between nodes using aggregation would appear to be technically “true” but is likely not what the author “meant”.