Triển khai lưu trữ bền vững cho AWS Fargate và Amazon EBS

Tác giả: Aritra Nag và Siva Shanmugam
Ngày phát hành: 17 MAR 2026
Chuyên mục: Amazon Elastic Block Store (Amazon EBS), Expert (400), Technical How-to

Người dùng yêu thích sự đơn giản của AWS Fargate để chạy các workload được container hóa mà không cần quản lý máy chủ, mở rộng cơ sở hạ tầng hoặc lo lắng về năng lực tính toán cơ bản. Khi người dùng mở rộng việc áp dụng Fargate, họ ngày càng muốn chạy các ứng dụng yêu cầu lưu trữ dữ liệu khối – các hệ thống quản lý nội dung như WordPress lưu giữ các tệp phương tiện đã tải lên và cấu hình plugin, các ứng dụng bán lẻ cần danh mục sản phẩm và dữ liệu khách hàng bền vững, và các pipeline xử lý dữ liệu. Tích hợp Amazon Elastic Block Store (EBS) với Fargate đã thu hẹp khoảng cách này bằng cách cung cấp lưu trữ khối hiệu suất cao, gắn trực tiếp vào các tác vụ Fargate.

Trong bài đăng blog này, chúng tôi sẽ trình bày cách triển khai lưu trữ khối cho các workload Fargate của bạn bằng cách sử dụng tích hợp EBS volume gốc, cho phép bạn chạy các ứng dụng với sự dễ dàng vận hành tương tự như bạn mong đợi từ Fargate.

Thách thức về tính phù du của Container

Khi các tổ chức phát triển danh mục ứng dụng được container hóa của mình, họ muốn tận dụng các lợi ích serverless của Fargate cho các workload ngày càng phức tạp.

Khách hàng tìm cách chạy:

Các hệ thống quản lý nội dung cần lưu trữ đáng tin cậy cho nội dung do người dùng tạo, tệp phương tiện và dữ liệu cấu hình
Các ứng dụng xử lý dữ liệu yêu cầu tính bền vững dữ liệu trung gian qua các giai đoạn xử lý và khởi động lại công việc
Các workload học máy muốn duy trì các điểm kiểm tra mô hình, dữ liệu đào tạo và kết quả suy luận
Các ứng dụng cơ sở dữ liệu cần lưu trữ nhất quán, hiệu suất cao với các đặc tính I/O có thể dự đoán được

Tích hợp EBS gốc với Fargate loại bỏ sự phức tạp này bằng cách cung cấp lưu trữ khối chuyên dụng tích hợp liền mạch với vòng đời của container.

Tổng quan kiến trúc

Giải pháp triển khai kiến trúc đa tầng kết hợp các container serverless với lưu trữ khối trên nhiều Availability Zone (AZ) để đạt được tính sẵn sàng cao.

Architecture overview diagram
Hình ảnh tổng quan kiến trúc

Mỗi tác vụ có một EBS volume chuyên dụng cung cấp lưu trữ io2 hoặc gp3 với hiệu suất nhất quán và mã hóa dữ liệu khi lưu trữ. Các nhóm bảo mật kiểm soát luồng lưu lượng truy cập trong khi Amazon CloudWatch Logs cung cấp khả năng gỡ lỗi.

Quan trọng: Đặc điểm vùng của EBS

EBS là một dịch vụ theo vùng – mỗi EBS volume tồn tại trong một AZ duy nhất và chỉ có thể gắn vào các EC2 instance hoặc tác vụ Fargate trong cùng AZ đó. Thiết kế này làm cho việc tích hợp EBS đặc biệt phù hợp với các ứng dụng cô lập theo vùng như môi trường phát triển và thử nghiệm nơi các workload không yêu cầu dự phòng đa vùng, các công việc xử lý hàng loạt hoạt động trên các tập dữ liệu cục bộ trong một vùng cụ thể, các hệ thống quản lý nội dung phục vụ nội dung dành riêng cho từng vùng và các workload phân tích dữ liệu xử lý dữ liệu nằm trong vùng.

Đối với các ứng dụng yêu cầu tính sẵn sàng dữ liệu đa AZ:

Tận dụng các giải pháp Multi-AZ của doanh nghiệp và mã nguồn mở như Veritas Alta cho sao lưu/khôi phục doanh nghiệp, Distributed Replicated Block Device (DRBD) cho sao chép thiết bị khối thời gian thực, hoặc các giải pháp cũ như Sun Network Data Replicator (SNDR) cho tích hợp cơ sở hạ tầng hiện có.
Sử dụng Amazon EFS (Elastic File System) cho lưu trữ chia sẻ có thể truy cập trên nhiều AZ.
Thiết kế các ứng dụng phi trạng thái với các kho dữ liệu bên ngoài (RDS, DynamoDB) cho trạng thái chia sẻ.
Cân nhắc các quy trình sao lưu và khôi phục dựa trên EBS snapshot cho phục hồi sau thảm họa. Ngoài ra, bạn cũng có thể cân nhắc các tính năng EBS mới ra mắt gần đây như sao chép dựa trên thời gian và Tốc độ được cấp phép cho khởi tạo Volume.

Đối với các ứng dụng cô lập theo vùng:

Mỗi tác vụ Fargate nhận EBS volume riêng trong AZ triển khai của nó.
Dữ liệu vẫn có tính sẵn sàng cao trong vùng nhưng yêu cầu các chiến lược sao lưu để phục hồi đa vùng.

Điều kiện tiên quyết

Trước khi bắt đầu, bạn cần có những điều sau:

Công cụ phát triển

AWS CDK phiên bản 2.0+ – Hướng dẫn thiết lập
Node.js 14.x+ – Tải xuống
Docker Engine – Hướng dẫn cài đặt
Python 3.8+ – Tải xuống
Tài khoản AWS với các quyền thích hợp

Thiết lập môi trường

Cài đặt AWS CDK toàn cục và cấu hình thông tin xác thực AWS của bạn:

			
# Install AWS CDK globally
npm install -g aws-cdk
# Set default account for CDK
export CDK_DEFAULT_ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
# Verify CDK installation
cdk --version

		

Xây dựng cơ sở hạ tầng

Thiết lập nền tảng mạng

Chúng tôi khuyên bạn nên thiết lập nền tảng mạng bằng cách sử dụng Amazon Virtual Private Cloud (VPC) được cấu hình với kiến trúc đa Availability Zone có ít nhất hai AZ, tốt nhất là ba, kết hợp cả public và private subnet với các khối CIDR /24 để cung cấp 256 địa chỉ IP cho mỗi subnet nhằm đảm bảo khả năng mở rộng.

Cấu hình ECS với EBS Volumes và quản lý tính bền vững

Cụm ECS và định nghĩa tác vụ kết hợp cấu hình EBS volume với các cân nhắc cụ thể để duy trì tính bền vững của dữ liệu trong các sự cố dịch vụ, cập nhật và các sự kiện mở rộng:

			
// Create ECS cluster with Container Insights enabled
const cluster = new ecs.Cluster(this, 'Cluster', {
  vpc,
  containerInsights: true // Enable CloudWatch Container Insights
});
// Create Fargate task definition with EBS volume
const taskDefinition = new ecs.FargateTaskDefinition(this, 'TaskDef', {
  memoryLimitMiB: 512, // 512MB memory allocation
  cpu: 256, // 0.25 vCPU allocation
  volumes: [volumeConfiguration] // Attach EBS volume configuration
});

		

Cấu hình container gắn EBS volume tại một đường dẫn cụ thể, làm cho lưu trữ khối có sẵn cho ứng dụng:

			
// Add container to task definition
const container = taskDefinition.addContainer('app', {
  image: ecs.ContainerImage.fromAsset('./app'), // Build from local Dockerfile
  logging: ecs.LogDrivers.awsLogs({
    streamPrefix: 'ecs-ebs',
    logRetention: logs.RetentionDays.ONE_WEEK // Log retention policy
  }),
  environment: {
    STORAGE_PATH: '/data' // Environment variable for storage path
  },
  healthCheck: {
    command: ['CMD-SHELL', 'curl -f http://localhost:5000/health || exit 1'],
    interval: Duration.seconds(30),
    timeout: Duration.seconds(5),
    retries: 3
  }
});
// Mount EBS volume to container filesystem
container.addMountPoints({
  sourceVolume: 'ebs-volume', // Reference to volume configuration
  containerPath: '/data', // Mount point in container
  readOnly: false // Allow read/write operations
});
// Expose container port for load balancer
container.addPortMappings({
  containerPort: 5000,
  protocol: ecs.Protocol.TCP
});

		

Cấu hình cân bằng tải

Cấu hình Application Load Balancer bao gồm kiểm tra sức khỏe và trình nghe HTTPS để giao tiếp an toàn:

			
// Create Application Load Balancer
const loadBalancer = new elbv2.ApplicationLoadBalancer(this, 'ALB', {
  vpc: vpc,
  internetFacing: true, // Public-facing load balancer
  securityGroup: albSecurityGroup,
  loadBalancerName: 'fargate-ebs-alb'
});
// Create target group for Fargate tasks
const targetGroup = new elbv2.ApplicationTargetGroup(this, 'TargetGroup', {
  vpc: vpc,
  port: 5000, // Container port
  protocol: elbv2.ApplicationProtocol.HTTP,
  targetType: elbv2.TargetType.IP, // Required for Fargate
  healthCheck: {
    path: '/health', // Health check endpoint
    healthyHttpCodes: '200',
    interval: Duration.seconds(30),
    timeout: Duration.seconds(5),
    healthyThresholdCount: 2,
    unhealthyThresholdCount: 3
  },
  deregistrationDelay: Duration.seconds(30) // Fast deregistration for development
});
// HTTPS listener with SSL certificate
const httpsListener = loadBalancer.addListener('HttpsListener', {
  port: 443,
  certificates: [certificate], // SSL certificate from ACM
  defaultAction: elbv2.ListenerAction.forward([targetGroup])
});
// Redirect HTTP to HTTPS
loadBalancer.addListener('HttpListener', {
  port: 80,
  defaultAction: elbv2.ListenerAction.redirect({
    protocol: 'HTTPS',
    port: '443',
    permanent: true
  })
});

		

Triển khai dịch vụ Fargate

Cấu hình dịch vụ Fargate tập hợp tất cả các thành phần với khả năng tự động mở rộng:

			
// Create Fargate service
const fargateService = new ecs.FargateService(this, 'FargateService', {
  cluster: cluster,
  taskDefinition: taskDefinition,
  desiredCount: 2, // Start with 2 tasks for high availability
  assignPublicIp: false, // Tasks run in private subnets
  securityGroups: [ecsSecurityGroup],
  vpcSubnets: {
    subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS // Deploy in private subnets
  },
  healthCheckGracePeriod: Duration.seconds(60), // Allow time for startup
  serviceName: 'fargate-ebs-service'
});
// Attach service to target group
fargateService.attachToApplicationTargetGroup(targetGroup);
// Configure auto-scaling
const scaling = fargateService.autoScaleTaskCount({
  minCapacity: 2, // Minimum tasks for availability
  maxCapacity: 10 // Maximum tasks for cost control
});
// Scale based on CPU utilization
scaling.scaleOnCpuUtilization('CpuScaling', {
  targetUtilizationPercent: 70, // Scale out at 70% CPU
  scaleInCooldown: Duration.minutes(5), // Wait 5 minutes before scaling in
  scaleOutCooldown: Duration.minutes(2) // Wait 2 minutes before scaling out
});
// Scale based on memory utilization
scaling.scaleOnMemoryUtilization('MemoryScaling', {
  targetUtilizationPercent: 80, // Scale out at 80% memory
  scaleInCooldown: Duration.minutes(5),
  scaleOutCooldown: Duration.minutes(2)
});

		

Triển khai ứng dụng

Trong ứng dụng flask này, chúng tôi đang trình bày một ví dụ không dùng cho sản xuất về tải tệp lên. Để có các phương pháp hay nhất, chúng tôi khuyên bạn nên thêm một kiểm tra sức khỏe vào ứng dụng để được gọi từ Application Load Balancer:

			
from flask import Flask, jsonify, request, send_file
import os
import logging
from datetime import datetime
import boto3
# Configure logging
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)
app = Flask(__name__)
# Get storage path from environment variable
STORAGE_PATH = os.environ.get('STORAGE_PATH', '/data')
@app.route('/health')
def health():
    """Basic health check endpoint for load balancer"""
    return jsonify({'status': 'healthy', 'timestamp': datetime.utcnow().isoformat()})
@app.route('/files', methods=['GET'])
def list_files():
    """List all files in the block storage"""
    try:
        if not os.path.exists(STORAGE_PATH):
            return jsonify({'error': 'Storage path does not exist'}), 404
        files = []
        for filename in os.listdir(STORAGE_PATH):
            filepath = os.path.join(STORAGE_PATH, filename)
            if os.path.isfile(filepath):
                stat = os.stat(filepath)
                files.append({
                    'name': filename,
                    'size': stat.st_size,
                    'modified': datetime.fromtimestamp(stat.st_mtime).isoformat()
                })
        return jsonify({
            'files': files,
            'count': len(files),
            'storage_path': STORAGE_PATH
        })
    except Exception as e:
        logger.error(f"Failed to list files: {str(e)}")
        return jsonify({'error': str(e)}), 500
@app.route('/upload', methods=['POST'])
def upload_file():
    """Upload a file to block storage"""
    if 'file' not in request.files:
        return jsonify({'error': 'No file provided'}), 400
    file = request.files['file']
    if file.filename == '':
        return jsonify({'error': 'No selected file'}), 400
    try:
        # Ensure storage directory exists
        os.makedirs(STORAGE_PATH, exist_ok=True)
        # Save file to block storage
        filepath = os.path.join(STORAGE_PATH, file.filename)
        file.save(filepath)
        # Get file information
        stat = os.stat(filepath)
        logger.info(f"File uploaded successfully: {file.filename}")
        return jsonify({
            'message': 'File uploaded successfully',
            'filename': file.filename,
            'size': stat.st_size,
            'path': filepath
        })
    except Exception as e:
        logger.error(f"Failed to upload file: {str(e)}")
        return jsonify({'error': str(e)}), 500
if __name__ == '__main__':
    # Create storage directory if it doesn't exist
    os.makedirs(STORAGE_PATH, exist_ok=True)
    # Start Flask application
    app.run(host='0.0.0.0', port=5000, debug=False)

		

Xử lý gián đoạn và cập nhật tác vụ

Khi chạy các ứng dụng trên Fargate với EBS volumes, một trong những thách thức vận hành quan trọng nhất là duy trì tính liên tục của dữ liệu trong các sự kiện vòng đời dịch vụ.

Các tác vụ Fargate có thể được thay thế do nhiều kịch bản khác nhau:

Cập nhật dịch vụ khi triển khai các phiên bản ứng dụng mới
Bảo trì cơ sở hạ tầng do AWS thực hiện trên nền tảng tính toán cơ bản
Gián đoạn Spot khi sử dụng giá Fargate Spot
Các sự kiện tự động mở rộng quy mô chấm dứt và tạo các tác vụ mới
Lỗi kiểm tra sức khỏe kích hoạt thay thế tác vụ

Khi một tác vụ chấm dứt, EBS volume được gắn vào nó trở thành mồ côi — và tác vụ thay thế vẫn cần truy cập vào dữ liệu đó. Bạn có thể giải quyết thách thức này bằng cách tạo một snapshot của volume mồ côi và khôi phục nó vào một volume mới cho tác vụ thay thế. Chúng tôi khuyên bạn nên triển khai quản lý volume dựa trên sự kiện: khi các sự kiện dịch vụ ECS xảy ra (cập nhật, mở rộng quy mô hoặc gián đoạn), Amazon CloudWatch Events sẽ kích hoạt một hàm AWS Lambda điều phối toàn bộ vòng đời bền vững của volume.

Để ngăn chặn một vòng lặp vô hạn — nơi AWS Lambda khởi chạy một tác vụ thay thế tạo ra các sự kiện ECS mới kích hoạt lại hàm — giải pháp phải bao gồm các biện pháp bảo vệ chống vòng lặp. Khi AWS Lambda khởi động một tác vụ thay thế, nó sẽ gắn thẻ cho tác vụ đó bằng một dấu hiệu (ví dụ: managed-by: ebs-lifecycle-lambda). Hàm kiểm tra thẻ này khi bắt đầu mỗi lần gọi và bỏ qua quá trình xử lý nếu thẻ đó có mặt. Ngoài ra, một kiểm tra tính bất biến của DynamoDB đảm bảo rằng một tổ hợp volume/tác vụ được xử lý nhiều nhất một lần, ngay cả khi có các lần thử lại hoặc các lần gọi đồng thời. Quy tắc CloudWatch Events cũng được giới hạn trong các cụm, dịch vụ hoặc họ định nghĩa tác vụ cụ thể để tránh kích hoạt các thay đổi trạng thái tác vụ không liên quan.

Kịch bản cập nhật dịch vụ

ECS khởi tạo một triển khai cuốn chiếu của định nghĩa tác vụ mới.
CloudWatch phát hiện các thay đổi trạng thái tác vụ (TASK_STOPPING hoặc TASK_STOPPED) và kích hoạt hàm AWS Lambda.
AWS Lambda kiểm tra thẻ managed-by: ebs-lifecycle-lambda — nếu có, quá trình xử lý sẽ bị bỏ qua để ngăn chặn việc nhập lại.
AWS Lambda kiểm tra DynamoDB để xác nhận tổ hợp volume/tác vụ chưa được xử lý (kiểm tra tính bất biến).
AWS Lambda xác định các EBS volumes được gắn vào các tác vụ đang chấm dứt.
AWS Lambda truy xuất chi tiết volume và tạo một snapshot.
Tham chiếu snapshot được ghi lại trong một bảng Amazon DynamoDB.
AWS Lambda tạo các định nghĩa tác vụ riêng lẻ được điều chỉnh cho từng cấu hình volume yêu cầu, gắn thẻ tất cả các tác vụ thay thế bằng managed-by: ebs-lifecycle-lambda.

Đối với các dịch vụ yêu cầu DesiredCount=N, kiến trúc hỗ trợ N dịch vụ riêng biệt mỗi dịch vụ có DesiredCount=1, hoặc chuyển đổi sang ECS Standalone Tasks thay vì ECS Services.

Chiến lược bền vững volume này cung cấp các lợi thế vận hành giúp tăng cường độ tin cậy và khả năng quản lý của các ứng dụng trên Fargate. Việc triển khai ứng dụng diễn ra mà không mất dữ liệu, cho phép các phương pháp phân phối liên tục cho các ứng dụng được thiết kế dưới dạng dịch vụ một instance. Mô hình này hoạt động tốt nhất cho các dịch vụ một tác vụ hoặc các ứng dụng có thể được phân tách thành nhiều dịch vụ một tác vụ, thay vì các triển khai dịch vụ đa bản sao truyền thống. Chúng tôi khuyên bạn nên triển khai quản lý vòng đời snapshot thích hợp thay vì bỏ qua việc dọn dẹp. Các snapshot mồ côi không có chính sách vòng đời sẽ tạo ra chi phí không cần thiết và gánh nặng vận hành.

Lưu ý quan trọng về EBS Snapshots cho hệ thống phân tán: Khi sử dụng EBS snapshots để sao lưu và khôi phục trong môi trường phân tán, hãy lưu ý rằng các snapshot ad-hoc không tự động duy trì tính nhất quán của ứng dụng hoặc tính nhất quán khi gặp sự cố trên nhiều volume, yêu cầu phối hợp thủ công để đảm bảo tính toàn vẹn của dữ liệu. Ngoài ra, việc khôi phục snapshot là một hoạt động nỗ lực tốt nhất với thời gian không xác định. Để tối ưu hóa hiệu suất, hãy cân nhắc tận dụng tốc độ cấp phép cấp nước volume mới của AWS để tăng tốc khôi phục và giảm thiểu mục tiêu điểm khôi phục trong khi cân bằng chi phí lưu trữ và độ phức tạp vận hành.

Kiểm tra và xác thực

Trước khi chạy các bài kiểm tra của bạn, hãy đảm bảo các EBS volumes của bạn được gắn vào các tác vụ Fargate của bạn. Bạn có thể xác minh điều này trong AWS Console bằng cách điều hướng đến ECS > Clusters > Tasks > tab Volumes.

EBS volumes attached to Fargate tasks in AWS Console
Hình ảnh: Các EBS volume được gắn vào các tác vụ Fargate trong AWS Console

Bước 1: Lấy URL của Load Balancer

Sau khi triển khai, hãy xác thực việc triển khai bằng cách kiểm tra các endpoint và hoạt động khác nhau. Đầu tiên, lấy URL của Application Load Balancer từ các output của CloudFormation:

			
# Get ALB DNS name from CloudFormation outputs
ALB_URL=$(aws cloudformation describe-stacks \
  --stack-name EcsEbsStack \
  --query 'Stacks[0].Outputs[?OutputKey==`LoadBalancerDNS`].OutputValue' \
  --output text)
echo "Application Load Balancer URL: https://${ALB_URL}"
# Verify ALB is responding
curl -I https://${ALB_URL}/health

		

Bước 2: Kiểm tra các thao tác tệp Tải lên một tệp kiểm tra để xác minh các thao tác ghi:

			
# Create a test file
echo "This is a test file for EBS persistence validation" > test.txt
echo "Created at: $(date)" >> test.txt
# Upload test file
echo "Uploading test file..."
curl -X POST -F "file=@test.txt" https://${ALB_URL}/upload
# List files to confirm upload
echo "Listing files in block storage..."
curl -s https://${ALB_URL}/files | jq '.'
# Download the file to verify content
echo "Downloading uploaded file..."
curl -o downloaded-test.txt https://${ALB_URL}/download/test.txt
# Verify file content
echo "Verifying downloaded file content..."
cat downloaded-test.txt

		

Trình tự kiểm tra này xác thực cả việc gắn EBS volume và khả năng của ứng dụng để thực hiện các thao tác đọc và ghi trên lưu trữ khối.

Phân tích chi phí

Bảng sau đây phân tích chi phí hàng tháng cho một triển khai điển hình trong khu vực us-east-1 với hai tác vụ chạy liên tục:

Hạng mục	Chi phí hàng tháng
Tính toán (Fargate)	$35.55
Lưu trữ (EBS)	$1.60
Tổng chi phí ước tính	$37

Dọn dẹp

Xóa tất cả các tài nguyên để tránh các khoản phí liên tục với xác minh thích hợp:

			
# Step 1: Delete the CDK stack
echo "Initiating stack deletion..."
cdk destroy --force
# Step 2: Verify deletion progress
echo "Monitoring deletion progress..."
aws cloudformation describe-stacks \
  --stack-name EcsEbsStack \
  --query 'Stacks[0].StackStatus' \
  --output text
# Step 3: Check for any remaining resources
echo "Checking for orphaned resources..."
# List any remaining EBS volumes
aws ec2 describe-volumes \
  --filters "Name=tag:aws:cloudformation:stack-name,Values=EcsEbsStack" \
  --query 'Volumes[*].[VolumeId,State]' \
  --output table
# List any remaining security groups
aws ec2 describe-security-groups \
  --filters "Name=tag:aws:cloudformation:stack-name,Values=EcsEbsStack" \
  --query 'SecurityGroups[*].[GroupId,GroupName]' \
  --output table

		

Các cân nhắc khi triển khai sản xuất

Đối với các triển khai sản xuất, hãy thực hiện các cân nhắc bổ sung này để đảm bảo độ tin cậy, bảo mật và xuất sắc trong vận hành:

Cấu hình đa vùng bao gồm triển khai đa vùng để phục hồi sau thảm họa, cho phép chuyển đổi dự phòng tự động và sao chép dữ liệu trên các AWS region phân tán về mặt địa lý.
Triển khai chiến lược sao lưu và phục hồi bao gồm tạo và xóa EBS snapshot tự động, sao chép sao lưu đa vùng và khả năng phục hồi tại một thời điểm.
Các quy trình phục hồi sau thảm họa với các mục tiêu thời gian phục hồi (RTO) và mục tiêu điểm phục hồi (RPO) được xác định để đảm bảo tính liên tục của doanh nghiệp và bảo vệ dữ liệu chống lại các kịch bản lỗi khác nhau.

Kết luận

Tích hợp EBS volume gốc với AWS Fargate cung cấp một giải pháp mạnh mẽ cho các yêu cầu lưu trữ khối trong các ứng dụng được container hóa. Việc triển khai này trình bày cách kết hợp thực thi container serverless với lưu trữ khối chuyên dụng trong khi vẫn duy trì các tiêu chuẩn bảo mật và vận hành.

Sẵn sàng hiện đại hóa chiến lược lưu trữ container hóa của bạn? Hãy bắt đầu tích hợp EBS volumes với các workload AWS Fargate của bạn ngay hôm nay. Khám phá tài liệu AWS để bắt đầu, hoặc liên hệ với kiến trúc sư giải pháp AWS của bạn để thiết kế một kiến trúc lưu trữ phù hợp với nhu cầu ứng dụng của bạn.

Về tác giả

Aritra Nag
Aritra Nag là Kiến trúc sư Giải pháp tại Amazon Web Services, nơi anh hỗ trợ khách hàng trong việc thiết kế và triển khai các giải pháp đám mây. Ngoài chuyên môn sâu về kiến trúc đám mây, Aritra còn có kinh nghiệm sâu rộng về DevOps và Hiện đại hóa, giúp các tổ chức khai thác toàn bộ tiềm năng của đổi mới dựa trên dữ liệu.

Siva Shanmugam
Siva Shanmugam là Kiến trúc sư Giải pháp cấp cao tại Amazon Web Services, chuyên về AI/ML, Dữ liệu và kiến trúc cloud-native. Chuyên môn của anh bao gồm các ứng dụng AI tạo sinh và tác nhân, Chuyển đổi trải nghiệm nhà phát triển — bao gồm Mã hóa tác nhân và các phương pháp kỹ thuật được hỗ trợ bởi AI — và các giải pháp đám mây doanh nghiệp đầu cuối.