On August 20, 2026, AWS published a series that connects Snowflake, Amazon SageMaker Canvas, and Amazon Quick in a no-code ML workflow. Part 1 does not build the model; it prepares the Snowflake environment that the model-building steps depend on.

“No code” can sound as if there is little work left on the data-platform side. A visual model-building interface, however, does not decide which data users may access, how they authenticate, or which compute resources should run.

So what does Part 1 establish, and what should change before its sample is used in an existing environment? The answer becomes clearer when the workflow is treated as a boundary between Snowflake and Canvas rather than as a single wizard.

No-code model building still depends on a prepared data platform

Amazon SageMaker Canvas provides a visual path through data preparation, model building and evaluation, prediction, and deployment. Snowflake was already supported as a data source when Canvas became generally available on November 30, 2021.

In September 2023, AWS added direct Snowflake imports without a storage intermediary and OAuth 2.0 connectivity. Today, Canvas can select Snowflake tables, shape an import with SQL or joins, and then continue into visual data preparation and model building.

What disappears is much of the hand-written work of choosing algorithms and assembling training code. The Snowflake warehouse, database, table, connection identifier, and authentication material still have to exist first. That is the boundary Part 1 prepares.

The Part 1 SQL establishes four prerequisites for Canvas

The tutorial opens a Snowflake SQL worksheet and uses the ACCOUNTADMIN role to create these resources:

• An X-Small virtual warehouse named HOL_WH
• A database named FRAUD
• A table named FRAUD.PUBLIC.FRAUD_TABLE
• 139,538 synthetic transaction rows representing 2020

The table contains transaction time, amount, merchant category, card number, location fields, and an is_fraud label. The label is generated from amount, time, and category rules combined with random values, so the dataset is a teaching asset for the connection and training workflow. It is not evidence of production detection accuracy or of the validity of those fraud rules.

After loading the rows, the tutorial checks the total count, previews ten records, and counts records by label. The useful question is not merely whether the SQL succeeded, but whether the table Canvas will import has the expected schema and distribution.

SELECT COUNT(*) AS total_records FROM FRAUD_TABLE;
SELECT TOP 10 * FROM FRAUD_TABLE;
SELECT is_fraud, COUNT(*) AS count
FROM FRAUD_TABLE
GROUP BY is_fraud;

Because the generation query uses randomness, the class counts can vary between runs. Record the results from the environment you actually use rather than assuming a fixed distribution when interpreting the model in Part 2.

The Snowflake account identifier becomes the Canvas connection point

At the end of Part 1, the organization name and account name are joined with a hyphen. Snowflake documents organization_name-account_name as the preferred account identifier for clients and third-party applications.

Canvas uses this value as the Account ID for its Snowflake connection. The current Canvas connection documentation lists three authentication choices: username and password, an AWS Secrets Manager secret ARN, and OAuth. Part 2 of the series uses a username and password, but that is not the platform's only option.

Following the tutorial literally can be reasonable in an isolated evaluation account. In an organizational environment, the choice should fit existing SSO, secret storage, and credential-rotation policies. OAuth also requires initial Canvas-side configuration, so running the Part 1 SQL alone does not complete that path.

Existing Snowflake accounts need a replacement, privilege, and suspension review

The sample includes CREATE OR REPLACE DATABASE FRAUD. If a database with that name already exists, it will be replaced. Snowflake specifies that OR REPLACE is equivalent to dropping the existing database and creating a new one with the same name. Use a dedicated sandbox name or establish that there is no collision before running the script in a shared account.

The tutorial also uses ACCOUNTADMIN for brevity. Snowflake recommends avoiding ACCOUNTADMIN for ordinary database-object creation and using custom roles aligned with business functions. A Canvas connection role needs access to use the intended warehouse, database, and schema and to read the intended table; it does not need to make every analyst an account administrator.

An X-Small HOL_WH still consumes Snowflake credits while it is running. Under the current CREATE WAREHOUSE defaults, a new warehouse auto-suspends after ten minutes of inactivity and auto-resumes for a query. Verify that behavior against the organization's cost policy and decide whether the sample warehouse and data should remain after the evaluation.

A SageMaker domain and Quick Sight complete the path beyond Snowflake

Finishing the Snowflake setup does not produce a model. Canvas also needs a SageMaker domain and user profile. The current Canvas onboarding guide identifies permission to run Studio applications and Canvas Core Access as the basic requirements, with separate permissions for advanced data preparation and direct model deployment.

Part 2 connects Canvas to Snowflake, applies visual Data Wrangler transformations, and builds a fraud-detection model. Part 3 writes batch predictions to Amazon S3 and creates dashboards in Quick Sight.

In the current product structure, Quick Sight is the business-intelligence capability within Amazon Quick. The Amazon Quick name in the series title and the Quick Sight dashboard step therefore describe different layers of the same destination rather than competing visualization paths.

The responsibilities remain separated: source data in Snowflake, Canvas artifacts and batch results in S3, and visualization in Quick Sight. Even without training code, teams must still decide where data is copied, which IAM roles can access it, and where training or endpoint costs arise.

Completing Part 1 prepares a connection contract, not a finished model

The opening question now has a concrete answer: no-code ML does not remove data-platform preparation. Part 1 delivers the training table, compute warehouse, and account identifier that form a connection contract between Snowflake and Canvas.

For a personal sandbox, it can be enough to avoid name collisions, verify auto-suspension, and run the sample. For shared or production environments, define a scoped custom role, choose an authentication method that fits the organization, and design Canvas storage and IAM permissions first.

That distinction keeps the workflow from becoming either “no code means no setup” or “the platform is too complex to try.” Build a small, safe boundary between Snowflake and Canvas, complete one pass with synthetic data, and only then move to real-data governance and model evaluation.

Source

• Title: Build a no-code ML workflow with Snowflake, Amazon SageMaker Canvas and Amazon Quick – Part 1: Setting up your Snowflake environment
• URL: https://aws.amazon.com/blogs/machine-learning/build-a-no-code-ml-workflow-with-snowflake-amazon-sagemaker-canvas-and-amazon-quick-part-1-setting-up-your-snowflake-environment/