In one pass, how does ownership differ for OS, SQL Server build, and storage layout between SQL Server on EC2 and RDS for SQL Server?
EC2: You install and patch Windows, choose edition/build/CUs, and design EBS volumes (data, log, tempdb, backup), growth, and disk types. RDS: AWS manages the host image and supplies a managed SQL build (major upgrades are coordinated ops); you size instance + storage with less direct disk control. Panel line: “On EC2 I own the stack; on RDS I trade disk micromanagement for AWS operating the platform.”
How do licensing models typically differ on EC2 vs RDS for SQL Server?
EC2: Common patterns are License Included (LI) AMIs or BYOL (Software Assurance / mobility where applicable) — you align cores, edition (Standard/Enterprise), and compliance with your EA or AWS terms. RDS: License Included is the usual path; instance class and edition map to Microsoft licensing on the backend; BYOL exists where AWS offers it — verify region and engine version in current docs.
When would you lean RDS vs lean EC2 for a new SQL Server workload on AWS?
RDS when the app fits managed limits, you want Multi-AZ without running WSFC, the team wants lower ops toil, and you don’t need datacenter-parity host access or exotic features. EC2 when you must design and operate WSFC + Always On AG (or FCI), need DTC-heavy or Windows/SQL co-integration, custom backup/DR (e.g. S3, third-party tools), or BYOL / full-stack audit requirements.
On AWS, what is Multi-AZ for RDS SQL Server vs a read replica vs your own cluster on EC2?
Multi-AZ is an AWS-managed synchronous standby (on supported versions, Always On–based under the hood) — you do not build WSFC. Read replicas are separate async copies for read scale / DR, not the Multi-AZ standby. EC2: you implement WSFC + AG (or FCI) — see clustering notes. Contrast: Multi-AZ = managed HA pair; replica = read/DR topology; EC2 = full topology control.
Does Always On Availability Groups “not exist” on RDS? What do you actually get vs EC2?
On supported versions/editions, RDS Multi-AZ can use Always On AG under the hood — AWS runs primary + sync standby, failover, and often an AG listener–style endpoint. You don’t get your cluster: no arbitrary nodes, quorum design, extra sync/async replicas, distributed AG, or full read-only routing like a self-built farm. Customer-operated WSFC + AG ⇒ EC2. Line: “RDS uses AG for managed HA; EC2 is where I own the AG design.”
For break-glass and host-level work, how do EC2 and RDS compare?
EC2: RDP or SSM to the box — full admin for OS and files. RDS: No RDP; sysadmin-style SQL surface is limited; no arbitrary OS or file-path operations. Custom agents and tools on the host are EC2-friendly; RDS only allows what the service supports.
Operationally, what does your team do day to day on EC2 vs RDS?
EC2: Full SRE/DRE — patching cadence, backup design, DR drills, monitoring agents, capacity, IaC for instances, SSM/Ansible/PowerShell for SQL. RDS: AWS handles provisioning, patching (supported channels), automated backups/snapshots, Multi-AZ failover, much scaling; you focus parameter groups, option groups, subnet groups, security groups, maintenance windows, and tuning inside RDS rules.
Name several SQL Server features that are not supported on RDS (or not in the EC2 sense) that interviews often touch — and why the list is version-specific.
Examples from your notes: native log shipping as an RDS feature (use snapshots/replicas/backups instead), SQL Server Replication publisher/subscriber model as on EC2, FILESTREAM / file tables, xp_cmdshell, Service Broker endpoints, CREATE ENDPOINT, PolyBase, server-level triggers, Maintenance Plans (GUI) — automate with Agent/scripts within RDS rules. CLR: not supported on RDS for SQL Server 2017+ per AWS (confirm current doc). Always cite AWS feature non-support — the canonical list changes by engine version.
What is limited on RDS vs broader on EC2 for linked servers and CLR?
Linked servers / distributed queries: Supported with constraints — check AWS guidance for the scenario. CLR: Historically SAFE + assembly patterns on older RDS; CLR not supported on RDS for SQL Server 2017+ per AWS documentation (verify the page for your version). On EC2 you can use the full feature set your edition and security posture allow.
Does SQL Server Agent run on RDS? How should you characterize it vs EC2?
Yes — Agent runs on both. On EC2 you can use the full toolkit (job step types, operators, native alerts) subject to security policy. On RDS, treat it as T-SQL automation: CmdExec, PowerShell, ActiveX steps, Agent tokens, native Agent alerts/operators patterns, and driving native backup commands via Agent are not supported or replaced by RDS backup/snapshot models; email workarounds often use Database Mail + sp_send_dbmail. You cannot start/stop Agent — AWS owns the service lifecycle.
On RDS Multi-AZ, how do SQL Server Agent jobs behave between primary and standby?
Only T-SQL job steps replicate to the standby; SSIS, Replication, PowerShell-style steps do not. AWS documents job count limits for Multi-AZ SQL Server — check current Multi-AZ for SQL Server docs. Plan jobs assuming RDS rules, not a full EC2 Agent feature set.
What RDS levers (besides SQL text) do you mention for tuning and configuration in an interview?
Parameter groups (engine settings), option groups (add-ons RDS supports), DB subnet groups, security groups, and maintenance windows — plus application/SQL tuning within RDS constraints. Contrast with EC2 where you can change anything the OS and edition allow.
How do read replicas on RDS fit next to Multi-AZ and native replication on EC2?
Read replicas (RDS) address async read workloads and DR patterns with lag and promotion considerations — they are not the Multi-AZ synchronous standby. Native replication topologies you fully design (publisher/distributor/subscriber) live in EC2-style discussions per your replication notes. Don’t conflate RDS replica with Multi-AZ or with customer-built replication.
What should you say if an interviewer asks about SQL Server 2022 on RDS and “latest feature” parity?
AWS calls out additional gaps for 2022 (e.g. some snapshot suspend, external data source / object store features, TLS 1.3 / MS-TDS 8.0, backup compression QAT offload, SSAS on-instance, etc.) — confirm on the same feature non-support documentation page before quoting edge cases in a panel.
