# Managing Amazon Neptune Instances
The following sections have information on instance-level operations.
**Topics**
+ [
# Neptune T3 Burstable Instance Class
](manage-console-instances-t3.md)
+ [
# Modifying a Neptune DB Instance (and Applying Immediately)
](manage-console-instances-modify.md)
+ [
# Renaming a Neptune DB Instance
](manage-console-instances-rename.md)
+ [
# Rebooting a DB instance in Amazon Neptune
](manage-console-instances-reboot.md)
+ [
# Deleting a DB Instance in Amazon Neptune
](manage-console-instances-delete.md)
# Neptune T3 Burstable Instance Class
In addition to fixed-performance instance classes such as `R5` and `R6`, Amazon Neptune gives you the option of using a burstable-performance `T3` instance. While you’re developing your graph application, you want your database to be fast and responsive, but you don't need to use it all the time. Neptune's `db.t3.medium` instance class is just what you should use in that situation, at significantly lower cost than the least expensive fixed-performance instance class.
A burstable instance runs at a baseline level of CPU performance until a workload needs more, and then bursts well above the baseline for as long as a workload requires. Its hourly price covers the bursts, provided that the average CPU utilization doesn't exceed the baseline over a 24-hour period. For most development and test situations, that translates to good performance at a low cost.
If you start with a `T3` instance class, you can easily switch later to a fixed-performance instance class when you’re ready to go into production, using the AWS Management Console, AWS CLI, or one of the AWS SDKs.
## T3 Bursting Is Governed by CPU Credits
A CPU credit represents the full utilization of one virtual CPU core (vCPU) for one minute. That can also translate into 50% utilization of a vCPU for two minutes, or 25% utilization of two vCPUs for two minutes, and so on.
A `T3` instance accrues CPU credits when it's idle and uses them up when it's active, both measured at millisecond resolution. The `db.t3.medium` instance class has two vCPUs, each of which earns 12 CPU credits per hour when idle. This means that 20% utilization of each vCPU results in a zero CPU credit balance. The 12 CPU credits earned are spent by 20% utilization of the vCPU (since 20% of 60 minutes is also 12). This 20% utilization is thus the *baseline* utilization rate that produces neither a positive nor negative CPU-credit balance.
Idle time (CPU utilization below 20% of the total available) causes CPU credits to be stored in a credit balance bucket, up to the limit for a `db.t3.medium` instance class of 576 (the maximum number of CPU credits that could be accrued in 24 hours, namely 2 x 12 x 24). Over that limit, CPU credits are simply discarded.
When necessary, CPU utilization can burst to as high as 100% for as long as needed by a workload, even after the CPU credit balance falls below zero. If the instance sustains a negative balance continuously for 24 hours, it incurs an additional charge of \$10.05 for every -60 CPU credits accrued over that period. For most development and test workloads, however, bursting is usually covered by idle time before or after the burst.
**Note**
Neptune's `T3` instance class is configured like the Amazon EC2 [unlimited mode](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances-unlimited-mode.html).
## Using the AWS Management Console to Create a T3 Burstable Instance
In the AWS Management Console, you can create a primary DB cluster instance or a read-replica instance that uses the `db.t3.medium` instance class, or you can modify an existing instance to use the `db.t3.medium` instance class.
For example, to create a new DB cluster primary instance in the Neptune console:
+ Choose **Create Database**.
+ Choose a **DB engine version** equal to or later than `1.0.2.2`.
+ Under **Purpose**, choose **Development and Testing**.
+ As the **DB instance class**, accept the default: `db.t3.medium — 2 vCPU, 4 GiB RAM`.
## Using the AWS CLI to Create a T3 Burstable Instance
You can also use the AWS CLI to do the same thing:
```
aws neptune create-db-cluster \
--db-cluster-identifier (name for a new DB cluster) \
--engine neptune \
--engine-version "1.0.2.2"
aws neptune create-db-instance \
--db-cluster-identifier (name of the new DB cluster) \
--db-instance-identifier (name for the primary writer instance in the cluster) \
--engine neptune \
--db-instance-class db.t3.medium
```
# Modifying a Neptune DB Instance (and Applying Immediately)
You can apply most changes to an Amazon Neptune DB instance immediately or defer them until the next maintenance window. Some modifications, such as parameter group changes, require that you manually reboot your DB instance for the change to take effect.
**Important**
Modifications result in an outage if Neptune must reboot your DB instance for the change to be applied. Review the impact on your database and applications before modifying DB instance settings.
## Common Settings and Downtime Implications
The following table contains details about which settings you can change, when the changes can be applied, and whether the changes cause downtime for the DB instance.
****
| DB instance setting | Downtime notes |
| --- | --- |
| **DB instance class** | An outage occurs during this change, whether it is applied immediately or during the next maintenance window. |
| **DB instance identifier** | The DB instance is rebooted and an outage occurs during this change, whether it is applied immediately or during the next maintenance window. |
| **Subnet group** | The DB instance is rebooted and an outage occurs during this change, whether it is applied immediately or during the next maintenance window. |
| **Security group** | The change is applied asynchronously as soon as possible, regardless of when you specify changes should take place, and no outage results. | – |
| **Certificate Authority** | By default, the DB instance is restarted when you assign a new Certificate Authority. |
| **Database Port** | The change always occurs immediately, causing the DB instance to be rebooted, and an outage occurs. |
| **DB parameter group** | Changing this setting doesn't result in an outage. The parameter group name itself is changed immediately, but the actual parameter changes are not applied until you reboot the instance without failover. In this case, the DB instance isn't rebooted automatically, and the parameter changes aren't applied during the next maintenance window. However, if you modify dynamic parameters in the newly associated DB parameter group, these changes are applied immediately without a reboot. For more information, see [Rebooting a DB instance in Amazon Neptune](manage-console-instances-reboot.md). |
| **DB cluster parameter group** | The DB parameter group name is changed immediately. |
| **Backup retention period** | If you specify that changes should occur immediately, this change does occur immediately. Otherwise, if you change the setting from a nonzero value to another nonzero value, the change is applied asynchronously, as soon as possible. Any other change occurs during the next maintenance window. An outage occurs if you change from zero to a nonzero value, or from a nonzero value to zero. |
| **Audit log** | Select **Audit log** if you want to use audit logging through CloudWatch Logs. You must also set the `neptune_enable_audit_log` parameter in the DB cluster parameter group to `enable` (1) for audit logging to be enabled. |
| **Auto minor version upgrade** | Select **Enable auto minor version upgrade** if you want to enable your Neptune DB cluster to receive minor engine version upgrades automatically when they become available. The *Auto minor version upgrade* option only applies to upgrades to minor engine versions for your Amazon Neptune DB cluster. It doesn't apply to regular patches applied to maintain system stability. |
# Renaming a Neptune DB Instance
You can rename an Amazon Neptune DB instance by using the AWS Management Console. Renaming a DB instance can have far-reaching effects. The following is a list of things you should know before you rename a DB instance.
+ When you rename a DB instance, the endpoint for the DB instance changes because the URL includes the name you assigned to the DB instance. You should always redirect traffic from the old URL to the new one.
+ When you rename a DB instance, the old DNS name that was used by the DB instance is immediately deleted, but it can remain cached for a few minutes. The new DNS name for the renamed DB instance becomes effective after about 10 minutes. The renamed DB instance is not available until the new name becomes effective.
+ You can't use an existing DB instance name when you are renaming an instance.
+ All read replicas that are associated with a DB instance remain associated with that instance after it is renamed. For example, suppose that you have a DB instance that serves your production database, and the instance has several associated read replicas. If you rename the DB instance and then replace it in the production environment with a DB snapshot, the DB instance that you renamed still has the read replicas associated with it.
+ Metrics and events that are associated with the name of a DB instance are maintained if you reuse a DB instance name. For example, if you promote a read replica and rename it to be the name of the previous primary instance, the events and metrics that were associated with the primary instance are then associated with the renamed instance.
+ DB instance tags remain with the DB instance, regardless of renaming.
+ DB snapshots are retained for a renamed DB instance.
**To rename a DB instance using the Neptune console**
1. Sign in to the AWS Management Console, and open the Amazon Neptune console at [https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home).
1. In the navigation pane, choose **Databases**.
1. Choose the radio button next to the DB instance that you want to rename.
1. In the **Instance actions** menu, choose **Modify**.
1. Enter a new name in the **DB instance identifier** text box. Select **Apply immediately**, and then choose **Continue**.
1. Choose **Modify DB instance** to complete the change.
# Rebooting a DB instance in Amazon Neptune
In some cases, if you modify an Amazon Neptune DB instance, change the DB parameter group that is associated with the instance, or change a static DB parameter in a parameter group that the instance uses, you must reboot the instance to apply the changes.
Rebooting a DB instance restarts the database engine service. A reboot also applies to the DB instance any changes to the associated DB parameter group that were pending. Rebooting a DB instance results in a momentary outage of the instance, during which the DB instance status is set to *rebooting*. If the Neptune instance is configured for Multi-AZ, the reboot might be conducted through a failover. A Neptune event is created when the reboot is completed.
If your DB instance is a Multi-AZ deployment, you can force a failover from one Availability Zone to another when you choose the **Reboot** option. When you force a failover of your DB instance, Neptune automatically switches to a standby replica in another Availability Zone. It then updates the DNS record for the DB instance to point to the standby DB instance. As a result, you must clean up and re-establish any existing connections to your DB instance.
**Reboot with failover** is beneficial when you want to simulate a failure of a DB instance for testing or restore operations to the original Availability Zone after a failover occurs. For more information, see [High Availability (Multi-AZ)](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html) in the *Amazon RDS User Guide*. When you reboot a DB cluster, it fails over to the standby replica. Rebooting a Neptune replica does not initiate a failover.
The time required to reboot is a function of the crash recovery process. To improve the reboot time, we recommend that you reduce database activities as much as possible during the reboot process to reduce rollback activity for in-transit transactions.
On the console, the **Reboot** option might be disabled if the DB instance is not in the **Available** state. This can be due to several reasons, such as an in-progress backup, a customer-requested modification, or a maintenance window action.
**Note**
Before [Release: 1.2.0.0 (2022-07-21)](engine-releases-1.2.0.0.md), all the read-replicas in a DB cluster were automatically rebooted whenever the primary (writer) instance restarted.
Starting with [Release: 1.2.0.0 (2022-07-21)](engine-releases-1.2.0.0.md), restarting the primary instance does not cause any of the replicas to restart. This means that if you are changing a cluster parameter, you must restart each instance separately to pick up the parameter change (see [Parameter groups](parameter-groups.md)).
**To reboot a DB instance using the Neptune console**
1. Sign in to the AWS Management Console, and open the Amazon Neptune console at [https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home).
1. In the navigation pane, choose **Databases**.
1. Choose the DB instance that you want to reboot.
1. Choose **Instance actions**, and then choose **Reboot**.
1. To force a failover from one Availability Zone to another, select **Reboot with failover?** in the **Reboot DB Instance** dialog box.
1. Choose **Reboot**. To cancel the reboot, choose **Cancel** instead.
# Deleting a DB Instance in Amazon Neptune
You can delete an Amazon Neptune DB instance in any state and at any time, as long the instance has been started.
**Warning**
If you delete the last remaining instance in a cluster using the **web console**, it will also delete the underlying cluster storage volume.
## Taking a Final Snapshot of Your DB Instance Before Deleting It
To delete a DB instance, you must specify the name of the instance and whether you want to have a final DB snapshot taken of the instance. If the DB instance that you're deleting has a status of **Creating**, you can't have a final DB snapshot taken. If the DB instance is in a failure state with a status of **failed**, **incompatible-restore**, or **incompatible-network**, you can only delete the instance when the `SkipFinalSnapshot` parameter is set to `true`.
If you delete all Neptune DB instances in a DB cluster using the AWS Management Console, the entire DB cluster is deleted automatically. If you are using the AWS CLI or SDK, you must delete the DB cluster manually after you delete the last instance.
**Important**
If you delete an entire DB cluster, all its automated backups are deleted at the same time, and cannot be recovered. This means that unless you choose to create a final DB snapshot manually, you can't restore the DB instance to its final state at a later time. Manual snapshots of an instance are not deleted when the cluster is deleted.
If the DB instance that you want to delete has a read replica, you should either promote the read replica or delete it.
In the following examples, you delete a DB instance both with and without a final DB snapshot.
## Deleting a DB Instance with No Final Snapshot
If you want to quickly delete a DB instance, you can skip creating a final DB snapshot. When you delete a DB instance, all automated backups are deleted and cannot be recovered. Manual snapshots are not deleted.
**To delete a DB instance with no final DB snapshot using the Neptune console**
1. Sign in to the AWS Management Console, and open the Amazon Neptune console at [https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home).
1. In the navigation pane, choose **Databases**.
1. In the **Instances** list, choose the radio button next to the DB instance that you want to delete.
1. Choose **Instance actions**, and then choose **Delete**.
1. Choose **No** in the **Create final snapshot?** box.
1. Choose **Delete**.
## Deleting a DB Instance with a Final Snapshot
If you want to be able to restore a deleted DB instance at a later time, you can create a final DB snapshot. All automated backups are also deleted and cannot be recovered. Manual snapshots are not deleted.
**To delete a DB instance with a final DB snapshot using the Neptune console**
1. Sign in to the AWS Management Console, and open the Amazon Neptune console at [https://console.aws.amazon.com/neptune/home](https://console.aws.amazon.com/neptune/home).
1. In the navigation pane, choose **Databases**.
1. In the **Instances** list, choose the radio button next to the DB instance that you want to delete.
1. Choose **Instance actions**, and then choose **Delete**.
1. Choose **Yes** in the **Create final snapshot?** box.
1. In the **Final snapshot name** box, enter the name of your final DB snapshot.
1. Choose **Delete**.
You can check the health of an instance, determine what kind of instance it is, find out which engine release version you currently have installed, and obtain other information about an instance using the [instance-status API](access-graph-status.md).