fix dead links

pages/aws/config.mdx

@@ -19,8 +19,8 @@ export default {
 };
 ```
 
-If you want to take a look at some simple configuration examples, you can check the [simple example](/config/simple_example).
+If you want to take a look at some simple configuration examples, you can check the [simple example](/aws/config/simple_example).
 
-For more advanced use cases, you can check [how to implement custom overrides](/config/custom_overrides).
+For more advanced use cases, you can check [how to implement custom overrides](/aws/config/custom_overrides).
 
-If you want to look at a full example, you can check [the full example](/config/full_example).
+If you want to look at a full example, you can check [the full example](/aws/config/full_example).

pages/aws/config/full_example.mdx

@@ -3,7 +3,7 @@ This file need to be at the same place as your `next.config.js` file
 
 `server` in here could refer to a lambda function, a docker container, a node server or whatever that can support running nodejs code. (Even cloudflare workers in the future)
 
-For more information about the options here, take a look at the [components section](/components/overview).
+For more information about the options here, take a look at the [components section](/aws/components/overview).
 
 ```ts
 import type { OpenNextConfig } from 'open-next/types/open-next'

pages/aws/config/simple_example.mdx

@@ -17,7 +17,7 @@ Here you can find the most common `open-next.config.ts` file examples that you c
   is a workaround for that on OpenNext 3.0.3+, setting environment variable
   `OPEN_NEXT_FORCE_NON_EMPTY_RESPONSE` to `"true"`. This will ensure that the
   stream body is not empty. <br /> <br />
-  If you have an issue with streaming send a message on [discord](https://sst.dev/discord)
+  If you have an issue with streaming send a message on [discord](https://discord.com/channels/1283128968140161065/1286094576788177059)
   and contact AWS support to let them know of the issue.
 </Callout>
 
@@ -107,7 +107,7 @@ export default config;
 <Callout type="info" emoji="i">
 This is not implemented in sst yet. You'll have to use your own IAC construct to deploy this.
 
-Be aware that this uses the exact same system for ISR/SSG as the default lambda setup. So it will have to have all the proper permissions and env variable to interact with S3, DynamoDB and SQS (Or whatever you override it with). You can see [here](/inner_workings/components/server/node#special-overrides) for more details
+Be aware that this uses the exact same system for ISR/SSG as the default lambda setup. So it will have to have all the proper permissions and env variable to interact with S3, DynamoDB and SQS (Or whatever you override it with). You can see [here](/aws/inner_workings/components/server/node#special-overrides) for more details
 </Callout>
 
 ```ts

pages/aws/contribute.mdx

@@ -1,6 +1,6 @@
 To run `OpenNext` locally:
 
-1. Clone [this repository](https://github.com/sst/open-next).
+1. Clone [this repository](https://github.com/opennextjs/aws).
 2. Build `open-next`:
    ```bash
    cd open-next
@@ -16,4 +16,4 @@ To run `OpenNext` locally:
    path/to/open-next/packages/open-next/dist/index.js build
    ```
 
-It can be a bit cumbersome to need to deploy every time you want to test changes. If your change is not dependent on the wrapper or the converter, then you can create a custom `open-next.config.ts` file, you can take a look [here](/contribute/local_run) for more information.
+It can be a bit cumbersome to need to deploy every time you want to test changes. If your change is not dependent on the wrapper or the converter, then you can create a custom `open-next.config.ts` file, you can take a look [here](/aws/contribute/local_run) for more information.

pages/aws/index.mdx

@@ -2,9 +2,9 @@ import { SITE } from '../../config';
 import { Callout } from 'nextra/components';
 
 <Callout>
-This docs is for the V3 of OpenNext. If you are looking for the V2 docs, you can find them [here](/v2).
+This docs is for the V3 of OpenNext. If you are looking for the V2 docs, you can find them [here](/aws/v2).
 
-If you're migrating from V2 to V3, you can find the migration guide [here](/migration#from-opennext-v2).
+If you're migrating from V2 to V3, you can find the migration guide [here](/aws/migration#from-opennext-v2).
 
 </Callout>
 

pages/aws/inner_workings.mdx

@@ -2,7 +2,7 @@ When calling `open-next build`, OpenNext **runs `next build`** to build the Next
 
 #### Building the Next.js app
 
-OpenNext runs the `build` script in your `package.json` file. Depending on the lock file found in the app, the corresponding packager manager will be used. Either `npm run build`, `yarn build`, or `pnpm build` will be run. For more on customizing the build command, see [overriding the build command](/advanced/options#custom-build-command).
+OpenNext runs the `build` script in your `package.json` file. Depending on the lock file found in the app, the corresponding packager manager will be used. Either `npm run build`, `yarn build`, or `pnpm build` will be run. For more on customizing the build command, see [overriding the build command](/aws/advanced/options#custom-build-command).
 
 #### Transforming the build output
 

pages/aws/inner_workings/architecture.mdx

@@ -48,7 +48,7 @@ This backend handles image optimization requests when the Next.js `<Image>` comp
 
 Note that the image optimization backend responds with the `Cache-Control` header, so the image will be cached both at the CDN level and at the browser level.
 
-See [Image Optimization](/features/image-optimization) for more details.
+See [Image Optimization](components/image_optimization) for more details.
 
 #### Servers Lambda backend
 
@@ -105,7 +105,7 @@ This backend is supposed to handle revalidation requests from the revalidation q
 
 OpenNext will create a `.open-next/warmer-function` folder containing the warmer backend.
 
-Read more on [how warming works](/v2/inner_workings/warming).
+Read more on [how warming works](/aws/v2/inner_workings/warming).
 
 #### Tag Provider backend
 

pages/aws/inner_workings/cache_interception.mdx

@@ -4,7 +4,7 @@ This is great but it still has go through `NextServer` which by default will loa
 
 Since OpenNext 3.1, we have added a new feature that we call Cache Interception that allows you to intercept the cache system directly inside OpenNext routing layer and serve the page directly from the cache without going through `NextServer`. If the cache interception fail, the request will be forwarded to the `NextServer` as usual.
 
-Enabling this alongside external middleware means that the external middleware will need to have all the proper permissions and env variable to interact with S3, DynamoDB and SQS (Or whatever you override it with). You can see [here](/inner_workings/components/server/node#special-overrides) for more details.
+Enabling this alongside external middleware means that the external middleware will need to have all the proper permissions and env variable to interact with S3, DynamoDB and SQS (Or whatever you override it with). You can see [here](/aws/inner_workings/components/server/node#special-overrides) for more details.
 
 This has the following benefits:
 - Faster cold start (No need to load the js associated with the page if the page is cached)

pages/aws/inner_workings/routing.mdx

@@ -13,10 +13,10 @@ Here is a list of features that OpenNext routing system handle:
   - basePath
   - i18n
 - [Middleware](#next-middleware)
-- [Optional Cache Interception](/inner_workings/cache_interception) (i.e. serve ISR/SSG directly from the routing layer)
+- [Optional Cache Interception](/aws/inner_workings/cache_interception) (i.e. serve ISR/SSG directly from the routing layer)
 - Handle 404 in some cases (i.e. when the page does not correspond to any of the regex routes)
 
 
 #### Next Middleware
 
-The Next middleware in OpenNext is not running in the same way as in Next.js. In Next.js, the middleware is running inside the `NextServer` inside a fake edge runtime. In OpenNext, we modify the middleware and run it fully inside the routing layer. So if you run the routing layer in Node, you can use Node api inside the middleware (it's a bit tricky because it won't work with `next dev` and involves some workaround because Next will remove Node api during bundling. Some example [here](/config/custom_overrides#define-a-global-to-use-node-in-the-middleware)).
+The Next middleware in OpenNext is not running in the same way as in Next.js. In Next.js, the middleware is running inside the `NextServer` inside a fake edge runtime. In OpenNext, we modify the middleware and run it fully inside the routing layer. So if you run the routing layer in Node, you can use Node api inside the middleware (it's a bit tricky because it won't work with `next dev` and involves some workaround because Next will remove Node api during bundling. Some example [here](/aws/config/custom_overrides#define-a-global-to-use-node-in-the-middleware)).

pages/aws/migration.mdx

@@ -4,7 +4,7 @@ If your Next.js app is already deployed to another platform or using another ope
 
 If you used all the default configurations, you should be able to deploy your app without any changes.
 
-OpenNext V3 replaced all the build args with a [custom config file](/config#configuration-file).
+OpenNext V3 replaced all the build args with a [custom config file](/aws/config#configuration-file).
 
 Here are the old build args and their new equivalent:
 
@@ -13,15 +13,15 @@ Here are the old build args and their new equivalent:
 - `--build-output-path`: `buildOutputPath` inside the config file.
 - `--package-json-path`: `packageJsonPath` inside the config file.
 - `--minify`: `minify` options inside each function property. This is enabled on a per function basis now.
-- `--streaming`: This is dependent on the wrapper you're using on a per function basis. To enable streaming in aws lambda, you can set `wrapper: 'aws-lambda-streaming'` in the override property of the function. Please note that AWS lambda streaming still suffer from buffering issue from the runtime itself. See [here](/inner_workings/components/overview#aws-lambda-streaming) for more info.
+- `--streaming`: This is dependent on the wrapper you're using on a per function basis. To enable streaming in aws lambda, you can set `wrapper: 'aws-lambda-streaming'` in the override property of the function. Please note that AWS lambda streaming still suffer from buffering issue from the runtime itself. See [here](/aws/inner_workings/components/overview#aws-lambda-streaming) for more info.
 - `--dangerously-disable-dynamodb-cache`: `dangerous.disableTagCache` inside the config file.
 - `--dangerously-disable-incremental-cache`: `dangerous.disableIncrementalCache` inside the config file.
 
 #### Vercel
 
 Everything should already be set up for you. But there are a few things you should know:
 
-- Streaming by default is disabled in open-next (for now). It is very **experimental** right now see [here](/inner_workings/streaming) for more info.
+- Streaming by default is disabled in open-next (for now). It is very **experimental** right now see [here](/aws/inner_workings/streaming) for more info.
 - Middleware is not run for static file and for image requests with open-next.
 
 #### AWS Amplify

pages/aws/v2/advanced/architecture.mdx

@@ -165,7 +165,7 @@ Create a Lambda function using the code in the `.open-next/warmer-function` fold
 
 Also, create an EventBridge scheduled rule to invoke the warmer function every 5 minutes.
 
-Read more on [how warming works](/inner_workings/warming).
+Read more on [how warming works](/aws/v2/inner_workings/warming).
 
 #### Dynamo Provider Function
 

pages/aws/v2/common_issues.mdx

@@ -14,10 +14,10 @@ If you are using sentry, API routes returns empty body. You could try configurin
 
 #### My ISR page has this cache-control header `s-maxage=2, stale-while-revalidate=2592000`
 
-Given how ISR works, while waiting for the revalidation to happen, the page will be served using this cache control header. This prevent your server from being overloaded by a lot of requests while the revalidation is done. You can read more about it [here](/inner_workings/isr).
+Given how ISR works, while waiting for the revalidation to happen, the page will be served using this cache control header. This prevent your server from being overloaded by a lot of requests while the revalidation is done. You can read more about it [here](/aws/v2/inner_workings/isr).
 
 #### Unzipped size must be smaller than 262144000 bytes
 
 AWS Lambda has an unzipped size limit of 250MB. If your app is over this limit, then it is most likely using a node_module library that is too large for serverless or there is a large dev dependency getting bundled.
-For example, `pdfjs` has `canvas` optional dependency which takes up 180MB. For more details, [read me](/common_issues/bundle_size).
+For example, `pdfjs` has `canvas` optional dependency which takes up 180MB. For more details, [read me](/aws/v2/common_issues/bundle_size).
 Note: a large bundle size will increase cold start significantly.

pages/aws/v2/inner_workings/isr.mdx

@@ -36,7 +36,7 @@ When we check if a page is stale, we check the `revalidatedAt` value for each re
 #### Cost
 
 <Callout type="warning" emoji="⚠️">
-  Be aware that fetch cache is using S3. `fetch` by default in next is cached, and even for SSR requests, it will be written to S3. This can lead to a lot of S3 requests and can be expensive. You can disable fetch cache by setting `cache` to `no-store` in the `fetch` options. Also see [this workaround](/common_issues/isr#patch-fetch-behaviour-for-isr-only-for-next1351)
+  Be aware that fetch cache is using S3. `fetch` by default in next is cached, and even for SSR requests, it will be written to S3. This can lead to a lot of S3 requests and can be expensive. You can disable fetch cache by setting `cache` to `no-store` in the `fetch` options. Also see [this workaround](/aws/v2/common_issues/isr#patch-fetch-behaviour-for-isr-only-for-next1351)
 </Callout>
 
 `get` will be called on every request to ISR and SSG that are not cached in Cloudfront, and `set` will be called on every revalidation.