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.

1. 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.

1. 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.

1. 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.

1. 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)