It may be more customization than you're willing to do, but I think you can do what you're interested in via network tags on both the injected routes and the regional instances (assuming the end points are GCE instances).
So using your CHKP_TAG modification, it appears that you can modify the create_route_request function in gcp_had.py to include that variable as a network tag. The code already has a fixed empty array. You may not even need to pass the CHKP_TAG in the function call. Just fix the tag with an array that includes that variable.
def create_route_request(name, network, range, priority, next_hop_instance,
project):
logger.info('Adding route "' + name + '":' +
'\n\t network: ' + network +
'\n\t range: ' + range +
'\n\t priority: ' + str(priority) +
'\n\t next hop instance: ' + next_hop_instance)
path = '/projects/{}/global/routes'.format(project)
route = {
'destRange': range,
'name': name,
'network': '/projects/{}/global/networks/{}'.format(project, network),
'priority': priority,
'tags': [],
'nextHopInstance': next_hop_instance
}
return gcp('POST', path, body=json.dumps(route))['selfLink']
which should inject the route into the VPC using the tag.
This would be similar to the guidance in sk114577 "Check Point CloudGuard IaaS reference architecture for Google Cloud Platform" at the end of section (4) Deployment where it indicates the deployment will automatically create network tags for the gateway instances and then it references those in section (8) Inspecting traffic where it has you create a default outbound route associated with the same tag.
Then if your source systems (assumption: GCE instances) also have the same network tag, it should preferentially use the tagged route which matches the network tag. Assuming the network tags are unique per region (and they should be based on your CHKP_TAG variable), then it should route traffic "regionally".
It's slightly unclear from Google documentation how the network tag and routing interact. It appears that the network tag impacts the selection of "applicable routes" (https://cloud.google.com/vpc/docs/routes#applicable_routes), so in your example, the europe-west2 instances would match only the europe-west2 CHKP_TAG route and the rest of your RFC1918 routes would not be applicable to europe-west2 instances since they would have a network tag which does not match the network tag for europe-west2. Then it would merely be up to the routing order (https://cloud.google.com/vpc/docs/routes#routeselection) to be certain that you're routing as you expect.
It seems feasible, but obviously some testing would be required.
