{
	"id": "0ff9b6c0-35f8-4e2b-93fa-02496e64a707",
	"created_at": "2026-04-06T00:10:08.730751Z",
	"updated_at": "2026-04-10T03:37:26.286104Z",
	"deleted_at": null,
	"sha1_hash": "b571fa3556fd731514097d083b7ef40848346b1c",
	"title": "Working with a DB instance in a VPC",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 130023,
	"plain_text": "Working with a DB instance in a VPC\r\nArchived: 2026-04-05 15:37:42 UTC\r\nYour DB instance is in a virtual private cloud (VPC). A VPC is a virtual network that is logically isolated from\r\nother virtual networks in the AWS Cloud. Amazon VPC makes it possible for you to launch AWS resources, such\r\nas an Amazon RDS DB instance or Amazon EC2 instance, into a VPC. The VPC can either be a default VPC that\r\ncomes with your account or one that you create. All VPCs are associated with your AWS account.\r\nYour default VPC has three subnets that you can use to isolate resources inside the VPC. The default VPC also has\r\nan internet gateway that can be used to provide access to resources inside the VPC from outside the VPC.\r\nFor a list of scenarios involving Amazon RDS DB instances in a VPC and outside of a VPC, see Scenarios for\r\naccessing a DB instance in a VPC.\r\nTopics\r\nWorking with a DB instance in a VPC\r\nVPC encryption control\r\nWorking with DB subnet groups\r\nShared subnets\r\nAmazon RDS IP addressing\r\nHiding a DB instance in a VPC from the internet\r\nCreating a DB instance in a VPC\r\nIn the following tutorials, you can learn to create a VPC that you can use for a common Amazon RDS scenario:\r\nTutorial: Create a VPC for use with a DB instance (IPv4 only)\r\nTutorial: Create a VPC for use with a DB instance (dual-stack mode)\r\nWorking with a DB instance in a VPC\r\nHere are some tips on working with a DB instance in a VPC:\r\nYour VPC must have at least two subnets. These subnets must be in two different Availability Zones in the\r\nAWS Region where you want to deploy your DB instance. A subnet is a segment of a VPC's IP address\r\nrange that you can specify and that you can use to group DB instances based on your security and\r\noperational needs.\r\nhttps://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html\r\nPage 1 of 13\n\nFor Multi-AZ deployments, defining a subnet for two or more Availability Zones in an AWS Region allows\r\nAmazon RDS to create a new standby in another Availability Zone as needed. Make sure to do this even\r\nfor Single-AZ deployments, just in case you want to convert them to Multi-AZ deployments at some point.\r\nNote\r\nThe DB subnet group for a Local Zone can have only one subnet.\r\nIf you want your DB instance in the VPC to be publicly accessible, make sure to turn on the VPC attributes\r\nDNS hostnames and DNS resolution.\r\nYour VPC must have a DB subnet group that you create. You create a DB subnet group by specifying the\r\nsubnets you created. Amazon RDS chooses a subnet and an IP address within that subnet group to associate\r\nwith your DB instance. The DB instance uses the Availability Zone that contains the subnet.\r\nYour VPC must have a VPC security group that allows access to the DB instance.\r\nFor more information, see Scenarios for accessing a DB instance in a VPC.\r\nThe CIDR blocks in each of your subnets must be large enough to accommodate spare IP addresses for\r\nAmazon RDS to use during maintenance activities, including failover and compute scaling. For example, a\r\nrange such as 10.0.0.0/24 and 10.0.1.0/24 is typically large enough.\r\nA VPC can have an instance tenancy attribute of either default or dedicated. All default VPCs have the\r\ninstance tenancy attribute set to default, and a default VPC can support any DB instance class.\r\nIf you choose to have your DB instance in a dedicated VPC where the instance tenancy attribute is set to\r\ndedicated, the DB instance class of your DB instance must be one of the approved Amazon EC2 dedicated\r\ninstance types. For example, the r5.large EC2 dedicated instance corresponds to the db.r5.large DB\r\ninstance class. For information about instance tenancy in a VPC, see Dedicated instances in the Amazon\r\nElastic Compute Cloud User Guide.\r\nFor more information about the instance types that can be in a dedicated instance, see Amazon EC2\r\ndedicated instances on the Amazon EC2 pricing page.\r\nNote\r\nWhen you set the instance tenancy attribute to dedicated for a DB instance, it doesn't guarantee that the DB\r\ninstance will run on a dedicated host.\r\nWhen an option group is assigned to a DB instance, it's associated with the DB instance's VPC. This\r\nlinkage means that you can't use the option group assigned to a DB instance if you attempt to restore the\r\nDB instance into a different VPC.\r\nIf you restore a DB instance into a different VPC, make sure to either assign the default option group to the\r\nDB instance, assign an option group that is linked to that VPC, or create a new option group and assign it\r\nto the DB instance. With persistent or permanent options, such as Oracle TDE, you must create a new\r\nhttps://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html\r\nPage 2 of 13\n\noption group that includes the persistent or permanent option when restoring a DB instance into a different\r\nVPC.\r\nVPC encryption control\r\nVPC encryption controls allow you to enforce encryption-in-transit for all network traffic within your VPCs. Use\r\nencryption control to meet regulatory compliance requirements by ensuring that only encryption-capable Nitro-based hardware can be provisioned in designated VPCs. Encryption control also catches compatibility issues at\r\nAPI request time rather than during provisioning. Your existing workloads continue operating and only new\r\nincompatible requests are blocked.\r\nSet your VPC encryption controls by setting the VPC control mode to :\r\ndisabled (default)\r\nmonitor\r\nenforced\r\nTo check the current control mode for your VPC, use the AWS Management Console or DescribeVpcs CLI or API\r\ncommand.\r\nIf your VPC enforces encryption, you can only provision Nitro-based DB instances that support encryption in\r\ntransit in that VPC. For more information see, DB instance class types. For information about Nitro instances, see\r\nInstances built on the AWS Nitro System in the Amazon EC2 User Guide.\r\nNote\r\nIf you try to provision incompatible DB instances in an encryption-enforced VPC, Amazon RDS returns a\r\nVpcEncryptionControlViolationException exception.\r\nWorking with DB subnet groups\r\nSubnets are segments of a VPC's IP address range that you designate to group your resources based on security\r\nand operational needs. A DB subnet group is a collection of subnets (typically private) that you create in a VPC\r\nand that you then designate for your DB instances. By using a DB subnet group, you can specify a particular VPC\r\nwhen creating DB instances using the AWS CLI or RDS API. If you use the console, you can choose the VPC and\r\nsubnet groups you want to use.\r\nEach DB subnet group should have subnets in at least two Availability Zones in a given AWS Region. When\r\ncreating a DB instance in a VPC, you choose a DB subnet group for it. From the DB subnet group, Amazon RDS\r\nchooses a subnet and an IP address within that subnet to associate with the DB instance. The DB uses the\r\nAvailability Zone that contains the subnet. Amazon RDS always assigns an IP address from a subnet that has free\r\nIP address space.\r\nhttps://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html\r\nPage 3 of 13\n\nIf the primary DB instance of a Multi-AZ deployment fails, Amazon RDS can promote the corresponding standby\r\nand later create a new standby using an IP address of the subnet in one of the other Availability Zones.\r\nThe subnets in a DB subnet group are either public or private. The subnets are public or private, depending on the\r\nconfiguration that you set for their network access control lists (network ACLs) and routing tables. For a DB\r\ninstance to be publicly accessible, all of the subnets in its DB subnet group must be public. If a subnet that's\r\nassociated with a publicly accessible DB instance changes from public to private, it can affect DB instance\r\navailability.\r\nTo create a DB subnet group that supports dual-stack mode, make sure that each subnet that you add to the DB\r\nsubnet group has an Internet Protocol version 6 (IPv6) CIDR block associated with it. For more information, see\r\nAmazon RDS IP addressing and Migrating to IPv6 in the Amazon VPC User Guide.\r\nNote\r\nThe DB subnet group for a Local Zone can have only one subnet.\r\nWhen Amazon RDS creates a DB instance in a VPC, it assigns a network interface to your DB instance by using\r\nan IP address from your DB subnet group. However, we strongly recommend that you use the Domain Name\r\nSystem (DNS) name to connect to your DB instance. We recommend this because the underlying IP address\r\nchanges during failover.\r\nNote\r\nFor each DB instance that you run in a VPC, make sure to reserve at least one address in each subnet in the DB\r\nsubnet group for use by Amazon RDS for recovery actions.\r\nYou can create a DB instance in a shared VPC.\r\nSome considerations to keep in mind while using shared VPCs:\r\nYou can move a DB instance from a shared VPC subnet to a non-shared VPC subnet and vice-versa.\r\nParticipants in a shared VPC must create a security group in the VPC to allow them to create a DB\r\ninstance.\r\nOwners and participants in a shared VPC can access the database by using SQL queries. However, only the\r\ncreator of a resource can make any API calls on the resource.\r\nAmazon RDS IP addressing\r\nIP addresses enable resources in your VPC to communicate with each other, and with resources over the internet.\r\nAmazon RDS supports both IPv4 and IPv6 addressing protocols. By default, Amazon RDS and Amazon VPC use\r\nthe IPv4 addressing protocol. You can't turn off this behavior. When you create a VPC, make sure to specify an\r\nIPv4 CIDR block (a range of private IPv4 addresses). You can optionally assign an IPv6 CIDR block to your VPC\r\nand subnets, and assign IPv6 addresses from that block to DB instances in your subnet.\r\nhttps://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html\r\nPage 4 of 13\n\nSupport for the IPv6 protocol expands the number of supported IP addresses. By using the IPv6 protocol, you\r\nensure that you have sufficient available addresses for the future growth of the internet. New and existing RDS\r\nresources can use IPv4 and IPv6 addresses within your VPC. Configuring, securing, and translating network\r\ntraffic between the two protocols used in different parts of an application can cause operational overhead. You can\r\nstandardize on the IPv6 protocol for Amazon RDS resources to simplify your network configuration.\r\nIPv4 addresses\r\nWhen you create a VPC, you must specify a range of IPv4 addresses for the VPC in the form of a CIDR block,\r\nsuch as 10.0.0.0/16 . A DB subnet group defines the range of IP addresses in this CIDR block that a DB instance\r\ncan use. These IP addresses can be private or public.\r\nA private IPv4 address is an IP address that's not reachable over the internet. You can use private IPv4 addresses\r\nfor communication between your DB instance and other resources, such as Amazon EC2 instances, in the same\r\nVPC. Each DB instance has a private IP address for communication in the VPC.\r\nA public IP address is an IPv4 address that's reachable from the internet. You can use public addresses for\r\ncommunication between your DB instance and resources on the internet, such as a SQL client. You control\r\nwhether your DB instance receives a public IP address.\r\nAmazon RDS uses Public Elastic IPv4 addresses from EC2's public IPv4 address pool for publicly accessible\r\ndatabase instances. These IP addresses are visible in your AWS account when using the describe-addresses\r\nCLI, API or viewing the Elastic IPs (EIP) section in the AWS Management Console. Each RDS-managed IP\r\naddress is marked with a service_managed attribute set to \"rds\" .\r\nWhile these IPs are visible in your account, they remain fully managed by Amazon RDS and cannot be modified\r\nor released. Amazon RDS releases IPs back into the public IPv4 address pool when no longer in use.\r\nCloudTrail logs API calls related to RDS's EIP, such as the AllocateAddress . These API calls are invoked by the\r\nService Principal rds.amazonaws.com .\r\nNote\r\nIPs allocated by Amazon RDS do not count against your account's EIP limits.\r\nFor a tutorial that shows you how to create a VPC with only private IPv4 addresses that you can use for a common\r\nAmazon RDS scenario, see Tutorial: Create a VPC for use with a DB instance (IPv4 only).\r\nIPv6 addresses\r\nYou can optionally associate an IPv6 CIDR block with your VPC and subnets, and assign IPv6 addresses from\r\nthat block to the resources in your VPC. Each IPv6 address is globally unique.\r\nThe IPv6 CIDR block for your VPC is automatically assigned from Amazon's pool of IPv6 addresses. You can't\r\nchoose the range yourself.\r\nWhen connecting to an IPv6 address, make sure that the following conditions are met:\r\nhttps://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html\r\nPage 5 of 13\n\nThe client is configured so that client to database traffic over IPv6 is allowed.\r\nRDS security groups used by the DB instance are configured correctly so that client to database traffic over\r\nIPv6 is allowed.\r\nThe client operating system stack allows traffic on the IPv6 address, and operating system drivers and\r\nlibraries are configured to choose the correct default DB instance endpoint (either IPv4 or IPv6).\r\nFor more information about IPv6, see IP Addressing in the Amazon VPC User Guide.\r\nDual-stack mode\r\nA DB instance runs in dual-stack mode when it can communicate over both IPv4 and IPv6 addressing protocols.\r\nResources can then communicate with the DB instance using either IPv4, IPv6, or both protocols. Private dual-stack mode DB instances have IPv6 endpoints that RDS restricts to VPC access only, ensuring your IPv6\r\nendpoints remain private. Public dual-stack mode DB instances provide both IPv4 and IPv6 endpoints that you\r\ncan access from the internet.\r\nTopics\r\nDual-stack mode and DB subnet groups\r\nWorking with dual-stack mode DB instances\r\nModifying IPv4-only DB instances to use dual-stack mode\r\nRegion and version availability\r\nLimitations for dual-stack network DB instances\r\nFor a tutorial that shows you how to create a VPC with both IPv4 and IPv6 addresses that you can use for a\r\ncommon Amazon RDS scenario, see Tutorial: Create a VPC for use with a DB instance (dual-stack mode).\r\nDual-stack mode and DB subnet groups\r\nTo use dual-stack mode, make sure that each subnet in the DB subnet group that you associate with the DB\r\ninstance has an IPv6 CIDR block associated with it. You can create a new DB subnet group or modify an existing\r\nDB subnet group to meet this requirement. After a DB instance is in dual-stack mode, clients can connect to it\r\nnormally. Make sure that client security firewalls and RDS DB instance security groups are accurately configured\r\nto allow traffic over IPv6. To connect, clients use the DB instance's endpoint. Client applications can specify\r\nwhich protocol is preferred when connecting to a database. In dual-stack mode, the DB instance detects the client's\r\npreferred network protocol, either IPv4 or IPv6, and uses that protocol for the connection.\r\nIf a DB subnet group stops supporting dual-stack mode because of subnet deletion or CIDR disassociation, there's\r\na risk of an incompatible network state for DB instances that are associated with the DB subnet group. Also, you\r\ncan't use the DB subnet group when you create a new dual-stack mode DB instance.\r\nhttps://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html\r\nPage 6 of 13\n\nTo determine whether a DB subnet group supports dual-stack mode by using the AWS Management Console, view\r\nthe Network type on the details page of the DB subnet group. To determine whether a DB subnet group supports\r\ndual-stack mode by using the AWS CLI, run the describe-db-subnet-groups command and view\r\nSupportedNetworkTypes in the output.\r\nRead replicas are treated as independent DB instances and can have a network type that's different from the\r\nprimary DB instance. If you change the network type of a read replica's primary DB instance, the read replica isn't\r\naffected. When you are restoring a DB instance, you can restore it to any network type that's supported.\r\nWorking with dual-stack mode DB instances\r\nWhen you create or modify a DB instance, you can specify dual-stack mode to allow your resources to\r\ncommunicate with your DB instance over IPv4, IPv6, or both.\r\nWhen you use the AWS Management Console to create or modify a DB instance, you can specify dual-stack mode\r\nin the Network type section. The following image shows the Network type section in the console.\r\nWhen you use the AWS CLI to create or modify a DB instance, set the --network-type option to DUAL to use\r\ndual-stack mode. When you use the RDS API to create or modify a DB instance, set the NetworkType parameter\r\nto DUAL to use dual-stack mode. When you are modifying the network type of a DB instance, downtime is\r\npossible. If dual-stack mode isn't supported by the specified DB engine version or DB subnet group, the\r\nNetworkTypeNotSupported error is returned.\r\nFor more information about creating a DB instance, see Creating an Amazon RDS DB instance. For more\r\ninformation about modifying a DB instance, see Modifying an Amazon RDS DB instance.\r\nTo determine whether a DB instance is in dual-stack mode by using the console, view the Network type on the\r\nConnectivity \u0026 security tab for the DB instance.\r\nModifying IPv4-only DB instances to use dual-stack mode\r\nYou can modify an IPv4-only DB instance to use dual-stack mode. To do so, change the network type of the DB\r\ninstance. The modification might result in downtime.\r\nIt is recommended that you change the network type of your Amazon RDS DB instances during a maintenance\r\nwindow. Currently, setting the network type of new instances to dual-stack mode isn't supported. You can set\r\nnetwork type manually by using the modify-db-instance command.\r\nBefore modifying a DB instance to use dual-stack mode, make sure that its DB subnet group supports dual-stack\r\nmode. If the DB subnet group associated with the DB instance doesn't support dual-stack mode, specify a different\r\nDB subnet group that supports it when you modify the DB instance. Modifying the DB subnet group of a DB\r\ninstance can cause downtime.\r\nIf you modify the DB subnet group of a DB instance before you change the DB instance to use dual-stack mode,\r\nmake sure that the DB subnet group is valid for the DB instance before and after the change.\r\nhttps://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html\r\nPage 7 of 13\n\nFor RDS for PostgreSQL, RDS for MySQL, RDS for Oracle, and RDS for MariaDB Single-AZ instances, we\r\nrecommend that you run the modify-db-instance command with only the --network-type parameter set to\r\nDUAL to change the network to dual-stack mode. Adding other parameters along with the --network-type\r\nparameter in the same API call could result in downtime. To modify multiple parameters, ensure that the network\r\ntype modification is successfully completed before sending another modify-db-instance request with other\r\nparameters.\r\nNetwork type modifications for RDS for PostgreSQL, RDS for MySQL, RDS for Oracle, and RDS for MariaDB\r\nMulti-AZ DB instances cause a brief downtime and trigger a failover if you only use the --network-type\r\nparameter or if you combine parameters in a modify-db-instance command.\r\nNetwork type modifications on RDS for SQL Server Single-AZ or Multi-AZ DB instances cause downtime if you\r\nonly use the --network-type parameter or if you combine parameters in a modify-db-instance command.\r\nNetwork type modifications cause failover in an SQL Server Multi-AZ instance.\r\nIf you can't connect to the DB instance after the change, make sure that the client and database security firewalls\r\nand route tables are accurately configured to allow traffic to the database on the selected network (either IPv4 or\r\nIPv6). You might also need to modify operating system parameter, libraries, or drivers to connect using an IPv6\r\naddress.\r\nWhen you modify a DB instance to use dual-stack mode, there can't be a pending change from a Single-AZ\r\ndeployment to a Multi-AZ deployment, or from a Multi-AZ deployment to a Single-AZ deployment.\r\nTo modify an IPv4-only DB instance to use dual-stack mode\r\n1. Modify a DB subnet group to support dual-stack mode, or create a DB subnet group that supports dual-stack mode:\r\n1. Associate an IPv6 CIDR block with your VPC.\r\nFor instructions, see Add an IPv6 CIDR block to your VPC in the Amazon VPC User Guide.\r\n2. Attach the IPv6 CIDR block to all of the subnets in your the DB subnet group.\r\nFor instructions, see Add an IPv6 CIDR block to your subnet in the Amazon VPC User Guide.\r\n3. Confirm that the DB subnet group supports dual-stack mode.\r\nIf you are using the AWS Management Console, select the DB subnet group, and make sure that the\r\nSupported network types value is Dual, IPv4.\r\nIf you are using the AWS CLI, run the describe-db-subnet-groups command, and make sure that the\r\nSupportedNetworkType value for the DB instance is Dual, IPv4 .\r\n2. Modify the security group associated with the DB instance to allow IPv6 connections to the database, or\r\ncreate a new security group that allows IPv6 connections.\r\nhttps://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html\r\nPage 8 of 13\n\nFor instructions, see Security group rules in the Amazon VPC User Guide.\r\n3. Modify the DB instance to support dual-stack mode. To do so, set the Network type to Dual-stack mode.\r\nIf you are using the console, make sure that the following settings are correct:\r\nNetwork type – Dual-stack mode\r\nDB subnet group – The DB subnet group that you configured in a previous step\r\nSecurity group – The security that you configured in a previous step\r\nIf you are using the AWS CLI, make sure that the following settings are correct:\r\n--network-type – dual\r\n--db-subnet-group-name – The DB subnet group that you configured in a previous step\r\n--vpc-security-group-ids – The VPC security group that you configured in a previous step\r\nFor example:\r\naws rds modify-db-instance --db-instance-identifier my-instance --network-type \"DUAL\"\r\n4. Confirm that the DB instance supports dual-stack mode.\r\nIf you are using the console, choose the Connectivity \u0026 security tab for the DB instance. On that tab,\r\nmake sure that the Network type value is Dual-stack mode.\r\nIf you are using the AWS CLI, run the describe-db-instances command, and make sure that the\r\nNetworkType value for the DB instance is dual .\r\nRun the dig command on the DB instance endpoint to identify the IPv6 address associated with it.\r\ndig db-instance-endpoint AAAA\r\nUse the DB instance endpoint, not the IPv6 address, to connect to the DB instance.\r\nRegion and version availability\r\nFeature availability and support varies across specific versions of each database engine, and across AWS Regions.\r\nFor more information on version and Region availability with dual-stack mode, see Supported Regions and DB\r\nengines for dual-stack mode in Amazon RDS.\r\nLimitations for dual-stack network DB instances\r\nThe following limitations apply to dual-stack network DB instances:\r\nhttps://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html\r\nPage 9 of 13\n\nDB instances can't use the IPv6 protocol exclusively. They can use IPv4 exclusively, or they can use the\r\nIPv4 and IPv6 protocol (dual-stack mode).\r\nAmazon RDS doesn't support native IPv6 subnets.\r\nFor RDS for SQL Server, dual-stack mode DB instances that use Always On AGs availability group\r\nlistener endpoints only present IPv4 addresses.\r\nYou can't use RDS Proxy with dual-stack mode DB instances.\r\nYou can't use dual-stack mode with RDS on AWS Outposts DB instances.\r\nYou can't use dual-stack mode with DB instances in a Local Zone.\r\nHiding a DB instance in a VPC from the internet\r\nOne common Amazon RDS scenario is to have a VPC in which you have an Amazon EC2 instance with a public-facing web application and a DB instance with a database that isn't publicly accessible. For example, you can\r\ncreate a VPC that has a public subnet and a private subnet. EC2 instances that function as web servers can be\r\ndeployed in the public subnet. The DB instances are deployed in the private subnet. In such a deployment, only\r\nthe web servers have access to the DB instances. For an illustration of this scenario, see A DB instance in a VPC\r\naccessed by an Amazon EC2 instance in the same VPC.\r\nWhen you launch a DB instance inside a VPC, the DB instance has a private IP address for traffic inside the VPC.\r\nThis private IP address isn't publicly accessible. You can use the Public access option to designate whether the DB\r\ninstance also has a public IP address in addition to the private IP address. If the DB instance is designated as\r\npublicly accessible, its DNS endpoint resolves to the private IP address from within the VPC. It resolves to the\r\npublic IP address from outside of the VPC. Access to the DB instance is ultimately controlled by the security\r\ngroup it uses. That public access is not permitted if the security group assigned to the DB instance doesn't include\r\ninbound rules that permit it. In addition, for a DB instance to be publicly accessible, the subnets in its DB subnet\r\ngroup must have an internet gateway. For more information, see Can't connect to Amazon RDS DB instance\r\nYou can modify a DB instance to turn on or off public accessibility by modifying the Public access option. The\r\nfollowing illustration shows the Public access option in the Additional connectivity configuration section. To\r\nset the option, open the Additional connectivity configuration section in the Connectivity section.\r\nFor information about modifying a DB instance to set the Public access option, see Modifying an Amazon RDS\r\nDB instance.\r\nCreating a DB instance in a VPC\r\nThe following procedures help you create a DB instance in a VPC. To use the default VPC, you can begin with\r\nstep 2, and use the VPC and DB subnet group have already been created for you. If you want to create an\r\nadditional VPC, you can create a new VPC.\r\nNote\r\nhttps://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html\r\nPage 10 of 13\n\nIf you want your DB instance in the VPC to be publicly accessible, you must update the DNS information for the\r\nVPC by enabling the VPC attributes DNS hostnames and DNS resolution. For information about updating the\r\nDNS information for a VPC instance, see Updating DNS support for your VPC.\r\nFollow these steps to create a DB instance in a VPC:\r\nStep 1: Create a VPC\r\nStep 2: Create a DB subnet group\r\nStep 3: Create a VPC security group\r\nStep 4: Create a DB instance in the VPC\r\nStep 1: Create a VPC\r\nCreate a VPC with subnets in at least two Availability Zones. You use these subnets when you create a DB subnet\r\ngroup. If you have a default VPC, a subnet is automatically created for you in each Availability Zone in the AWS\r\nRegion.\r\nFor more information, see Create a VPC with private and public subnets, or see Create a VPC in the Amazon VPC\r\nUser Guide.\r\nStep 2: Create a DB subnet group\r\nA DB subnet group is a collection of subnets (typically private) that you create for a VPC and that you then\r\ndesignate for your DB instances. A DB subnet group allows you to specify a particular VPC when you create DB\r\ninstances using the AWS CLI or RDS API. If you use the console, you can just choose the VPC and subnets you\r\nwant to use. Each DB subnet group must have at least one subnet in at least two Availability Zones in the AWS\r\nRegion. As a best practice, each DB subnet group should have at least one subnet for every Availability Zone in\r\nthe AWS Region.\r\nFor Multi-AZ deployments, defining a subnet for all Availability Zones in an AWS Region enables Amazon RDS\r\nto create a new standby replica in another Availability Zone if necessary. You can follow this best practice even for\r\nSingle-AZ deployments, because you might convert them to Multi-AZ deployments in the future.\r\nFor a DB instance to be publicly accessible, the subnets in the DB subnet group must have an internet gateway.\r\nFor more information about internet gateways for subnets, see Connect to the internet using an internet gateway in\r\nthe Amazon VPC User Guide.\r\nNote\r\nThe DB subnet group for a Local Zone can have only one subnet.\r\nWhen you create a DB instance in a VPC, you can choose a DB subnet group. Amazon RDS chooses a subnet and\r\nan IP address within that subnet to associate with your DB instance. If no DB subnet groups exist, Amazon RDS\r\ncreates a default subnet group when you create a DB instance. Amazon RDS creates and associates an Elastic\r\nhttps://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html\r\nPage 11 of 13\n\nNetwork Interface to your DB instance with that IP address. The DB instance uses the Availability Zone that\r\ncontains the subnet.\r\nFor Multi-AZ deployments, defining a subnet for two or more Availability Zones in an AWS Region allows\r\nAmazon RDS to create a new standby in another Availability Zone should the need arise. You need to do this even\r\nFor Single-AZ deployments, just in case you want to convert them to Multi-AZ deployments at some point.\r\nIn this step, you create a DB subnet group and add the subnets that you created for your VPC.\r\nTo create a DB subnet group\r\n1. Open the Amazon RDS console at https://console.aws.amazon.com/rds/.\r\n2. In the navigation pane, choose Subnet groups.\r\n3. Choose Create DB Subnet Group.\r\n4. For Name, type the name of your DB subnet group.\r\n5. For Description, type a description for your DB subnet group.\r\n6. For VPC, choose the default VPC or the VPC that you created.\r\n7. In the Add subnets section, choose the Availability Zones that include the subnets from Availability\r\nZones, and then choose the subnets from Subnets.\r\nNote\r\nIf you have enabled a Local Zone, you can choose an Availability Zone group on the Create DB subnet\r\ngroup page. In this case, choose the Availability Zone group, Availability Zones, and Subnets.\r\n8. Choose Create.\r\nYour new DB subnet group appears in the DB subnet groups list on the RDS console. You can choose the\r\nDB subnet group to see details, including all of the subnets associated with the group, in the details pane at\r\nthe bottom of the window.\r\nStep 3: Create a VPC security group\r\nBefore you create your DB instance, you can create a VPC security group to associate with your DB instance. If\r\nyou don't create a VPC security group, you can use the default security group when you create a DB instance. For\r\ninstructions on how to create a security group for your DB instance, see Create a VPC security group for a private\r\nDB instance, or see Control traffic to resources using security groups in the Amazon VPC User Guide.\r\nStep 4: Create a DB instance in the VPC\r\nIn this step, you create a DB instance and use the VPC name, the DB subnet group, and the VPC security group\r\nyou created in the previous steps.\r\nhttps://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html\r\nPage 12 of 13\n\nNote\r\nIf you want your DB instance in the VPC to be publicly accessible, you must enable the VPC attributes DNS\r\nhostnames and DNS resolution. For more information, see DNS attributes for your VPC in the Amazon VPC User\r\nGuide.\r\nFor details on how to create a DB instance, see Creating an Amazon RDS DB instance.\r\nWhen prompted in the Connectivity section, enter the VPC name, the DB subnet group, and the VPC security\r\ngroup.\r\nSource: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html\r\nhttps://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html"
	],
	"report_names": [
		"USER_VPC.WorkingWithRDSInstanceinaVPC.html"
	],
	"threat_actors": [
		{
			"id": "9041c438-4bc0-4863-b89c-a32bba33903c",
			"created_at": "2023-01-06T13:46:38.232751Z",
			"updated_at": "2026-04-10T02:00:02.888195Z",
			"deleted_at": null,
			"main_name": "Nitro",
			"aliases": [
				"Covert Grove"
			],
			"source_name": "MISPGALAXY:Nitro",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "a2b44a04-a080-4465-973d-976ce53777de",
			"created_at": "2022-10-25T16:07:23.911791Z",
			"updated_at": "2026-04-10T02:00:04.786538Z",
			"deleted_at": null,
			"main_name": "Nitro",
			"aliases": [
				"Covert Grove",
				"Nitro"
			],
			"source_name": "ETDA:Nitro",
			"tools": [
				"AngryRebel",
				"Backdoor.Apocalipto",
				"Chymine",
				"Darkmoon",
				"Farfli",
				"Gen:Trojan.Heur.PT",
				"Gh0st RAT",
				"Ghost RAT",
				"Moudour",
				"Mydoor",
				"PCClient",
				"PCRat",
				"Poison Ivy",
				"SPIVY",
				"Spindest",
				"pivy",
				"poisonivy"
			],
			"source_id": "ETDA",
			"reports": null
		},
		{
			"id": "761d1fb2-60e3-46f0-9f1c-c8a9715967d4",
			"created_at": "2023-01-06T13:46:38.269054Z",
			"updated_at": "2026-04-10T02:00:02.90356Z",
			"deleted_at": null,
			"main_name": "APT3",
			"aliases": [
				"GOTHIC PANDA",
				"TG-0110",
				"Buckeye",
				"Group 6",
				"Boyusec",
				"BORON",
				"BRONZE MAYFAIR",
				"Red Sylvan",
				"Brocade Typhoon"
			],
			"source_name": "MISPGALAXY:APT3",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "06f622cb-3a78-49cf-9a4c-a6007a69325f",
			"created_at": "2022-10-25T16:07:23.315239Z",
			"updated_at": "2026-04-10T02:00:04.537826Z",
			"deleted_at": null,
			"main_name": "APT 3",
			"aliases": [
				"APT 3",
				"Boron",
				"Brocade Typhoon",
				"Bronze Mayfair",
				"Buckeye",
				"G0022",
				"Gothic Panda",
				"Group 6",
				"Operation Clandestine Fox",
				"Operation Clandestine Fox, Part Deux",
				"Operation Clandestine Wolf",
				"Operation Double Tap",
				"Red Sylvan",
				"TG-0110",
				"UPS Team"
			],
			"source_name": "ETDA:APT 3",
			"tools": [
				"APT3 Keylogger",
				"Agent.dhwf",
				"BKDR_HUPIGON",
				"Backdoor.APT.CookieCutter",
				"Badey",
				"Bemstour",
				"CookieCutter",
				"Destroy RAT",
				"DestroyRAT",
				"DoublePulsar",
				"EXL",
				"EternalBlue",
				"HTran",
				"HUC Packet Transmit Tool",
				"Hupigon",
				"Hupigon RAT",
				"Kaba",
				"Korplug",
				"LaZagne",
				"MFC Huner",
				"OSInfo",
				"Pirpi",
				"PlugX",
				"RedDelta",
				"RemoteCMD",
				"SHOTPUT",
				"Sogu",
				"TIGERPLUG",
				"TTCalc",
				"TVT",
				"Thoper",
				"Xamtrav",
				"remotecmd",
				"shareip",
				"w32times"
			],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434208,
	"ts_updated_at": 1775792246,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b571fa3556fd731514097d083b7ef40848346b1c.pdf",
		"text": "https://archive.orkl.eu/b571fa3556fd731514097d083b7ef40848346b1c.txt",
		"img": "https://archive.orkl.eu/b571fa3556fd731514097d083b7ef40848346b1c.jpg"
	}
}