Managed Relational Database Services: Deploy and Connect

What Is a Managed Relational Database Service?

A managed relational database service (sometimes called DBaaS, Database-as-a-Service) is a cloud platform offering in which the provider handles hardware provisioning, operating-system patching, storage allocation, automated backups, and high-availability failover. You, the DBA, focus on schema design, query tuning, user management, and connectivity — not on maintaining the underlying server. The three dominant platforms for this lesson are Amazon Web Services (AWS) with RDS, Microsoft Azure with Azure SQL Database, and Google Cloud with Cloud SQL.

Understanding how each platform exposes a managed database is directly tested in the Microsoft DP-300 exam and is a practical requirement for any database administrator working in a modern enterprise.

AWS RDS: Core Concepts Before You Click

AWS Relational Database Service (RDS) runs your engine — PostgreSQL, MySQL, SQL Server, and others — inside a Virtual Private Cloud (VPC). Before you provision an instance, you must plan three network objects:

• DB Subnet Group: tells RDS which subnets (in at least two Availability Zones) the instance may use. Without this, RDS cannot place your instance in a private network.
• Parameter Group: a named collection of engine configuration parameters (for example, `max_connections` or `shared_buffers` for PostgreSQL). The default parameter group works for a lab but production environments almost always need a custom one.
• Security Group: acts as a stateful firewall. You must add an inbound rule allowing TCP on port 5432 (PostgreSQL) from your client's IP address or CIDR block. Opening port 5432 to the entire internet (0.0.0.0/0) is a serious security misconfiguration — never do this in production.

Once the instance reaches the Available state, the console shows an endpoint hostname such as `mydb.c9akciq32.us-east-1.rds.amazonaws.com`. Use that hostname in your connection string, never an IP address, because managed services can change the underlying IP during maintenance.

To connect from a local VM using `psql`:

```

psql -h <endpoint> -U <master_user> -d <dbname> -p 5432

```

Azure SQL Database: Portal and CLI Together

Azure SQL Database is a fully managed SQL Server-compatible engine. The General Purpose tier uses a vCore purchasing model and provides a balance of compute and storage suitable for most workloads.

Key setup steps unique to Azure:

1. Logical server: every Azure SQL Database sits inside a logical server (not a VM). The server holds authentication settings and firewall rules.

2. Firewall rules: by default, the logical server blocks all incoming connections. You add rules by IP range in the portal or with `az sql server firewall-rule create`. For the lab, add your workstation's public IP.

3. Azure Active Directory (AAD) admin: you can designate an AAD user or group as an administrator in addition to SQL authentication. This is a best practice because it enables password-free, identity-based access and is an auditable control.

4. Connection string: Azure provides ready-made connection strings for ADO.NET, JDBC, ODBC, and others under the database's Connection strings blade. Always use the FQDN of the logical server, for example `myserver.database.windows.net`.

Azure Data Studio is a cross-platform GUI client maintained by Microsoft. It supports both Azure SQL and PostgreSQL via extensions and is the recommended client for this lab.

Google Cloud SQL and the Run-Book Exercise

Cloud SQL for PostgreSQL is Google's managed offering. Provisioning mirrors AWS RDS conceptually — you choose a machine type, storage, a region, and configure authorized networks (IP allowlisting). The `gcloud` CLI command pattern follows:

```

gcloud sql instances create <name> --database-version=POSTGRES_15 \

--tier=db-f1-micro --region=us-central1

```

The run-book exercise is not just a documentation task — it is a professional skill. A run-book is a numbered, repeatable procedure a colleague can execute without ambiguity. Good run-books include exact commands, expected output, verification steps, and rollback actions. When you peer-review a partner's run-book, check that every step is present, every command is complete, and the expected state after each step is stated.

Security and Access-Control Principles

Across all three platforms, these principles apply:

• Least privilege: grant only the permissions a user or application needs. Avoid using the master/admin account for application connections.
• Encryption in transit: all three platforms enforce TLS on database connections by default. Never disable TLS requirement in production.
• No public exposure without necessity: prefer private endpoints or VPC peering over public internet access. When public access is required for a lab, restrict it to known IPs and remove it after the exercise.
• Credential hygiene: never hard-code passwords in scripts you share or commit to version control. Use environment variables or secrets managers.
• Physical safety note: when working on lab VMs that are physical workstations, follow your facility's electrical safety policies. Do not bypass lockout/tagout procedures on any shared rack equipment, and always wear appropriate PPE if working inside network closets or data center aisles.

Verifying Connectivity

A successful connection is not enough for a professional standard. After connecting, run a simple query to confirm you are in the right database on the right instance:

```sql

SELECT current_database(), version();

```

Document the output. Your instructor will verify a live connection to each platform and will review your run-book for completeness. Both checks must pass to earn credit for this lab.