Amplify Hosting 배포 사양을 참조하여 빌드 출력 구성 - AWS Amplify 호스팅

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

Amplify Hosting 배포 사양을 참조하여 빌드 출력 구성

Amplify Hosting 배포 사양은 Amplify Hosting으로 배포를 촉진하도록 디렉터리 구조를 정의하는 파일 시스템 기반 사양입니다. 프레임워크에서는 Amplify Hosting의 서비스 기본 요소가 프레임워크에서 활용되도록 이러한 예상 디렉터리 구조를 빌드 명령의 출력으로 생성할 수 있습니다. Amplify Hosting은 배포 번들의 구조를 파악하고 적절히 배포합니다.

배포 사양을 사용하는 방법을 설명하는 비디오 데모를 보려면 Amazon Web Services YouTube 채널을 사용하여 AWS Amplify웹 사이트를 호스팅하는 방법을 참조하십시오.

다음은 Amplify에서 예상하는 배포 번들 폴더 구조의 예시입니다. 상위 수준에는 이름이 static인 폴더, 이름이 compute인 폴더 및 이름이 deploy-manifest.json인 배포 매니페스트 파일이 있습니다.

.amplify-hosting/ ├── compute/ │ └── default/ │ ├── chunks/ │ │ └── app/ │ │ ├── _nuxt/ │ │ │ ├── index-xxx.mjs │ │ │ └── index-styles.xxx.js │ │ └── server.mjs │ ├── node_modules/ │ └── server.js ├── static/ │ ├── css/ │ │ └── nuxt-google-fonts.css │ ├── fonts/ │ │ ├── font.woff2 │ ├── _nuxt/ │ │ ├── builds/ │ │ │ └── latest.json │ │ └── entry.xxx.js │ ├── favicon.ico │ └── robots.txt └── deploy-manifest.json

Amplify 프리미티브 지원 SSR

Amplify Hosting 배포 사양에는 다음과 같은 기본 요소에 긴밀하게 매핑되는 계약이 정의됩니다.

정적 자산

정적 파일을 호스팅하는 기능을 프레임워크에 제공합니다.

컴퓨팅

포트 3000에서 Node.js HTTP 서버를 실행할 수 있는 기능을 갖춘 프레임워크를 제공합니다.

이미지 최적화

런타임 시 이미지를 최적화하는 서비스를 프레임워크에 제공합니다.

라우팅 규칙

수신되는 요청 경로를 특정 대상에 매핑하는 메커니즘을 프레임워크에 제공합니다.

.amplify-hosting/static 디렉터리

응용 프로그램에서 제공하도록 되어 있는 공개적으로 액세스 가능한 모든 정적 파일을 URL .amplify-hosting/static 디렉터리에 배치해야 합니다. 이 디렉터리 내부의 파일은 정적 자산 기본 요소를 통해 제공됩니다.

정적 파일은 내용, 파일 이름 또는 확장자를 URL 변경하지 않고도 응용 프로그램의 루트 (/) 에서 액세스할 수 있습니다. 또한 하위 디렉토리는 URL 구조에 보존되며 파일 이름 앞에 표시됩니다. 예를 들면 .amplify-hosting/static/favicon.icohttps://myAppId.amplify-hostingapp.com/favicon.ico에서 제공되고 .amplify-hosting/static/_nuxt/main.js https://myAppId.amplify-hostingapp.com/_nuxt/main.js에서 제공됩니다.

프레임워크에서 애플리케이션의 기본 경로를 수정하는 기능이 지원되면 .amplify-hosting/static 디렉터리 내부의 정적 자산 앞에 기본 경로를 추가해야 합니다. 예를 들어 기본 경로가 /folder1/folder2인 경우에는 main.css라는 정적 자산의 빌드 출력이 .amplify-hosting/static/folder1/folder2/main.css가 됩니다.

.amplify-hosting/compute 디렉터리

단일 컴퓨팅 리소스는 .amplify-hosting/compute 디렉터리 내에 포함된 default라는 단일 하위 디렉터리로 표시됩니다. 경로는 .amplify-hosting/compute/default입니다. 이 컴퓨팅 리소스는 Amplify Hosting의 컴퓨팅 기본 요소에 매핑됩니다.

default 하위 디렉터리의 콘텐츠는 다음 규칙을 준수해야 합니다.

  • 컴퓨팅 리소스의 진입점 역할을 하려면 파일이 default 하위 디렉터리의 루트에 있어야 합니다.

  • 진입점 파일은 Node.js 모듈이어야 하며 포트 3000에서 수신 대기하는 HTTP 서버를 시작해야 합니다.

  • 다른 파일을 default 하위 디렉터리에 배치하고 진입점 파일의 코드에서 해당 파일을 참조할 수 있습니다.

  • 하위 디렉터리의 콘텐츠는 독립적이어야 합니다. 진입점 모듈의 코드에서는 하위 디렉터리 외부의 모듈을 참조할 수 없습니다. 참고로 프레임워크는 원하는 방식으로 HTTP 서버를 번들로 묶을 수 있습니다. 하위 디렉터리 내에서 항목 파일의 이름이 server.js isnode server.js 명령으로 컴퓨팅 프로세스를 시작할 수 있으면 Amplify에서는 디렉터리 구조가 배포 사양을 준수하는 것으로 간주합니다.

Amplify Hosting에서는 default 하위 디렉터리 내부의 모든 파일을 번들링하여 프로비저닝한 컴퓨팅 리소스에 배포합니다. 각 컴퓨팅 리소스에는 512MB의 임시 스토리지가 할당됩니다. 이 스토리지는 실행 인스턴스 간에 공유되지 않지만, 동일한 실행 인스턴스 내의 후속 간접 호출 간에는 공유됩니다. 실행 인스턴스의 최대 실행 시간은 15분으로 제한되며, 실행 인스턴스 내 쓰기 가능한 경로는 /tmp 디렉터리뿐입니다. 각 컴퓨팅 리소스 번들의 압축된 크기는 220MB를 초과할 수 없습니다. 예를 들어 .amplify/compute/default 하위 디렉터리는 압축 시 220MB를 초과할 수 없습니다.

.amplify-hosting/deploy-manifest.json 파일

deploy-manifest.json 파일을 사용하여 배포의 구성 세부 정보와 메타데이터를 저장합니다. deploy-manifest.json 파일에는 최소한 version 속성, catch-all 라우팅이 지정된 routes 속성, 프레임워크 메타데이터가 지정된 framework 속성이 포함되어야 합니다.

다음 객체 정의에서는 배포 매니페스트의 구성을 보여줍니다.

type DeployManifest = { version: 1; routes: Route[]; computeResources?: ComputeResource[]; imageSettings?: ImageSettings; framework: FrameworkMetadata; };

다음 주제에서는 배포 매니페스트의 각 속성에 대한 세부 정보 및 사용법을 설명합니다.

version 속성 사용

version 속성에서는 구현 중인 배포 사양의 버전이 정의됩니다. 현재 Amplify Hosting 배포 사양의 버전은 버전 1뿐입니다. 다음 JSON 예제는 속성의 version 사용법을 보여줍니다.

"version": 1

routes 속성 사용

routes 속성을 통해 프레임워크에서 Amplify Hosting 라우팅 규칙 기본 요소를 활용할 수 있습니다. 라우팅 규칙은 수신되는 요청 경로를 배포 번들의 특정 대상으로 라우팅하는 메커니즘을 제공합니다. 라우팅 규칙은 수신되는 요청의 목적지만 지정하며, 다시 쓰기 및 리디렉션 규칙에 따라 요청이 변환된 후에 라우팅 규칙이 적용됩니다. Amplify Hosting에서 다시 쓰기와 리디렉션을 처리하는 방식에 대한 자세한 내용은 리디렉션 사용 섹션을 참조하세요.

라우팅 규칙은 요청을 다시 쓰거나 변환하지 않습니다. 수신되는 요청이 라우팅의 경로 패턴과 일치하면 요청이 그대로 대상에 라우팅됩니다.

routes 배열에 지정된 라우팅 규칙에서는 다음과 같은 규칙을 준수해야 합니다.

  • catch-all 라우팅이 지정되어야 합니다. catch-all 라우팅에는 수신되는 모든 요청과 일치하는 /* 패턴이 있습니다.

  • routes 배열에는 최대 25개 항목이 포함될 수 있습니다.

  • Static 경로 또는 Compute 경로를 지정해야 합니다.

  • Static 경로를 지정하는 경우 .amplify-hosting/static 디렉터리가 있어야 합니다.

  • Compute 경로를 지정하는 경우 .amplify-hosting/compute 디렉터리가 있어야 합니다.

  • ImageOptimization 경로를 지정하는 경우 Compute 경로도 지정해야 합니다. 완전히 정적인 애플리케이션에는 아직 이미지 최적화가 지원되지 않기 때문에 이 작업이 필요합니다.

다음 객체 정의에서는 Route 객체의 구성을 보여줍니다.

type Route = { path: string; target: Target; fallback?: Target; }

다음 테이블에는 Route 객체의 속성이 설명되어 있습니다.

유형 필수 설명

경로

String

수신되는 요청 경로와 일치하는 패턴을 정의합니다(쿼리 문자열 제외).

최대 경로 길이는 255자입니다.

경로는 슬래시(/)로 시작해야 합니다.

경로에는 [A-Z], [a-z], [0-9], [ _-.*$/~"'@:+] 문자가 포함될 수 있습니다.

패턴 일치에는 다음과 같은 와일드카드 문자만 지원됩니다.

  • *(0개 이상의 문자와 일치)

  • /* 패턴은 catch-all 패턴이라고 하며 수신되는 모든 요청과 일치합니다.

대상

대상

일치하는 요청을 라우팅할 대상이 정의되는 객체입니다.

Compute 경로를 지정하면 해당하는 ComputeResource가 있어야 합니다.

ImageOptimization 경로를 지정하면 imageSettings도 지정해야 합니다.

fallback

대상

아니요

원래 대상에서 404 오류가 반환되는 경우 대체할 대상이 정의되는 객체입니다.

지정한 경로의 target 종류와 fallback 종류는 같을 수 없습니다. 예를 들면 Static에서 Static으로의 대체는 허용되지 않습니다. 폴백은 본문이 없는 GET 요청에만 지원됩니다. 요청에 본문이 있으면 대체 중에 본문이 삭제됩니다.

다음 객체 정의에서는 Target 객체의 구성을 보여줍니다.

type Target = { kind: TargetKind; src?: string; cacheControl?: string; }

다음 테이블에는 Target 객체의 속성이 설명되어 있습니다.

유형 필수 설명

kind

Targetkind

대상 유형이 정의되는 enum입니다. 유효한 값은 Static, Compute, ImageOptimization입니다.

src

String

Compute의 경우 예

기타 기본 요소의 경우 아니요

기본 요소의 실행 코드가 포함되어 있는 배포 번들의 하위 디렉터리 이름이 지정되는 문자열입니다. 컴퓨팅 기본 요소의 경우에만 유효하고 필요합니다.

값은 배포 번들에 있는 컴퓨팅 리소스 중 하나를 가리켜야 합니다. 현재 이 필드에서 지원되는 유일한 값은 default입니다.

cacheControl

String

아니요

응답에 적용할 Cache-Control 헤더의 값을 지정하는 문자열입니다. 스태틱 및 ImageOptimization 프리미티브에만 유효합니다.

지정한 값은 사용자 지정 헤더에 의해 재정의됩니다. Amplify Hosting 사용자 지정 헤더에 대한 자세한 내용은 사용자 지정 헤더 섹션을 참조하세요.

참고

이 Cache-Control 헤더는 상태 코드가 200 (OK) 으로 설정된 성공적인 응답에만 적용됩니다.

다음 객체 정의에서는 TargetKind 열거의 사용법을 보여줍니다.

enum TargetKind { Static = "Static", Compute = "Compute", ImageOptimization = "ImageOptimization" }

다음 목록을 통해 TargetKind 열거형의 유효한 값이 지정됩니다.

정적

요청을 정적 자산 기본 요소로 라우팅합니다.

컴퓨팅

요청을 컴퓨팅 기본 요소로 라우팅합니다.

ImageOptimization

요청을 이미지 최적화 기본 요소로 라우팅합니다.

다음 JSON 예제는 여러 라우팅 규칙이 routes 지정된 속성의 사용법을 보여줍니다.

"routes": [ { "path": "/_nuxt/image", "target": { "kind": "ImageOptimization", "cacheControl": "public, max-age=3600, immutable" } }, { "path": "/_nuxt/builds/meta/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/_nuxt/builds/*", "target": { "cacheControl": "public, max-age=1, immutable", "kind": "Static" } }, { "path": "/_nuxt/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/*.*", "target": { "kind": "Static" }, "fallback": { "kind": "Compute", "src": "default" } }, { "path": "/*", "target": { "kind": "Compute", "src": "default" } } ]

배포 매니페스트의 라우팅 규칙 지정에 대한 자세한 내용은 라우팅 규칙 구성 모범 사례 섹션을 참조하세요.

속성 사용 computeResources

프로비저닝한 컴퓨팅 리소스에 대한 메타데이터가 이 computeResources 속성을 통해 프레임워크에서 제공될 수 있습니다. 모든 컴퓨팅 리소스는 해당하는 경로와 연결되어 있어야 합니다.

다음 객체 정의에서는 ComputeResource 객체의 사용법을 보여줍니다.

type ComputeResource = { name: string; runtime: ComputeRuntime; entrypoint: string; }; type ComputeRuntime = 'nodejs16.x' | 'nodejs18.x' | 'nodejs20.x';

다음 테이블에는 ComputeResource 객체의 속성이 설명되어 있습니다.

유형 필수 설명

name

String

컴퓨팅 리소스의 이름을 지정합니다. 이름은 .amplify-hosting/compute directory 내부의 하위 디렉터리 이름과 일치해야 합니다.

배포 사양 버전 1의 경우 유효한 값은 default뿐입니다.

런타임

ComputeRuntime

프로비저닝한 컴퓨팅 리소스의 런타임을 정의합니다.

유효한 값은 nodejs16.x, nodejs18.x, nodejs20.x입니다.

entrypoint

String

지정한 컴퓨팅 리소스에 대해 코드가 실행될 시작 파일의 이름을 지정합니다. 파일은 컴퓨팅 리소스를 나타내는 하위 디렉터리 내부에 있어야 합니다.

다음과 같은 디렉터리 구조가 있는 경우입니다.

.amplify-hosting |---compute | |---default | |---index.js

computeResource속성의 모양은 다음과 같습니다. JSON

"computeResources": [ { "name": "default", "runtime": "nodejs16.x", "entrypoint": "index.js", } ]

imageSettings 속성 사용

imageSettings 속성을 통해 런타임 시 이미지의 온디맨드 최적화가 제공되는 이미지 최적화 기본 요소의 동작을 프레임워크에서 사용자 지정할 수 있습니다.

다음 객체 정의에서는 ImageSettings 객체의 사용법을 보여줍니다.

type ImageSettings = { sizes: number[]; domains: string[]; remotePatterns: RemotePattern[]; formats: ImageFormat[]; minumumCacheTTL: number; dangerouslyAllowSVG: boolean; }; type ImageFormat = 'image/avif' | 'image/webp' | 'image/png' | 'image/jpeg';

다음 테이블에는 ImageSettings 객체의 속성이 설명되어 있습니다.

유형 필수 설명

크기

Number[]

지원되는 이미지 너비의 배열입니다.

domains

String[]

이미지 최적화를 사용하도록 허용된 외부 도메인의 배열입니다. 배포 도메인에서만 이미지 최적화가 사용되도록 하려면 배열을 비워둡니다.

remotePatterns

RemotePattern[]

이미지 최적화를 사용하도록 허용된 외부 패턴의 배열입니다. 도메인과 비슷하지만, 정규 표현식(regex)이 제공되어 추가로 제어할 수 있습니다.

formats

ImageFormat[]

허용된 출력 이미지 형식의 배열입니다.

minimumCacheTTL

숫자

최적화된 이미지의 캐시 기간(초)입니다.

dangerouslyAllowSVG

이미지 SVG 입력을 허용합니다URLs. 보안을 위해 기본적으로 비활성화되어 있습니다.

다음 객체 정의에서는 RemotePattern 객체의 사용법을 보여줍니다.

type RemotePattern = { protocol?: 'http' | 'https'; hostname: string; port?: string; pathname?: string; }

다음 테이블에는 RemotePattern 객체의 속성이 설명되어 있습니다.

유형 필수 설명

프로토콜

String

아니요

허용된 원격 패턴의 프로토콜입니다.

유효한 값은 http 또는 https입니다.

hostname

String

허용된 원격 패턴의 호스트 이름입니다.

리터럴 또는 와일드카드를 지정할 수 있습니다. 1개(`*`)는 하나의 하위 도메인과 일치합니다. 2개(`**`)는 모든 하위 도메인의 수와 일치합니다. Amplify에서는 `**`만 지정하는 포괄적인 와일드카드가 허용되지 않습니다.

포트

String

아니요

허용된 원격 패턴의 포트입니다.

pathname

String

아니요

허용된 원격 패턴의 경로 이름입니다.

다음 예시에서는 imageSettings 속성을 보여줍니다.

"imageSettings": { "sizes": [ 100, 200 ], "domains": [ "example.com" ], "remotePatterns": [ { "protocol": "https", "hostname": "example.com", "port": "", "pathname": "/**", } ], "formats": [ "image/webp" ], "minumumCacheTTL": 60, "dangerouslyAllowSVG": false }

framework 속성 사용

framework 속성을 사용하여 프레임워크 메타데이터를 지정합니다.

다음 객체 정의에서는 FrameworkMetadata 객체의 구성을 보여줍니다.

type FrameworkMetadata = { name: string; version: string; }

다음 테이블에는 FrameworkMetadata 객체의 속성이 설명되어 있습니다.

유형 필수 설명

name

String

프레임워크의 이름입니다.

version

String

프레임워크의 버전입니다.

유효한 의미 체계 버전 관리(semver) 문자열이어야 합니다.

라우팅 규칙 구성 모범 사례

라우팅 규칙에서는 수신되는 요청 경로를 배포 번들의 특정 대상으로 라우팅하는 메커니즘이 제공됩니다. 배포 번들에서 프레임워크 작성자는 다음과 같은 대상 중 하나에 배포되는 파일을 빌드 출력에 내보낼 수 있습니다.

  • 정적 자산 기본 요소 – 파일이 .amplify-hosting/static 디렉터리에 포함되어 있습니다.

  • 컴퓨팅 기본 요소 – 파일이 .amplify-hosting/compute/default 디렉터리에 포함되어 있습니다.

프레임워크 작성자는 라우팅 규칙 배열도 배포 매니페스트 파일로 제공합니다. 배열의 각 규칙은 일치 항목이 있을 때까지 수신되는 요청과 순차적인 순회 순서로 대조됩니다. 일치하는 규칙이 있으면 일치하는 규칙에 지정된 대상에 요청이 라우팅됩니다. 규칙마다 대체 대상을 지정할 수도 있습니다. 원래 대상에서 404 오류를 반환하면 요청이 대체 대상으로 라우팅됩니다.

배포 사양에서는 순회 순서의 마지막 규칙이 catch-all 규칙이 되어야 합니다. catch-all 규칙은 /* 경로와 함께 지정됩니다. 수신되는 요청이 라우팅 규칙 배열의 이전 경로와 전혀 일치하지 않으면 요청이 catch-all 규칙 대상으로 라우팅됩니다.

같은 SSR 프레임워크의 경우Nuxt.js, 포괄적 규칙 대상은 컴퓨팅 프리미티브여야 합니다. SSR애플리케이션에는 빌드 시 예측할 수 없는 경로가 포함된 서버 측 렌더링 페이지가 있기 때문입니다. 예를 들어 /blog/[slug]에 Nuxt.js 애플리케이션의 페이지가 있으면 [slug]가 동적 경로 파라미터입니다. catch-all 규칙 대상은 요청을 이러한 페이지에 라우팅하는 유일한 방법입니다.

이와 달리 특정 경로 패턴을 사용하여 빌드 시 알려진 경로를 대상으로 지정할 수 있습니다. 예를 들면 /_nuxt에서는 정적 자산이 Nuxt.js 경로에서 제공됩니다. 따라서 요청을 정적 자산 기본 요소로 라우팅하는 특정 라우팅 규칙에 따라 /_nuxt/* 경로를 대상으로 지정할 수 있습니다.

퍼블릭 폴더 라우팅

대부분의 SSR 프레임워크는 폴더에서 변경 가능한 정적 자산을 제공하는 기능을 제공합니다. public favicon.ico및 와 같은 robots.txt 파일은 일반적으로 public 폴더 내에 보관되며 애플리케이션의 루트에서 제공됩니다. URL 예를 들면 favicon.ico 파일은 https://example.com/favicon.ico에서 제공됩니다. 참고로, 이러한 파일에는 예측 가능한 경로 패턴이 없습니다. 거의 전적으로 파일 이름에 따라 결정됩니다. public 폴더 내부의 파일을 대상으로 지정하는 유일한 방법은 catch-all 라우팅을 사용하는 것입니다. 그러나 catch-all 라우팅 대상은 컴퓨팅 기본 요소여야 합니다.

public 폴더 관리에는 다음과 같은 접근 방식 중 하나를 따르는 것이 좋습니다.

  1. 경로 패턴을 사용하여 파일 확장명이 있는 요청 경로를 대상으로 지정합니다. 예를 들면 /*.*를 사용하여 파일 확장명이 있는 모든 요청 경로를 대상으로 지정할 수 있습니다.

    참고로, 이 접근 방식은 신뢰할 수 없습니다. 예를 들면 public 폴더에 속한 파일에 파일 확장명이 없다면 해당 파일은 이 규칙에 따라 대상으로 지정되지 않습니다. 이 접근 방식에서 유의할 다른 문제는 이름에 마침표가 있는 페이지가 애플리케이션에 있을 수 있다는 점입니다. 예를 들면 /blog/2021/01/01/hello.world의 페이지가 /*.* 규칙에 따라 대상으로 지정됩니다. 페이지는 정적 자산이 아니므로 이는 바람직하지 않습니다. 그러나 정적 기본 요소에서 404 오류가 발생하는 경우 요청이 컴퓨팅 기본 요소로 대체되도록 이 규칙에 대체 대상을 추가할 수 있습니다.

    { "path": "/*.*", "target": { "kind": "Static" }, "fallback": { "kind": "Compute", "src": "default" } }
  2. 빌드 시 public 폴더의 파일을 식별하고 각 파일에 대한 라우팅 규칙을 내보냅니다. 배포 사양에 따라 규칙이 25개로 제한되므로 이 접근 방식은 확장할 수 없습니다.

    { "path": "/favicon.ico", "target": { "kind": "Static" } }, { "path": "/robots.txt", "target": { "kind": "Static" } }
  3. 프레임워크 사용자는 변경 가능한 모든 정적 자산을 public 폴더의 하위 폴더에 저장하는 것이 좋습니다.

    다음 예시에서는 사용자가 변경 가능한 모든 정적 자산을 public/assets 폴더에 저장할 수 있습니다. 그런 다음 경로 패턴이 /assets/*인 라우팅 규칙을 사용하여 public/assets 폴더의 모든 변경 가능한 정적 자산을 대상으로 지정할 수 있습니다.

    { "path": "/assets/*", "target": { "kind": "Static" } }
  4. catch-all 라우팅에 대한 정적 대체를 지정합니다. 이 접근 방식에는 단점이 있으며 다음 catch-all 대체 라우팅 섹션에 자세히 설명되어 있습니다.

catch-all 대체 라우팅

컴퓨팅 프리미티브 대상에 대해 포괄 경로가 지정된 것과 Nuxt.js 같은 SSR 프레임워크의 경우 프레임워크 작성자는 폴더 라우팅 문제를 해결하기 위해 포괄 경로에 정적 폴백을 지정하는 것을 고려할 수 있습니다. public 그러나 이 라우팅 규칙 유형은 서버 측에서 렌더링한 404 페이지를 중단시킵니다. 예를 들어 최종 사용자가 존재하지 않는 페이지를 방문하면 애플리케이션에서는 상태 코드가 404인 404 페이지를 렌더링합니다. 그러나 catch-all 라우팅에 정적 대체가 있으면 404 페이지가 렌더링되지 않습니다. 대신에 요청은 정적 기본 요소로 대체되고 여전히 404 상태 코드로 끝나지만, 404 페이지는 렌더링되지 않습니다.

{ "path": "/*", "target": { "kind": "Compute", "src": "default" }, "fallback": { "kind": "Static" } }

기본 경로 라우팅

애플리케이션의 기본 경로를 수정하는 기능이 제공되는 프레임워크에서는 .amplify-hosting/static 디렉터리 내부의 정적 자산 앞에 기본 경로를 추가할 것으로 예상됩니다. 예를 들어 기본 경로가 /folder1/folder2인 경우에는 main.css라는 정적 자산의 빌드 출력이 .amplify-hosting/static/folder1/folder2/main.css가 됩니다.

따라서 기본 경로가 반영되도록 라우팅 규칙도 업데이트해야 합니다. 예를 들어 기본 경로가 /folder1/folder2인 경우에는 public 폴더의 정적 자산에 대한 라우팅 규칙은 다음과 같습니다.

{ "path": "/folder1/folder2/*.*", "target": { "kind": "Static" } }

마찬가지로 서버 측 경로도 앞에 기본 경로를 추가해야 합니다. 예를 들어 기본 경로가 /folder1/folder2인 경우에는 /api 경로에 대한 라우팅 규칙은 다음과 같습니다.

{ "path": "/folder1/folder2/api/*", "target": { "kind": "Compute", "src": "default" } }

그러나 catch-all 라우팅 앞에는 기본 경로를 추가하면 안 됩니다. 예를 들어 기본 경로가 /folder1/folder2인 경우에는 catch-all 라우팅이 다음과 같이 유지됩니다.

{ "path": "/*", "target": { "kind": "Compute", "src": "default" } }

Nuxt.js 경로 예시

다음은 라우팅 규칙을 지정하는 방법을 보여주는 Nuxt 애플리케이션의 예시 deploy-manifest.json 파일입니다.

{ "version": 1, "routes": [ { "path": "/_nuxt/image", "target": { "kind": "ImageOptimization", "cacheControl": "public, max-age=3600, immutable" } }, { "path": "/_nuxt/builds/meta/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/_nuxt/builds/*", "target": { "cacheControl": "public, max-age=1, immutable", "kind": "Static" } }, { "path": "/_nuxt/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/*.*", "target": { "kind": "Static" }, "fallback": { "kind": "Compute", "src": "default" } }, { "path": "/*", "target": { "kind": "Compute", "src": "default" } } ], "computeResources": [ { "name": "default", "entrypoint": "server.js", "runtime": "nodejs18.x" } ], "framework": { "name": "nuxt", "version": "3.8.1" } }

다음은 기본 경로가 포함된 라우팅 규칙을 지정하는 방법을 보여주는 Nuxt의 예시 deploy-manifest.json 파일입니다.

{ "version": 1, "routes": [ { "path": "/base-path/_nuxt/image", "target": { "kind": "ImageOptimization", "cacheControl": "public, max-age=3600, immutable" } }, { "path": "/base-path/_nuxt/builds/meta/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/base-path/_nuxt/builds/*", "target": { "cacheControl": "public, max-age=1, immutable", "kind": "Static" } }, { "path": "/base-path/_nuxt/*", "target": { "cacheControl": "public, max-age=31536000, immutable", "kind": "Static" } }, { "path": "/base-path/*.*", "target": { "kind": "Static" }, "fallback": { "kind": "Compute", "src": "default" } }, { "path": "/*", "target": { "kind": "Compute", "src": "default" } } ], "computeResources": [ { "name": "default", "entrypoint": "server.js", "runtime": "nodejs18.x" } ], "framework": { "name": "nuxt", "version": "3.8.1" } }

routes 속성에 대한 자세한 내용은 routes 속성 사용 섹션을 참조하세요.