Во-первых, подход может зависеть от того, где находятся экземпляры App Engine и Compute Engine: являются ли они частью одного и того же или разных проектов, находятся в одной или разных зонах или регионах, взаимодействуют ли они через внутренний или внешний IP.
Google использует аутентификацию, проверки целостности и шифрование AS128 для защиты данных на одном или нескольких сетевых уровнях, когда эти данные выходят за физические границы, не контролируемые Google. Данные в пути в пределах физической границы, контролируемой Google, не обязательно шифруются, поскольку по умолчанию применяются строгие меры физической безопасности, но всегда применяются аутентификация и целостность.
Более подробную информацию можно найти в документе Шифрование при транзите в Google Cloud .
Далее, было бы хорошо выяснить, какие риски безопасности вы ожидаете в отношении ваших данных в пути. Говоря о рисках, следует оценить потенциальные уязвимости и угрозы, а также их вероятность и осуществимость. Например, для данных, передаваемых между двумя службами, осуществляющими связь через внутренние IP-адреса в одной подсети той же зоны, угрозы и уязвимости весьма ограничены по сравнению с общедоступной сетью c.
В случае, если требования безопасности настолько высоки, что базовой сети нельзя доверять, Google VP C и VPN go выходят за рамки, и вам необходимо зашифровать на уровне 7. То есть почему использование HTTPS кажется логичным решением в этом случае.