Great explanation! I'd add one important consideration from a cross-cloud architecture and data governance perspective.

Before implementing OpenSharing with AWS Glue, I would clarify exactly what the source team means by "no replication or ingestion into AWS."

There is an important difference between avoiding a permanent replica in S3 and prohibiting any temporary data persistence or processing within AWS.

Even when using OpenSharing, the data still crosses cloud boundaries. Depending on the Glue job configuration, intermediate Spark data could also be written to temporary storage.

I'd suggest validating three things during a small proof of concept:

Governance: Confirm whether temporary processing and potential data spilling in AWS are permitted.

Performance: Measure cross-cloud transfer costs, query latency and the volume of data transferred.

Operations: Validate credentials, network connectivity and how shared-table schema changes affect downstream consumers.

If the requirement is strictly read-only access without a permanent replica, OpenSharing is worth evaluating.

However, if no data is permitted to leave Azure, I would consider keeping the processing in Azure and exposing only approved results.

One question: Is the Glue Catalog requirement driven by Athena integration, or could the AWS consumers work directly with shared datasets through Glue Spark?