Creating a SQL Server Database on Azure SQL and AWS RDS: A Beginner’s PaaS Guide

Every option in the last lesson — Developer Edition, Docker, Express — means you install and manage SQL Server. A huge share of real jobs instead use a managed (PaaS) SQL Server, where the cloud provider runs the engine for you. Here’s what that actually looks like, and why it’s worth understanding even as a beginner — you may well connect to one of these on your very first day at a job.

IaaS vs PaaS vs On-Prem — Where Each Fits

It helps to place “managed SQL” on a spectrum rather than treat it as one thing:

• On-prem / local install (what Chapter 0.3 covered) — you own the hardware, the OS, and the SQL Server installation. Maximum control, maximum responsibility.
• IaaS (e.g. a SQL Server VM on Azure/AWS/GCP) — the cloud provider gives you a virtual machine; you still install and manage SQL Server on it yourself, same as local, just on someone else’s hardware.
• PaaS (Azure SQL Database, AWS RDS for SQL Server) — the provider manages the SQL Server engine itself. You get a connection string, not a server to log into.

This lesson is specifically about the third option, since it’s the one most beginners haven’t seen and the one most likely to surprise you in a real job (“why can’t I just RDP into the database server?” — because there isn’t one you can access).

What “PaaS” Changes

You still write the exact same T-SQL you’ve been learning. What changes is everything around the database — how it’s created, connected to, secured, and maintained.

Creating a Database on Azure SQL

1. In the Azure Portal, search for SQL Database → Create
2. Choose or create a logical server (a management boundary and connection endpoint, not a physical machine — one logical server can host many databases) — set an admin login and password here
3. Pick a pricing tier: DTU-based (simpler, bundled compute+storage+IO into one number, good for beginners) or vCore-based (separately configurable compute/storage, closer to how you’d think about a VM’s specs, and the tier Microsoft is steering customers toward long-term)
4. Under Networking, add your current IP to the firewall rule so you can actually connect — by default, Azure SQL blocks every IP, including yours, until explicitly allowed
5. Click Create — provisioning takes a few minutes

-- Connect via SSMS using the server's full name, e.g.:
-- Server: yourserver.database.windows.net
-- Authentication: SQL Server Authentication, using the admin login you set

SELECT @@VERSION; -- confirms you're connected, same as any other SQL Server

Creating a Database on AWS RDS for SQL Server

1. In the AWS Console, go to RDS → Create database
2. Choose engine: Microsoft SQL Server, pick an edition (Express is free-tier eligible for learning)
3. Set the DB instance identifier, master username, and password
4. Under Connectivity, set a Security Group rule allowing inbound traffic on port 1433 from your IP — AWS’s equivalent of Azure’s firewall rule, same underlying idea: nothing gets in until you explicitly allow it
5. Create — RDS provisions the instance, then gives you an endpoint (hostname) to connect to

-- Connect via SSMS using the RDS endpoint, e.g.:
-- Server: yourinstance.abc123xyz.us-east-1.rds.amazonaws.com,1433

CREATE DATABASE TechCorpLite; -- works exactly like it did locally
GO

What a Beginner Should Actually Know Is Different

Everything you’ll learn for the rest of this course — SELECT, JOIN, constraints, all of it — works identically once you’re connected. The only thing that changes is how you got connected in the first place, and a short list of admin-level features (cross-database queries, SQL Server Agent, filesystem access) that a beginner course won’t rely on anyway.

Why This Matters Even If You Never Provision One Yourself

In most companies, a DBA or platform team provisions the Azure SQL/RDS instance, and you’re handed a connection string. But you’ll still hit PaaS-specific quirks directly: connection timeouts from firewall misconfiguration, “feature X isn’t supported” errors that don’t happen locally, and cost conversations driven by DTU/vCore tier choice. Recognizing “oh, this is a PaaS limitation, not a bug in my query” saves real debugging time — which is exactly why this lesson exists this early in the course, not buried in an advanced chapter.