Infrastructure
📄️ Navigating Infrastructure
Before we can process data through Syntasa, we need to update Syntasa with some details about the cloud environment it is installed in. We accomplish this in the Infrastructure screen, which is available from the settings menu gear icon (mceclip3.png).
📄️ Infrastructure - Google Cloud Platform (GCP)
Now that the Syntasa software is installed, there's a bit of setup needed before you can take advantage of the platform. The high-level steps of system configuration are described in the article System Configuration Guide.
📄️ Infrastructure - Amazon Web Services (AWS)
Now that the Syntasa software is installed, there's a bit of setup needed before you can take advantage of the platform. The high-level steps of system configuration are described in the article System Configuration Guide.
📄️ Introduction to Cross-GCP Project Support
Syntasa’s Cross-GCP Project Support introduces a decoupled architecture that separates the platform’s Control Plane from its Data Plane. This allows enterprise customers to install and manage the Syntasa platform in one GCP project while executing jobs, storing data, and managing connections in a completely separate GCP project.
📄️ Architecture Overview: Cross-Project Deployment in GCP
As organizations scale their data operations, the traditional “single-project” cloud model often becomes a bottleneck for security, governance, and financial management. Syntasa addresses these challenges through a Cross-Project Deployment Architecture, which physically and logically separates the platform’s management functions from its data processing activities.
📄️ When and Why to Use Cross-GCP Project Support
In the early stages of data platform adoption, a single-project architecture—where the application and the data reside together—is often sufficient. However, as organizations scale, they encounter increasingly complex requirements related to security, financial accountability, and regulatory compliance.
📄️ Understanding Control Plane and Data Plane in GCP Cross Project
As enterprise data ecosystems grow in complexity, the need for strict security boundaries and operational isolation becomes increasingly important. Syntasa addresses these requirements through the architectural separation of the Control Plane and the Data Plane.
📄️ Service Account: AWS IAM Policy Reference
For platform administrators configuring Service Accounts on the Syntasa platform. {#h\_01KS284Y953D4P6K32KWHBBNRF}
📄️ Service Accounts for Runtimes and Notebooks
Syntasa supports associating Cloud Service Accounts (AWS IAM Roles or IAM Users) directly with Notebook Workspaces and Runtime Templates. When a notebook is launched or a job is submitted, the platform automatically assumes the correct cloud identity - no manual credential management inside notebook code is required.
📄️ Service Account Isolation from Syntasa System Folders
Scope
📄️ How to Attach Service Account in Runtime and Notebook workspace
Syntasa’s Service Account (SA) framework provides two primary attachment points for cloud identities: the Notebook Workspace and the Runtime Template. Understanding where to attach a Service Account is key to balancing ease of use for your team with strict security requirements.
📄️ How to create Service Accounts - Per-Group Cloud Identities
Syntasa Service Accounts (SA) are first-class entities that allow teams and groups to bring their own cloud credentials into the platform. Instead of relying on a single, broad “System Service Account,” groups can now use specific cloud identities (AWS IAM Roles, GCP Service Accounts, etc.) to govern data access for their Notebooks and Spark jobs.