📖 Scenario: You are planning to deploy a database using Amazon RDS for your small business application. You want to understand how different configurations affect the monthly cost.
🎯 Goal: Build a simple AWS CloudFormation template that defines an RDS instance with configurable parameters to explore pricing factors such as instance class, storage size, and multi-AZ deployment.
📋 What You'll Learn
Create a CloudFormation template with an RDS DB instance resource
Define parameters for DB instance class, allocated storage, and Multi-AZ deployment
Use the parameters to configure the RDS instance resource
Add outputs to show the chosen configuration values
💡 Why This Matters
🌍 Real World
CloudFormation templates help automate and standardize AWS resource deployment, making it easier to manage costs by adjusting configurations.
💼 Career
Understanding how to configure RDS instances and their pricing factors is essential for cloud architects and engineers managing AWS infrastructure.
Progress0 / 4 steps
1
Create CloudFormation template with RDS DB instance resource
Create a CloudFormation template with a resource named MyDBInstance of type AWS::RDS::DBInstance. Set the Engine property to mysql and MasterUsername to admin.
AWS
Hint
Use the Resources section to define the RDS instance with the required properties.
2
Add parameters for instance class, storage, and Multi-AZ
Add parameters named DBInstanceClass (default db.t3.micro), AllocatedStorage (default 20), and MultiAZ (default false) to the template.
AWS
Hint
Define parameters under the Parameters section with the specified names and defaults.
3
Use parameters to configure the RDS instance properties
Update the MyDBInstance resource to use the parameters DBInstanceClass for DBInstanceClass, AllocatedStorage for AllocatedStorage, and MultiAZ for MultiAZ properties using !Ref.
AWS
Hint
Use !Ref to reference parameters in the resource properties.
4
Add outputs to show selected configuration values
Add outputs named SelectedInstanceClass, SelectedStorage, and SelectedMultiAZ that output the values of parameters DBInstanceClass, AllocatedStorage, and MultiAZ respectively using !Ref.
AWS
Hint
Use the Outputs section to show parameter values using !Ref.
Practice
(1/5)
1. Which factor directly affects the hourly cost of an AWS RDS instance?
easy
A. The number of tables in the database
B. The instance size (e.g., db.t3.medium vs db.m5.large)
C. The number of users connected
D. The database engine version
Solution
Step 1: Understand RDS pricing components
RDS pricing depends on instance size, storage, backups, and deployment options, not on users or tables.
Step 2: Identify the factor affecting hourly cost
The instance size determines the compute capacity and directly affects the hourly price.
Final Answer:
The instance size (e.g., db.t3.medium vs db.m5.large) -> Option B
Quick Check:
Instance size = hourly cost [OK]
Hint: Instance size controls hourly cost, not users or tables [OK]
Common Mistakes:
Confusing number of users with cost
Thinking database engine version affects hourly price
Assuming number of tables changes cost
2. Which storage type option is valid when configuring AWS RDS storage?
easy
A. Magnetic
B. NVMe
C. SSD General Purpose (gp3)
D. Tape Drive
Solution
Step 1: Review valid RDS storage types
AWS RDS supports SSD General Purpose (gp2/gp3), Provisioned IOPS SSD, and Magnetic (deprecated).
Step 2: Identify the valid current option
SSD General Purpose (gp3) is a valid and recommended storage type for RDS.
Final Answer:
SSD General Purpose (gp3) -> Option C
Quick Check:
gp3 is valid RDS storage [OK]
Hint: Choose gp3 for modern RDS SSD storage [OK]
Common Mistakes:
Selecting deprecated or unsupported storage types
Confusing tape or NVMe with RDS storage
Assuming Magnetic is still recommended
3. Given an RDS instance with 100 GB of gp3 storage and 7 days backup retention, which factor will increase the monthly cost the most?
medium
A. Switching database engine from MySQL to PostgreSQL
B. Increasing backup retention from 7 to 35 days
C. Changing instance type from db.t3.medium to db.t3.small
D. Increasing storage from 100 GB to 200 GB
Solution
Step 1: Analyze cost impact of backup retention
Backup storage beyond allocated free backup size adds cost, but increasing retention from 7 to 35 days may add moderate cost.
Step 2: Analyze cost impact of storage increase
Doubling storage from 100 GB to 200 GB doubles storage cost, which is a significant monthly cost increase.
Step 3: Analyze instance type and engine changes
Changing to smaller instance reduces cost; engine change does not affect pricing directly.
Final Answer:
Increasing storage from 100 GB to 200 GB -> Option D
Quick Check:
Storage size increase = biggest cost rise [OK]
Hint: Storage size impacts monthly cost more than backup days [OK]
Common Mistakes:
Assuming backup retention always costs more
Thinking smaller instance increases cost
Believing engine type changes price
4. You configured an RDS instance with Multi-AZ deployment but forgot to enable automated backups. What pricing issue will occur?
medium
A. You will be charged for Multi-AZ but no backup storage cost
B. You will be charged for backup storage even if backups are disabled
C. You will not be charged for Multi-AZ deployment
D. You will be charged for backup storage only if manual snapshots exist
Solution
Step 1: Understand Multi-AZ pricing
Multi-AZ doubles instance cost because a standby instance runs in another zone.
Step 2: Understand backup storage pricing
Automated backups must be enabled to incur backup storage charges; if disabled, no backup storage cost applies.
Final Answer:
You will be charged for Multi-AZ but no backup storage cost -> Option A
Quick Check:
Multi-AZ charges apply; backups disabled means no backup cost [OK]
Hint: Multi-AZ costs apply even if backups are off [OK]
Common Mistakes:
Assuming backup storage cost applies without backups enabled
Thinking Multi-AZ is free
Confusing manual snapshots with automated backups
5. You want to minimize AWS RDS costs for a development environment that requires low latency and high availability. Which combination is best?
hard
A. Use a small instance with Multi-AZ deployment and gp3 storage
B. Use a medium instance with Multi-AZ deployment and Magnetic storage
C. Use a small instance with Single-AZ deployment and gp3 storage
D. Use a large instance with Single-AZ deployment and gp3 storage
Solution
Step 1: Identify cost and availability needs
Low latency and high availability require Multi-AZ deployment and sufficient instance size.
Step 2: Evaluate storage and instance size
gp3 storage is cost-effective and performant; small instance reduces cost while Multi-AZ ensures availability.
Step 3: Compare options
Use a small instance with Multi-AZ deployment and gp3 storage balances cost (small instance), availability (Multi-AZ), and performance (gp3 storage).
Final Answer:
Use a small instance with Multi-AZ deployment and gp3 storage -> Option A
Quick Check:
Small + Multi-AZ + gp3 = cost-effective high availability [OK]
Hint: Multi-AZ + small instance + gp3 balances cost and availability [OK]
Common Mistakes:
Choosing Magnetic storage which is slower and deprecated
Ignoring Multi-AZ for high availability
Picking large instance unnecessarily increasing cost
Recommended
Ready to prove it?
Pass the test and this pattern moves unknownstrongwhile earning +1 Grip toward your certificate.