---
cuppy_hub: aws
cuppy_path: changelog/doc-findings/aws-doc-findings.md
cuppy_section: docs
cuppy_doc: 1YS2-VYNJ
cuppy_doc_uuid: 46a6623d-47a5-4c07-a989-7dafa0819bbf
cuppy_permalink: https://cuppy.io/aws/d/1YS2-VYNJ
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/aws/docs/changelog/doc-findings/aws-doc-findings
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 89e213149e713ddf35b6202f2688fdb76593fc58b7068f62d65b15b60a0a7200
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# Where AWS's documentation disagrees with itself

While building a source-verified AWS knowledge base for AI coding agents, I found **21 places where AWS's own
documentation contradicts itself or its own SDKs and templates** — 2 of them with security or data-correctness
impact, and 5 more that would break a deployment or a runtime call. Every finding below was re-checked against
the live pages and the published packages on **2026-10-21**; 19 are still present and 2 have been corrected
upstream since I logged them.

This is not a complaint list. It is what a cross-checking method turns up, and the method is the point.

---

## Method

I built the knowledge base on a rule that no claim ships from a single source. Five steps, applied to every
fact:

1. **Read the page, not a summary.** For `docs.aws.amazon.com` I fetch the `.md` variant of each page, which
   returns the page text itself rather than a model's precis. Anything a summariser *added* to a page was
   discarded, not kept as a fact.
2. **Triangulate across interface layers.** Every API name, default and limit is checked in at least two of:
   the user guide, the API reference, the SDK's TypeScript type definitions, the CLI's own help and source
   strings, and the CloudFormation or CDK template that actually provisions the thing.
3. **Pin the version.** SDK and library evidence is read from a named published version
   (`aws-cdk-lib` 2.274.0, `@aws-sdk/client-*` 3.1154.0, the `aws-cdk` CLI 2.1146.0), unpacked from npm and
   grepped — never from memory of an API.
4. **Run it where running is cheap.** CDK examples were synthesised and the emitted template inspected;
   documented build commands were executed; code blocks were type-checked as written. A type check alone would
   not have caught a property that does not exist on the object the guide hands you.
5. **Log the conflict; never silently resolve it.** When two sources disagree, the conflict goes in a
   `CONTRADICTIONS` section with both URLs, and the published document is written so that it holds for both
   readings — usually by naming the API as the arbiter. Every published document carries `provenance`
   front matter: the URL read, the authority, the read date, and a re-check interval.

The discipline that mattered most was step 5. A writer who quietly picks the likelier of two numbers produces a
document that reads well and is wrong half the time. Recording the disagreement is what made the list below
possible.

---

## Top findings

### 1. CDK bootstrap: the documented default is `[]`, the applied default is `AdministratorAccess`

**Impact: security exposure. Status: still present (2026-10-21).**

| | |
|---|---|
| **Quote A** | "By default, stacks are deployed with full administrator permissions using the `AdministratorAccess` policy." |
| **Quote B** | "*Default value*: `[]`" |
| **Source** | Both sentences are in the same `--cloudformation-execution-policies` option block of the `cdk bootstrap` command reference, `https://docs.aws.amazon.com/cdk/v2/guide/ref-cli-cmd-bootstrap.html` (read 2026-10-21; no last-updated date is published on the page) |

The two statements are in the same option block, a few lines apart. One of them describes a deployment role
with no permissions; the other describes one with every permission in the account. A reader skimming the
options table — which is how a reference page is read — sees `[]`.

**What is actually true, and how I proved it.** The bootstrap template that the CLI deploys is bundled in the
`aws-cdk` package, so the answer is readable without touching an account. In
`aws-cdk@2.1146.0/lib/api/bootstrap/bootstrap-template.yaml`, the parameter is declared with
`Default: ''`, and the deployment role's managed policies are:

> ```
>       ManagedPolicyArns:
>         Fn::If:
>           - HasCloudFormationExecutionPolicies
>           - Ref: CloudFormationExecutionPolicies
>           - Fn::If:
>             - HasTrustedAccounts
>             # The CLI will prevent this case from occurring
>             - Ref: AWS::NoValue
>             # The CLI will advertise that we picked this implicitly
>             - - Fn::Sub: "arn:${AWS::Partition}:iam::aws:policy/AdministratorAccess"
> ```

So with no `--cloudformation-execution-policies` and no `--trust`, the role gets `AdministratorAccess`. The
CLI's own code confirms the branch and prints a warning that the page's defaults table does not mention:

> `Using default execution policy of '<AdministratorAccess ARN>'. Pass '--cloudformation-execution-policies' to customize.`
> — `aws-cdk@2.1146.0/lib/index.js`

The page is not hiding this: the same option block also warns that the template "effectively grants the
permissions implied by the `--cloudformation-execution-policies` to any AWS account in the `--trust` list". The
defect is that its machine-readable default field says the opposite of its prose, and the two are a paragraph
apart.

**How the knowledge base handles it.** The bootstrap document states the applied behaviour first — a plain
`cdk bootstrap` creates a deployment role with `AdministratorAccess` — then names
`--cloudformation-execution-policies` as the only way to narrow it, and records the page's `[]` as a known
documentation conflict rather than
repeating it.

---

### 2. SNS delivery guarantees: a decision guide promises "exactly-once" where the service guides say at least once

**Impact: data correctness. Status: still present (2026-10-21).**

| | |
|---|---|
| **Quote A** | "Offers at-least-once delivery for HTTP/S subscribers and **exactly-once delivery for Lambda and Amazon SQS subscribers**." — and in the comparison table, "At-least-once delivery for HTTP/S, exactly-once for Lambda and Amazon SQS" |
| **Quote B** | "Lambda event source mappings **process each event at least once**, and duplicate processing of records can occur. To avoid potential issues related to duplicate events, we strongly recommend that you make your function code idempotent." |
| **Source A** | *Amazon SQS, Amazon SNS, or Amazon EventBridge?* decision guide, `https://docs.aws.amazon.com/decision-guides/latest/decision-guides/sns-or-sqs-or-eventbridge.html` — the page's own header table gives its **Last updated** value as "November, 2025" |
| **Source B** | *Using Lambda with Amazon SQS*, `https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html` (read 2026-10-21) |

A second counter-quote, from SNS's own guide, covers the SQS half. On
`https://docs.aws.amazon.com/sns/latest/dg/fifo-topic-message-ordering.html` (read 2026-10-21):

> "With an Amazon SQS FIFO queue subscribed, the consumer of the queue receives the messages in the exact order
> in which the messages are delivered to the queue, and no duplicates. With an Amazon SQS **standard** queue
> subscribed, however, the consumer of the queue may receive messages out of order, and **more than once**."

**What is actually true, and how I proved it.** The two service guides agree with each other and disagree with
the decision guide. Exactly-once is available in a narrow configuration — an SNS FIFO topic delivering to an
SQS FIFO queue, where deduplication is doing the work — and the decision guide's cell states it as a property
of SNS delivery to Lambda and SQS generally. Even in that narrow configuration, what the SQS FIFO
exactly-once page described when I read it on 2026-10-18 is a five-minute deduplication interval on
`SendMessage` — a narrower guarantee than end-to-end exactly-once processing.

This is the finding I would most want a reviewer to see, because the failure mode is silent. An engineer — or
an agent — who reads the decision guide first ships a non-idempotent consumer, and the duplicate arrives weeks
later as a double charge or a double write, with nothing in the logs that looks like an error.

**How the knowledge base handles it.** The fan-out and queue-consumer documents state at-least-once as the
design assumption for every standard path, require idempotent consumers, and name SNS FIFO to SQS FIFO
deduplication as the only configuration where stronger wording applies. The decision guide's claim is recorded
as a conflict and is never cited as a delivery guarantee.

---

### 3. The CDK guide documents a stack property that `aws-cdk-lib` does not have

**Impact: failed deployment or runtime error. Status: still present (2026-10-21).**

| | |
|---|---|
| **Quote A** | "Exceeding the AWS CloudFormation resource limit is an error during AWS CloudFormation synthesis. The AWS CDK issues a warning if your stack exceeds 80% of the limit. **You can use a different limit by setting the `maxResources` property on your stack, or disable validation by setting `maxResources` to 0.**" |
| **Quote B** | `StackProps` in `aws-cdk-lib` has twelve members — `description`, `env`, `stackName`, `tags`, `notificationArns`, `synthesizer`, `terminationProtection`, `analyticsReporting`, `crossRegionReferences`, `permissionsBoundary`, `suppressTemplateIndentation`, `propertyInjectors` — and `maxResources` is not among them. |
| **Source A** | *Troubleshooting common AWS CDK issues*, `https://docs.aws.amazon.com/cdk/v2/guide/troubleshooting.html` (read 2026-10-21) |
| **Source B** | `aws-cdk-lib` 2.273.0 and 2.274.0, `core/lib/stack.d.ts`, read from the npm tarball on 2026-10-21 |

**What is actually true, and how I proved it.** This is the one category where "two pages disagree" understates
it: a property that does not exist in the library is provably not settable, whatever the guide says. In
`core/lib/stack.d.ts`, `maxResources` appears exactly once, as a **private** getter on `Stack`:

> `private get maxResources();`

and its implementation in `core/lib/stack.js` reads a context key, not a prop:

> `get maxResources(){const contextLimit=this.node.tryGetContext(exports.STACK_RESOURCE_LIMIT_CONTEXT);return contextLimit!==void 0?parseInt(contextLimit,10):MAX_RESOURCES}`

with the key declared at the top of the same file:

> `export declare const STACK_RESOURCE_LIMIT_CONTEXT = "@aws-cdk/core:stackResourceLimit";`

So the supported control is the context key `@aws-cdk/core:stackResourceLimit`, set in `cdk.json` or with
`--context`. I checked both the version the knowledge base pins (2.273.0) and the then-current release
(2.274.0): identical in both, so this is not a version-skew artefact.

**How the knowledge base handles it.** The CDK document gives the context key, with the `cdk.json` placement,
and states that no stack property controls the limit. The guide's property name is recorded as a documentation
conflict so an agent that has read the guide can reconcile the two rather than retrying a bad synth.

---

### 4. An S3 troubleshooting page prescribes a CloudFront configuration that CloudFront documents as impossible

**Impact: failed deployment or runtime error. Status: still present (2026-10-21).**

| | |
|---|---|
| **Quote A** | "Make sure you're using the S3 website endpoint format (bucket-name.s3-website-region.amazonaws.com) rather than the REST API endpoint" — and, in the same bullet list, "Ensure your bucket policy includes permissions for your CloudFront distribution's Origin Access Identity (OAI) or Origin Access Control (OAC)" |
| **Quote B** | "If your origin is an Amazon S3 bucket configured as a website endpoint, you must set it up with CloudFront as a custom origin. That means **you can't use OAC (or OAI)**." |
| **Source A** | *Troubleshoot access denied (403 Forbidden) errors in Amazon S3*, "CloudFront distribution access" section, `https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshoot-403-errors.html` (read 2026-10-21) |
| **Source B** | *Restrict access to an Amazon S3 origin*, `https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html` (read 2026-10-21) |

**What is actually true, and how I proved it.** The CloudFront page states the constraint twice, the second time
as a prerequisite: "This origin must be a regular S3 bucket, not a bucket configured as a website endpoint."
The S3 troubleshooting page offers the two requirements as adjacent bullets for the same symptom, so following
both is not possible — a reader who does what it says will chase a 403 that the configuration guarantees.

This one shows the logging rule earning its keep. I recorded it while collecting S3 sources and could not
settle it there, because neither S3 page says which endpoint OAC applies to. Rather than pick the likelier
reading, I left it in the log marked unresolved, with a note that the CloudFront sources should settle it; it
was closed later the same day, once the CloudFront restriction page had been read, and the resolution recorded
against the original entry. Guessing would have been faster and would have produced a published document
telling agents to build something that cannot work.

**How the knowledge base handles it.** The CloudFront-to-S3 pattern document uses the REST endpoint with OAC as
the single recommended shape, and states explicitly that a website endpoint must be configured as a custom
origin and cannot use OAC or OAI — with the S3 troubleshooting page's advice flagged as superseded.

---

### 5. CloudFormation express mode: the guide says rollback is off by default, the SDK says the flag defaults to `false`

**Impact: failed deployment or runtime error. Status: still present (2026-10-21).**

| | |
|---|---|
| **Quote A** | "When you use express mode, CloudFormation disables rollback by default. If a resource operation fails, CloudFormation does not automatically roll back the changes." |
| **Quote B** | "Specifies whether to disable rollback of the stack if the stack operation fails." / "Default: `false`" |
| **Source A** | *Deploy AWS CloudFormation stacks faster with express mode*, `https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cloudformation-express-mode.html` (read 2026-10-21) |
| **Source B** | `DeploymentConfig.DisableRollback` doc comment, `@aws-sdk/client-cloudformation` 3.1154.0, `dist-types/models/models_0.d.ts` |

**What is actually true, and how I proved it.** `DeploymentConfig` is the exact structure that turns express mode
on — its sibling field is `Mode`, whose own comment reads "`EXPRESS` - Complete the stack operation when
resource configuration is applied, without waiting for resources to become ready to serve traffic." So the SDK's
"Default: `false`" is attached to the field that governs express deployments, and it says the opposite of the
user guide's "disables rollback by default".

The user guide is internally consistent and behaviourally specific: its comparison table reads
"Rollback support \| Supports rollback (disabled by default)", and its remedy is to pass the flag explicitly —

> "To re-enable rollback when using express mode, set `disableRollback` to `false` in the
> `--deployment-config` parameter"

— which only makes sense if `false` is *not* already the default. A third AWS page agrees with the guide: the
`cdk bootstrap` reference's `--express` option says "express mode does not perform rollback automatically and
will leave stacks in a failed state if something goes wrong." Two guides against one SDK comment, so the
likeliest reading is that the SDK comment is a stale inherited default. I have no public evidence of which side
AWS considers correct, so I have not claimed one.

**How the knowledge base handles it.** The express mode document instructs the reader to set `DisableRollback`
explicitly in either direction and never to rely on the default, and records both quotes so an agent reading
the SDK types does not "correct" the guidance back.

---

## Full table of verified findings

Every row was re-checked on 2026-10-21. "Guide / SDK" means a documentation page disagrees with the published
package; "page / page" means two AWS pages disagree; "same page" means one page disagrees with itself.

| # | Finding | Kind | Impact | Status |
|---|---|---|---|---|
| 1 | `cdk bootstrap` lists `--cloudformation-execution-policies` default `[]`; the same option block says `AdministratorAccess` applies, and the bundled template and CLI warning confirm admin | same page | security exposure | still present |
| 2 | The SQS/SNS/EventBridge decision guide gives SNS "exactly-once for Lambda and Amazon SQS"; the Lambda and SNS guides give at-least-once and "more than once" for standard subscribers | page / page | data correctness | still present |
| 3 | The CDK guide documents a `maxResources` stack property; `aws-cdk-lib` has no such prop and reads the context key `@aws-cdk/core:stackResourceLimit` | guide / SDK | failed deployment | still present |
| 4 | S3's 403 troubleshooting page says to use the S3 website endpoint as the CloudFront origin *and* to grant OAI/OAC; CloudFront documents that a website endpoint can't use OAC or OAI | page / page | failed deployment | still present |
| 5 | The express mode guide says rollback is disabled by default; `DeploymentConfig.DisableRollback` in the SDK says "Default: `false`" | guide / SDK | failed deployment | still present |
| 6 | DynamoDB's PITR page spells the field `RecoveryPeriodinDays` (lowercase i), three times in one bullet; the SDK field is `RecoveryPeriodInDays` | guide / SDK | failed deployment (typo) | still present |
| 7 | Lambda's SQS pages give the provisioned-mode poller maximum as "between 2 and 10,000" and as "(2-2000)" | page / page | failed deployment | still present |
| 8 | `PutResourcePolicy`'s `RevisionId` parameter says to read the revision with `GetResourcePolicy`; the Errors section of the same page says to call `GetFunction` or `GetAlias` for "all other API operations" | same page | wasted time | still present |
| 9 | SQS's SDK doc comments look mis-copied: `KmsDisabled` says "The request was denied due to request throttling" (which is `KmsThrottled`'s meaning) and `KmsOptInRequired` describes an invalid key policy | SDK | wasted time | still present |
| 10 | CloudFront's 504 page says "you can't use private servers ... as origin servers with CloudFront"; the VPC origins page serves ALBs, NLBs and EC2 instances in private subnets | page / page | wasted time | still present |
| 11 | NAT troubleshooting tells you to "Create additional NAT gateways in the public subnet", and elsewhere that "The NAT gateway must be in a public subnet" (that second sentence sits in a section about a public NAT gateway, so it is contextually scoped); the regional NAT gateway page states "No public subnets required ... you do not need a public subnet in your VPC to host a regional NAT Gateway", and the NAT gateway basics page still opens "Each NAT gateway is created in a specific Availability Zone" with no mention of regional mode | page / page | wasted time | still present |
| 12 | The IAM quotas page describes the STS global endpoint change as "upcoming ... will not share a requests per second (RPS) quota"; the STS Regions page says "AWS has made changes" and the quota "do not share" | page / page | wasted time | still present |
| 13 | The presigned-URL sharing page's only sample output is a Signature Version 2 query URL (`AWSAccessKeyId`, `Signature`, `Expires`) and the page never mentions signing versions; the companion page ties the 7-day lifetime and every checksum algorithm beyond MD5 to Signature Version 4 | page / page | wasted time | still present |
| 14 | The same sharing page says the console can share "an object up to 5 TB"; the multipart limits page gives the maximum object size as 48.8 TiB | page / page | wasted time | still present |
| 15 | `aws-cdk-lib` marks `Bucket.grantRead` "The use of this method is discouraged. Please use `grants.read()` instead", while the CDK guide's grant examples used `grantRead` | guide / SDK | wasted time | **fixed since** — the guide's Permissions page now shows `bucket.grants.read(function)` and `BucketGrants.fromBucket(bucket)`, says the Grants class "is preferred", and no longer shows a `grantRead` example |
| 16 | The runtimes page marks `nodejs26.x` "in **public preview** ... should not be used for production workloads"; the TypeScript page lists the same runtime with no qualifier | page / page | wasted time | still present |
| 17 | The TypeScript page's sample `tsconfig.json` targets `es2020` with `"module":"commonjs"` and links a Node 14 base config, while its own runtime table lists only Node 22, 24 and 26 | same page | wasted time | still present |
| 18 | S3's 403 troubleshooting page enumerates Block Public Access as applying to "an access point, a bucket, or an entire AWS account"; the Block Public Access page adds the organization level | page / page | wasted time | still present |
| 19 | `AssumeRole`'s `PackedPolicySize` is marked "deprecated. Use `SessionTokenUtilization` instead", yet the sample response on the same page returns only `PackedPolicySize` | same page | cosmetic | still present |
| 20 | The CloudFront origin-access page gives the Region cut-off as "opt-in Regions launched after December 2022" in the OAC list and "New AWS Regions launched after January 2023" in the OAI list | same page | cosmetic | still present |
| 21 | The Lambda runtimes summary gave only a deprecation date for `nodejs24.x` while the TypeScript page gave block-create and block-update dates | page / page | wasted time | **fixed since** — corrected between my read on 2026-10-18 and 2026-10-21; both tables now show Apr 30 2028 / Jun 1 2028 / Jul 1 2028 |

**Counts.** 21 verified findings, all of them in the table above; rows 1 to 5 are the five written up as cards.
By impact: 1 security exposure, 1 data correctness, 5 failed deployment or runtime error, 12 wasted engineering
time, 2 cosmetic — 21 in total. By status: 19 still present on 2026-10-21, 2 fixed upstream.

### A note on the two that were fixed

These are the rows I most wanted to keep, because they are the ones a reader can audit.

**Row 21.** I logged it on 2026-10-18 because the runtimes summary table gave `nodejs24.x` a deprecation date
and nothing else, while the TypeScript page gave block-create and block-update dates for the same runtime — so
a planner reading the summary would have budgeted the wrong migration window. On 2026-10-21 both tables carry
all three dates and agree exactly: Apr 30 2028, Jun 1 2028, Jul 1 2028.

**Row 15.** When I logged it, the CDK guide's grant examples called `grantRead` while the library's own doc
comment on `Bucket.grantRead` said the method was discouraged in favour of `grants.read()`. The guide's
Permissions page now leads with the Grants classes, shows `bucket.grants.read(function)`, and states that the
Grants-class form "is preferred because they can be used to grant access to both L1 and L2 resources in the
same way". The deprecation note is still in the library; the guide has caught up with it.

In neither case do I have a public statement from AWS, and I am not claiming they acted on anything of mine.
What I can say is that each discrepancy existed, I recorded both sides with dates, and the re-check closed it.
That is the whole value of recording a conflict instead of resolving it quietly — a logged finding can be
checked later by anyone, including as fixed.

---

## False alarms I ruled out

A list like this is only trustworthy if it also shows what did not make it. These looked like contradictions
and are not:

| Apparent conflict | Why it is not one |
|---|---|
| S3 maximum object size: "50 TB" in the launch announcement, "48.8 TiB" on the multipart limits page | The same limit in different units. The limits page gives 10,000 parts at up to 5 GiB each; 10,000 x 5 GiB = 50,000 GiB = 48.828125 TiB, which the page rounds to 48.8 TiB and the announcement rounds to "50 TB". I state the page's own unit and give the conversion. |
| CloudWatch Logs event size: "1,024 Kilobytes" on the quotas page, "no larger than 1 MB" in `PutLogEvents` | The same value. `PutLogEvents` also states the batch maximum as "1,048,576 bytes", which is exactly 1,024 KB — AWS writes that quantity as 1 MB. The quotas table itself uses both conventions in adjacent rows. |
| A fetch tool's summary called part of an AWS messaging guide "misleading" | A tool's editorial judgement is not evidence. I recorded the guide's actual claim and the conflict, and resolved it only after reading the service's own developer guide. The judgement never entered a document. |
| Lambda VPC timeout message: "Task timed out after 3.00 seconds" on one page, "3.01 seconds" on another | Both are real. The number is the configured timeout plus jitter, so it varies by invocation. The error catalogue indexes the stable prefix and says which part varies. |
| IAM Identity Center: a concept page says permission-set changes propagate automatically; `CreateAccountAssignment` says you must call `ProvisionPermissionSet` | Both are true of different callers. The console reprovisions on your behalf; API and IaC callers must call `ProvisionPermissionSet`. The fix was to say which interface each statement describes, not to pick one. |
| Access-denied messages: one page ends them "with an explicit deny", another "with an explicit deny in a `<type>` policy", a third adds a policy ARN | Documented evolution, not disagreement. The type phrase and the ARN were added in different years and not every service emits the newest shape, so all three occur in the wild. The catalogue indexes all three. |
| The 2025 compute decision guide does not mention App Runner, while the App Runner page says it is closed to new customers | An omission, not an inaccuracy. A lifecycle notice outranks a decision guide's service list; nothing in either page is false. |
| A NAT error message embeds a default quota ("limit of 5 NAT gateways") | Not a contradiction with the quotas page; it is an adjustable quota appearing inside a fixed string. The catalogue indexes the message with the number replaced and names it as the account's quota. |

---

## What this means for teams

Documentation errors used to cost one engineer an afternoon. They now propagate: an agent grounded on a
decision guide's "exactly-once" cell will write a non-idempotent consumer and defend the choice with a
citation, and a reviewer who checks the citation will find it says exactly that. Retrieval does not fix this,
because the wrong claim is genuinely on an authoritative page.

What fixes it is cross-checking against the artefacts that cannot be stale in the same way — the SDK's type
definitions, the template the tool actually deploys, the library's own deprecation markers — and recording
disagreements instead of resolving them silently, so the conflict is visible to whoever reads the document
next. Three of the five findings above were only settleable from a package or a template; none of them would
have surfaced from reading pages alone.

That is the work of a data and solutions architect: deciding which source is authoritative for which kind of
claim, building the verification into the pipeline rather than the reviewer's memory, and leaving behind a
record that says how each fact was established and when it should be checked again.

---

## Appendix: sources

All URLs read on **2026-10-21** unless noted. AWS documentation pages were read via their `.md` variant; the
canonical `.html` URL is given here.

### AWS documentation pages

| Page | URL | Date read |
|---|---|---|
| `cdk bootstrap` command reference | `https://docs.aws.amazon.com/cdk/v2/guide/ref-cli-cmd-bootstrap.html` | 2026-10-21 |
| Troubleshooting common AWS CDK issues | `https://docs.aws.amazon.com/cdk/v2/guide/troubleshooting.html` | 2026-10-21 |
| Permissions and the AWS CDK | `https://docs.aws.amazon.com/cdk/v2/guide/permissions.html` | 2026-10-21 |
| Deploy CloudFormation stacks faster with express mode | `https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cloudformation-express-mode.html` | 2026-10-21 |
| Amazon SQS, Amazon SNS, or Amazon EventBridge? (decision guide; page states "Last updated November, 2025") | `https://docs.aws.amazon.com/decision-guides/latest/decision-guides/sns-or-sqs-or-eventbridge.html` | 2026-10-21 |
| Using Lambda with Amazon SQS | `https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html` | 2026-10-21 |
| Creating and configuring an Amazon SQS event source mapping | `https://docs.aws.amazon.com/lambda/latest/dg/services-sqs-configure.html` | 2026-10-21 |
| Amazon SNS message ordering details for FIFO topics | `https://docs.aws.amazon.com/sns/latest/dg/fifo-topic-message-ordering.html` | 2026-10-21 |
| Lambda `PutResourcePolicy` API reference | `https://docs.aws.amazon.com/lambda/latest/api/API_PutResourcePolicy.html` | 2026-10-21 |
| Lambda Event Function runtimes | `https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html` | 2026-10-21 |
| Building Lambda Event Functions with TypeScript | `https://docs.aws.amazon.com/lambda/latest/dg/lambda-typescript.html` | 2026-10-21 |
| Point-in-time backups for DynamoDB | `https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/Point-in-time-recovery.html` | 2026-10-21 |
| HTTP 504 status code (Gateway Timeout) | `https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/http-504-gateway-timeout.html` | 2026-10-21 |
| Restrict access with VPC origins | `https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html` | 2026-10-21 |
| Restrict access to an Amazon S3 origin (OAC / OAI) | `https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html` | 2026-10-21 |
| Troubleshoot NAT gateways | `https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-troubleshooting.html` | 2026-10-21 |
| NAT gateways (connectivity types) | `https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html` | 2026-10-21 |
| NAT gateway basics | `https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-basics.html` | 2026-10-21 |
| Regional NAT gateways for automatic multi-AZ expansion | `https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateways-regional.html` | 2026-10-21 |
| IAM and AWS STS quotas | `https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html` | 2026-10-21 |
| AWS STS Regions and endpoints | `https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_region-endpoints.html` | 2026-10-21 |
| STS `AssumeRole` API reference | `https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html` | 2026-10-21 |
| Sharing objects with presigned URLs | `https://docs.aws.amazon.com/AmazonS3/latest/userguide/ShareObjectPreSignedURL.html` | 2026-10-21 |
| Download and upload objects with presigned URLs | `https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html` | 2026-10-21 |
| Amazon S3 multipart upload limits | `https://docs.aws.amazon.com/AmazonS3/latest/userguide/qfacts.html` | 2026-10-21 |
| Troubleshoot access denied (403 Forbidden) errors in Amazon S3 | `https://docs.aws.amazon.com/AmazonS3/latest/userguide/troubleshoot-403-errors.html` | 2026-10-21 |
| Blocking public access to your Amazon S3 storage | `https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html` | 2026-10-21 |
| CloudWatch Logs quotas | `https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/cloudwatch_limits_cwl.html` | 2026-10-21 |
| CloudWatch Logs `PutLogEvents` API reference | `https://docs.aws.amazon.com/AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html` | 2026-10-21 |

### Packages read at a pinned version

Each was downloaded from the npm registry with `npm pack` at the version shown and read from the unpacked
tarball; nothing was installed into a project.

| Package | Version | What was read |
|---|---|---|
| `aws-cdk` (the CDK CLI) | 2.1146.0 | `lib/api/bootstrap/bootstrap-template.yaml`, and the bootstrap code path in `lib/index.js` |
| `aws-cdk-lib` | 2.273.0 and 2.274.0 | `core/lib/stack.d.ts`, `core/lib/stack.js`, `aws-s3/lib/bucket.d.ts` |
| `@aws-sdk/client-cloudformation` | 3.1154.0 | `dist-types/models/models_0.d.ts` (`DeploymentConfig`) |
| `@aws-sdk/client-dynamodb` | 3.1154.0 | `dist-types/models/models_0.d.ts` (`PointInTimeRecoverySpecification`) |
| `@aws-sdk/client-lambda` | 3.1154.0 | `dist-types/models/models_0.d.ts` (`PutResourcePolicyRequest`) |
| `@aws-sdk/client-sqs` | 3.1154.0 | `dist-types/models/errors.d.ts` (the KMS exception classes) |


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 131 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/aws/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->