As an ArcGIS Online administrator and architect of our enterprise GIS more broadly, I would like to leverage ArcGIS Enterprise to serve as an alternate and/or complementary integrated backing store to the Feature Data Store in SaaS AGOL, primarily to offload content from the Feature Data Store, but also to address use cases of content archival and restoration.
Our AGOL organization is the "front door" for thousands of users to find content, create maps, apps, StoryMaps, etc., often referencing hosted feature layers residing in AGOL. But hosted feature layers consume credits - an increasingly scarce resource. If organizations with the capability to run ArcGIS Enterprise were able to more tightly couple a dedicated ArcGIS Enterprise deployment to their ArcGIS Online org, large hosted feature layers could be "offloaded" to the AGE deployment, with the original content item persisting with the same AGOL ItemID, but accessing the source service by reference. This could be thought of as analogous to AWS "Intelligent tiering" for S3, such that AGOL is front-line storage, but for infrequently used or very large content, the SaaS storage footprint could be shifted to ArcGIS Enterprise, and its admins could add (and pay for) storage locally as needed, rather than using storage credits.
In a similar vein, admins might also use a tightly coupled AGE deployment to archive old user content. This is important for user deprovisioning workflows. In this use case, content would be removed from the AGOL site but persist on AGE with the ability to "rehydrate" it in ArcGIS Online with the original ItemIDs. We have to reassign or delete content before deprovisioning users - this would be a third option... offload everything to AGE before user deletion in case it's needed later.
What all these use cases have in common is the idea of the ability to more tightly couple AGOL and AGE, in a manner more analogous to a Federated Server in AGE than to a Collaboration. Perhaps this becomes a new type of collaboration, accompanied by admin tooling and Python API code to initiate ad hoc offloads (option 1: offload service, but retain all Items in AGOL; option 2: offload and remove Item from AGOL).
Our users' feature layers should be accessible within the Portal component of the AGOL SaaS platform, since that's the front door, but it does not follow from that that large hosted services need to physically reside there in its metered/credit consuming Server component. In cases where org admins have the infrastructure and expertise to run AGOL and AGE in parallel, let AGE do the heavy lifting of large feature layer hosting and the long term task of service archival, allowing us to be good stewards of SaaS resources by augmenting them with our own resources.
