แนะนำบริการ AWS App Runner ในปี 2024

บทความนี้เป็นบทความวันที่ 19 ของ "AWS Introductory Blog Relay 2024" ซึ่งจัดทำโดยแผนกธุรกิจ AWS ของบริษัทเรา

แนวคิดของ Blog Relay นี้คือ การให้สมาชิกที่มักจะเขียนเกี่ยวกับข่าวสารล่าสุดของบริการ AWS หรือหัวข้อเชิงลึกและรายละเอียดต่างๆ ได้ย้อนกลับไปสู่พื้นฐานอีกครั้ง เพื่อทบทวนและอธิบายเนื้อหาพื้นฐานของ AWS

สำหรับผู้ที่กำลังเริ่มต้นเรียนรู้ AWS บทความนี้จะเป็นบทความแนะนำเบื้องต้นตามชื่อของมัน และสำหรับผู้ที่ใช้งาน AWS อยู่แล้ว เราหวังว่าบทความนี้จะช่วยให้คุณค้นพบมุมมองใหม่ๆ เกี่ยวกับบริการของ AWS รวมถึงช่วยให้คุณติดตามการอัปเดตบริการในปีต่อๆ ไปได้อีกด้วย เราหวังว่าคุณจะติดตามอ่านจนจบ และหวังว่าบทความนี้จะเป็นประโยชน์กับคุณ

เอาล่ะ! มาเริ่มกันเลย หัวข้อของวันนี้คือ "AWS App Runner"

AWS App Runner คืออะไร

เมื่อดูที่หน้าเว็บทางการของ App Runner จะพบว่ามีการอธิบายไว้ดังนี้

AWS App Runner สร้างและติดตั้งใช้งานเว็บแอปพลิเคชันโดยอัตโนมัติ ปรับสมดุลโหลดการรับส่งข้อมูลด้วยการเข้ารหัส ปรับขนาดเพื่อตอบสนองความต้องการการรับส่งข้อมูลของคุณ และอนุญาตให้กำหนดค่าวิธีการเข้าถึงบริการและการสื่อสารกับแอปพลิเคชัน AWS อื่นๆ ใน Amazon VPC ส่วนตัว

ตามชื่อที่เรียกว่า "Fully Managed" เพียงแค่เตรียมแอปพลิเคชันคอนเทนเนอร์หนึ่งตัว ส่วนโครงสร้างพื้นฐานที่เหลือ AWS จะจัดการให้ ทำให้สามารถเผยแพร่เว็บแอปพลิเคชันได้อย่างสะดวกสบาย

นอกจาก App Runner แล้ว AWS ยังมีบริการอื่นๆ สำหรับจัดการคอนเทนเนอร์ เช่น Amazon ECS และ Amazon EKS แต่ App Runner ได้รับการออกแบบให้มีการจัดการโครงสร้างพื้นฐานที่เป็นแบบ Managed มากขึ้น ทำให้ผู้ใช้สามารถมุ่งเน้นไปที่การพัฒนาแอปพลิเคชันได้อย่างเต็มที่
ในทางเทคนิค ภายในของ App Runner ใช้ Amazon ECS ที่บริหารโดย AWS และทำงานร่วมกับ AWS Fargate

สำหรับผู้ที่คุ้นเคยกับบริการของผู้ให้บริการคลาวด์รายอื่น อาจเข้าใจได้ง่ายขึ้นหากเปรียบเทียบ App Runner กับ Google Cloud Run หรือ Azure App Service (Web Apps for Containers บน Linux)

โครงสร้างพื้นฐาน

โครงสร้างพื้นฐานของ App Runner เป็นดังภาพด้านล่าง

ใน App Runner แอปพลิเคชันที่เผยแพร่จะถูกลงทะเบียนในรูปแบบของ "Service" โดยภายใน Service จะเป็นการรัน Container Application ที่ใช้ Image เดียวกัน
จำนวน Container Instance จะถูกปรับขนาดโดยอัตโนมัติตามจำนวนคำขอ (Auto Scaling) และ Log ต่างๆ จะถูกส่งออกไปยัง CloudWatch Logs

สำหรับ Container Image ผู้ใช้สามารถเลือกได้ 2 วิธีโดยจะ Push Docker Image ที่สร้างขึ้นเองไปยัง ECR Repository เพื่อใช้งาน หรือเชื่อมต่อกับ Bitbucket หรือ GitHub Repository เพื่อสร้าง Docker Image บน Amazon Linux โดยอัตโนมัติจาก Source Code

ในกรณีที่เชื่อมต่อกับ Source Code ภาษาที่สามารถเลือกใช้ได้ ณ วันนี้คือ

• Python 3.7 - 3.8, 3.11
• Node.js 12, 14, 16, 18
• Java (corretto) 8, 11
• .NET 6
• PHP 8.1
• Ruby 3.1
• Go 1.18

ดูรายละเอียดเพิ่มเติมได้ที่ลิงก์ด้านล่างนี้
App Runner service based on source code

Region พร้อมใช้งานและค่าบริการ

Region ที่พร้อมใช้งานสำหรับ App Runner ณ วันนี้คือ

• N. Virginia
• Ohio
• Oregon
• Mumbai
• Singapore
• Sydney
• Tokyo
• Frankfurt
• Ireland
• London
• Paris

ดูรายละเอียดเพิ่มเติมได้ที่ลิงก์ด้านล่างนี้
AWS App Runner endpoints and quotas

แม้ว่าจำนวน Region จะเพิ่มขึ้นตั้งแต่ปี 2022 แต่เป็นที่น่าเสียดายที่ยังไม่สามารถใช้งานใน Thailand ได้
สำหรับค่าบริการจะถูกเรียกเก็บตามสเปกของ Container Instance (จำนวน CPU และ Memory values) รวมถึงระยะเวลาการใช้งาน
AWS App Runner Pricing (โปรดทราบว่าอัตราค่าบริการของ Singapore Region ระบุไว้ในหมายเหตุ)

มีจุดสำคัญที่ควรทราบอย่างหนึ่งคือ ค่าบริการจะเปลี่ยนแปลงตามสถานะของ Container ที่ถูก Deploy โดยค่าบริการ CPU จะถูกคิดเฉพาะในช่วงที่ Container อยู่ในสถานะ Active เท่านั้น
ส่วนค่าบริการของ Memory จะถูกคิดค่าบริการทันทีที่มีการ Provision โดยไม่ขึ้นกับสถานะของ Container ซึ่งสามารถสรุปได้ดังนี้

• หากมีการ Provision แต่ยังไม่ Active (Inactive): คิดค่าบริการตามขนาดของ Memory
• หากมีการ Provision และอยู่ในสถานะ Active: คิดค่าบริการตามจำนวน vCPU และขนาดของ Memory

โครงสร้างเครือข่าย (Network)

ในการใช้งาน App Runner แบบพื้นฐาน ผู้ใช้ไม่จำเป็นต้องคำนึงถึงโครงสร้างเครือข่ายมากนัก อย่างไรก็ตาม ในทางปฏิบัติ หากเข้าใจโครงสร้างเครือข่าย ก็จะสามารถพัฒนาแอปพลิเคชันที่มีความซับซ้อนมากขึ้นได้

ในโครงสร้างพื้นฐานของ App Runner ที่แสดงไว้ก่อนหน้านี้ จะเห็นว่าไม่มี VPC ปรากฏอยู่เลย [1] ซึ่งจุดนี้เป็นข้อจำกัดสำคัญเมื่อต้องพิจารณาการเชื่อมต่อกับ Data Store โดยค่าเริ่มต้น ผู้ใช้สามารถใช้บริการที่ไม่ขึ้นกับ VPC เช่น DynamoDB หรือใช้ RDS ที่เปิดให้เข้าถึงแบบ Public (รวมถึงบริการฐานข้อมูลที่เปิดให้เข้าถึงสาธารณะอื่นๆ) เท่านั้น

หมายเหตุ
[1] ในความเป็นจริง AWS มี VPC ภายใน ที่ใช้สำหรับจัดการระบบ ซึ่ง Container จะถูกเปิดใช้งานภายในนั้น

ตัวอย่าง Data Store ที่สามารถใช้งานได้ในค่าเริ่มต้น

VPC Connector (ตัวเชื่อมต่อ VPC)

หากต้องการเชื่อมต่อ Resource ภายใน VPC จาก App Runner จำเป็นต้องตั้งค่า "VPC Connector"

ตามชื่อเลยคือ VPC Connector จะทำหน้าที่เป็นตัวเชื่อมต่อจาก App Runner Service ไปยัง User VPC โดยในทางเทคนิคแล้ว ระบบจะสร้าง ENI (Elastic Network Interface) ขึ้นใน Subnet ที่ผู้ใช้กำหนด ทำให้ App Runner สามารถสื่อสารกับเครือข่ายภายใน VPC ได้เสมือนว่าเป็นส่วนหนึ่งของ Subnet นั่นเอง

แผนภาพ VPC Connector

ข้อควรระวังคือ เมื่อมีการตั้งค่า VPC Connector แล้วการสื่อสาร Outbound ของ [2] เกือบทั้งหมดจาก App Runner จะถูกส่งผ่าน VPC ดังนั้นหากต้องการเข้าถึง Internet จำเป็นต้องเตรียม NAT Gateway เพื่อรองรับการเชื่อมต่อดังกล่าว

หมายเหตุ
[2] การสื่อสารที่ใช้สำหรับ Pull Container Image, ส่ง Log ไปยัง CloudWatch Logs และ เข้าถึง Secrets (ซึ่งในเอกสารเรียกว่า "App Runner traffic") ถือเป็นข้อยกเว้น

VPC Endpoint (VPC Interface Endpoint)

นอกจากนี้ App Runner ยังรองรับการใช้ VPC Endpoint ซึ่งช่วยให้สามารถจำกัดการเข้าถึงบริการจากภายใน VPC ได้อีกด้วย

แผนภาพการใช้งาน VPC Endpoint

VPC Endpoint และ VPC Connector สามารถใช้งานร่วมกันได้ และสามารถออกแบบโครงสร้างระบบให้เป็นไปตามตัวอย่างในภาพด้านล่างได้

ตัวอย่างการใช้ VPC Connector และ VPC Endpoint ร่วมกัน

สิ่งที่สามารถทำได้ใน App Runner (ณ เดือนเมษายน 2025)

เราจะสรุปฟีเจอร์ที่สามารถใช้งานได้ใน App Runner ณ ปัจจุบัน

1. Auto scaling

App Runner รองรับ Auto Scaling ตามจำนวน Requests ที่ได้รับ
โดยค่าเริ่มต้นจะกำหนดให้ "1 Container Instance รองรับ 100 Concurrent Requests" และ "จำนวน Instances จะปรับเปลี่ยนแบบไดนามิกอยู่ในช่วง 1 - 25 Instances" เป็นเกณฑ์

2. Auto Deployment

เมื่อมีการ Push Image ใหม่ไปยัง Amazon ECR หรือ Push โค้ดไปยัง Branch ที่กำหนดใน GitHub ระบบสามารถทำ Auto Deployment ของแอปพลิเคชันได้โดยอัตโนมัติ

รูปแบบการ Deploy จะเป็น Blue/Green Deployment อย่างไรก็ตาม App Runner จะจัดการกระบวนการทั้งหมดให้เอง โดยไม่มีการตั้งค่าการ Re-routing เหมือนกับ Amazon ECS

3. Custom Domain

App Runner Service จะได้รับการกำหนด Domain Name ในรูปแบบ [Random ID].[Region Name].awsapprunner.com เป็นค่าเริ่มต้นให้กับแต่ละ Service

ผู้ใช้สามารถเชื่อมโยง Custom Domain ของตนเองเข้ากับ Service และเปิดใช้งาน Automatic SSL Certificate Issuance ได้โดยอัตโนมัติ
นอกจากนี้หากใช้ Route 53 เป็น DNS ระบบยังสามารถลงทะเบียน TXT Record ได้โดยอัตโนมัติอีกด้วย

4. การเชื่อมต่อกับ AWS X-Ray

จากการอัปเดตในเดือนเมษายน 2022 ทำให้สามารถใช้ AWS Distro for OpenTelemetry เพื่อติดตั้ง OpenTelemetry Instrumentation ในแอปพลิเคชัน และรองรับ Distributed Tracing ผ่าน AWS X-Ray ได้
・Tracing for your App Runner application with X-Ray

5. Secrets Management

จากการอัปเดตในเดือนมกราคม 2023 ทำให้สามารถนำ Secrets จาก AWS Secrets Manager และ ค่า Configuration จาก SSM Parameter Store มาใช้เป็น Environment Variables ได้

ด้วยฟีเจอร์นี้ แอปพลิเคชันสามารถเข้าถึงข้อมูลที่มีความสำคัญสูง เช่น Credentials และข้อมูลลับอื่นๆ ผ่าน Environment Variables ได้โดยตรง

6. AWS WAF Integration

จากการอัปเดตในเดือนกุมภาพันธ์ 2023 ทำให้สามารถเลือก App Runner Service เป็นเป้าหมายในการป้องกันจาก AWS WAF ได้แล้ว
ด้วยเหตุนี้ App Runner จึงสามารถตั้งค่าการป้องกันและจำกัดการเข้าถึงได้

7. Monorepo Support

จากการอัปเดตในเดือนกันยายน 2023 ได้เพิ่มความสามารถให้กำหนด Source Directory ได้เมื่อต้องการ Deploy จาก Source Code
(ก่อนหน้านี้ Root Directory จะถูกเลือกโดยอัตโนมัติเป็น Source Directory)
ด้วยเหตุนี้จึงสามารถใช้ App Runner เพื่อ Deploy จาก Repository ที่มีโครงสร้างแบบ Monorepo ได้แล้ว

8. IPv6 Support (Public Endpoint Only)

จากการอัปเดตในเดือนพฤศจิกายน 2023 ได้เพิ่มความสามารถให้สามารถเปิดให้บริการในรูปแบบ Dual Stack ที่รองรับทั้ง IPv4 และ IPv6 ได้
อย่างไรก็ตาม การรองรับ Dual Stack นี้ใช้ได้เฉพาะกับ Public Endpoint เท่านั้น
ส่วนการเข้าถึงแบบ Private ผ่าน VPC Endpoint ยังคงรองรับเฉพาะ IPv4 ตามเดิม

ลองใช้งานจริง

จากนี้เราจะมาลองใช้งาน App Runner กันจริงๆ
ครั้งนี้ผมจะทดสอบโดยใช้บัญชีสำหรับการทดลองใน Singapore Region

0. แอปพลิเคชันสำหรับทดสอบ

เราได้อัปเกรดแอปพลิเคชันตัวอย่างที่เคยสร้างไว้ตอนเขียนบทความแนะนำในปี 2022 ให้เป็นเวอร์ชันใหม่แล้ว
https://github.com/stknohg/app-runner-flask-sample

สามารถทดสอบการเชื่อมต่อกับ DynamoDB และ RDS (for PostgreSQL) ได้ด้วย Python Applications ที่ใช้ Flask + Gunicorn

ตัวอย่างหน้าจอ Home

1. การ Push Image ไปยัง ECR Repository

เมื่อต้นปีนี้ [AWS CloudShell ได้รองรับการใช้งาน Docker แล้ว] จึงทำให้สามารถสร้างแอปพลิเคชันสำหรับการทดสอบทั้งหมดบน CloudShell ได้

เพียงแค่เปิด CloudShell และรันคำสั่งด้านล่างนี้ ระบบจะดาวน์โหลดซอร์สโค้ดจาก GitHub และ Push Docker Image ไปยัง ECR โดยอัตโนมัติ
(※ให้ดำเนินการด้วย User ที่มีสิทธิ์สร้างทรัพยากรต่างๆ ใน AWS)

# 1. สร้าง ECR Repository ชื่อ my-flask-app
aws ecr create-repository --repository-name 'my-flask-app'

# 2. Clone source code + สร้าง Docker Image
git clone https://github.com/stknohg/app-runner-flask-sample.git
cd ./app-runner-flask-sample/
docker build -t my-flask-app .

# 3. Push Docker Image ไปยัง ECR
AWS_ACCOUNT_ID=$(aws sts get-caller-identity --query 'Account' --output text)
aws ecr get-login-password | docker login --username AWS --password-stdin "$AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com"
docker tag my-flask-app:latest "$AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/my-flask-app:latest"
docker push "$AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/my-flask-app:latest"

หากผลลัพธ์ของการรันคำสั่งแสดงเป็น Image ที่มีแท็ก latest ถูกบันทึกอยู่ใน ECR Repository my-flask-app ก็ถือว่าโอเคแล้ว

2. การสร้าง App Runner Service

จากนั้น ให้รันคำสั่งต่อไปนี้บน CloudShell เพื่อสร้าง CloudFormation Stack

สร้าง CloudFormation Stack โดยรันคำสั่งนี้บน CloudShell

# 4. รัน CloudFormation Template (app-runner.yaml) และสร้าง App Runner Service
aws cloudformation create-stack --stack-name my-flask-app --template-body file://./app-runner.yaml --capabilities CAPABILITY_NAMED_IAM

รอสักครู่จนกว่า Stack จะถูกสร้างเสร็จ แล้ว App Runner Service ที่ชื่อ "my-flask-app" ก็น่าจะพร้อมใช้งานแล้ว
โดยตรวจสอบที่หน้าจอ [CloudFormation > Stacks > my-flask-app]

หลังจากนี้สามารถตรวจสอบหรือเปลี่ยนแปลงการตั้งค่าต่างๆ ได้ตามต้องการ และทดสอบการทำงานได้เลย
โดยตรวจสอบที่หน้าจอ [AWS App Runner > Services > my-flask-app]
แล้วคลิกเข้าไปที่ชื่อ Service ครั้งนี้คือ my-flask-app

แล้วคัดลอก Default domain (xxxxxxxxxx.ap-southeast-1.awsapprunner.com) เตรียมไว้

แล้วนำ Default domain มาเปิดบนเว็บเบราว์เซอร์ ก็จะแสดงหน้าจอแบบนี้

เสริม 1: ลองเข้าถึง DynamoDB

ในส่วนเสริมนี้ เราจะลองดึงข้อมูลจาก DynamoDB กัน

ใน App Runner เราสามารถกำหนดสิทธิ์ให้กับ Container Instance เพื่อให้สามารถเข้าถึง AWS Resources ต่างๆ ได้

ครั้งนี้ระบบได้สร้าง IAM Role ชื่อ "my-flask-app-task-role" และเชื่อมโยงกับ App Runner Service ผ่าน CloudFormation ไว้แล้ว

ดูที่หน้าจอ [AWS App Runner > Services > my-flask-app > หัวข้อ Security]

ดูที่หน้าจอ [IAM > Roles > my-flask-app-task-role > แท็บ Permissions > หัวข้อ Permissions policies > ดูที่ my-flask-app-task-policy]

IAM Role นี้ได้รับสิทธิ์ในการเข้าถึง DynamoDB Table Employee และ SSM Parameter Store

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "dynamodb:BatchGetItem",
                "dynamodb:GetShardIterator",
                "dynamodb:GetItem",
                "dynamodb:Scan",
                "dynamodb:Query",
                "dynamodb:GetRecords"
            ],
            "Resource": "arn:aws:dynamodb:ap-northeast-1:xxxxxxxxxxxx:table/Employee",
            "Effect": "Allow",
            "Sid": "DynamoDB"
        },
        {
            "Action": [
                "ssm:GetParameters"
            ],
            "Resource": "arn:aws:ssm:ap-northeast-1:xxxxxxxxxxxx:parameter/my-flask-app/*",
            "Effect": "Allow",
            "Sid": "SSMParameter"
        }
    ]
}

ดังนั้นหากเตรียม DynamoDB Table Employee และใส่ข้อมูลเข้าไป ก็จะสามารถแสดงข้อมูลได้ในลักษณะนี้ได้
※โปรดเตรียม Sample Table ของ Employee data model ใน NoSQL WorkBench โดยดูตัวอย่างได้ที่ลิงก์ด้านล่างนี้

https://dev.classmethod.jp/articles/managing-dynamodb-using-nosql-workbench/

เสริม 2: การเข้าถึง RDS for PostgreSQL

ต่อไปจะเปิดใช้งาน VPC Connector และลองดึงข้อมูลจาก RDS for PostgreSQL ที่เตรียมไว้ภายใน VPC
ให้เตรียม Resource ที่ต้องใช้สำหรับ เปิดใช้งาน VPC Connector ดังนี้
・VPC Environment
・RDS for PostgreSQL Instance (ใน Security Group ของ RDS ให้ Add rule ของ "Security Group สำหรับ VPC Connector" เข้ามาที่นี่เพื่ออนุญาตการเข้าถึงให้กับ App Runner ด้วย เช่น [Type=PostgreSQL | Source=Custom(securit_group_id_for_app_runner)])
・Security Group สำหรับ VPC Connector (Security Group นี้ใช้สำหรับ App Runner ไม่จำเป็นต้องตั้งค่า Inbound rules และ Outbound rules)

หากตั้งค่า Security Group ให้สามารถเชื่อมต่อการสื่อสาร Outbound Traffic ไปยัง RDS ได้ก็ถือว่าโอเค

ครั้งนี้จะใช้ AWS CLI ผ่าน CloudShell เพื่อสร้าง VPC Connector
aws apprunner create-vpc-connector เป็นคำสั่งที่ใช้สร้าง โดยต้องระบุ Subnet ID ที่ต้องการเชื่อมต่อ และ Security Group ID ที่เกี่ยวข้องเป็น Parameter

# สร้าง VPC Connector ด้วยคำสั่ง aws apprunner create-vpc-connector
aws apprunner create-vpc-connector --vpc-connector-name 'ชื่อ VPC Connector' \
    --subnets 'Subnet ID ที่ต้องการเชื่อมต่อ (สามารถระบุหลายค่าได้)' \
    --security-groups 'Security Group ID ที่เตรียมไว้ล่วงหน้า'

เมื่อเปิดใช้งาน CloudShell และรันคำสั่ง ก็จะมีการสร้างขึ้นในลักษณะนี้

# ตัวอย่างการรันบน CloudShell
[cloudshell-user@ip-xx-xz-xx-xx ~]$ aws apprunner create-vpc-connector --vpc-connector-name 'my-vpc-connector' \
>     --subnets subnet-xxxxxxxxxx subnet-yyyyyyyyyy \
>     --security-groups sg-zzzzzzzzzzzzzzzz
{
    "VpcConnector": {
        "VpcConnectorName": "my-vpc-connector",
        "VpcConnectorArn": "arn:aws:apprunner:ap-southeast-1:xxxxxxxxxxxx:vpcconnector/my-vpc-connector/1/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "VpcConnectorRevision": 1,
        "Subnets": [
            "subnet-xxxxxxxxxx",
            "subnet-yyyyyyyyyy"
        ],
        "SecurityGroups": [
            "sg-zzzzzzzzzzzzzzzz"
        ],
        "Status": "ACTIVE",
        "CreatedAt": "2025-02-20T02:46:37.851000+00:00"
    }
}

ด้วยวิธีนี้ VPC Connector my-vpc-connector ได้ถูกสร้างขึ้นแล้ว แต่ยังไม่ได้เชื่อมโยงกับ App Runner Service ดังนั้นจะตั้งค่าดังนี้
・เลือกแท็บ "Configuration" ในหน้าจอ Service และคลิก "Edit"
・เลื่อนลงมาที่หัวข้อ "Networking" แล้วคลิกเพื่อขยายหน้า Detail ลงมา
・เลือก "Custom VPC" ในช่อง "Outgoing network traffic" แล้ว VPC connector จะแสดงขึ้นมา
・และเลือก VPC Connector ที่สร้างเตรียมไว้แล้วในช่อง "VPC Connector" (ครั้งนี้คือ my-vpc-connector)
・เมื่อเสร็จแล้วคลิก "Save changes" แล้วระบบจะเริ่มเปลี่ยนแปลง และเส้นทางการสื่อสารของ Outbound จะถูกอัปเดต

สำหรับแอปพลิเคชันที่ใช้ในการทดสอบครั้งนี้ เราได้เตรียม SSM Parameter Store ชื่อ /my-flask-app/RDSPostgreSQL สำหรับใช้เชื่อมต่อกับ RDS ไว้แล้ว [3]

หมายเหตุ
[3] เพื่อความสะดวกในการสร้าง Environment สำหรับการทดสอบ ด้วย CloudFormation ในครั้งเดียว เราจึงใช้ String แทน SecureString อย่างไรก็ตาม ใน Production Environment ควรใช้ SecureString เพื่อความปลอดภัยที่ดียิ่งขึ้น

ให้แก้ไข Value ด้านล่างสุดตาม Resource ของ RDS ที่สร้างเตรียมไว้ (ครั้งนี้ใช้ PostgreSQL)

postgresql://postgres:[master_password]@[endpoint_rds]:5432/postgres

เมื่ออัปเดตค่าของ Parameter Store แล้ว ทำการ Redeploy App Runner Service โดยคลิก "Deploy"

จากนั้นระบบจะดึงค่าที่อัปเดตจาก SSM Parameter Store และสามารถเชื่อมต่อกับ RDS PostgreSQL ได้

ในฝั่งของ App Runner Service กำหนด Environment Variables ไว้ในลักษณะนี้
(กำหนดค่า Environment Variable POSTGRES_URL ให้เป็น ARN ของ SSM Parameter Store)

ลบ Resource

แนะนำให้ลบ Resource ตามด้านล่างนี้ เนื่องจากหากลบบริการบางอย่างออกไป Resource ในบริการอื่นที่เชื่อมโยงกันจะถูกลบออกโดยอัตโนมัติด้วย ซึ่งจะทำให้ลดขั้นตอนในการลบได้

AWS CloudFormation

Stacks: my-flask-app

※เมื่อลบ Stacks ใน CloudFormation แล้ว รายการ Resource ด้านล่างนี้ก็จะถูกลบด้วยโดยอัตโนมัติ เนื่องจาก Resource เหล่านี้ถูกสร้างมาจากการรัน CloudFormation template
・App Runner Services: my-flask-app
・IAM Role: my-flask-app-task-role
・SSM Parameter Store: /my-flask-app/RDSPostgreSQL

Amazon ECR

Private repositories
Repositories: my-flask-app

AWS App Runner

Networking configuration: my-vpc-connector

RDS

Databases: mydb (ลบ Databases ที่คุณสร้าง)

DynamoDB

Tables: Employee (ครั้งนี้ผมใช้เป็น Tables ใน DynamoDB ที่สร้างเอง)

EC2

Security Group:
・mydb-sg
・my-dev-app-runner-sg

VPC

※หากลบ Resource ที่เชื่อมโยงกับ VPC นี้ทั้งหมดแล้วจะสามารถลบ VPC ได้
VPC: my-vpc

ลบ Resource ใน CloudShell

เข้าไปที่ CloudShell แล้วรันคำสั่งเพื่อลบโฟลเดอร์ "app-runner-flask-sample" ใน CloudShell ดังนี้

cd ~/
rm -rf app-runner-flask-sample

สุดท้ายนี้

จบไปแล้วสำหรับบทความในวันที่ 19 ของ "AWS Introductory Blog Relay 2024" ในหัวข้อ "AWS App Runner"

บทความต้นฉบับ

https://dev.classmethod.jp/articles/introduction-2024-aws-app-runner/

แปลโดย: POP (Tinnakorn Maneewong) จากบริษัท Classmethod (Thailand) ครับ !

บทความที่เกี่ยวข้อง

• การสร้าง NoSQL WorkBench