AWS vDiscovery - process won't merge into default view due to overlapped VPCs

[#1]

Hey all, we're looking for a bit of guidance.

Currently we're unable to run an AWS vDiscovery job successfully when attempting to merge into the default view. The error message is the dreaded "Overlapped VPCs". We have to allow the creation of a new view, in which case the job does succeed, but we end up with 3 new ones, so named after the tenant (AWS account ID in this case), but also due to some duped CIDRs which we've added to the EXCLUDE list as summarised ranges where applicable (although they live in separate VPCS, whch is apparently ok for the vDiscovery process... although bad practice for VPC peering!), it seems we end up with some suffixed views (_1, _2):

"1234567890"

"1234567890_1"

"1234567890_2"

Interestingly, not all of the CIDR ranges in the additional suffixed views are dupes, and the actual first view (non-suffixed) contains hundreds of CIDRs, mostly carved out of a RAM shared VPC.

Now, the main question I have is about this first view. Those CIDR ranges we already have defined (via import) as "Non-cloud" containers in the default view. I was lead to belive the vDiscovery job would "merge" the cloud containers (or rather, perhaps update the existing containers to indicate they're now cloud, and set to vDiscovery discovery engine or so.

However, due to the fact that we have almost all CIDR ranges appearing in the new view, I believe we are not supposed to already have defined these ranges first in the default view - it's my belief that this is the source of the initial "Overlapped VPCs" message.. or am I wrong?

Many thanks for any guidance

[#2]

If you already have containers in the Grid, that are the exact same CIDR range or overlapping the AWS VPCs you are trying to discover, it will continue to conflict and put thos discovered VPCs in different Network Views. You will need to delete those containers in order to sync discovered VPCs to that network view.