Launching workloads without internet access

[huanjani]

Copilot enables you to launch tasks in private subnets (whether your workload is a scheduled job, load-balanced web service, or backend service), automatically creating NAT gateways for internet connectivity.

However, isolated tasks that are not internet-facing do not need NAT gateways; instead they require VPC Endpoints to communicate with other AWS services. You can import an existing VPC with the necessary endpoints, and specify private subnet placement in your service or job manifest.

Not sure what resources you'll need? Use this template:

Resources:
  # A Virtual Private Cloud to control networking of your AWS resources.
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.0.0.0/16
      EnableDnsHostnames: true
      EnableDnsSupport: true
      InstanceTenancy: default

  # Private subnets.
  PrivateSubnet1:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 10.0.0.0/24
      VpcId: !Ref VPC
      AvailabilityZone: !Select [ 0, !GetAZs '' ]
      MapPublicIpOnLaunch: false

  PrivateSubnet2:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: 10.0.1.0/24
      VpcId: !Ref VPC
      AvailabilityZone: !Select [ 1, !GetAZs '' ]
      MapPublicIpOnLaunch: false

  # Security Group to allow use of VPC Endpoints.
  VPCEndpointSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      VpcId: !Ref VPC
      GroupDescription: "Security group to allow use of VPC Endpoints."
      SecurityGroupIngress:
        - IpProtocol: tcp
          Description: HTTPS
          FromPort: 443
          ToPort: 443
          CidrIp: 10.0.0.0/0

  # Route table for gateway endpoint(s).
  RouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC

  # Associations between your route table and subnets.
  RouteTableAssociation1:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref RouteTable
      SubnetId: !Ref PrivateSubnet1

  RouteTableAssociation2:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      RouteTableId: !Ref RouteTable
      SubnetId: !Ref PrivateSubnet2

  # Gateway endpoint for S3.
  S3GatewayVPCEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      VpcEndpointType: Gateway
      RouteTableIds:
        - !Ref RouteTable
      ServiceName: !Sub com.amazonaws.${AWS::Region}.s3
      VpcId: !Ref VPC

  # Interface endpoints.
  # Enables pulling images from ECR.
  EcrApiVPCEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      VpcEndpointType: Interface
      PrivateDnsEnabled: true
      SubnetIds:
        - !Ref PrivateSubnet1
        - !Ref PrivateSubnet2
      ServiceName: !Sub com.amazonaws.${AWS::Region}.ecr.api
      VpcId: !Ref VPC
      SecurityGroupIds:
        - !Ref VPCEndpointSecurityGroup

  EcrDkrVPCEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      VpcEndpointType: Interface
      PrivateDnsEnabled: true
      SubnetIds:
        - !Ref PrivateSubnet1
        - !Ref PrivateSubnet2
      ServiceName: !Sub com.amazonaws.${AWS::Region}.ecr.dkr
      VpcId: !Ref VPC
      SecurityGroupIds:
        - !Ref VPCEndpointSecurityGroup

  # Enables CloudWatch logging.
  LogsVPCEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      VpcEndpointType: Interface
      PrivateDnsEnabled: true
      SubnetIds:
        - !Ref PrivateSubnet1
        - !Ref PrivateSubnet2
      ServiceName: !Sub com.amazonaws.${AWS::Region}.logs
      VpcId: !Ref VPC
      SecurityGroupIds:
        - !Ref VPCEndpointSecurityGroup

Add more VPC endpoints depending on which services you need access to.

For Systems Manager (to enable exec functionality and more):

SSMVPCEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds:
      - !Ref PrivateSubnet1
      - !Ref PrivateSubnet2
    ServiceName: !Sub com.amazonaws.${AWS::Region}.ssm
    VpcId: !Ref VPC
    SecurityGroupIds:
      - !Ref VPCEndpointSecurityGroup

EC2MessagesVPCEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds:
      - !Ref PrivateSubnet1
      - !Ref PrivateSubnet2
    ServiceName: !Sub com.amazonaws.${AWS::Region}.ec2messages
    VpcId: !Ref VPC
    SecurityGroupIds:
      - !Ref VPCEndpointSecurityGroup

EC2VPCEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds:
      - !Ref PrivateSubnet1
      - !Ref PrivateSubnet2
    ServiceName: !Sub com.amazonaws.${AWS::Region}.ec2
    VpcId: !Ref VPC
    SecurityGroupIds:
      - !Ref VPCEndpointSecurityGroup

SSMMessagesVPCEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds:
      - !Ref PrivateSubnet1
      - !Ref PrivateSubnet2
    ServiceName: !Sub com.amazonaws.${AWS::Region}.ssmmessages
    VpcId: !Ref VPC
    SecurityGroupIds:
      - !Ref VPCEndpointSecurityGroup

For Secrets Manager:

SecretsManagerVPCEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds:
      - !Ref PrivateSubnet1
      - !Ref PrivateSubnet2
    ServiceName: !Sub com.amazonaws.${AWS::Region}.secretsmanager
    VpcId: !Ref VPC
    SecurityGroupIds:
      - !Ref VPCEndpointSecurityGroup

For Key Management Service:

KMSVPCEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds:
      - !Ref PrivateSubnet1
      - !Ref PrivateSubnet2
    ServiceName: !Sub com.amazonaws.${AWS::Region}.kms
    VpcId: !Ref VPC
    SecurityGroupIds:
      - !Ref VPCEndpointSecurityGroup

For Auto Scaling:

AutoScalingVPCEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds:
      - !Ref PrivateSubnet1
      - !Ref PrivateSubnet2
    ServiceName: !Sub com.amazonaws.${AWS::Region}.autoscaling
    VpcId: !Ref VPC
    SecurityGroupIds:
      - !Ref VPCEndpointSecurityGroup

To connect to an Elastic File System volume:

EFSVPCEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds:
      - !Ref PrivateSubnet1
      - !Ref PrivateSubnet2
    ServiceName: !Sub com.amazonaws.${AWS::Region}.elasticfilesystem
    VpcId: !Ref VPC
    SecurityGroupIds:
      - !Ref VPCEndpointSecurityGroup

For DynamoDB, you’ll need another gateway endpoint (like S3, above):

# Gateway endpoint for DynamoDB.
DynamoDBGatewayVPCEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcEndpointType: Gateway
    RouteTableIds:
      - !Ref RouteTable
    ServiceName: !Sub com.amazonaws.${AWS::Region}.dynamodb
    VpcId: !Ref VPC

For RDS/Aurora:

RDSVPCEndpoint:
  Type: AWS::EC2::VPCEndpoint
  Properties:
    VpcEndpointType: Interface
    PrivateDnsEnabled: true
    SubnetIds:
      - !Ref PrivateSubnet1
      - !Ref PrivateSubnet2
    ServiceName: !Sub com.amazonaws.${AWS::Region}.rds
    VpcId: !Ref VPC
    SecurityGroupIds:
      - !Ref VPCEndpointSecurityGroup

[misaka]

Thanks for posting this. it looks like exactly what we need to satisfy some security requirements we have which stipulate that we shouldn't have overly permissive ingress or egress rules on our service environment.

However, I'm not sure how to apply the above. We have load-balanced web service, do we need to add the above templates to the addons, and then import VPC into our environments? Seeing as we've already initialised some of our environments, is it possible to import this to existing envs?

Alternatively, is it possible to add the VPC endpoints to our existing VPC using overrides?

[iamhopaul123]

Hello @misaka.

Alternatively, is it possible to add the VPC endpoints to our existing VPC using overrides?

I think for existing environment with services already deployed in, it makes more sense to add VPC endpoints through addons instead of sub. the VPC by importing an existing one, since otherwise you would have to remove all the deployment before replacing the VPC.

[misaka]

Thanks for the response @iamhopaul123

Reading the documentation about Custom Environment Resources it talks about importing an environment when running copilot env init. As we've already initialised and created our envs, is it just a matter copying the generated copilot config resulting from that command, or does copilot do other work in AWS when running env init?

[iamhopaul123]

You don't have to run env init again if you've already created the envs. Instead, you can just update the env manifest to import resources and then run env deploy --diff to apply the changes.