I've been looking into this all morning but it seems to be beyond my knowledge about AWS VPCs.

We have and old AWS account with a series of VPCs in it. These were created years ago. The VPC I'm concerned about can easily be 6 years old if not older. The existing VPCs are:

eu-west-1 (Ireland)

I1: 172.31.0.0/16
I2: 172.102.0.0/16
I3: 172.201.0.0/16
I4: 192.168.96.0/20

us-west-2 (Oregon)

O1: 192.168.0.144/20

The VPC I'm working with is I1: 172.31.0.0/16.

I1 and O1 Are peered.

Right, I now have a new account where I've created a new VPC in Oregon. Let's call it

NO1: 10.1.0.0/20

I have peered O1 and NO1. Peering works fine and the route tables do too.

The issue comes when I peered I1 and NO1.

Creating the peered connection was fine.
Adding rules to the NO1 route table worked fine.

My concern is the following: when I go to modify the route table for I1 I see the following rules.

172.31.0.0/16 local active (that's the IP range set for this VPC, expected)
10.0.0.0/8 local active (This is my issue)
0.0.0.0/0 inet active
Some other existing rules...

I don't understand the 10.0.0.0/8 rule. The full IP range is being routed internally and:

That's not within the IP range of the VPC
just in case I was missing something I checked all the VPCs and subnets I could find. There's nothing with that IP range.

When I went to modify the route table the 172.31.0.0/16 and the 10.0.0.0/8 rules cannot be deleted so I can only assume they were created by default.

My question is, how can this rule be active when the IP range is "non-existent"? Why I cannot delete this? I've never seen this range being added by default to a route table, is this something maybe AWS used to do ages ago?

I've added a rule 10.1.0.0/20 routing traffic to my peered VPC. I'm hoping since it's more specific it will work fine. Am I right to think that?