在 Amazon Linux 2023 上部署 GPU 容器环境：快速入门指南

摘要：本文旨在为客户提供一份清晰、可操作的快速安装指导，涵盖前置条件说明、安装配置步骤、验证方法及常见故障排除，帮助客户在 Amazon Linux 2023 上快速完成 GPU 容器环境的搭建。

1. 概述

随着深度学习、机器学习推理和科学计算需求的快速增长，越来越多的客户选择在 GPU 实例上以容器方式运行工作负载。容器化部署不仅能够简化环境管理、提升资源利用率，还能确保模型训练和推理任务在不同环境中的一致性。

Amazon Linux 2023（AL2023）是亚马逊云科技提供的下一代 Amazon Linux，可在安全、稳定和高性能的运行时环境中开发和运行云及企业应用程序。在 AL2023 上搭建 GPU 容器环境，需要依次完成三个核心组件的安装与配置：

• NVIDIA GPU 驱动：宿主机与 GPU 硬件通信的基础，负责管理 GPU 设备。
• Docker：容器运行时，提供容器的创建、运行和管理能力。
• NVIDIA Container Toolkit：连接 Docker 与 GPU 驱动的关键中间层，通过 OCI 运行时钩子将宿主机 GPU 设备和驱动库注入容器，使容器内的应用无需自行安装驱动即可直接使用 GPU 资源。

本文旨在为客户提供一份清晰、可操作的快速安装指导，涵盖前置条件说明、安装配置步骤、验证方法及常见故障排除，帮助客户在 Amazon Linux 2023 上快速完成 GPU 容器环境的搭建。

支持的实例类型

本文适用于以下在亚马逊云科技中国区域可用的 x86_64 架构 NVIDIA GPU 实例：

注意

• 本文仅适用于 x86_64 架构实例。ARM 架构 GPU 实例（G5g，基于 Graviton2 + NVIDIA T4G）和 AMD GPU 实例（G4ad）目前在亚马逊云科技中国区域不可用，且安装步骤有所不同。
• 各实例类型在中国区域的实际可用性，请以 亚马逊云科技中国区域实例类型 页面为准。

2. 安装前的准备工作

在开始安装前，请确保满足以下条件：

• 支持 GPU 的 Amazon EC2 实例：已启动上述表格中的任一 GPU 实例，操作系统为 Amazon Linux 2023（x86_64），且实例处于运行状态。
• 登录至实例并确保登录用户有 sudo 权限：通过 SSH 客户端或 AWS Systems Manager Session Manager 连接到实例，确保使用拥有 sudo 权限的用户（如默认的 ec2-user）。
• 网络连接：通过查看 AL2023 DNF 仓库配置 /etc/yum.repos.d/amazonlinux.repo，可以发现 AL2023 的 DNF 仓库软件包实际托管于 Amazon Simple Storage Service（Amazon S3） 存储桶。因此，若实例无法访问互联网，需在实例所在的 Amazon Virtual Private Cloud（Amazon VPC）中配置 Amazon S3 VPC 网关终端节点，以便实例能够通过私有连接访问 AL2023 系统仓库。此外，安装 NVIDIA Container Toolkit 及后续拉取容器镜像，同样需要能够访问对应的软件仓库和镜像仓库（公网或通过 Amazon Elastic Container Registry 接口终端节点）。

在开始安装前，确认实例已正确识别 GPU 硬件：

$ lspci | grep -i nvidia

预期输出示例：

00:1e.0 3D controller: NVIDIA Corporation GA102GL [A10G] (rev a1)

3. 安装 NVIDIA GPU 驱动

3.1 更新系统并安装依赖

在安装驱动之前，需要先更新现有软件包，并安装驱动编译所需的内核开发工具：

$ sudo dnf update -y
$ sudo dnf install -y gcc kernel-devel-$(uname -r) kernel-headers-$(uname -r) make

3.2 检查 Nouveau 驱动（可选）

Nouveau 是开源的 NVIDIA 兼容驱动，会与官方 NVIDIA 驱动产生冲突。官方 AL2023 AMI 默认不包含 Nouveau 驱动，通常可跳过此步骤。如使用自定义 AMI 或从其他发行版迁移而来，先执行检查：

$ lsmod | grep nouveau

若上述命令没有输出，说明系统未加载 Nouveau 驱动，可直接跳到 2.3 节。若有输出，需执行以下步骤禁用 Nouveau 驱动：

# 创建黑名单配置文件
$ sudo tee /etc/modprobe.d/blacklist-nouveau.conf <<EOF
blacklist nouveau
options nouveau modeset=0
EOF
# 备份当前 initramfs（便于回滚）
$ sudo cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).img.bak
# 重新生成 initramfs
$ sudo dracut --force
# 重启系统使配置生效
$ sudo reboot

重启后再次执行 lsmod | grep nouveau，若无输出则说明 Nouveau 已成功禁用。

3.3 安装 NVIDIA 驱动

3.3.1 选择驱动模块流

NVIDIA 驱动提供两种内核模块风格，在本节的安装命令中以模块流（module stream）的形式体现，需根据实例的 GPU 架构选择：

说明：开源内核模块是 NVIDIA 推荐的现代方案，但仅支持 Turing 及之后的架构；Volta（V100）及更早的 GPU 必须使用专有驱动模块流。两者都支持 DKMS 在内核更新后自动重新编译，使用方式一致，只需将下文安装命令中的 nvidia-driver:open-dkms 替换为 nvidia-driver:latest-dkms 即可。

本文后续命令以 open-dkms 为例，请根据实际实例类型替换。

3.3.2 安装方式

提供两种安装方式，根据实例的网络环境选择。

方法一：网络仓库安装（推荐）

适合实例可以访问互联网的场景，通过 NVIDIA 官方网络仓库在线安装。

步骤 1：配置 NVIDIA CUDA 仓库

$ sudo dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/amzn2023/x86_64/cuda-amzn2023.repo
$ sudo dnf clean expire-cache

步骤 2：安装 NVIDIA 驱动

# 启用驱动模块流（以 Turing+ 架构为例，Volta/Maxwell 请改用 latest-dkms）
$ sudo dnf module enable nvidia-driver:open-dkms -y
# 安装驱动
$ sudo dnf install -y nvidia-open

步骤 3：重启系统

$ sudo reboot

方法二：本地安装包（适合离线环境）

适合实例位于私有子网无法访问互联网的场景。在有网络的机器上下载安装包，通过 SCP 等方式传输到目标实例后执行安装。

步骤 1：下载 CUDA 本地安装包

# 以 CUDA 13.0 为例，更多版本请访问 https://developer.nvidia.com/cuda-downloads
$ wget https://developer.download.nvidia.com/compute/cuda/13.0.0/local_installers/cuda-repo-amzn2023-13-0-local-13.0.0_580.65.06-1.x86_64.rpm

步骤 2：安装本地仓库并安装驱动

$ sudo rpm -i cuda-repo-amzn2023-13-0-local-13.0.0_580.65.06-1.x86_64.rpm
$ sudo dnf clean all
# 以 Turing+ 架构为例，Volta/Maxwell 请将模块流改为 latest-dkms
$ sudo dnf module install nvidia-driver:open-dkms -y

步骤 3：重启系统

$ sudo reboot

3.4 验证驱动安装

重启完成后，执行以下命令验证驱动是否正常加载：

$ nvidia-smi

成功安装后的输出示例：

[图 1]

3.5 配置驱动持久化模式（推荐）

持久化模式使 NVIDIA 驱动在没有活跃 GPU 进程时仍保持加载状态，避免每次访问 GPU 时重新初始化驱动，从而减少启动延迟。在容器频繁启停的场景下，开启持久化模式尤为重要。

# 立即启用持久化模式（当前会话生效）
$ sudo nvidia-smi -pm 1
# 配置开机自动启用（重启后仍然生效）
$ sudo systemctl enable nvidia-persistenced
$ sudo systemctl start nvidia-persistenced

验证：执行 nvidia-smi 后，查看输出中的 Persistence-M 列，显示 On 即表示持久化模式已启用。

[图 2]

4. 安装配置 Docker

4.1 安装 Docker

在 AL2023 中，Docker 已包含在默认的软件源中，可直接使用 dnf 命令安装：

$ sudo dnf install -y docker

启动 Docker 服务并设置开机自启动：

# 启动 Docker
$ sudo systemctl start docker
# 设置开机自启
$ sudo systemctl enable docker
# 检查运行状态
$ sudo systemctl status docker

4.2 配置用户权限（测试环境推荐）

默认情况下，运行 Docker 命令需要 sudo 权限。在开发或测试环境中，为了减少频繁输入 sudo，可将当前用户（例如 ec2-user）添加到 docker 用户组，后续运行 Docker 命令时无需携带 sudo。

将用户加入 docker 用户组：

$ sudo usermod -aG docker $USER

使权限生效：

退出当前会话（断开 SSH 或 Session Manager 连接）并重新登录，或直接运行以下命令刷新当前会话的组成员身份：

$ newgrp docker

5. 安装 NVIDIA Container Toolkit

NVIDIA Container Toolkit 是实现容器访问宿主机 GPU 的关键组件。它通过 OCI 运行时钩子，在容器启动时自动将宿主机的 GPU 设备文件和 NVIDIA 驱动库挂载进容器，使容器内的应用无需自行安装驱动即可直接调用 GPU 资源。

5.1 配置 NVIDIA Container Toolkit 仓库

$ curl -s -L https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo | \
  sudo tee /etc/yum.repos.d/nvidia-container-toolkit.repo

5.2 安装 NVIDIA Container Toolkit

5.2.1 DNF 命令直接安装（适用于实例可以访问互联网）

$ sudo dnf install -y nvidia-container-toolkit

5.2.2 离线安装（适合无法访问互联网的环境）

若实例无法访问 NVIDIA 软件仓库，可在有网络的机器上预先下载 RPM 包，再传输到目标实例进行离线安装。

步骤 1：在有网络的机器上下载 RPM 包（含依赖）

# 添加 NVIDIA Container Toolkit 仓库
$ sudo dnf config-manager --add-repo \
  https://nvidia.github.io/libnvidia-container/stable/rpm/nvidia-container-toolkit.repo
# 下载 nvidia-container-toolkit 及其所有依赖包到指定目录
$ sudo dnf download --resolve --destdir ./nvidia-ctk-rpms nvidia-container-toolkit

步骤 2：将下载的 RPM 包传输到目标实例

$ scp -r ./nvidia-ctk-rpms/ ec2-user@<目标实例 IP>:~/

步骤 3：在目标实例上离线安装

$ cd ~/nvidia-ctk-rpms/
$ sudo dnf install -y ./*.rpm

5.3 配置 Docker 使用 NVIDIA 运行时

$ sudo nvidia-ctk runtime configure --runtime=docker
$ sudo systemctl restart docker

nvidia-ctk runtime configure 命令会自动在 /etc/docker/daemon.json 中写入 NVIDIA 运行时配置，且会保留已有的 data-root、log-driver 等配置项。验证配置是否已正确写入：

$ cat /etc/docker/daemon.json

预期输出中包含以下内容：

{
  "runtimes": {
    "nvidia": {
      "path": "nvidia-container-runtime",
      "runtimeArgs": []
    }
  }
}

6. 验证 GPU 容器环境

由于中国区无法直接访问 Docker Hub，本文使用亚马逊云科技提供的 AWS Deep Learning Containers 镜像进行验证。该镜像托管在 Amazon ECR Public Gallery 仓库中，已预装 CUDA 运行时和主流深度学习框架，可直接用于验证 GPU 容器环境。

6.1 在容器内运行 nvidia-smi

$ docker run --rm --gpus all \
  public.ecr.aws/deep-learning-containers/pytorch:2.11-cu130-amzn2023 \
  nvidia-smi

若容器内的输出与宿主机执行 nvidia-smi 的结果一致，说明容器已成功访问 GPU。

• --gpus 参数说明：
• --gpus all：将宿主机所有 GPU 挂载进容器。
• --gpus '"device=0"'：仅挂载编号为 0 的 GPU。
• --gpus 2：挂载前 2 块 GPU。

6.2 验证容器内可见的 GPU 设备

$ docker run --rm --gpus all \
  public.ecr.aws/deep-learning-containers/pytorch:2.11-cu130-amzn2023 \
  nvidia-smi -L

预期输出示例：

GPU 0: NVIDIA A10G (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)

6.3 验证 PyTorch GPU 可用性（可选）

如需进一步验证深度学习框架能否正常调用 GPU：

$ docker run --rm --gpus all \
  public.ecr.aws/deep-learning-containers/pytorch:2.11-cu130-amzn2023 \
  python3 -c "import torch; print('CUDA available:', torch.cuda.is_available()); print('GPU:', torch.cuda.get_device_name(0))"

预期输出示例：

CUDA available: True
GPU: NVIDIA A10G

7. 最佳实践

7.1 配置 Docker 数据目录与日志滚动

Docker 默认将镜像、容器、卷等数据存储在 /var/lib/docker 目录，而实例根卷空间通常有限。GPU 工作负载所使用的容器镜像（如深度学习框架镜像）体积通常较大，动辄数 GB 至数十 GB。生产环境建议挂载独立的 Amazon Elastic Block Store（Amazon EBS） 数据卷，并将 Docker 数据目录迁移至该卷，避免根卷空间耗尽导致实例异常。同时，Docker 容器默认使用 json-file 日志驱动且不限制日志文件大小，长期运行的容器日志会持续增长，本节同时配置全局日志滚动策略以避免磁盘耗尽。

步骤一：挂载 EBS 卷作为实例数据卷

在 AWS 控制台或通过 AWS CLI 创建并挂载 EBS 卷至实例（假设设备名为 /dev/nvme1n1），然后格式化并挂载：

# 第一步：通过 SERIAL 列确认设备对应的 EBS Volume ID（Nitro 实例支持）
# SERIAL 列显示的值在 "vol" 字符串后加上 "-" 即为 Volume ID，如 vol-011cb59b7addxxxxx
$ lsblk -o NAME,SERIAL
NAME          SERIAL
nvme0n1       vol0a1b2c3d4e5fxxxxx
nvme1n1       vol011cb59b7addxxxxx
# 第二步：检查设备是否已有文件系统（FSTYPE 列为空表示未格式化，可安全继续）
$ lsblk -f /dev/nvme1n1
NAME     FSTYPE LABEL UUID MOUNTPOINTS
nvme1n1
# 第三步：确认无误后格式化为 xfs 文件系统
$ sudo mkfs -t xfs /dev/nvme1n1
# 创建挂载点
$ sudo mkdir -p /data/docker
# 挂载数据卷
$ sudo mount /dev/nvme1n1 /data/docker

配置数据卷开机自动挂载，使用 UUID 更稳定（设备名在重启后可能变化）：

# 查询设备 UUID
$ sudo blkid /dev/nvme1n1
/dev/nvme1n1: UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" BLOCK_SIZE="512" TYPE="xfs"
# 将 UUID 追加到 /etc/fstab（替换下方 <UUID> 为实际值）
$ echo 'UUID=<UUID> /data/docker xfs defaults,nofail 0 2' | sudo tee -a /etc/fstab

步骤二：配置 Docker 使用新数据目录并启用日志滚动

停止 Docker 服务，迁移现有数据，并一次性写入包含数据目录与日志滚动的 Docker daemon 配置：

$ sudo systemctl stop docker
# 迁移现有数据（如有）
$ sudo rsync -aP /var/lib/docker/ /data/docker/
# 创建或编辑 Docker daemon 配置文件
$ sudo mkdir -p /etc/docker
$ sudo tee /etc/docker/daemon.json > /dev/null <<'EOF'
{
  "data-root": "/data/docker",
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m",
    "max-file": "3"
  }
}
EOF
# 重新加载 systemd 配置
$ sudo systemctl daemon-reload
# 重启 Docker 服务
$ sudo systemctl start docker

daemon.json 配置说明：

• data-root：指定 Docker 数据存储目录。若未执行步骤一、希望保持默认的 /var/lib/docker，可删除此行。
• log-driver：指定日志驱动为 json-file（Docker 默认驱动）。
• max-size：单个日志文件的最大大小，超出后自动滚动，此处设置为 100MB。
• max-file：保留的日志文件数量上限，此处保留最近 3 个文件，即单个容器最多占用 300MB 日志空间。

验证数据目录配置是否生效：

$ docker info | grep "Docker Root Dir"
# 预期输出：Docker Root Dir: /data/docker

7.2 容器资源限制

在多容器场景下，建议显式限制每个容器可使用的 GPU、CPU 和内存资源，避免单个容器独占宿主机资源，影响其他容器的正常运行。

GPU 限制

通过 --gpus 参数指定容器可见的 GPU 设备：

# 仅挂载编号为 0 的 GPU
$ docker run --gpus '"device=0"' <image>
# 挂载前 2 块 GPU
$ docker run --gpus 2 <image>

内存限制

# 限制容器最多使用 16GB 内存
$ docker run --memory 16g <image>
# 同时限制内存和 swap（建议将 memory-swap 设置为 memory 的 2 倍，或设为 -1 禁用 swap）
$ docker run --memory 16g --memory-swap 32g <image>

CPU 限制

Docker 提供两种 CPU 限制方式，适用于不同场景：

• --cpus：硬限制，限制容器在每个调度周期内可使用的 CPU 时间比例。注意这里并不是绑定到某个固定的物理核心，而是限制 CPU 时间的占用比例。例如在 4 核宿主机上设置 --cpus 1，容器可以同时占用 4 个核各 25% 的时间，无论宿主机 CPU 是否空闲，容器的 CPU 用量始终不会超过该限制。
• --cpu-shares：软限制，默认值为 1024。该参数只在 CPU 资源紧张时才生效，宿主机 CPU 空闲时容器仍可使用更多 CPU。权重值仅代表容器之间的相对优先级，例如 A 容器设置 1024、B 容器设置 512，则 CPU 紧张时 A 获得的 CPU 时间是 B 的 2 倍。

# 硬限制：容器最多使用相当于 1 个 CPU 全载的时间比例
$ docker run --cpus 1 <image>
# 软限制：高优先级容器（相对权重较高）
$ docker run --cpu-shares 1024 <image>
# 软限制：低优先级容器（相对权重较低）
$ docker run --cpu-shares 512 <image>

两者可组合使用：--cpus 确保容器不会过度占用 CPU，--cpu-shares 在多容器竞争资源时确保重要容器获得更多的 CPU 时间。

组合示例

# 同时限制 GPU、CPU 和内存
$ docker run --gpus '"device=0"' --cpus 4 --memory 16g --memory-swap 32g <image>

7.3 使用 DKMS 模块流安装驱动

建议始终使用 Dynamic Kernel Module Support（DKMS）模块流（open-dkms 或 latest-dkms）安装 NVIDIA 驱动。DKMS 会在系统内核更新后自动重新编译驱动模块，避免因内核版本变化导致驱动失效，无需手动干预。

7.4 配置安全组最小入站规则

在 EC2 实例上运行 Docker 容器时，除了通过 docker run -p 暴露容器端口外，还需要在实例绑定的安全组中放行对应的入站流量。需要注意，Docker 端口映射只表示容器端口映射到宿主机端口，并不代表外部网络一定可以访问该端口，最终是否可访问还取决于安全组、网络 ACL、路由表等网络配置。生产环境建议安全组入站规则遵循最小权限原则：只开放应用实际需要的端口，并尽量限制来源地址。不建议为了排障或方便访问而开放所有端口或允许任意来源访问。

场景一：仅通过 SSH 管理实例

如果需要通过 SSH 登录实例，不建议将 22 端口开放给所有公网地址：

建议仅允许可信来源访问，例如管理员办公网公网 IP：

如条件允许，建议优先使用 AWS Systems Manager Session Manager 管理实例，减少或避免直接开放 SSH 入站端口。

场景二：容器应用直接对外提供 HTTP/HTTPS 服务

如果容器应用通过宿主机端口直接对外提供服务，例如：

$ docker run –d –p 8080:80 <image>

表示将容器内的 8080 端口映射到宿主机的 80 端口。此时安全组中需要允许对应访问来源访问 TCP 80 端口。

HTTP 服务示例：

HTTPS 服务示例：

如果服务需要面向公网用户开放，80/443 可以根据业务情况对公网开放；如果仅用于内部访问，则应限制为内网 CIDR、办公网 IP 或调用方安全组。

场景三：通过 Elastic Load Balancing（ELB）访问容器应用

生产环境更推荐通过 ELB 对外暴露 Web 服务，由 ELB 负责接收公网流量，EC2 实例仅接受来自 ELB 的流量。

例如容器监听宿主机 8080 端口：

$ docker run –d –p 8080:8080 <image>

此时建议安全组配置如下：

ELB 安全组入站规则：

EC2 实例安全组入站规则：

这种方式可以避免 EC2 实例应用端口直接暴露到公网，外部用户只能通过 ELB 访问应用。

8. 常见故障排除

8.1 docker run –gpus all 报错：unknown flag: –gpus

故障原因

• NVIDIA Container Toolkit 未正确安装，或 Docker 运行时未完成配置。

解决方案

# 确认 nvidia-container-toolkit 已安装
$ nvidia-ctk --version
# 重新配置运行时并重启 Docker
$ sudo nvidia-ctk runtime configure --runtime=docker
$ sudo systemctl restart docker

8.2 容器内 nvidia-smi 报错：Failed to initialize NVML

故障原因

• 宿主机 NVIDIA 驱动未正确加载，或 GPU 设备未成功挂载进容器。

解决方案

首先确认宿主机驱动状态：

$ nvidia-smi

若宿主机 nvidia-smi 也报错，检查内核模块是否已加载：

$ lsmod | grep nvidia
# 手动加载模块
$ sudo modprobe nvidia
# 查看系统日志定位原因
$ sudo dmesg | grep -i nvidia

8.3 拉取容器镜像失败

故障原因

• 实例无法访问公网镜像仓库（如 Docker Hub、ECR 仓库）。

解决方案

将镜像推送至 Amazon Elastic Container Registry（Amazon ECR），并在实例所在 VPC 中配置以下终端节点：

• cn.com.amazonaws.<region>.ecr.api（接口终端节点）
• cn.com.amazonaws.<region>.ecr.dkr（接口终端节点）
• com.amazonaws.<region>.s3（网关终端节点，用于拉取 ECR 镜像层）

8.4 执行 dnf install 报错 timeout

故障原因

• 实例无法访问 AL2023 软件仓库（托管在 Amazon S3）或 NVIDIA 软件仓库（需要访问互联网）。

解决方案

• 对于 AL2023 系统仓库，配置 Amazon S3 VPC 网关终端节点后重试。
• 对于 NVIDIA 软件仓库，参考 2.3.2 节方法二，改用本地安装包方式进行离线安装。
• 对于 NVIDIA Container Toolkit 软件仓库，参考 4.2.2 节，改用本地安装包方式进行离线安装。

9. 结语

本文介绍了在 Amazon Linux 2023 上搭建 GPU 容器环境的完整流程，涵盖 NVIDIA 驱动安装、Docker 配置以及 NVIDIA Container Toolkit 集成，并提供了数据目录迁移、日志管理和资源限制等生产环境最佳实践。

完成部署后，您将获得一个可靠的 GPU 容器运行环境，可直接用于模型训练与推理任务。后续可根据业务需要，进一步向 Amazon Elastic Container Service（Amazon ECS）或 Amazon Elastic Kubernetes Service（Amazon EKS）等容器编排服务演进，实现更灵活的 GPU 工作负载管理。

➡️ 下一步行动：

相关产品：

• Amazon EC2 — 安全且可调整大小的计算容量
• Amazon S3 — 适用于 AI、分析和存档的几乎无限的安全对象存储
• Amazon EBS — 高性能数据块存储
• Amazon ElastiCache — 无服务器缓存
• Amazon VPC — 隔离云网络

相关文章：

• 用 Hermes Agent 在 AWS 上搭建投研助手
• AI Agent 的迁移与现代化 — 使用 Amazon Bedrock AgentCore 将 OpenClaw 从单机改造为多租户 Serverless 架构 第二篇
• 短剧视频字幕位置自动识别：OpenCV + Amazon Nova 2 Lite 混合方案
• 应对TLS/SSL证书有效期大幅缩短——使用ACME协议实现证书自动续期
• 基于Amazon中国区EKS使用Code家族和 Argo CD 构建GitOps CICD流程

10. 参考资料

1. NVIDIA Container Toolkit 安装文档
2. NVIDIA Tesla Driver Installation Guide – Amazon Linux
3. Amazon ECR 接口 VPC 终端节点
4. AWS Deep Learning Containers
5. Amazon EBS 卷使用指南
6. Docker 官方安装文档
7. Docker 容器资源限制

*前述特定亚马逊云科技生成式人工智能相关的服务目前在亚马逊云科技海外区域可用。亚马逊云科技中国区域相关云服务由西云数据和光环新网运营，具体信息以中国区域官网为准。

本篇作者

AWS 架构师中心：云端创新的引领者 探索 AWS 架构师中心，获取经实战验证的最佳实践与架构指南，助您高效构建安全、可靠的云上应用