Deploying a RDS Instance into a Specific VPC: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
No edit summary
 
(2 intermediate revisions by the same user not shown)
Line 12: Line 12:
The deployment of a RDS instance in a specific VPC consists in the following steps:
The deployment of a RDS instance in a specific VPC consists in the following steps:


1. Create a dedicated subnet.
1. Create at least two dedicated subnets, in two different availability zones. One subnet is not sufficient, the DB deployment will fail.


This is optional, and it's probably best to do for the clarity of the solution, but it's probably not necessary.
This is optional, and it's probably best to do for the clarity of the solution, but it's probably not necessary.
Line 21: Line 21:
Resources:
Resources:
   ...   
   ...   
   PostgresSubnet:
   PostgresSubnet1:
     Type: AWS::EC2::Subnet
     Type: AWS::EC2::Subnet
     Properties:
     Properties:
       VpcId:
       VpcId:
         Fn::ImportValue: !Sub ${MicroworldName}-vpc-id
         Fn::ImportValue: !Sub ${MicroworldName}-vpc-id
       CidrBlock: !Ref PostgreSQLCIDRBlock
       CidrBlock: !Ref PostgreSQLSubnet1CIDRBlock
       #
       #
       # We do not explicitly associate the subnet with any availability zone, because we really don't care
       # We explicitly associate the subnet with an availability zone, because we've seen situations in the
       # about this, for the RDS instance. In case of the main private subnets of the environment we did,
       # past when AWS, left to its own devices, would deploy both subnets in the same availability zone, and
       # as the ALB won't start if the subnets are in the same availability zone.
       # that would prevent the ALB from starting. We use the same availability zone as Subnet1
       #
       #
      AvailabilityZone: !Sub ${AWS::Region}${Subnet1AvailabilityZoneSuffix}
       MapPublicIpOnLaunch: false
       MapPublicIpOnLaunch: false
       Tags:
       Tags:
         - Key: Name
         - Key: Name
           Value: !Sub ${MicroworldName}-${EnvironmentName}-postgres-subnet
           Value: !Sub ${MicroworldName}-${EnvironmentName}-postgres-subnet1


   PostgresRouteTable:
   PostgresSubnet1RouteTable:
     Type: AWS::EC2::RouteTable
     Type: AWS::EC2::RouteTable
     Properties:
     Properties:
Line 44: Line 45:
       Tags:
       Tags:
         - Key: Name
         - Key: Name
           Value: !Sub ${MicroworldName}-${EnvironmentName}-postgres-subnet-rt
           Value: !Sub ${MicroworldName}-${EnvironmentName}-postgres-subnet1-rt


   PostgresRouteTableAssociation:
   PostgresSubnet1RouteTableAssociation:
     Type: AWS::EC2::SubnetRouteTableAssociation
     Type: AWS::EC2::SubnetRouteTableAssociation
     Properties:
     Properties:
       RouteTableId: !Ref PostgresRouteTable
       RouteTableId: !Ref PostgresSubnet1RouteTable
       SubnetId: !Ref PostgresSubnet
       SubnetId: !Ref PostgresSubnet1
 
  #
  # We don't need a route to NAT, as the PostgreSQL instance does not need internet access
  #
 
  PostgresSubnet2:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId:
        Fn::ImportValue: !Sub ${MicroworldName}-vpc-id
      CidrBlock: !Ref PostgreSQLSubnet2CIDRBlock
      #
      # We explicitly associate the subnet with an availability zone, because we've seen situations in the
      # past when AWS, left to its own devices, would deploy both subnets in the same availability zone, and
      # that would prevent the ALB from starting. We use the same availability zone as Subnet2
      #
      AvailabilityZone: !Sub ${AWS::Region}${Subnet2AvailabilityZoneSuffix}
      MapPublicIpOnLaunch: false
      Tags:
        - Key: Name
          Value: !Sub ${MicroworldName}-${EnvironmentName}-postgres-subnet2
 
  PostgresSubnet2RouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId:
        Fn::ImportValue: !Sub ${MicroworldName}-vpc-id
      Tags:
        - Key: Name
          Value: !Sub ${MicroworldName}-${EnvironmentName}-postgres-subnet2-rt
 
  PostgresSubnet2RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref PostgresSubnet2RouteTable
      SubnetId: !Ref PostgresSubnet2


   #
   #
Line 63: Line 100:
3. Create a VPC security group for the RDS instance.
3. Create a VPC security group for the RDS instance.


 
<syntaxhighlight lang='yaml'>
  PostgresSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub ${MicroworldName}-${EnvironmentName}-postgres-sg
      VpcId:
        Fn::ImportValue: !Sub ${MicroworldName}-vpc-id
      GroupDescription: !Sub Security group for ${MicroworldName} ${EnvironmentName} PostgreSQL instance
      SecurityGroupIngress:
        - IpProtocol: -1
          CidrIp: 0.0.0.0/0
</syntaxhighlight>


4. Configure the RDS instance with all of the above.
4. Configure the RDS instance with all of the above.


See: {{Internal|Amazon_Relational_Database_Operations#AWS::RDS::DBInstance|AWS::RDS::DBInstance}}
See: {{Internal|Amazon_Relational_Database_Operations#AWS::RDS::DBInstance|AWS::RDS::DBInstance}}

Latest revision as of 20:00, 17 April 2019

External

Internal

Procedure

The deployment of a RDS instance in a specific VPC consists in the following steps:

1. Create at least two dedicated subnets, in two different availability zones. One subnet is not sufficient, the DB deployment will fail.

This is optional, and it's probably best to do for the clarity of the solution, but it's probably not necessary.

The subnet does not need a route to the internet.

Resources:
  ...  
  PostgresSubnet1:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId:
        Fn::ImportValue: !Sub ${MicroworldName}-vpc-id
      CidrBlock: !Ref PostgreSQLSubnet1CIDRBlock
      #
      # We explicitly associate the subnet with an availability zone, because we've seen situations in the
      # past when AWS, left to its own devices, would deploy both subnets in the same availability zone, and
      # that would prevent the ALB from starting. We use the same availability zone as Subnet1
      #
      AvailabilityZone: !Sub ${AWS::Region}${Subnet1AvailabilityZoneSuffix}
      MapPublicIpOnLaunch: false
      Tags:
        - Key: Name
          Value: !Sub ${MicroworldName}-${EnvironmentName}-postgres-subnet1

  PostgresSubnet1RouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId:
        Fn::ImportValue: !Sub ${MicroworldName}-vpc-id
      Tags:
        - Key: Name
          Value: !Sub ${MicroworldName}-${EnvironmentName}-postgres-subnet1-rt

  PostgresSubnet1RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref PostgresSubnet1RouteTable
      SubnetId: !Ref PostgresSubnet1

  #
  # We don't need a route to NAT, as the PostgreSQL instance does not need internet access
  #

  PostgresSubnet2:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId:
        Fn::ImportValue: !Sub ${MicroworldName}-vpc-id
      CidrBlock: !Ref PostgreSQLSubnet2CIDRBlock
      #
      # We explicitly associate the subnet with an availability zone, because we've seen situations in the
      # past when AWS, left to its own devices, would deploy both subnets in the same availability zone, and
      # that would prevent the ALB from starting. We use the same availability zone as Subnet2
      #
      AvailabilityZone: !Sub ${AWS::Region}${Subnet2AvailabilityZoneSuffix}
      MapPublicIpOnLaunch: false
      Tags:
        - Key: Name
          Value: !Sub ${MicroworldName}-${EnvironmentName}-postgres-subnet2

  PostgresSubnet2RouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId:
        Fn::ImportValue: !Sub ${MicroworldName}-vpc-id
      Tags:
        - Key: Name
          Value: !Sub ${MicroworldName}-${EnvironmentName}-postgres-subnet2-rt

  PostgresSubnet2RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref PostgresSubnet2RouteTable
      SubnetId: !Ref PostgresSubnet2

  #
  # We don't need a route to NAT, as the PostgreSQL instance does not need internet access
  #

2. Create a DB subnet Group.

See:

AWS::RDS::DBSubnetGroup

3. Create a VPC security group for the RDS instance.

  PostgresSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub ${MicroworldName}-${EnvironmentName}-postgres-sg
      VpcId:
        Fn::ImportValue: !Sub ${MicroworldName}-vpc-id
      GroupDescription: !Sub Security group for ${MicroworldName} ${EnvironmentName} PostgreSQL instance
      SecurityGroupIngress:
        - IpProtocol: -1
          CidrIp: 0.0.0.0/0

4. Configure the RDS instance with all of the above.

See:

AWS::RDS::DBInstance