part0008

EC2 serves as the foundation for scores of additional Amazon web services. Very prominent among these services is the Amazon Relational Database Service (Amazon RDS), a managed web service for enabling and facilitating the implementation of familiar, contemporary relational database management systems (RDBMS) -- such as Oracle DB, Microsoft SQL Server, MySQL, MariaDB, and PostgreSQL -- in the Amazon cloud.

As a managed service, RDS facilitates and reduces the stress of dealing with administrative chores for overseeing the operational aspects of relational databases. Mundane admin tasks usually performed by DBAs (e.g., scaling additional CPU resources, allocating additional memory and storage devices, performing backups, applying software patches, detecting and reacting to database failures, recovering databases from backups, etc.) are simplified and often expedited by RDS.

RDS also accelerates the implementation of complex requirements, such as high availability by optionally synchronizing database updates and failing over to a secondary database instance in the event of database failure. In some cases (i.e., for MySQL, MariaDB, and PostgreSQL), RDS enables the establishment of read replicas -- additional database instances for read-only access -- to relieve the pressure on a primary database instance from query activity.

In Figure 2.1, the ENGINE and ENGINE VERSION entities reflect the DBMS engines and versions of database engines supported by RDS (e.g., the various supported versions of Oracle DB, MySQL, PostgreSQL, Microsoft SQL Server, and MariaDB). Each DBMS engine has many supported versions. The many-to-many relationship between the CHARACTER SET and ENGINE VERSION entities emphasizes that each version of a database engine can support many character sets, one of which can be designated as the default character set. In the opposite direction, a character set (e.g., UTF8) can be supported by many engine versions. The many-to-many reflexive relationship (labelled “upgrade”) between the ENGINE VERSION entity and itself points out possible engine versions that are valid targets for upgrade. More specifically, each engine version can possibly be upgraded to many later and greater versions, and an engine version can be the target of many prior engine versions .

The PARAMETER GROUP and PARAMETER entities deal with maintaining database configuration information. The one-to-many relationship between the PARAMETER GROUP and PARAMETER entities conveys that each parameter group is a collection of many parameters used for setting up a database. Values are assigned to database parameters, such as for the database time zone, character set, optimization features, audit trails, cache size for caching tables, the maximum number of processes for parallel execution, various categories of database memory, etc. More specific examples, well-known to Oracle DBAs, include setting parameter limits for system global area (i.e., SGA, the memory shared among processes within an Oracle database), and program global area (i.e., PGA, the private memory reserved for a single Oracle database process). Names of specific SGA and PGA related parameters for which values can be set include sga_target , sga_max_size , and pga_aggregate_target . The following example of an RDS CLI command, describe-engine-default-parameters, can be used for providing default parameters for a specific engine family (i.e., in this case for “oracle-ee-12.1”).

For setting the time zone parameter of a database, note the many-to-many relationship between the ENGINE and TIME ZONE entities emphasizing that each database engine supports many time zones and, of course, a time zone can be supported by many engines. For example, the default time zone for MySQL and MariaDB databases is Universal Time Coordinated (UTC). For these engines, however, the time_zone parameter in a parameter group can be set to the specific regional time zone (i.e., set to one of the supported values associated with the database engine) corresponding to the application’s time zone.

The DB INSTANCE entity represents a collection of EC2 instances for running isolated database environments. Such is emphasized in Figure 2.1 by noting that DB INSTANCE is a sub-type of the INSTANCE entity, thereby inheriting attributes and relationships of its INSTANCE super-type (e.g., each DB instance inherits an instance type, resides in a subnet, is associated with security groups, etc.) because a DB instance is a kind of EC2 instance. Depending on the database engine, each DB instance can support a single database (e.g., an Oracle database with multiple schemas ) or multiple databases (e.g., a Microsoft SQL Server environment).

The one-to-many relationship between the ENGINE VERSION and DB INSTANCE entities emphasizes that each DB instance is associated with a single DBMS engine version. The one-to-many relationship between the CHARACTER SET and DB INSTANCE entities emphasizes that each DB instance is associated with a single character set. The one-to-many relationship between the AVAILABILITY ZONE and DB INSTANCE entities emphasizes that each DB instance can be associated with an alternate availability zone for implementing high availability. As previously noted, RDS provides an option for having a secondary DB instance synchronized with the primary DB instance for failover to the secondary DB instance residing in this alternate availability zone .

The one-to-many relationships (i.e., two relationships) between the CUSTOMER MASTER KEY and DB INSTANCE entities emphasize two database encryption options available to each DB instance. Amazon encryption is provided by yet another service, the AWS Key Management Service (KMS) , which uses customer master keys (CMKs) as the basis for encrypting or decrypting data.21 The two relationships between CUSTOMER MASTER KEY and DB INSTANCE entities imply that two CMKs are optionally provided as foreign keys (FKs) to a DB instance. The relationship labelled “KMS Key Id” is the FK used for encrypting DB instance data. Amazon RDS is also endowed with the ability to monitor the load and analyze the performance of DB instances. RDS refers to this as Performance Insights data invaluable for troubleshooting database performance problems. The relationship labelled “Performance Insights KMS Key Id” is the FK for encrypting such performance metrics. This capability is supported for only a subset of RDS database engines and versions.

The context and purpose of the SUBNET GROUP entity is clarified with the help of the many-to-many relationship between the SUBNET GROUP and SUBNET entities. A subnet group is simply a collection of subnets and each subnet can belong to many subnet groups. The one-to-many relationship from the VPC entity to the SUBNET GROUP entity suggests that each subnet group is defined within a VPC. The one-to-many relationship between the SUBNET GROUP and DB INSTANCE entities suggests that each DB instance is associated with a single subnet group, which is used by RDS for assigning the DB instance to an appropriate subnet. Each subnet group should have subnets dispersed among multiple availability zones to facilitate implementing high availability (i.e., RDS can use an alternate subnet in a different availability zone if the primary DB instance fails).

The many-to-many relationship between the PARAMETER GROUP and DB INSTANCE entities shows that a DB instance can actually be associated with more than one parameter group. This accounts for the fact that RDS supports replacing the currently assigned parameter group with a second parameter group and that the status of this modification is pending . Most commonly, a DB instance has only one parameter group associated with it.

The one-to-many reflexive relationship between the DB INSTANCE entity and itself emphasizes RDS support, as previously noted, for read replicas applicable to MariaDB, MySQL, and PostgreSQL database engines. A primary DB instance serves as the source of data copied to one or more DB instances serving as read replicas. A read replica provides read-only access. Rather than accessing the primary DB instance, an application can re-direct its database queries to a read replica, thereby alleviating the workload on the primary DB instance. Any data updates on the primary DB instance are automatically and asynchronously pushed to its read replicas. Read replicas can be added as-needed for scaling capacity based on actual utilization.

Database engines provide optional capabilities, features or tools that extend or enhance fundamental engine capabilities. Amazon RDS refers to such features as options which are collected into option groups . Option groups are associated with DB instances. Examples of options for Oracle include:

Options have a collection of option settings that are specified to enable, configure, or govern the behavior of these capabilities for a DB instance. Each option setting has a current value and can also specify the set of possible valid values. For example, the Oracle Native Network Encryption option has an option setting “SQLNET. ENCRYPTION TYPES SERVER” which has several possible valid values. This option setting specifies a list of encryption algorithms used for encrypting inbound and outbound network traffic for a DB instance. The OEM option has option settings for specifying a port and security groups for governing access to the OEM database.

Amazon RDS provides (i.e., via the Amazon RDS console, API, or CLI) the ability to create new option groups, copy existing option groups, modify existing option groups by adding or removing options, assign current values to option settings, and assign option groups to DB instances. Once an option group is assigned, the DB instance is empowered with the options as governed by the option settings.

From Figure 2.2, the one-to-many relationship between the OPTION GROUP and OPTION entities indicates that each option group is composed of one or more options. The one-to-many relationship between the OPTION and OPTION SETTING entities indicates that each option has one or more option settings (e.g., as previously noted for Oracle, specifying the encryption algorithms for the “SQLNET.ENCRYPTION TYPES SERVER” option). The one-to-many relationship between the OPTION SETTING and ALLOWED VALUE entities indicate that each option setting has one or more valid values.

The many-to-many reflexive relationship between the OPTION entity and itself suggests prerequisites and conflicts for each option. Each option can depend on, or be in conflict with, one or more other options. Each dependent (or conflicted) option can be a prerequisite for (or in conflict with) many other options. Recall from the explanation of a conceptual data model (CDM) and logical data model (LDM) in the Introduction, an LDM would resolve this many-to-many relationship (i.e., reveal more detail) by introducing a new associative entity (aka an association class in UML) including an attribute to flag (i.e., indicate) whether a related option is a prerequisite or conflict.22

The many-to-many relationship between the OPTION GROUP and DB INSTANCE entities shows that a DB INSTANCE can actually be associated with more than one option group. This acknowledges the possibility that RDS supports replacing the currently assigned option group with a second option group and that the status of this modification is pending. Most commonly, a DB instance has only one option group associated with it.

The one-to-many relationship between the VPC and OPTION GROUP entities indicates that each option group can be associated with a single VPC, meaning that the option group is applicable only to DB instances that reside within the associated VPC.

Amazon RDS enables the ability to configure notifications (e.g., email, text messages, calls to other AWS services, etc.) triggered when database life events transpire. For publishing such event notifications, Amazon RDS partners with yet another Amazon service, the Amazon Simple Notification Service (SNS) .23 Database life events are classified into event categories such as “backup”, “ failure”, “ low storage”, “configuration”, etc. It is also possible to set up a subscription for specific event categories, thereby sending notifications to subscribers whenever an event in any of the subscribed categories occurs. Consider, for example, the “backup” event category. If a subscription is setup to the “backup” category for a specific database instance, then notices will be generated for any backup start events and backup completion events that occur. The “low storage” category results in alerts for both storage being totally used up and also for 90% utilization.

From Figure 2.3, the one-to-many relationship between the EVENT CATEGORY and EVENT entities indicates that each event category (e.g., “backup”, “failure”, “low storage”, “configuration change”, etc.) is associated with one or more events. The many-to-many relationship between the SOURCE TYPE and EVENT CATEGORY entities conveys that each event category is associated with many source types from which events can potentially be generated. In addition to DB instances, other types of event sources include parameter groups and database backups. Database backups are also referred to as snapshots. Snapshots will be further explained in a subsequent section. An example of events applicable to parameter groups includes, in the “configuration change” category, the occurrence of a parameter group modification (i.e., replacing the currently assigned parameter group by assigning a different parameter group to a DB instance). In the opposite direction, a source type can be associated with one or more event categories.

The one-to-many relationship between the SOURCE TYPE and EVENT SOURCE entities conveys that each source type is composed of many event sources such as specific DB instances and specific parameter groups. The one-to-many relationships from the DB INSTANCE and PARAMETER GROUP entities to the EVENT SOURCE entity shows that an event source is optionally either a specific DB instance or a specific parameter group .

The many-to-many relationship between the EVENT CATEGORY and EVENT SUBSCRIPTION entities conveys that each event subscription enables event notifications from possibly many event categories. But from which sources are these notifications? The one-to-many relationship between the EVENT SUBSCRIPTION and EVENT SOURCE entities indicates the specific sources (e.g., conceivably many DB instances) to which the subscription applies. The one-to-many relationship between the SOURCE TYPE and EVENT SUBSCRIPTION entities reveals that each subscription can be associated with a specific source type (e.g., if no event categories are associated). If a source type is specified (e.g., DB instances) but no event sources are specified (e.g., no specific DB instances) for an event subscription, then event notifications are received for all event sources belonging to the customer account for the specified source type (e.g., all DB instances). Specifying neither a source type nor an event source generates event notifications from all RDS sources (i.e., all DB instances, parameter groups, etc.) belonging to the customer account.

Note also the one-to-many relationship between the SNS TOPIC and EVENT SUBSCRIPTION entities revealing that each subscription specifies an SNS topic. Simply stated, an SNS topic is a named communication pathway enabling RDS to publish messages to SNS so that subscribers can receive event notifications. SNS topics and their associated endpoints (e.g., email addresses, text messages, HTTP/HTTPS entry points for web services, etc.) for receiving notifications are created via Amazon SNS (i.e., the Amazon SNS console, API, or software development kits) or via the Amazon RDS console.

Amazon SNS details (i.e., conceptual data modeling details) are beyond the scope of this immediate RDS conceptual modeling effort. It is envisioned that someday this paragraph -- in an updated edition -- will be modified to include a reference to a separate conceptual data model for Amazon SNS. Indeed, the world will be a much better place when all AWS services are graced with the accompaniment of their respective conceptual data models.

Amazon RDS is equipped with features offering AWS customers opportunities for substantial cost reductions associated with running database instances. One such offering is referred to as a reserved instance. A reserved instance is not the same as an actual running database instance. In essence, a reserved instance provides the prospect of (i.e., a reservation for) discounted pricing on one or more actually running or new database instances in exchange for a long term purchase commitment (i.e., reserving a DB instance for a one-year or three-year term) .

So basically, an account purchases reserved instance offerings for price breaks. Each such reservation requests one or more DB instances having a specific instance type, a time period (i.e., the time duration of the reservation, either one year or three years), a payment option (e.g., a full upfront payment), the number of instances to be reserved, etc. The discount on usage charges varies depending on factors such as the instance type, region, database engine, and the selected payment option.

In general, launching a new DB instance in harmony with the specifications of a purchased reserved instance offering (e.g., same DB instance class and engine) enables Amazon RDS to apply the reduced price offering to the new DB instance. That is, for the duration of the reservation, if a DB instance is launched having the same configuration parameters as specified for the reservation, then the reduced pricing applies.

In general, newly launched DB instances whose configuration is not in harmony with a purchased reserved instance offering are billed at the prevailing on-demand rate. In certain cases, however, and for some database engines (e.g., MariaDB, MySQL, etc.), RDS does provide flexibility (i.e., referred to as Size-Flexible Reserved Instances ) for applying reduced pricing to DB instances that are sized differently (i.e., but with the same region, engine, and instance family) from the offered reserved instance size.

Reserved instance discounts can also apply to currently running DB instances that are harmoniously or size-flexibly configured. Purchased reserved instances are automatically applied to the billing of active instances matching the reserved instance configuration. Charges for purchased reserved instances apply whether or not DB instances are actually being used.

From Figure 2.4, the RESERVED INSTANCE OFFERING entity represents the starting point for purchasing reserved instances. The process starts with Amazon RDS providing a list of reserved instance offerings, when a user searches for offerings prior to actually purchasing reserved instances (e.g., via the Amazon RDS console). The one-to-many relationship from the INSTANCE TYPE entity to the RESERVED INSTANCE OFFERING entity indicates that an instance type (i.e., a DB instance class) can be referenced on one or more offerings and that each reserved instance offering identifies a single instance type. The one-to-many relationship from the ENGINE entity to the RESERVED INSTANCE OFFERING entity identifies the database engine for which the reserved instance offering applies. In addition to instance type and engine (i.e., foreign keys), noteworthy attributes of the RESERVED INSTANCE OFFERING entity include:

Each reserved instance offering can spawn one or more reserved instances, as represented by the one-to-many relationship between the RESERVED INSTANCE OFFERING entity and the RESERVED INSTANCE entity. Beyond attributes inferred from its relationship to the RESERVED INSTANCE OFFERING entity, examples of significant attributes of the RESERVED INSTANCE entity include:

The one-to-many relationship between the RESERVED INSTANCE and INSTANCE entities suggests that each reserved instance (i.e., the discounted pricing associated with each reserved instance) can apply to one or more actually running database instances.

Amazon RDS provides automated backups of DB instances and also enables creation of manual (i.e., user initiated) backups. RDS backups, whether automated or user initiated, are referred to as database snapshots . RDS backs up the entire DB instance including all individual databases managed within the database instance. RDS enables both full backups and incremental backups whereby only the data modified since the previous snapshot is copied.

From Figure 2.5, the DB SNAPSHOT entity maintains backup information for both automated and manual backups. The one-to-many relationship between the DB INSTANCE and DB SNAPSHOT entities reveals that many DB snapshots can be maintained for each DB instance. By virtue of its potential need for database recovery, the DB SNAPSHOT entity duplicates crucial DB INSTANCE relationships necessary for accurately restoring a DB instance. These include one-to-many relationships from OPTION GROUP, CUSTOMER MASTER KEY, VPC, AVAILABILITY ZONE, and ENGINE VERSION entities to the DB SNAPSHOT entity. These relationships reflect the essential state of the DB instance at the time of the backup (e.g., the option group, encryption master key, VPC, and availability zone in effect at the time of the snapshot creation).

The one-to-many relationship from the DB SNAPSHOT entity to the EVENT SOURCE entity reflects that snapshots can also be the source for event notifications (i.e., in addition to parameter groups and DB instances). Note also the one-to-many relationship from the DB SNAPSHOT entity to the DB SNAPSHOT PROC FEATURE entity reflecting that snapshots also duplicate DB instance processor features in effect at the time of the backup as provided by the PROCESSOR FEATURE entity and its association with the DB INSTANCE entity. Valid processor features include the core count (i.e., number of CPU cores) and threads per core in effect for the DB instance at the time of the backup .

The one-to-many reflexive relationship from the DB SNAPSHOT entity to itself indicates that a DB snapshot can be copied from another DB snapshot (i.e., a DB snapshot can serve as the source for creating possibly many copies of the source DB snapshot).

Many database engines provide the ability to monitor ongoing database activity and collect monitoring data which is then preserved in database log files . Amazon RDS enables the monitoring of DB instances and collection of data in log files to assist in troubleshooting performance issues. Retrieval and analysis of performance data in log files also promotes an understanding of load conditions and traffic patterns, comparing historical data for contrast with current performance data, and detecting performance trends.

Examples of log files for the MariaDB engine are the error log , slow query log , general log , and audit log . Oracle log files include alert logs , audit files , trace files , and listener log s. Amazon RDS enables access to log files (i.e., for viewing, downloading, etc.) via the Amazon RDS console and API. Amazon RDS also collaborates with Amazon CloudWatch Logs , yet another AWS service, which provides access to log files generated by most database engines.24 RDS database engines can be configured to export their log files to CloudWatch Logs. CloudWatch Logs then enables published log data to be analysed in real-time and provides the ability to create alarms and view metrics. Log files published to CloudWatch Logs can be saved for an unlimited length of time unless a specified retention period has expired. The Amazon RDS console enables choosing the logs to be published to Amazon CloudWatch Logs.

From Figure 2.6, the one-to-many relationship between the ENGINE and LOG TYPE entities reveals that each database engine can support multiple log types. As previously noted, the Oracle engine for example supports alert , audit , trace , and listener log types. The many-to-many relationship between the LOG TYPE and DB INSTANCE entities acknowledges that a DB instance can export many of its engine’s log types to Amazon CloudWatch Logs. Each log type of course can be exported by many DB instances. The one-to-many relationship between the DB INSTANCE and LOG FILE entities reveals that each database instance can generate multiple log files. The one-to-many relationship between the LOG TYPE and LOG FILE entities indicates that each log file is associated with a valid log type. All three RDS user interfaces (i.e., the Amazon RDS console, AWS CLI, and Amazon RDS API) enable access to database log files (i.e., for viewing, downloading, etc.).

Note also the one-to-many relationship between the IAM ROLE and DB INSTANCE entities. IAM refers to AWS Identity and Access Management , another AWS service, which enables customers to maintain authorization information necessary for accessing other AWS services.25 In this case, the IAM role associated with the DB instance permits RDS to send enhanced monitoring metrics (e.g., CPU and memory utilization for RDS processes and OS processes) to Amazon CloudWatch Logs .

RDS Fundamentals: A variety of relational DBMS engines and versions of database engines are supported by RDS (Oracle DB, MySQL, PostgreSQL, Microsoft SQL Server, and MariaDB). Each version of a database engine can support many character sets, one of which can be designated as the default character set. A character set (e.g., UTF8) can be supported by many engine versions. Engine versions that are possible valid targets for upgrade. More specifically, each engine version can possibly be upgraded to many later and greater versions, and an engine version can be the target of many prior engine versions .

A parameter group is a collection of many parameters used for setting up a database. Values are assigned to database parameters such as for time zone, character set, optimization features, audit trails, table cache size, maximum number of processes for parallel execution, categories of database memory (e.g., Oracle’s system global area, SGA). Each parameter can be associated with an initial engine version (i.e., the initial engine version for which the parameter is relevant).

A database engine can support many time zones and a time zone can be supported by many engines. For example, UTC is the default time zone for RDS MySQL and MariaDB databases. For these engines, the time_zone parameter in a parameter group can be set to the specific regional time zone corresponding to the application’s time zone.

An RDS DB instance is a kind of EC2 instance for running isolated database environments. As a kind of EC2 instance, each DB instance inherits an instance type, resides in a subnet, is associated with security groups, etc. Depending on the database engine, each DB instance can support a single database (e.g., an Oracle database with multiple schemas ) or multiple databases (e.g., a Microsoft SQL Server environment). Each DB instance is associated with a single DBMS engine version and a single character set.

Each DB instance can be associated with an alternate availability zone for implementing high availability. RDS provides an option for having a secondary DB instance synchronized with the primary DB instance for failover to the secondary DB instance in this alternate availability zone.

Amazon encryption is provided by the AWS Key Management Service (AWS KMS), which uses customer master keys (CMKs) as the basis for encrypting or decrypting data. Two CMKs are optionally provided (as foreign keys, FKs) to a DB instance -- one is used for encrypting DB instance data, and a second CMK encrypts Performance Insights data for troubleshooting performance problems.

A subnet group within a VPC is a collection of subnets and each subnet can belong to many subnet groups. Each DB instance is associated with a single subnet group for assigning the DB instance to an appropriate subnet. Each subnet group should have subnets dispersed among multiple availability zones to facilitate high availability.

A DB instance can be associated with more than one parameter group (i.e., the currently assigned parameter group can be replaced with a second pending parameter group). A DB instance normally has only one parameter group associated with it.

A primary DB instance serves as the source of data copied to one or more DB instances serving as read replicas (i.e., applicable to MariaDB, MySQL and PostgreSQL). A read replica provides read-only access and alleviates the load on the primary DB instance. Any data updates on the primary DB instance are automatically and asynchronously pushed to its read replicas.

Option Groups and Options: An option group is composed of one or more options with each option having one or more option settings (e.g., Oracle’s “SQLNET.ENCRYPTION TYPES SERVER” option). Each option setting has one or more valid values that are allowed. An engine version can be the major engine version for many option groups. Each option can depend on, or be in conflict with, one or more other options. Each dependent (or conflicted) option can be a prerequisite for (or in conflict with) many other options. A DB instance can be associated with more than one option group (i.e., the currently assigned option group is replaced with a second pendin g option group). An option group is associated with a single VPC and is eligible only to DB instances in the associated VPC.

Event Notification: For DB instances, life events happen that fall into event categories (e.g., “backup”, “failure”, “low storage”, “configuration change”, etc.). Each event category is associated with many source types from which event notifications can potentially be generated. In addition to DB instances, other types of event sources include parameter groups and database backups (aka snapshots). A source type can be associated with many event categories. Each source type is composed of many event sources such as specific DB instances, parameter groups, or snapshots. An event source is optionally either a specific DB instance, parameter group, or snapshot. Each event is generated from a source.

An event subscription enables event notifications from possibly many event categories. An event subscription also indicates the specific sources (e.g., many DB instances) to which the subscription applies. Each event subscription can optionally be associated with a specific source type. If a source type is specified for an event subscription (e.g., the subscription is for DB instances) but no event sources are specified (i.e., no specific DB instances are specified) then event notifications are received for all RDS sources of the specified source type (i.e., all DB instances) belonging to the customer account. Specifying neither a source type nor an event source generates event notifications from all RDS sources (i.e., all DB instances, parameter groups, etc.) belonging to the customer account.

Reserved Database Instances: Amazon RDS enables the purchase of reserved instances -- by providing a list of reserved instance offerings . An instance type (i.e., a DB instance class) can be referenced on one or more offerings and each reserved instance offering identifies a single instance type. Each reserved instance offering applies to a single database engine. Each reserved instance offering purchased by an account can spawn one or more reserved instances. Each reserved instance (i.e., the discounted pricing associated with each reserved instance) can apply to one or more actually running DB instances.

Database Backups: DB snapshots maintain backup information for both automated and manual backups. Many DB snapshots can be maintained for each DB instance. Each DB snapshot duplicates crucial DB instance relationships necessary for accurately restoring a DB instance. These relationships reflect the essential state of the DB instance at the time of the backup (e.g., the option group, encryption master key, VPC, availability zone, etc.) in effect at the time of the snapshot creation). In addition to parameter groups and DB instances, snapshots can also be the source of event notifications. Snapshots also duplicate DB instance processor features in effect at the time of the backup. Valid processor features include the core count (i.e., number of CPU cores) and threads per core in effect for the DB instance at the time of the backup. A DB snapshot can serve as the source for creating possibly many snapshot copies.

Logs and Log Types: Each database engine can support multiple log types (e.g., Oracle supports alert , audit , trace , and listener log types). A DB instance can export many of its engine’s log types to Amazon CloudWatch Logs. Each log type can be exported by many DB instances. Each DB instance can generate multiple log files. Each log file is associated with a valid log type. The Amazon RDS console, AWS CLI, and Amazon RDS API enable access to database log files (i.e., for viewing, downloading, etc.). IAM (AWS Identity and Access Management) enables customers to maintain user authorization information necessary for accessing other AWS services. The IAM role associated with the DB instance permits RDS to send enhanced monitoring metrics (e.g., CPU and memory utilization for RDS processes and OS processes) to Amazon CloudWatch Logs.