Part 1 of this series built a two-node SQL Server 2025 Availability Group across two AWS Availability Zones by hand: reserving secondary IPs on ENIs, fighting WSFC's assumptions about Layer 2 networking, wiring security groups, DNS, listeners, and quorum witnesses one command at a time. That article exists because every one of those steps has a failure mode. This one exists because AWS eventually packaged all of those steps — the ENI arithmetic, the cluster build, the AD wiring, the listener, even the sizing math — into a free console wizard that produces a working Always On deployment in about two hours. Part 2 covers AWS Launch Wizard end to end: what it actually provisions under the hood, the IAM and Active Directory prerequisites that break most first attempts, the full walkthrough, the FSx shared-storage path that unlocks Failover Cluster Instances on Standard Edition, and the honest answer to when you should still do it part-1 style.
If you have not read part 1, the short version: SQL Server Always On on EC2 works, but VPC networking replaces the Layer 2 behaviors WSFC was designed around, so cluster and listener IPs must be reserved on ENIs through the AWS control plane, kept out of the Windows adapter configuration, and connected to clients through multi-subnet-aware drivers. Nothing in this article changes that architecture — Launch Wizard builds exactly the same shape. What changes is who types the commands.
What Launch Wizard actually is
AWS Launch Wizard is a free orchestration service — you pay only for the EC2, EBS, FSx, and Directory Service resources it creates, never for the wizard itself. You answer a guided questionnaire about your workload (performance needs, network layout, Active Directory situation, SQL licensing), and it sizes, provisions, and configures a complete SQL Server Always On deployment: EC2 instances across two Availability Zones, EBS or FSx storage, security groups, a Windows Server Failover Cluster, the Availability Group or Failover Cluster Instance itself, and the listener.
Under the hood it is not magic — it is CloudFormation plus AWS Systems Manager. The wizard generates CloudFormation templates for the infrastructure and drives SSM Automation documents and user-data scripts inside the instances to install and configure SQL Server, join the domain, build the cluster, and create the AG. Two properties fall out of this design that matter in practice:
The generated CloudFormation templates are yours to keep. Deploy once through the console, then re-deploy the identical stack through your pipeline for the next environment.
Deleting a Launch Wizard deployment rolls back the CloudFormation stacks, tearing down what it created. Failed deployments can roll back automatically if you enable it.
Everything it builds is a normal resource in your account. The EC2 instances, the cluster, the AG — you can RDP in, open Failover Cluster Manager, and verify it exactly like part 1's hand-built cluster.
Figure 1 — Launch Wizard is a thin, free orchestration layer: your answers become CloudFormation templates for infrastructure and Systems Manager automation for everything inside the guest OS. The moving dot traces one deployment.
The decision the wizard forces early: AG or FCI
Part 1 built an Availability Group and only mentioned Failover Cluster Instances in passing, because FCIs need shared storage every clustering node can reach — historically painful on EC2, where EBS volumes attach to one instance. Launch Wizard changes this calculus by offering Amazon FSx as the shared-storage layer, which makes the FCI path genuinely practical on AWS for the first time without third-party replication software. So before the walkthrough, the choice the wizard's first pages force on you:
| Aspect | Availability Group (part 1's build) | FCI on FSx shared storage |
|---|---|---|
| What is protected | Chosen user databases only; system databases (logins, jobs, linked servers) must be synced manually | The entire SQL instance, system databases included — nothing to sync by hand |
| Replication | Database-level, log-stream over TCP 5022; costs CPU and memory on every replica | Block-level at the storage layer (FSx replicates synchronously across AZs); near-zero instance overhead |
| Licensing | Multi-database AGs require Enterprise Edition | Standard Edition is sufficient — AWS quotes Standard as typically 50–60% cheaper than Enterprise |
| Read scaling | Readable secondaries can serve report traffic | One node runs the instance at a time; no readable secondary |
| Storage | Independent EBS volumes per node — two full copies of the data | One FSx file system, one copy (plus FSx's own synchronous AZ replica) |
If the licensing budget only covers Standard Edition, or the team keeps forgetting to sync logins and Agent jobs to the secondary, FCI-on-FSx is the pragmatic choice. If you need readable secondaries or database-level failover granularity, it's an AG and Enterprise licensing. Launch Wizard automates both paths equally well.
Prerequisites 1: the two IAM identities people confuse
Most failed first deployments die here, so it's worth being precise. There are two separate identities involved, and they need different things:
Your user — the human clicking through the console — needs the AmazonLaunchWizardFullAccessV2 managed policy (via an Identity Center permission set, a federated role, or an assumable role; AWS explicitly discourages attaching it directly to an IAM user).
The EC2 instances Launch Wizard creates need an instance role named AmazonEC2RoleForLaunchWizard, composed of two managed policies: AmazonSSMManagedInstanceCore (so Systems Manager can drive the in-guest configuration) and AmazonEC2RolePolicyForLaunchWizard. You don't have to build this role — on the wizard's Choose Application page, it looks for the role and offers to create it if missing. That creation is a one-time act needing IAM privileges; after it exists, an admin can delegate all future deployments to users who hold only the Launch Wizard policy.
Launch Wizard stores your domain administrator and SQL service-account passwords in AWS Secrets Manager, and attaches a resource policy allowing exactly the AmazonEC2RoleForLaunchWizard role to call GetSecretValue during the build. Passwords never ride through CloudFormation parameters or user data in the clear — and after deployment, the secrets remain yours to rotate.
Prerequisites 2: Active Directory — where the sharp edges live
Launch Wizard supports three AD postures: create a brand-new AWS Managed Microsoft AD as part of the deployment, use an existing AWS Managed AD, or connect to a self-managed AD (on EC2 or on-premises over VPN/Direct Connect). Two things trip people constantly.
The domain user needs six specific OU permissions
Whether managed or self-managed, the domain account you hand to the wizard must hold these rights on the default Organizational Unit, because the deployment creates real AD objects — the cluster's computer object, the SQL service user, the listener's virtual computer object:
Reset passwordandWrite userAccountControlCreate user accountsandCreate computer objectsRead all propertiesandModify permissions
During the build, Launch Wizard adds the SQL service user to AD if absent, joins the SQL nodes and the Remote Desktop Gateway instance to the domain, grants the cluster the CreateChild right (this is what lets the CNO create the listener VCO — the exact delegation part 1 configured by hand), and gives the service account FullControl file-system rights where needed.
Self-managed AD adds networking homework
Connecting to your own AD means the VPC must reach your domain controllers (VPN, Direct Connect, or VPC peering), the deployment subnets must resolve your AD DNS zone (the same conditional-forwarding requirement from part 1 — pointing at public DNS breaks everything), domain-controller firewalls must admit the VPC's traffic on the standard AD port set, and the domain functional level must be Windows Server 2019 or later. The AD does not need to live in the same VPC as the SQL deployment — cross-VPC works if connectivity and DNS resolution are in place.
The existing-AD deployment option supports AWS Managed AD fully; for self-managed AD, verify DNS resolution from the deployment VPC before starting the wizard. A deployment that fails forty minutes in because the node couldn't resolve corp.example.com still consumed forty minutes of provisioned-resource time, and you get to watch the rollback.
Prerequisites 3: versions, AMIs, and the BYOL fine print
The support matrix is refreshingly square — every current SQL Server pairs with every current Windows Server:
| SQL Server | Windows Server 2019 | Windows Server 2022 | Windows Server 2025 |
|---|---|---|---|
| SQL Server 2019 | yes | yes | yes |
| SQL Server 2022 | yes | yes | yes |
| SQL Server 2025 | yes | yes | yes |
Licensing offers three lanes:
- License-included AMIs — the easy lane. Windows and SQL licensing baked into the instance-hour price; zero pre-checks required.
- Windows license-included + SQL BYOL — your SQL media must be an ISO file, sitting in a folder inside an S3 bucket whose name starts with
LaunchWizard-*, publicly readable within that folder so the wizard can pull and install it. - Fully custom AMIs — allowed, with conditions: root volume on
C:, SQL installed on the root drive, NTFS, English language pack, EC2Launch v2 configured so user-data scripts execute at launch (Launch Wizard bootstraps configuration through user data — an AMI that doesn't run it produces an instance that sits there doing nothing), plus current ENA/NVMe/SSM agents.
Everything Systems Manager later does inside the guest starts from a user-data bootstrap. AWS's own AMIs enable user-data execution on first boot by default; custom images sysprepped the wrong way silently don't, and the deployment hangs at "configuring instance" until timeout. If you re-image, follow the EC2Launch v2 sysprep path.
The walkthrough: six pages between you and a cluster
With prerequisites settled, the wizard itself is genuinely quick. What follows maps each console page to what part 1 did manually.
Application settings
Deployment name, an SNS topic ARN if you want progress and failure notifications pushed to email or Slack, and the rollback preference for failed deployments. Then connectivity: choose an existing key pair, tenancy, and either an existing VPC or let the wizard create one; pick the two Availability Zones and private subnets for the SQL nodes. This page replaces part 1's subnet planning — the wizard enforces one subnet per node, the same unique-subnet-per-node rule AWS's clustering guidance mandates.
Active Directory and SQL settings
Select your AD posture from the section above and supply the domain user. Then SQL: service account details, license model (license-included AMI or BYOL), and — optionally — your own node names, cluster name, and instance name instead of generated ones. Take that option: when you're staring at Failover Cluster Manager during an incident, SQLNODE1 beats a generated identifier.
Infrastructure requirements — the sizing engine
Two modes. "Based on infrastructure": you state performance requirements — vCPUs, memory, network throughput, SQL transaction throughput — and the wizard recommends instance types and storage. "Based on instance type": you pick r6i.4xlarge yourself because you already know. Choosing FSx storage adds throughput-capacity and storage-capacity inputs. Every selection updates a dynamically calculated monthly cost estimate in place — change the instance type, watch the number move. It is an estimate of the infrastructure at list price, not a quote; RIs, Savings Plans, and data transfer aren't in it.
Review and deploy
A summary page, one button, and roughly two hours of CloudFormation events and SSM run-command output. SNS keeps you posted; the deployments list shows per-stage progress. When it finishes, you have the part 1 architecture — built by robots.
The FSx path: FCI with genuinely shared storage
This is the part with no part 1 equivalent, so it gets the full treatment. An FCI needs storage every possible owner node can mount. Amazon FSx for Windows File Server provides it as a managed SMB file system with the two properties an FCI cannot live without:
- SMB Continuous Availability (CA) shares — the SMB 3 transparent-failover feature SQL Server requires for database files on a file share. FSx supports CA natively; a plain file server share without CA will corrupt an FCI's world during storage failover.
- Multi-AZ deployment — FSx itself runs as an active/standby pair across two Availability Zones with synchronous block replication, automatic failure detection, failover, and failback. Your FCI's single data copy is therefore not a single point of failure: lose the AZ hosting the active FSx side, and FSx fails over underneath the cluster.
The same FSx file system can also host the file-share witness for cluster quorum — the third-failure-domain vote part 1 placed manually.
Figure 2 — The FCI never replicates SQL data itself: FSx replicates blocks synchronously across AZs beneath it. The pulsing outline marks the single node running the instance; on failover the standby mounts the identical share and the system databases arrive with it.
The ONTAP variant and its sizing formula
Launch Wizard also offers Amazon FSx for NetApp ONTAP as the shared-storage engine, presenting iSCSI LUNs instead of SMB shares. The wizard carves the file system with a fixed formula worth knowing before you're surprised by the numbers — using the default 1,024 GB file system:
| Layer | Sizing rule | At 1,024 GB |
|---|---|---|
| FSx file system | what you select | 1,024 GB |
| Volume | 85% of file system | 870.4 GB |
| LUN | 80% of volume (65% of total) | 696.3 GB |
| SQL data LUN | 60% of LUN storage | 522.2 GB |
| SQL log LUN | 20% of the data LUN | 139.3 GB |
So a "1 TB" selection yields roughly 522 GB of usable data-file space — the headroom is deliberate (snapshots, metadata, performance), and all of it is adjustable after deployment. Two ONTAP-specific behaviors: backups are disabled by default during the build (enable a schedule in the FSx console afterward), and deleting an ONTAP-backed deployment triggers a final volume backup that lingers — and bills — until you delete it manually.
For FSx for Windows File Server, the wizard computes capacity from your peak IOPS requirement as well as raw size — FSx throughput scales with provisioned capacity, so demanding high IOPS can produce a file system noticeably larger than the storage you asked for. That isn't a bug; it's the throughput floor being purchased through capacity.
What lands in your account: the configuration it applies
The instances come out configured the way part 1 configured them by hand — the notable defaults:
| Setting | Value applied |
|---|---|
| SQL patching | Latest service pack applied; service set to start automatically |
| Network ports | TCP 1433 (client) and UDP 1434 (browser) opened; ICMP and RDP allowed through the host firewall |
| Clock behavior | RealTimeIsUniversal registry key set — without it, Windows time drifts on non-UTC time zones (the same clock hygiene part 1 required) |
| Server role | BUILTIN\Administrators added to the SysAdmin server role |
| PowerShell | Execution policy Unrestricted during setup — tighten it after deployment completes |
| Backups (FSx Windows) | Daily automatic backup 01:00, 7-day retention, weekly maintenance window Saturday 22:00 — all adjustable in the FSx console |
Two defaults deserve immediate attention in production: pull BUILTIN\Administrators out of SysAdmin unless your ops model genuinely wants every local admin owning SQL, and restore a stricter PowerShell execution policy once the build is done. The wizard optimizes for a working deployment, not your final security posture.
Verifying the deployment — same checklist as part 1
Trust, then verify, exactly as if you'd built it yourself:
- RDP to a node (through the RD Gateway instance the wizard deployed) and open Failover Cluster Manager — confirm both nodes are up, the witness has a vote, and the cluster core resources are online.
- For FSx deployments, browse
\\<fsxdnsname>\<sqlshare>from a domain-joined instance and confirm the SQL data files live there. - Run a manual failover — move the AG or FCI role to the second node — and confirm the instance (and, for FCIs, the system databases with all their logins and jobs) comes up intact on the other side.
- Test client connectivity through the listener with
MultiSubnetFailover=True, part 1's non-negotiable client-driver requirement, which remains non-negotiable here. - Confirm the instances report as managed in Systems Manager — that's your ongoing patching lane via Patch Manager.
Part 1 by hand vs part 2 by wizard — the honest comparison
| Dimension | Manual build (part 1) | Launch Wizard (part 2) |
|---|---|---|
| Time to running AG | A focused day, if nothing bites | ~2 hours, mostly unattended |
| ENI/IP reservation errors | Yours to make and debug | Automated away |
| Topology flexibility | Anything WSFC supports — odd subnet layouts, existing clusters, exotic quorum | The wizard's supported patterns only |
| Custom hardening at build time | Baked in as you go | Applied after; defaults documented above |
| Repeatability | Your runbook's discipline | Generated CloudFormation, replayable |
| Understanding what you own | Deep, earned the hard way | Only what you bring — which is why part 1 exists |
Use Launch Wizard for the build; use part 1's knowledge for the 3 a.m. incident. The wizard removes the toil, not the responsibility — when a listener IP refuses to come online eight months from now, "the wizard configured it" is not a diagnosis. The two articles are one skill set.
FAQ
Does Launch Wizard cost anything? No — the service is free. You pay for the EC2, EBS, FSx, Directory Service, and other resources it provisions, and the in-wizard cost estimate tracks exactly those.
Can it deploy into my existing VPC and existing AD? Yes, both — that's the mainstream enterprise path. Existing-AD support is full for AWS Managed AD and works for self-managed AD when the connectivity, DNS-resolution, firewall, and 2019+ functional-level prerequisites hold.
Can I use my own SQL licenses? Yes — SQL BYOL on Windows license-included AMIs (ISO in a LaunchWizard-* S3 bucket) or a fully custom AMI meeting the EC2Launch v2/user-data requirements.
What happens if a deployment fails midway? With rollback enabled in application settings, the CloudFormation stacks tear back down automatically. Deleting a successful deployment later rolls back the stacks the same way — minus the ONTAP farewell backup noted above.
Does the wizard support SQL Server on Linux? Yes — Ubuntu 18.04 LTS with SQL Server 2019, including custom-AMI support with its own requirement list. The Windows path covered here is the far more common one.
Takeaways
- Launch Wizard is free orchestration over CloudFormation + Systems Manager that turns part 1's day of careful manual work into a ~2-hour guided deployment, producing the identical multi-subnet Always On architecture.
- The prerequisites are where deployments fail:
AmazonLaunchWizardFullAccessV2for the human,AmazonEC2RoleForLaunchWizardfor the instances, six specific OU permissions for the domain user, and verified DNS resolution for self-managed AD. - FSx makes FCIs practical on AWS — SMB Continuously Available shares plus Multi-AZ synchronous replication give a Standard Edition cluster whole-instance protection at 50–60% lower licensing cost than an Enterprise AG.
- Know the sizing formulas going in: ONTAP's 1 TB selection nets ~522 GB of data-LUN space, and FSx-for-Windows capacity is driven by peak IOPS, not just gigabytes.
- Harden after deployment:
BUILTIN\Administratorsin SysAdmin and anUnrestrictedPowerShell policy are build-time conveniences, not production posture. - The wizard replaces the typing, not the understanding — keep part 1 within reach for the day something fails over and doesn't come back.
References & extra reads
- Part 1 — SQL Server 2025 Always On across AWS subnets — the manual build this article automates.
- AWS Launch Wizard for SQL Server — Getting Started — IAM, AD, AMI, and FSx prerequisites in full.
- AWS News Blog — Accelerate SQL Server Always On Deployments with AWS Launch Wizard — the launch announcement and wizard tour.
- AWS Storage Blog — Simplify SQL Server Always On Deployments with Launch Wizard and Amazon FSx — the FCI-on-FSx walkthrough and licensing math.
- AWS — SQL Server clustering on EC2 guidance — the ENI and subnet rules both parts of this series follow.