AAtsushi's Blog
Cloud

Book Notes: Practical Introduction to Cloud Native with AWS

→ 日本語版を読む

Overview

Notes on important points from "Practical Introduction to Cloud Native with AWS."

This time I only read Chapter 2 "Cloud Native Services Built on AWS" and Chapter 3 "Building Container Services."

Chapter 4 "Building CI/CD" will be read when I have time.

About ECR

  • ECR (Elastic Container Registry) does not exist on a VPC; it exists as an AWS regional service
  • Access to ECR is done via the internet or via VPC endpoints
  • To access ECR via VPC endpoints, 3 types of VPC endpoints are required:
    • 2 interface-type VPC endpoints for ECR:
      • com.amazonaws.[region].ecr.api
        • Used for calling ECR APIs such as the awsecr login command
      • com.amazonaws.[region].ecr.dkr
        • Used for calling Docker client commands such as docker push
    • 1 gateway-type VPC endpoint for S3:
      • com.amazonaws.[region].s3
        • Used for Docker image retrieval
  • An interface-type VPC endpoint is an endpoint that allows private connection to individual AWS services via ENI (Elastic Network Interface). Since an IP address is assigned to the ENI, you need to specify a VPC subnet when creating a VPC endpoint.
  • A gateway-type VPC endpoint is like an internet gateway. There is no network interface; you just add a destination for the gateway-type endpoint to the route table to enable private connection to AWS resources.
  • VPC endpoints must be created for each AWS service. Furthermore, time + processed data weight-based billing occurs for each interface-type VPC endpoint (except S3 and DynamoDB). As the number of services used increases, costs can rise, so it's also effective to adopt a NAT gateway while balancing cost and security requirements.
  • The following options can be specified when creating ECR:
    • Tag immutability
      • Does not allow registration with the same tag (prevents overwriting) for Docker image tags representing generation management
    • Scan on push
      • Runs a security vulnerability check when a Docker image is pushed
  • ECR charges based on the storage size of Docker images
  • Lifecycle definitions can be set to delete older generation images
  • Up to 10,000 images can be stored per repository
  • Docker images pushed to ECR are encrypted and stored in an S3 bucket. This bucket is managed by AWS, so it cannot be checked from the user's S3 list. However, when you want to push or pull Docker images from ECR, IAM roles and network paths to S3 are required — be careful.
  • Pricing is slightly higher than S3 (0.10 USD/GB)
  • Pushing to ECR requires a bit of extra work. Since AWS identifies Docker images in ECR per AWS account, you need to push using the IMAGE ID in the specified format:

Image Scanning

  • Vulnerability assessment scanning of Docker images pushed to ECR is implemented based on an OSS called Clair
  • Performs OS-level vulnerability scans such as Red Hat and Ubuntu
  • Application-level scanning is not performed — be careful
  • Also, not all base images are supported
  • For example, Alpine Linux, a lightweight base image, is not supported (verify if still unsupported)
  • If the base image is obtained with latest, check whether it is a supported target

Cloud9

  • By default, authentication permissions are automatically configured with the permissions of the logged-in AWS user
  • This is called AWS Managed Temporary Credentials
  • Using AMTC eliminates the need for EC2 authentication setup, and Cloud9 will periodically update credential information

ECS

  • ECS is the control plane
    • Manages scaling and health monitoring of running containers
  • Fargate is the data plane
    • Provides the resource environment where containers actually run

Container Deployment Flow

  • Register the Docker image in ECR
  • Update the definition on ECS to deploy the registered Docker image
  • ECS, upon receiving the instruction, instructs Fargate to deploy the container based on the Docker image information in the specified ECS definition
  • In Fargate, a micro VM called Firecracker20 is started for each container, and the container runs on top of it

Terminology

ECS cluster > ECS service > Task definition (task)

This is the containment relationship. Note that the ECS service is above the task.

Task Definition

  • The unit of application execution consisting of one or more containers
  • A template definition for creating tasks, written in JSON
  • The JSON specifies the Docker image to deploy, resources and IAM roles assigned to the container, CloudWatch Logs output destination, etc.

Task

  • The actual application instance started from the task definition

Service

  • A scheduler that maintains the specified number of tasks
  • The core function of an orchestration service

Cluster

  • A logical group for running tasks and ECS services

Billing

  • When using Fargate, billing is based on the CPU and memory resources assigned to the task
  • Note that this is not the resources assigned to the container

Log Output

  • Log output definitions are made in the task definition
  • The typical log destination is Cloud Watch Logs
  • Note that the container application's log output must be set to standard output

ECS Cluster Creation Units

About how to aggregate containers.

Scaling Perspective

  • Capacity Provider, a task scaling adjustment function, operates at the ECS cluster level
  • If scaling strategies are the same, they should be aggregated as the same ECS cluster

IAM Control Perspective

  • IAM can be controlled at the ECS cluster level
  • If you want to allow only specific containers, you need to separate the ECS cluster

Business Service Perspective

  • Separating ECS clusters by business granularity such as payment, details, transfers, and screening is easy to understand and makes IAM control easier

Fargate Disadvantages

  • Since it's a managed data plane, you cannot modify the OS where the container runs. Cannot tune OS resources such as kernel parameters.
  • Container startup is slightly slower compared to using EC2 as the data plane
    • Because an ENI is attached and an individual IP is assigned (due to awsvpc mode)
  • Since container images are not cached on the host OS, Docker images are downloaded each time during container startup such as scale-outs

Test Port

  • When enabled, only internal stakeholders can verify container operation via the test port before the new container is publicly exposed

Investigating Task Launch Failures

Debugging Containers

  • Since Fargate is a managed data plane, you cannot log into the container with docker exec -it <container name> /bin/sh
  • Deploy with ECS+EC2 first and check
    • Strictly speaking Fargate and EC2 are different environments, but it's acceptable as a temporary workaround

SSM Parameter Store

  • Can securely store environment variables
  • Seamless integration with containers running on Fargate
  • To load as environment variables on containers, grant access permissions in the ECS task definition:
    • ssm:GetParameters
      • Required for referencing parameter store parameters
    • secretsmanager:GetSecretValue
      • Required when referencing Secrets Manager secrets in the parameter store
    • kms:Decrypt configuration is also needed when using custom KMS keys

Secrets Manager

  • Similar to SSM parameter store, but Secrets Manager has a rotation feature
  • Use Secrets Manager when you want rotation
← Back to articles