Menu
Amazon Relational Database Service
User Guide (API Version 2014-10-31)

Troubleshooting

The following sections can help you troubleshoot problems you have with Amazon RDS.

Cannot Connect to Amazon RDS DB Instance

When you cannot connect to a DB instance, the following are common causes:

  • The access rules enforced by your local firewall and the ingress IP addresses that you authorized to access your DB instance in the instance's security group are not in sync. The problem is most likely the ingress rules in your security group. By default, DB instances do not allow access; access is granted through a security group. To grant access, you must create your own security group with specific ingress and egress rules for your situation. For more information about setting up a security group, see Provide Access to the DB Instance in the VPC by Creating a Security Group.

  • The port you specified when you created the DB instance cannot be used to send or receive communications due to your local firewall restrictions. In this case, check with your network administrator to determine if your network allows the specified port to be used for inbound and outbound communication.

  • Your DB instance is still being created and is not yet available. Depending on the size of your DB instance, it can take up to 20 minutes before an instance is available.

Testing a Connection to an Amazon RDS DB Instance

You can test your connection to a DB instance using common Linux or Windows tools.

From a Linux or Unix terminal, you can test the connection by typing the following (replace <DB-instance-endpoint> with the endpoint and <port> with the port of your DB instance):

Copy
$nc -zv <DB-instance-endpoint> <port>

For example, the following shows a sample command and the return value:

Copy
$nc -zv postgresql1.c6c8mn7tsdgv0.us-west-2.rds.amazonaws.com 8299 Connection to postgresql1.c6c8mn7tsdgv0.us-west-2.rds.amazonaws.com 8299 port [tcp/vvr-data] succeeded!

Windows users can use Telnet to test the connection to a DB instance. Note that Telnet actions are not supported other than for testing the connection. If a connection is successful, the action returns no message. If a connection is not successful, you receive an error message such as the following:

Copy
C:\>telnet sg-postgresql1.c6c8mntzhgv0.us-west-2.rds.amazonaws.com 819 Connecting To sg-postgresql1.c6c8mntzhgv0.us-west-2.rds.amazonaws.com...Could not open connection to the host, on port 819: Connect failed

If Telnet actions return success, your security group is properly configured.

Troubleshooting Connection Authentication

If you can connect to your DB instance but you get authentication errors, you might want to reset the master user password for the DB instance. You can do this by modifying the RDS instance; for more information, see one of the following topics:

Amazon RDS Security Issues

To avoid security issues, never use your master AWS user name and password for a user account. Best practice is to use your master AWS account to create IAM users and assign those to DB user accounts. You can also use your master account to create other user accounts, if necessary. For more information on creating IAM users, see Create an IAM User.

Error Message "Failed to retrieve account attributes, certain console functions may be impaired."

There are several reasons you would get this error; it could be because your account is missing permissions, or your account has not been properly set up. If your account is new, you may not have waited for the account to be ready. If this is an existing account, you could lack permissions in your access policies to perform certain actions such as creating a DB instance. To fix the issue, your IAM administrator needs to provide the necessary roles to your account. For more information, see the IAM documentation.

Resetting the DB Instance Owner Role Password

You can reset the assigned permissions for your DB instance by resetting the master password. For example, if you lock yourself out of the db_owner role on your SQL Server database, you can reset the db_owner role password by modifying the DB instance master password. By changing the DB instance password, you can regain access to the DB instance, access databases using the modified password for the db_owner, and restore privileges for the db_owner role that may have been accidentally revoked. You can change the DB instance password by using the Amazon RDS console, the AWS CLI command modify-db-instance, or by using the ModifyDBInstance action. For more information about modifying a SQL Server DB instance, see Modifying a DB Instance Running the Microsoft SQL Server Database Engine.

Amazon RDS DB Instance Outage or Reboot

A DB instance outage can occur when a DB instance is rebooted, when the DB instance is put into a state that prevents access to it, and when the database is restarted. A reboot can occur when you manually reboot your DB instance or when you change a DB instance setting that requires a reboot before it can take effect.  

When you modify a setting for a DB instance, you can determine when the change is applied by using the Apply Immediately setting. To see a table that shows DB instance actions and the effect that setting the Apply Immediately value has, see Modifying an Amazon RDS DB Instance and Using the Apply Immediately Parameter.  

A DB instance reboot only occurs when you change a setting that requires a reboot, or when you manually cause a reboot. A reboot can occur immediately if you change a setting and request that the change take effect immediately or it can occur during the DB instance's maintenance window.

A DB instance reboot occurs immediately when one of the following occurs:

  • You change the backup retention period for a DB instance from 0 to a nonzero value or from a nonzero value to 0 and set Apply Immediately to true.

  • You change the DB instance class, and Apply Immediately is set to true.

  • You change the storage type from Magnetic (Standard) to General Purpose (SSD) or Provisioned IOPS (SSD), or from Provisioned IOPS (SSD) or General Purpose (SSD) to Magnetic (Standard). from standard to PIOPS.

A DB instance reboot occurs during the maintenance window when one of the following occurs:

  • You change the backup retention period for a DB instance from 0 to a nonzero value or from a nonzero value to 0, and Apply Immediately is set to false.

  • You change the DB instance class, and Apply Immediately is set to false.

When you change a static parameter in a DB parameter group, the change will not take effect until the DB instance associated with the parameter group is rebooted. The change requires a manual reboot; the DB instance will not automatically be rebooted during the maintenance window.

Amazon RDS DB Parameter Changes Not Taking Effect

If you change a parameter in a DB parameter group but you don't see the changes take effect, you most likely need to reboot the DB instance associated with the DB parameter group. When you change a dynamic parameter, the change takes effect immediately; when you change a static parameter, the change won't take effect until you reboot the DB instance associated with the parameter group.

You can reboot a DB instance using the RDS console or explicitly calling the RebootDbInstance API action (without failover, if the DB instance is in a Multi-AZ deployment). The requirement to reboot the associated DB instance after a static parameter change helps mitigate the risk of a parameter misconfiguration affecting an API call, such as calling ModifyDBInstance to change DB instance class or scale storage. For more information, see Modifying Parameters in a DB Parameter Group.

Amazon RDS DB Instance Running Out of Storage

If your DB instance runs out of storage space, it might no longer be available. We highly recommend that you constantly monitor the FreeStorageSpace metric published in CloudWatch to ensure that your DB instance has enough free storage space.

If your database instance runs out of storage, its status will change to storage-full. For example, a call to the DescribeDBInstances action for a DB instance that has used up its storage will output the following:

Copy
aws rds describe-db-instances --db-instance-identifier mydbinstance DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m3.large mysql5.6 50 sa storage-full mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 SECGROUP default active PARAMGRP default.mysql5.6 in-sync

To recover from this scenario, add more storage space to your instance using the ModifyDBInstance action or the following AWS CLI command:

For Linux, OS X, or Unix:

Copy
aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --allocated-storage 60 \ --apply-immediately

For Windows:

Copy
aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --allocated-storage 60 ^ --apply-immediately
Copy
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m3.large mysql5.6 50 sa storage-full mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 60 SECGROUP default active PARAMGRP default.mysql5.6 in-sync

Now, when you describe your DB instance, you will see that your DB instance will have modifying status, which indicates the storage is being scaled.

Copy
aws rds describe-db-instances --db-instance-identifier mydbinstance
Copy
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m3.large mysql5.6 50 sa modifying mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 60 SECGROUP default active PARAMGRP default.mysql5.6 in-sync

Once storage scaling is complete, your DB instance status will change to available.

Copy
aws rds describe-db-instances --db-instance-identifier mydbinstance
Copy
DBINSTANCE mydbinstance 2009-12-22T23:06:11.915Z db.m3.large mysql5.6 60 sa available mydbinstance.clla4j4jgyph.us-east-1.rds.amazonaws.com 3306 us-east-1b 3 SECGROUP default active PARAMGRP default.mysql5.6 in-sync

Note that you can receive notifications when your storage space is exhausted using the DescribeEvents action. For example, in this scenario, if you do a DescribeEvents call after these operations you will see the following output:

Copy
aws rds describe-events --source-type db-instance --source-identifier mydbinstance
Copy
2009-12-22T23:44:14.374Z mydbinstance Allocated storage has been exhausted db-instance 2009-12-23T00:14:02.737Z mydbinstance Applying modification to allocated storage db-instance 2009-12-23T00:31:54.764Z mydbinstance Finished applying modification to allocated storage

Amazon RDS Insufficient DB Instance Capacity

If you get an InsufficientDBInstanceCapacity error when you try to modify a DB instance class, it might be because the DB instance is on the EC2-Classic platform and is therefore not in a VPC. Some DB instance classes require a VPC. For example, if you are on the EC2-Classic platform and try to increase capacity by switching to a DB instance class that requires a VPC, this error results. For information about Amazon Elastic Compute Cloud instance types that are only available in a VPC, see Instance Types Available Only in a VPC in the Amazon Elastic Compute Cloud User Guide.

To correct the problem, you can move the DB instance into a VPC. For more information, see Moving a DB Instance Not in a VPC into a VPC.

For information about modifying a DB instance, see Modifying an Amazon RDS DB Instance and Using the Apply Immediately Parameter. For information about troubleshooting instance capacity issues for Amazon EC2, see Troubleshooting Instance Capacity in the Amazon Elastic Compute Cloud User Guide.

Amazon RDS MySQL and MariaDB Issues

Index Merge Optimization Returns Wrong Results

This issue applies only to MySQL DB instances.

Queries that use index merge optimization might return wrong results due to a bug in the MySQL query optimizer that was introduced in MySQL 5.5.37. When you issue a query against a table with multiple indexes the optimizer scans ranges of rows based on the multiple indexes, but does not merge the results together correctly. For more information on the query optimizer bug, go to http://bugs.mysql.com/bug.php?id=72745 and http://bugs.mysql.com/bug.php?id=68194 in the MySQL bug database.

For example, consider a query on a table with two indexes where the search arguments reference the indexed columns.

Copy
SELECT * FROM table1 WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';

In this case, the search engine searches both indexes. However, due to the bug, the merged results are incorrect.

To resolve this issue, you can do one of the following:

  • Set the optimizer_switch parameter to index_merge=off in the DB parameter group for your MySQL DB instance. For information on setting DB parameter group parameters, see Working with DB Parameter Groups.

  • Upgrade your MySQL DB instance to MySQL version 5.6 or 5.7. For more information, see Upgrading a MySQL DB Snapshot.

  • If you cannot upgrade your instance or change the optimizer_switch parameter, you can work around the bug by explicitly identifying an index for the query, for example:

    Copy
    SELECT * FROM table1 USE INDEX covering_index WHERE indexed_col1 = 'value1' AND indexed_col2 = 'value2';

For more information, go to Index Merge Optimization.

Diagnosing and Resolving Lag Between Read Replicas

After you create a MySQL or MariaDB Read Replica and the Read Replica is available, Amazon RDS first replicates the changes made to the source DB instance from the time the create Read Replica operation was initiated. During this phase, the replication lag time for the Read Replica will be greater than 0. You can monitor this lag time in Amazon CloudWatch by viewing the Amazon RDS ReplicaLag metric.

The ReplicaLag metric reports the value of the Seconds_Behind_Master field of the MySQL or MariaDB SHOW SLAVE STATUS command. For more information, see SHOW SLAVE STATUS. When the ReplicaLag metric reaches 0, the replica has caught up to the source DB instance. If the ReplicaLag metric returns -1, replication might not be active. To troubleshoot a replication error, see Diagnosing and Resolving a MySQL or MariaDB Read Replication Failure. A ReplicaLag value of -1 can also mean that the Seconds_Behind_Master value cannot be determined or is NULL.

The ReplicaLag metric returns -1 during a network outage or when a patch is applied during the maintenance window. In this case, wait for network connectivity to be restored or for the maintenance window to end before you check the ReplicaLag metric again.

Because the MySQL and MariaDB read replication technology is asynchronous, you can expect occasional increases for the BinLogDiskUsage metric on the source DB instance and for the ReplicaLag metric on the Read Replica. For example, a high volume of write operations to the source DB instance can occur in parallel, while write operations to the Read Replica are serialized using a single I/O thread, can lead to a lag between the source instance and Read Replica. For more information about Read Replicas and MySQL, go to Replication Implementation Details in the MySQL documentation. For more information about Read Replicas and MariaDB, go to Replication Overview in the MariaDB documentation.

You can reduce the lag between updates to a source DB instance and the subsequent updates to the Read Replica by doing the following:

  • Set the DB instance class of the Read Replica to have a storage size comparable to that of the source DB instance.

  • Ensure that parameter settings in the DB parameter groups used by the source DB instance and the Read Replica are compatible. For more information and an example, see the discussion of the max_allowed_packet parameter in the next section.

  • Disable the query cache. For tables that are modified often, using the query cache can increase replica lag because the cache is locked and refreshed often. If this is the case, you might see less replica lag if you disable the query cache. You can disable the query cache by setting the query_cache_type parameter to 0 in the DB parameter group for the DB instance. For more information on the query cache, see Query Cache Configuration.

  • Warm the InnoDB for MySQL or XtraDB for MariaDB buffer pool on the Read Replica. If you have a small set of tables that are being updated often, and you are using the InnoDB or XtraDB table schema, then dump those tables on the Read Replica. Doing this causes the database engine to scan through the rows of those tables from the disk and then cache them in the buffer pool, which can reduce replica lag. The following shows an example.

    For Linux, OS X, or Unix:

    Copy
    PROMPT> mysqldump \ –h <endpoint> \ --port=<port> \ -u=<username> \ -p <password> \ database_name table1 table2 > /dev/null

    For Windows:

    Copy
    PROMPT> mysqldump ^ –h <endpoint> ^ --port=<port> ^ -u=<username> ^ -p <password> ^ database_name table1 table2 > /dev/null

Diagnosing and Resolving a MySQL or MariaDB Read Replication Failure

Amazon RDS monitors the replication status of your Read Replicas and updates the Replication State field of the Read Replica instance to Error if replication stops for any reason. You can review the details of the associated error thrown by the MySQL or MariaDB engines by viewing the Replication Error field. Events that indicate the status of the Read Replica are also generated, including RDS-EVENT-0045, RDS-EVENT-0046, and RDS-EVENT-0047. For more information about events and subscribing to events, see Using Amazon RDS Event Notification. If a MySQL error message is returned, review the error in the MySQL error message documentation. If a MariaDB error message is returned, review the error in the MariaDB error message documentation.

Common situations that can cause replication errors include the following:

  • The value for the max_allowed_packet parameter for a Read Replica is less than the max_allowed_packet parameter for the source DB instance.

    The max_allowed_packet parameter is a custom parameter that you can set in a DB parameter group that is used to specify the maximum size of data manipulation language (DML) that can be executed on the database. If the max_allowed_packet parameter value for the source DB instance is smaller than the max_allowed_packet parameter value for the Read Replica, the replication process can throw an error and stop replication. The most common error is packet bigger than 'max_allowed_packet' bytes. You can fix the error by having the source and Read Replica use DB parameter groups with the same max_allowed_packet parameter values.

  • Writing to tables on a Read Replica. If you are creating indexes on a Read Replica, you need to have the read_only parameter set to 0 to create the indexes. If you are writing to tables on the Read Replica, it can break replication.

  • Using a non-transactional storage engine such as MyISAM. Read replicas require a transactional storage engine. Replication is only supported for the InnoDB for MySQL and XtraDB for MariaDB storage engines.

    You can convert a MyISAM table to InnoDB with the following command:

    alter table <schema>.<table_name> engine=innodb;

  • Using unsafe non-deterministic queries such as SYSDATE(). For more information, see Determination of Safe and Unsafe Statements in Binary Logging.

The following steps can help resolve your replication error:

  • If you encounter a logical error and you can safely skip the error, follow the steps described in Skipping the Current Replication Error. Your MySQL or MariaDB DB instance must be running a version that includes the mysql_rds_skip_repl_error procedure. For more information, see mysql.rds_skip_repl_error.

  • If you encounter a binlog position issue, you can change the slave replay position with the mysql_rds_next_master_log command. Your MySQL or MariaDB DB instance must be running a version that supports the mysql_rds_next_master_log command in order to change the slave replay position. For version information, see mysql.rds_next_master_log.

  • If you encounter a temporary performance issue due to high DML load, you can set the innodb_flush_log_at_trx_commit parameter to 2 in the DB parameter group on the Read Replica. Doing this can help the Read Replica catch up, though it temporarily reduces atomicity, consistency, isolation, and durability (ACID).

  • You can delete the Read Replica and create an instance using the same DB instance identifier so that the endpoint remains the same as that of your old Read Replica.

If a replication error is fixed, the Replication State changes to replicating. For more information, see Troubleshooting a MySQL or MariaDB Read Replica Problem.

Creating Triggers with Binary Logging Enabled Requires SUPER Privilege

When trying to create triggers in an RDS MySQL or MariaDB DB instance, you might receive the following error:

Copy
"You do not have the SUPER privilege and binary logging is enabled"

To use triggers when binary logging is enabled requires the SUPER privilege, which is restricted for RDS MySQL and MariaDB DB instances. You can create triggers when binary logging is enabled without the SUPER privilege by setting the log_bin_trust_function_creators parameter to true. To set the log_bin_trust_function_creators to true, create a new DB parameter group or modify an existing DB parameter group.

To create a new DB parameter group that allows you to create triggers in your RDS MySQL or MariaDB DB instance with binary logging enabled, use the following CLI commands. To modify an existing parameter group, start with step 2.

To create a new parameter group to allow triggers with binary logging enabled using the CLI

  1. Create a new parameter group.

    For Linux, OS X, or Unix:

    Copy
    aws rds create-db-parameter-group \ --db-parameter-group-name allow-triggers \ --db-parameter-group-family mysql15.5 \ --description "parameter group allowing triggers"

    For Windows:

    Copy
    aws rds create-db-parameter-group ^ --db-parameter-group-name allow-triggers ^ --db-parameter-group-family mysql15.5 ^ --description "parameter group allowing triggers"
  2. Modify the DB parameter group to allow triggers.

    For Linux, OS X, or Unix:

    Copy
    aws rds modify-db-parameter-group \ --db-parameter-group-name allow-triggers \ --parameters "name=log_bin_trust_function_creators,value=true, method=pending-reboot"

    For Windows:

    Copy
    aws rds modify-db-parameter-group ^ --db-parameter-group-name allow-triggers ^ --parameters "name=log_bin_trust_function_creators,value=true, method=pending-reboot"
  3. Modify your DB instance to use the new DB parameter group.

    For Linux, OS X, or Unix:

    Copy
    aws rds modify-db-instance \ --db-instance-identifier mydbinstance \ --db-parameter-group-name allow-triggers \ --apply-immediately

    For Windows:

    Copy
    aws rds modify-db-instance ^ --db-instance-identifier mydbinstance ^ --db-parameter-group-name allow-triggers ^ --apply-immediately
  4. In order for the changes to take effect, manually reboot the DB instance.

    Copy
    aws rds reboot-db-instance mydbinstance

Diagnosing and Resolving Point-In-Time Restore Failures

Restoring a DB Instance That Includes Temporary Tables

When attempting a Point-In-Time Restore (PITR) of your MySQL or MariaDB DB instance, you might encounter the following error:

Copy
Database instance could not be restored because there has been incompatible database activity for restore functionality. Common examples of incompatible activity include using temporary tables, in-memory tables, or using MyISAM tables. In this case, use of Temporary table was detected.

PITR relies on both backup snapshots and binlogs from MySQL or MariaDB to restore your DB instance to a particular time. Temporary table information can be unreliable in binlogs and can cause a PITR failure. If you use temporary tables in your MySQL or MariaDB DB instance, you can minimize the possibility of a PITR failure by performing more frequent backups. A PITR failure is most probable in the time between a temporary table's creation and the next backup snapshot.

Restoring a DB Instance That Includes In-Memory Tables

You might encounter a problem when restoring a database that has in-memory tables. In-memory tables are purged during a restart. As a result, your in-memory tables might be empty after a reboot. We recommend that when you use in-memory tables, you architect your solution to handle empty tables in the event of a restart. If you are using in-memory tables with replicated DB instances, you might need to recreate the Read Replicas after a restart if a Read Replica reboots and is unable to restore data from an empty in-memory table.

For more information about backups and PITR, see Working With Backups and Restoring a DB Instance to a Specified Time.

Slave Down or Disabled Error

When you call the mysql.rds_skip_repl_error command, you might receive the following error message: Slave is down or disabled.

This error message appears because replication has stopped and could not be restarted.

If you need to skip a large number of errors, the replication lag can increase beyond the default retention period for binary log files. In this case, you might encounter a fatal error due to binary log files being purged before they have been replayed on the replica. This purge causes replication to stop, and you can no longer call the mysql.rds_skip_repl_error command to skip replication errors.

You can mitigate this issue by increasing the number of hours that binary log files are retained on your replication master. After you have increased the binlog retention time, you can restart replication and call the mysql.rds_skip_repl_error command as needed.

To set the binlog retention time, use the mysql.rds_set_configuration procedure and specify a configuration parameter of 'binlog retention hours' along with the number of hours to retain binlog files on the DB cluster, up to 720 (30 days). The following example sets the retention period for binlog files to 48 hours:

Copy
CALL mysql.rds_set_configuration('binlog retention hours', 48);

Read Replica Create Fails or Replication Breaks With Fatal Error 1236

After changing default parameter values for a MySQL or MariaDB DB instance, you might encounter one of the following problems:

  • You are unable to create a Read Replica for the DB instance.

  • Replication fails with fatal error 1236.

Some default parameter values for MySQL or MariaDB DB instances help to ensure the database is ACID compliant and Read Replicas are crash-safe by making sure that each commit is fully synchronized by writing the transaction to the binary log before it is committed. Changing these parameters from their default values to improve performance can cause replication to fail when a transaction has not been written to the binary log.

To resolve this issue, set the following parameter values:

  • sync-binlog = 1

  • innodb_support_xa = 1

  • innodb_flush_log_at_trx_commit = 1

Amazon Aurora Issues

No Space Left on Device Error

You might encounter the following error message from Amazon Aurora:

Copy
ERROR 3 (HY000): Error writing file '/rdsdbdata/tmp/XXXXXXXX' (Errcode: 28 - No space left on device)

Each DB instance in an Amazon Aurora DB cluster uses local SSD storage to store temporary tables for a session. This local storage for temporary tables does not autogrow like the Aurora cluster volume. Instead, the amount of local storage is limited. The limit is based on the DB instance class for DB instances in your DB cluster. To find the amount of local SSD storage for R3 DB instance types, go to Memory Optimized R3 instances.

If your workload cannot be modified to reduce the amount temporary storage required, then you can scale your DB instances up to use a DB instance class that has more local SSD storage.

Amazon RDS Oracle GoldenGate Issues

Retaining Logs for Sufficient Time

The source database must retain archived redo logs. The duration for log retention is specified in hours. The duration should exceed any potential downtime of the source instance or any potential period of communication or networking issues for the source instance, so that Oracle GoldenGate can recover logs from the source instance as needed. The absolute minimum value required is one (1) hour of logs retained. If you don't have log retention enabled, or if the retention value is too small, you will receive the following message:

Copy
2014-03-06 06:17:27 ERROR OGG-00446 error 2 (No such file or directory) opening redo log /rdsdbdata/db/GGTEST3_A/onlinelog/o1_mf_2_9k4bp1n6_.log for sequence 1306Not able to establish initial position for begin time 2014-03-06 06:16:55.

Cannot Connect to Amazon RDS SQL Server DB Instance

When you have problems connecting to a DB instance using SQL Server Management Studio, the following are some common causes:

  • The access rules enforced by your local firewall and the IP addresses you authorized to access your DB instance in the instance's security group are not in sync. If you use your DB instance’s endpoint and port with Microsoft SQL Server Management Studio and cannot connect, the problem is most likely the egress or ingress rules on your firewall. To grant access, you must create your own security group with specific ingress and egress rules for your situation. For more information about security groups, see Amazon RDS Security Groups.

  • The port you specified when you created the DB instance cannot be used to send or receive communications due to your local firewall restrictions. In this case, check with your network administrator to determine if your network allows the specified port to be used for inbound and outbound communication.

  • Your DB instance is still being created and is not yet available. Depending on the size of your DB instance, it can take up to 20 minutes before an instance is available.

If you can send and receive communications through the port you specified, check for the following SQL Server errors:

  • Could not open a connection to SQL Server - Microsoft SQL Server, Error: 53 – You must include the port number when you specify the server name when using Microsoft SQL Server Management Studio. For example, the server name for a DB instance (including the port number) might be: sqlsvr-pdz.c6c8mdfntzgv0.region.rds.amazonaws.com,1433.

  • No connection could be made because the target machine actively refused it - Microsoft SQL Server, Error: 10061 – In this case, you reached the DB instance but the connection was refused. This error is often caused by an incorrect user name or password.

Cannot Connect to Amazon RDS PostgreSQL DB Instance

The most common problem when attempting to connect to a PostgreSQL DB instance is that the security group assigned to the DB instance has incorrect access rules. By default, DB instances do not allow access; access is granted through a security group. To grant access, you must create your own security group with specific ingress and egress rules for your situation. For more information about creating a security group for your DB instance, see Provide Access to the DB Instance in the VPC by Creating a Security Group.

The most common error is could not connect to server: Connection timed out. If you receive this error, check that the host name is the DB instance endpoint and that the port number is correct. Check that the security group assigned to the DB instance has the necessary rules to allow access through your local firewall.