Deploying a RDS Instance into a Specific VPC: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
|||
(One intermediate revision 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 | 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: | ||
... | ... | ||
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 | CidrBlock: !Ref PostgreSQLSubnet1CIDRBlock | ||
# | # | ||
# We | # 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 | MapPublicIpOnLaunch: false | ||
Tags: | Tags: | ||
- Key: Name | - Key: Name | ||
Value: !Sub ${MicroworldName}-${EnvironmentName}-postgres- | Value: !Sub ${MicroworldName}-${EnvironmentName}-postgres-subnet1 | ||
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- | Value: !Sub ${MicroworldName}-${EnvironmentName}-postgres-subnet1-rt | ||
PostgresSubnet1RouteTableAssociation: | |||
Type: AWS::EC2::SubnetRouteTableAssociation | Type: AWS::EC2::SubnetRouteTableAssociation | ||
Properties: | Properties: | ||
RouteTableId: !Ref | RouteTableId: !Ref PostgresSubnet1RouteTable | ||
SubnetId: !Ref | 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 | |||
# | # |
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:
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: