这篇是“AWS RDS 介绍”系列的第三篇。前两篇聊了RDS的基本概念以及它跟自建数据库的差异今天就直接上手专门讲怎么创建一个RDS实例。很多新手第一次操作时面对控制台里密密麻麻的选项都会发懵引擎版本、存储类型、VPC、安全组、Multi-AZ每一个都像在考决策力。这篇文章我会把创建之前需要想清楚的问题、关键参数怎么搭配、控制台和CLI两种创建方式的具体步骤以及我在生产环境里踩过的一些坑一次性讲清楚。需要先说明一下这里说的AWS RDS是亚马逊的关系型数据库托管服务Relational Database Service不是Windows Server里的远程桌面服务Remote Desktop Services。有些朋友看到“RDS”会联想到远程桌面如果你搜过“Windows Server 2016 RDS服务器升级补丁重启后断连”之类的内容那跟云数据库是两回事。文章的核心只有一个在AWS上把一个数据库实例稳稳地建起来。创建RDS实例本身不难难的是“选型”和“网络配置”。控制台点点按钮一般十几分钟就能起来但如果一开始就选错规格、开错访问权限后面有的是折腾。所以这篇的顺序是先讲架构选型思路再讲关键参数接着给完整实操步骤和连接验证最后整理常见问题和我自己的避坑经验。1. 创建RDS实例前先把需求和架构想明白1.1 四个核心选型不能拍脑袋创建RDS实例的第一件事不是打开AWS控制台而是先回答几个问题。我见过不少人在这一步图省事结果环境搭好后应用连不上只能删除重建白白浪费时间。第一个问题是用什么数据库引擎。AWS RDS支持MySQL、PostgreSQL、MariaDB、Oracle、SQL Server以及Aurora。选择主要看你现有应用的兼容性和开发团队熟悉程度。如果你是从本机MySQL迁过来就用MySQL如果业务上有较强的一致性读写、JSON处理或地理信息需求PostgreSQL会更合适。Aurora虽然兼容MySQL和PostgreSQL但它是AWS自研的云原生引擎性能更好、成本也更高一般生产核心业务才推荐。这里的原则很朴素能用熟悉引擎解决就不轻易换引擎。第二个问题是实例规格。RDS实例规格分为标准型、内存优化型、突发性能型等。测试环境用db.t3.micro、db.t4g.micro这类突发型就够用线上业务至少从db.t3.medium或db.r6g.large起步。选择规格时要参考两个指标CPU和内存的峰值水位而不是平均值。数据库是时延敏感型服务CPU长期超过70%就要考虑升级了否则一次大查询就能拖垮整体响应。第三个问题是架构。你是要单个数据库实例还是要高可用AWS提供了Multi-AZ部署也就是主备实例分别放到不同可用区自动同步和自动故障切换。生产环境我强烈建议用Multi-AZ因为单实例一旦底层硬件故障RDS会自动重启但会有数分钟不可用Multi-AZ可以把不可用时间压缩到几十秒。开发、联调环境可以不用能省一半成本。第四个问题是网络和安全。数据库要放到哪个VPC是否允许公网访问安全组怎么开放都要提前想。这里的原则是默认不要把数据库暴露到公网。真正生产环境中数据库实例通常放在私有子网应用服务器通过安全组规则访问DBA通过堡垒机或跳板机登录。如果你只是想本地开发连一下可以临时开启“公开访问”但务必用安全组严格限制来源IP。1.2 控制台、CLI、IaC创建方式不只是习惯问题AWS上创建RDS实例主要有三种方式控制台、CLI/SDK、基础设施即代码CloudFormation/Terraform/AWS SAM等。控制台适合第一次体验和临时起一个环境能直观看到所有配置项CLI适合脚本化和批量操作比如一次性给多个环境创建同名但配置不同的实例IaC适合团队协作和持续交付数据库、安全组、子网组都通过代码管理变更可审计。我之所以在实操部分把控制台和CLI都写出来是因为两者应对的场景不同。比如你负责的是一个小应用一个人全包控制台创建完全够用但如果你在公司负责平台团队每天要帮开发环境拉数据库写一个基于CLI的脚本能省下大量重复操作。AWS SAM虽然主要用于Serverless应用但它的底层也是CloudFormation如果你用SAM管理Lambda和API Gateway完全可以在同一个模板里声明RDS实例让基础设施结构更清晰。提示创建RDS实例前先确认你所在账号的IAM权限。RDS相关操作至少需要rds:CreateDBInstance、rds:DescribeDBInstances等权限控制台操作还需要rds:CreateDBSubnetGroup等。别图省事直接用管理员账号权限分离早晚是审计要求。2. 创建实例时关键参数应该怎么选2.1 引擎版本和参数组决定了兼容性和默认行为选择数据库引擎时会遇到“版本”问题。比如MySQL有5.7、8.0、8.4等不同版本在认证方式、字符集、SQL模式上都有差异。一个常见坑是MySQL 8.0默认的caching_sha2_password认证方式老版本客户端连不上。如果你计划的应用程序用的还是老客户端可以在创建时选择兼容的参数组或者在创建后修改数据库用户认证方式。AWS RDS允许你管理参数组Parameter Group它相当于数据库配置文件的托管版本。比如你可以把MySQL的max_connections从小值调大把slow_query_log打开把时区和字符集都设好。创建实例时可以选择默认参数组也可以预先建好自定义参数组。我建议从一开始就顺手建一个项目专用参数组把字符集、时区、连接数上限都调整好省得以后改配置还要重启实例。2.2 存储类型、存储容量与自动扩展RDS支持通用型SSDgp2/gp3、预置IOPSio1/io2和磁性存储已基本淘汰。大量场景下gp3性价比最高它的基线性能和最高性能已经够中小规模业务用。如果你的数据库对IOPS有稳定要求比如每秒写入量大再考虑io2。这里有个容易忽略的点存储的“容量”和“性能”并不是完全独立的。gp2在容量小于一定值时IOPS随容量增加而增加gp3则允许独立调整IOPS和吞吐量。所以创建时不要只盯着容量大小要看磁盘类型和你实际需要的IOPS。存储容量建议宁多勿少但也不必一次到位。RDS支持“存储自动扩展”当剩余存储低于阈值时自动增加容量。以MySQL为例默认自动扩展最多到最大阈值你可以自己设置上限。我以前遇到过一次业务量突然上涨磁盘在半夜被日志打满幸好开了自动扩展数据库才没有被迫进入只读模式。这个开关强烈建议打开上限不要设得太低否则跟没开一样。2.3 备份、维护窗口和Multi-AZ机制创建实例时备份相关设置最容易被跳过但出了问题最要命。RDS默认开启自动备份保留天数默认7天你可以调整到0到35天。备份保留天数决定了你可以按时间点恢复PITR到多久之前所以生产环境至少设15天。另外自动备份会占用存储空间但灾难面前这点成本别省。维护窗口和备份窗口是两个不同的时间段。备份窗口用于每天自动备份维护窗口用于系统更新和补丁。都建议设置在业务低峰期比如凌晨2点到3点。如果创建时模棱两可AWS会随机分配很可能恰好落在你的业务高峰期。Multi-AZ是RDS“高可用”的关键。开启后AWS会自动创建一个备用实例主库数据同步到备库。当主库故障或可用区故障时自动切换到备库。这里要注意的是Multi-AZ并不同时提升读性能读流量仍然在主库上。想扩展读需要创建只读副本Read Replica那是另一件事。注意Multi-AZ开启后想变回单实例一般需要先删除再重建或者通过还原快照重建。虽然标准文档没有绝对禁止但实际运维中通常这么操作。所以创建前一定要想清楚生产环境是否需要高可用避免来回折腾。2.4 数据库访问凭据与加密创建实例时要设置“主用户名”和“主密码”。这里有个容易被忽略的细节RDS不会替你保存密码明文如果忘记密码你需要“重置主密码”。用CLI或控制台重置密码时实例会强制重启连接会中断1到2分钟。所以建议把凭据放到AWS Secrets Manager或Parameter Store里管理不要写在配置文件中。尤其是微服务和自动化部署场景Secret Manager可以自动轮换密码减少人工干预。加密方面RDS支持存储加密和传输加密。创建实例时勾选“启用加密”即可使用AWS KMS密钥。一旦启用加密底层存储、自动备份、快照都会被加密。虽然无法在创建后给未加密实例直接开启加密需要迁移或快照复制但新建实例时建议直接开启。3. 实操从零创建RDS实例并连上3.1 控制台创建MySQL实例一步一步来最直观的方式是控制台。登录AWS管理控制台在搜索框输入RDS进入RDS Dashboard点击“创建数据库”。第1步选择数据库创建方式。标准创建和简单创建二选一。简单创建会隐藏不少配置默认选标准创建即可。第2步引擎选项。选择MySQL版本选一个尽量新的稳定版比如8.0.x。如果是测试学习选默认版本即可。第3步模板。选“生产”模板会自动帮你启用Multi-AZ、存储自动扩展和删除保护“开发/测试”模板则默认单实例。根据实际情况选择。第4步设置。数据库实例标识符例如 myblog-db主用户名例如 admin主密码自行设置或通过Secret Manager管理。第5步实例配置。选择“标准型”或“内存优化型”比如db.t3.micro。如果没有预留实例这里显示的是按需价格。第6步存储。选择gp3分配存储20GB开启存储自动扩展最大存储500GB。第7步可用性和持久性。Multi-AZ选“创建备用实例”或“不创建备用实例”。生产选“创建备用实例”。第8步连接。VPC选默认VPC子网组通常自动创建默认组公有访问选“否”除非本地调试需要安全组选“选择现有”或新建入站规则放通3306。第9步额外配置。数据库名称、端口、参数组、备份设置、维护窗口、删除保护等都可以在这里调整。建议把“删除保护”勾选上防止手滑删除。第10步点击“创建数据库”。整个过程看起来简单但里面有几个容易踩的坑。第一数据库端口默认3306如果业务用别的端口需要改成对应端口第二安全组入站规则不光要允许某个IP访问更推荐允许应用服务器所在的安全组ID这样EC2实例重建后IP变化也不影响连接第三如果选择“公开访问是”一定把来源IP限制到你自己的固定IP否则全世界都能扫到你数据库端口。创建后实例状态为“创建中”一般需要等待10到20分钟。可以刷新页面查看状态直到变成“可用”再连接。控制台事件日志里能看到详细的创建过程如果长时间卡住先在事件里找原因。3.2 用CLI创建RDS实例适合批量环境如果不想在页面里一步步点或者要写自动化脚本可以直接用AWS CLI。先确保本机安装了AWS CLI并配置好凭证aws configure然后用类似下面的命令创建MySQL实例aws rds create-db-instance \ --db-instance-identifier myblog-db \ --db-instance-class db.t3.micro \ --engine mysql \ --engine-version 8.0.35 \ --master-username admin \ --master-user-password ChangeThisPassword123! \ --allocated-storage 20 \ --storage-type gp3 \ --db-name myblog \ --port 3306 \ --no-publicly-accessible \ --vpc-security-group-ids sg-0abc123def456 \ --db-subnet-group-name default \ --backup-retention-period 7 \ --multi-az有一点需要注意CLI创建实例时不会像控制台那样提示你补充所有参数像存储自动扩展、删除保护、加密这些都需要额外参数来打开。例如启用存储自动扩展可以加--max-allocated-storage 500启用删除保护加--deletion-protection启用加密加--storage-encrypted和--kms-key-id。如果漏了创建后再开启会比一次性创建麻烦得多。CLI的好处是参数可复用。你可以把命令存成Shell脚本循环创建不同环境的实例仅替换标识符和密码。但是提醒一句不要把密码硬编码在脚本里更不要提交到Git仓库。建议从环境变量或AWS Secrets Manager读取这也是很多团队安全基线里的硬性要求。3.3 创建后怎么验证数据库能连实例状态变成“可用”后先找到“端点”Endpoint它是数据库的连接地址类似myblog-db.xxxxx.rds.amazonaws.com。使用MySQL客户端连接mysql -h myblog-db.xxxxx.rds.amazonaws.com -P 3306 -u admin -p输入密码后如果能看到mysql提示符说明连接成功。如果连接超时或报权限错误大概率是安全组或网络路径的问题。另外创建实例时填写的“数据库名称”只是默认创建的一个库并不是实例名称。连接时如果指定了错误的数据库名会报Unknown database。创建实例时不填“数据库名称”也没关系后面可以自己执行CREATE DATABASE。4. 常见问题与排查技巧实录4.1 典型问题速查表创建RDS实例从控制台到连接我遇到过不少问题挑几个典型的列在下面。现象可能原因排查思路连接超时安全组入站规则未放行端口检查RDS实例关联的安全组是否添加了3306入站规则连接超时数据库位于私有子网无法直接访问使用同一VPC中的EC2跳板机连接或者开启公开访问并通过安全组限制来源IPAccess denied用户名或密码错误到RDS控制台重置主密码注意会有重启过程Unknown database连接时指定了不存在的库名先不指定数据库名连接执行SHOW DATABASES确认存储不足数据增长超过分配容量开启存储自动扩展或手工修改分配容量实例卡在“创建中”后台资源调度或参数无效检查事件日志必要时删除重建表格里的“连接超时”很多人第一反应是改安全组放通所有IP。这样确实能通但非常危险。正确的做法是先把RDS实例的安全组规则和网络ACL都检查一遍数据库端口只对需要访问的IP或安全组开放。还有如果RDS实例和EC2不在同一个VPC即使安全组放通了也可能不通需要检查VPC对等连接或转发配置。4.2 创建RDS实例容易犯的错我替你踩过了第一个坑实例标签没规划。一个账号里如果跑着几十个RDS没有标签的话账单上根本分不清哪个实例属于哪个项目。我习惯在创建时就打上Environmentprod、Teambackend、CostCenterxxx这类标签。控制台和CLI都支持Tags创建时多敲几行参数后面查询账单和权限管理能省不少力气。第二个坑删除保护没开。有一次开发误删了一个测试数据库还好有快照恢复了数据但折腾了半天。后来我每次创建实例都默认勾选“删除保护”。如果你真的需要删除控制台会要求你先取消这个选项算是多一道确认环节。第三个坑忽略SSL证书验证。RDS提供了SSL/TLS证书用于加密连接如果你在客户端开启了证书验证但拿的是公共CA证书可能会连接失败。开发环境可以暂不启用SSL生产环境强烈建议走SSL并关注AWS证书更新通知。第四个坑备份窗口和业务高峰重叠。有些团队创建时图省事备份窗口选了默认结果每天备份都跟活动高峰撞车数据库性能明显下降。我建议创建时就设置一个明确的备份窗口不要在高峰期做备份。第五个坑错误选择多可用区导致成本翻倍。Multi-AZ意味着主备两套实例计费如果你只是学习或做前端DEMO完全不需要。反过来生产环境如果单实例跑了一年没开Multi-AZ遇到一次底层硬件故障被强制重启几分钟不可用就很被动。所以按环境需求选不要盲目上也不要盲目省。5. 创建完成后的安全加固与架构优化5.1 安全组、子网组与Web应用防火墙别搞混创建RDS实例时会遇到两个网络概念子网组和安全组。子网组决定数据库实例落在哪些子网里安全组是虚拟防火墙决定谁能访问数据库端口。这个跟WAFWeb Application Firewall不一样WAF保护的是HTTP/HTTPS应用层流量通常挂在ELB或CloudFront前面RDS安全组保护的是数据库端口本身。有不少朋友问RDS前面能不能挂WAF答案是直接挂不了因为WAF不面向数据库协议它过滤的是Web请求。如果你关心数据库被SQL注入之类的攻击核心手段是应用层参数化查询、最小权限账号、定期备份和审计日志而不是在数据库前加WAF。安全组、子网隔离、KMS加密、IAM权限这些才是RDS防护的主力。5.2 用Well-Architected框架审视你创建的RDS实例AWS有一套“Well-Architected Framework”包括六个支柱卓越运营、安全性、可靠性、性能效率、成本优化和可持续性。用这个框架回头看看你刚创建的RDS实例能帮你发现不少疏漏。可靠性备份保留是否足够有没有开启Multi-AZ能不能做时间点恢复安全性是否开启存储加密主账号是否设置了强密码安全组是否最小化开放性能效率实例规格是否匹配业务峰值存储类型是否选对连接池是否配置成本优化是否启用了预留实例或Savings Plans标签和账单是否清晰卓越运营监控告警是否配置Performance Insights是否开启维护窗口是否合理这其实就是把“创建实例”从一次性的操作上升为可运维、可解释、可持续的架构设计。每一步都不复杂但组合起来能避免后期不少麻烦。如果你所在团队有审核流程可以先照着这个列表自我检查一遍。提示如果是通过AWS SAM或CloudFormation创建RDS尽量把数据库配置、安全组、子网组都写在同一个模板中并给资源加上明确逻辑ID。这样删除整个资源栈时数据库能跟着一起清理不留孤儿资源。6. 创建RDS实例的经验沉淀6.1 每次创建前都要确认的几个习惯我现在每创建一个RDS实例都会先画一个简化的访问架构图应用在哪个VPC、数据库在哪个子网、安全组怎么放通、谁有权限连数据库。脑子里有这些信息比看到控制台页面再临时想靠谱得多。另一个习惯是“从小规格起步但生产环境不压规格”。开发环境db.t3.micro真的够用生产环境至少db.t3.medium起步并开启Multi-AZ。存储自动扩展一定要开上限设到当前容量的3到5倍能解决很多“突然容量不足”的焦虑。还有个小技巧创建实例时顺手把Performance Insights打开。这个功能会在实例创建后开始收集性能数据虽然没有它也能用但等出了问题再去开启就看不到历史数据了。打开它至少保留7天免费周期排查慢SQL时会比较从容。6.2 从创建走向稳定的日常运维实例创建完成只是开始。建议创建完马上配置CloudWatch告警至少关注CPU利用率、数据库连接数、磁盘空间和复制延迟这四个指标。很多故障在发生前都有迹象告警能让你提前介入。另外主账号密码不要长期不变。生产环境建议启用Secrets Manager自动轮换或者至少在运维日历里设置密码定期更新。RDS控制台支持重置密码但注意重置会触发重启所以最好放在维护窗口去做。如果你现在正打算在AWS上建第一个RDS实例不用把所有参数都研究透先按推荐值创建起来能连通再逐步调优。毕竟数据库这东西实际跑起来才知道问题在哪。等你有经验了自然会形成一套自己的默认配置。