Where the AWS Primary Sources Disagree About Launch Dates - Which Document Systems Carry a Date, What Shapes the Disagreements Take, and Which Date to Record

First Published: 2026-09-22
Last Updated: 2026-09-22

An internal technical document needs one line that says when a particular AWS feature became available. The research was supposed to take five minutes. The AWS What's New announcement page opens, and a date is printed on it, ready to be copied across. Then a colleague's comparison document turns out to carry a date one day apart. Both of them link to an official AWS page.

What is happening in this scenario is not an error in the documents themselves. All that happened is that only one source was opened. AWS records the same events across multiple document systems, each with its own named date field, and each recording a different kind of day. The date the announcement was published, the date the document itself was updated, and the date the feature actually became effective are three different things. Most of those one-day gaps come from comparing dates of different kinds.

Beyond those, genuine disagreements exist as well. There are events documented in only one document system, instances where the same event is associated with two different dates, and cases where the dates are the same but the scope of the information described differs. Occasionally, a page might even present conflicting information with itself. These are not the result of a reader misreading anything; they are real differences on the side of the sources.

This article will focus on differentiating these two categories. This is not a tour of the documentation. Instead, it sets out which document systems carry a date and what each of those dates records, a classification of the shapes those disagreements take, and ultimately, a method for selecting a single date to record. The intended reader is anyone who has to put a single AWS launch date into a technical document, a comparison table, an audit trail, or a timeline.

One point is worth stating before anything else. This article does not claim that the AWS documentation contradicts itself. The claim is narrower than that: a date is not settled by a single source. In fact, many of the examples cited in this article arose as a result of each document accurately fulfilling its intended purpose. It is entirely normal for the day a document was updated to differ from the day a feature became available. Problems only arise when a reader misinterprets that field as an answer to a different question.

Every specification and every measured value in this article was verified against the official AWS documentation and against a corpus held locally. The verification date is 2026-09-21. Every measured value carries its population. That population is not AWS as a whole. One of the two is the set of public AWS pages this article retrieved by name; the other is the set of URLs cited by the existing articles on this site. No claim of comprehensiveness is made.

The division of labor with the existing articles is worth stating first as well. This article does not contain specific dates for individual services. The existing timelines hold those dates. What it holds is the result of reading across the answers those timelines gave one at a time. It does not hold the dates at the other end either, the retirement and end-of-support deadlines. AWS Retired Services History and Timeline and AWS End-of-Support and EOL Reference maintain that information. Furthermore, this article does not address the lifecycle classification terms themselves. The definitions of terms like Maintenance, Sunset, and Full Shutdown, and how those terms are used, are maintained in AWS Service Lifecycle States. Here that system appears only as one of the document systems that carry a date.

What Happens Before a Single Date Can Be Written
Which Documents Carry a Date
What Is Not a Disagreement
The Four Shapes a Disagreement Takes
What Actually Happened Across the Existing Timelines
Deciding Which Date to Record
Failure Modes
Frequently Asked Questions
Summary
References

1. What Happens Before a Single Date Can Be Written

Writing down a date is not research. It is a choice. This chapter sets out what has to be settled before that choice can be made.

1.1 The Date You Are About to Record

When recording a date on documentation, the author typically intends to indicate one of the following:

Intention	What the reader expects
The date AWS announced this feature.	The date the announcement was released.
The date this feature was first used in production.	The date general availability began.
The date this feature became available for activation within an account.	The date the feature became available.
The date the description of this feature was included in the documentation.	The date the documentation was updated.
The date this change takes effect.	The effective date.

The problem is that, before you begin your search, you often have not decided which of these dates you are looking for. If you have not decided, the first date you find will become the answer. And the date that appears first is determined by the search terms you use and the whims of the search engine.

1.2 Being Different and Disagreeing Are Not the Same Thing

That two sources show different dates does not by itself mean they disagree. Two things have to be separated first.

Different facts. The date of an announcement and the date of general availability are separate events. The date a document is updated is a different event from the date a feature becomes available. The date a change takes effect is a different event from the date it was announced. In these cases, the two sources are not giving different values for the same thing; they are recording different events.
A genuine disagreement. In these cases, two AWS documents present different values for the same event, or one document may not record the event at all, or the two may record a different scope for it. One source may also carry values that do not line up with each other.

Chapter 3 takes the first of these and Chapter 4 takes the second. Do not reverse that order. Counting different facts as disagreements makes the number of disagreements look far larger than it is, potentially leading to the incorrect conclusion that AWS documentation is unreliable.

1.3 Scope of this Article

Covered	Not Covered
Which document systems carry a date	The launch date of an individual service
The name of each date column, and what that column records	End-of-support and retirement deadlines
How the shapes of a disagreement are classified and told apart	The lifecycle vocabulary and how it drifts
How a single date is chosen	The document systems of other clouds
The failure modes that arise while researching a date	Pricing

2. Which Documents Carry a Date

AWS has no single field named launch date. This is the starting point of this article. There are multiple document systems, and each one stores different dates in fields with different names.

2.1 AWS What's New

Each AWS What's New announcement page displays a single line with the date at the top of the content. The format is as follows:

Posted on: Jun 30, 2026

The server puts this Posted on: line straight into the raw HTML bytes. Displaying the date takes no work in the browser.

The same page's HTML also includes a machine-readable date.

postDateTime":"2026-06-30T07:00:00Z"

⚠ The postDateTime value appears in two formats. One is Coordinated Universal Time carrying a trailing Z, and the other carries a numeric offset. Out of the 198 pages examined, 183 had a value. Of those, 157 carry the Z form and 26 carry the numeric offset form (measured 2026-09-21; the population is set out in Section 5.1). The offsets that appear are -04:00, -05:00, -07:00, and -08:00. The remaining 15 pages do not contain a value, a topic addressed in Section 7.1.

For the 157 pages carrying the Z form, the date shown on the Posted on: line matched the UTC date in postDateTime in all 157. Among the 26 pages carrying a numeric offset, not one case appears in which the date read against the offset and the date read as UTC fall on different days. It was not possible to determine whether the displayed date followed the offset or the UTC time. This point remains unverified in this analysis.

2.2 The History Page in a User Guide

Each service's user guide has a dedicated page that tracks changes and revisions. This page does not have a single, consistent name or URL.

Retrieving the 48 history pages that the existing articles on this site cite turns up 13 distinct file names (measured 2026-09-21). The counts below add up to the 48.

File Name	Count
`doc-history.html`	18
`document-history.html`	10
`WhatsNew.html`	6
`release-notes.html`	5
Nine more names, one page each (`cloudtrail-document-history.html` / `cognito-document-history.html` / `dochistory.html` / `eb-document-history.html` / `lifecycle-doc-history.html` / `sagemaker-eks-checkpointless-release-notes.html` / `sagemaker-hyperpod-inference-release-notes.html` / `slurm-versions_release-notes.html` / `sqs-release-notes.html`)	9

⚠⚠ The most confusing of these is Amazon S3. The history page of the Amazon S3 User Guide sits in a file named WhatsNew.html, and the heading on that page reads Document history. The name of a different document system, AWS What's New, is the file name of the history page. Guessing the URL from the name gets it wrong.

⚠ The page titles are also inconsistent. Under the same file name WhatsNew.html, the Amazon S3 page is titled Document history while the Amazon ElastiCache page is titled ElastiCache Documentation history. A single keyword will not find these pages, whether the search is on the file name or on the page title.

⚠ Attempting to construct URLs based on assumptions can result in incorrectly identifying existing pages as non-existent. When trying the name doc-history.html on the Amazon S3 user guide, the server returns an HTTP 200 status, but the page redirects to the guide's front page. No historical content is found. You need to navigate from the table of contents. AWS History and Timeline regarding Amazon EFS recorded this pitfall first, for Amazon EFS.

2.3 Two Tables on a Single Page

A history page may contain more than one table. Of the 49 pages retrieved, 9 had two history tables (measured 2026-09-21, from a population of 48 pages plus one AWS Wavelength history page). 32 pages had only one table, while 8 had a different structure and lacked any history tables.

And within a single page, the name of the date column splits.

Page	Date column, first table	Date column, second table
Amazon EFS User Guide	`Date`	`Date Changed`
Amazon ElastiCache User Guide	`Date`	`Date Changed`
Amazon RDS User Guide	`Date`	`Date changed`
AWS CloudTrail User Guide	`Date`	`Release Date`
Amazon Redshift Administration Guide	`Date`	`Release date`

Restricted to the table at the top of the page, the name of the date column is stable: 39 of 41 pages use Date. The remaining 2 use Release Date, and the AWS Wavelength Developer Guide is one of them. Therefore, while the term Release Date does exist, it is not the majority and may only appear in the lower portion of a page.

⚠ This finding came out of rebuilding the check once, during the writing of this article. The initial extraction only read the first heading row on each page. The second extraction only read tables enclosed in <thead>. Each of them looked at one table only, and the two disagreed. Counting both tables is what revealed that a single page can carry two different column names. The inspections produce candidates, not definitive conclusions.

2.4 Pages Describe Their Scope

History pages sometimes include a brief sentence, preceding the table, that describes what information is being tracked. The history page for Amazon EFS, for example, states this directly before the first table.

The following table describes important changes to the Amazon Elastic File System User Guide
after July 2018.

Before the second table, the text reads before July 2018. This means that this page is effectively split into two sections; reading only the first table makes it look as though the record for Amazon EFS begins in July 2018. In reality, the second table contains entries from before that date, including information about the general availability release.

Change:       General availability
Description:  Amazon EFS is now generally available to all users in the US East (N. Virginia),
              US West (Oregon), and Europe (Ireland) Regions.
Date Changed: June 28, 2016

This row sits under a date column named Date Changed, not Date.

A history page can also carry dates that sit outside the table. The Amazon EFS history page, for instance, includes two lines within the heading block.

API version: 2015-02-01
Latest documentation update: June 9, 2025

API version is an identifier that indicates the version of the service's API, and is not the date the service began. Latest documentation update indicates the date the documentation was last updated, and is not the date the service was last updated. If you interpret these two lines as representing the service's launch date, you will find that they provide answers to different questions.

2.5 The Lifecycle Announcements

There is a separate document system related to the end-of-life process. However, this article does not address the terminology used within that system. The definitions of the three states Maintenance, Sunset, and Full Shutdown, what each one takes away, the circulation of terms that are not formally defined, and the methods for monitoring announcements to ensure nothing is missed, are all documented in AWS Service Lifecycle States. This article focuses solely on determining the dates associated with this system.

The dates this system carries are effective dates. They are not the days the announcements went out. Section 3.3 takes up the relationship between the two.

AWS posts the individual changes to AWS What's New. Counting these posts is more complex than it appears.

Posting Date	Title	`postDateTime`
2025-05-20	`AWS service changes`	`2025-05-20T13:00:00-04:00`
2025-10-13	`AWS Service Availability Updates`	`2025-10-13T07:00:00Z`
2026-03-31	`AWS Service Availability Updates`	`2026-03-31T17:00:00Z`
2026-06-30	`AWS Service Availability Updates`	`2026-06-30T07:00:00Z`

⚠⚠ Only the first post has a different title and URL slug. Subsequent posts all use the aws-service-availability slug, but the first post uses aws-service-changes. If you search using a single slug and vary the year and month, you will not find the first post. This was actually observed during the writing of this article (see Section 7.6).

⚠ The criteria for collection are as follows: The table holds posts on AWS What's New whose subject is a portfolio-wide availability update, as found on 2026-09-21. Complete coverage is not guaranteed. Any posts with different titles may not appear in this table. It also does not include announcements regarding the end-of-life for individual services.

⚠ Regarding the period from July to September 2026, three searches using the aws-service-availability slug all resulted in HTTP 404 errors. This does not prove that there are no subsequent entries. As with the first post, there remains a possibility that the information is available under a different slug.

2.6 Documents That Carry No Date

Finally, there are materials that are widely referenced but lack dates. Service FAQ pages, product overview pages, the main body of user guides, and console help panels all describe the current state of a service, but do not state when that state came into being. While these are primary sources for describing the current condition, they cannot be used as sources for dates.

⚠ One service has already had all of this set out for it. Amazon Linux History and Timeline names the systems it drew on for a single product family, and it reaches the same split: the announcements, the document history of the release notes, the FAQ pages, and the update notes at the head of a blog post.

Which AWS Document Systems Carry a Date, and What Each Date Records

3. What Is Not a Disagreement

This chapter is the premise for the next one. Skip it and the classification in Chapter 4 cannot be applied. Most of the cases where two values differ are explained by the two sources having recorded different things from the outset.

3.1 Announcement Date and General Availability Date

AWS announces the preview and the general availability of one feature separately. AWS announced Amazon Bedrock AgentCore in preview in July 2025 and as generally available in October 2025. Both announcements sit on AWS What's New, and the Posted on: date on each is correct. Without specifying which announcement is being referenced, the question of when it was released cannot be answered.

⚠ Whether these two dates are differentiated depends on the service. AWS History and Timeline regarding Amazon FSx does not differentiate between two dates for Amazon FSx's four file systems. This is because the oldest entry on each user guide's history page refers to the general availability release, and that date matches the announcement date on the AWS News Blog. The decision was not made because information was lacking; rather, it was determined that there was no need to differentiate these four instances.

3.2 The Document Update Date

The date column on a history page records the day the document was updated, not the day the feature became available. Therefore, it is normal for the dates on the AWS What's New page and the history page to differ.

⚠⚠ The direction of the gap is not consistent. AWS History and Timeline regarding AWS Direct Connect records two changes to one service where the gap leans opposite ways. For a 400 Gbps dedicated connection, the history page is 17 days later, while for longer ASN support, the history page is 50 days earlier. This cannot be explained by a simple relationship where the document merely catches up to the announcement. Therefore, no rule about taking the later date or the earlier one follows from watching which way the gap leans.

3.3 Effective Date

Lifecycle announcements have both an announcement date and an effective date. These two dates are distinct, and the effective date can sometimes precede the announcement date. For example, the AWS Service Availability Updates of October 2025, whose postDateTime is 2025-10-13T07:00:00Z, says this about end of support:

The following services have reached end of support and are no longer available as of October 7, 2025.

Support ended six days before the announcement went out. Recording the announcement date as the end-of-support date puts it six days out.

⚠ There are at least three different dates associated with the end of a service. AWS Retired Services History and Timeline keeps the announcement date, the new-customer-close date, and the end-of-service date apart in every row.

3.4 The Year and Month in the URL

The URLs for AWS What's New, such as /about-aws/whats-new/2026/03/..., include a year and month within the path. That year and month need not match the publication date.

Out of the 157 pages retrieved, in only one instance did the year and month in the path differ from the year and month in the postDateTime field (measured 2026-09-21). The path indicated March 2026, while the postDateTime was 2026-02-26T23:06Z. The proportion is small, but one hit puts the date a month out.

⚠ This pattern is documented earlier in AWS History and Timeline regarding AWS Elastic Beanstalk. It records a case where the path reads 2026/04 while the Posted on: line reads May 6, 2026. Therefore, the year and month in the URL should not be considered a reliable source for determining the actual publication date.

3.5 The Umbrella Date and the Per-Service Exception

The umbrella date and its exceptions are missed more often than anything else in this chapter. Lifecycle announcements first state the umbrella date in a single sentence, followed by a list of affected services. However, within that list, some entries include a different date in parentheses.

The announcement for March 2026 states the umbrella date as follows:

Services moving to maintenance will no longer be accessible to new customers starting April 30, 2026.

Following that, the list includes the following entry:

AWS CloudTrail Lake (CloudTrail Lake will stop accepting new customers on May 31, 2026)

These two entries are not contradictory. The date in parentheses specifies an individual exception. Reading only the list and applying the umbrella date puts the row 31 days out.

The June 2026 announcement follows the same structure. The umbrella date is starting July 30, 2026, and the list includes the following entry:

AWS IoT Device Defender – Detect (feature will no longer be accessible to new customers starting August 31, 2026)

The announcements for May 2025 and October 2025 do not have this type of exception; they only state the umbrella date. Therefore, in two out of the four instances referenced in Section 2.5, applying the umbrella date to individual services will result in an error.

⚠ The value of May 31, 2026 for AWS CloudTrail Lake appears with the same value on the product page, in the API reference, in the partner guide, and in the history page of the user guide. A majority of the materials list this individual value. Only the umbrella date statement describes a different date, and that date is correct for the overall scope.

4. The Four Shapes a Disagreement Takes

What is left after Chapter 3 is the genuine disagreement. The classification in this chapter reconciles the classifications that the existing timelines on this site reached one at a time (see Section 4.5 for the background).

4.1 The First Shape - Only One Source Carries It

Regarding the same event, one document contains a record while the other does not. This is the most common of the four shapes.

AWS History and Timeline regarding Amazon EFS records that 20 of its 36 rows were carried by only one of the two sources. AWS History and Timeline regarding AWS Elastic Beanstalk records that 41 of its 47 rows were carried by only one side, and that 37 of those appear only in the release notes.

⚠ Which of the two is missing carries meaning of its own.

Carried only by the history page: A change of default, or the arrival of a piece of vocabulary, can happen without an announcement. The date when Amazon EFS's default throughput mode changed, and the introduction of the concept of file system type, are both recorded only on the history page. Reading only the announcements provides no way to know when the default changed.
Carried only by AWS What's New: When the ways of reaching a service are extended on another service's side, the record lands in that other service's documentation. For Amazon EFS, 7 of the 10 rows carried by only one side are of this kind. This is not a case of missing information; rather, the information is located elsewhere.

⚠⚠ The absence of a record is not the same as nothing happening. AWS History and Timeline regarding AWS Direct Connect records that, despite having no entries for 2022 on the history page, an actual feature was added on August 8, 2022. The same article also notes that while the history page's entries for new locations stopped in 2021, the announcements kept describing a count that grew from more than 100 to more than 150. Do not interpret silence on the history page as evidence that the service was inactive.

4.2 The Second Shape - The Same Event, Different Dates

Both sets of records describe the same event, but the dates differ.

Timeline	Event	Gap
Amazon EFS	General availability	1 day
AWS Direct Connect	400 Gbps dedicated connection	17 days
AWS Direct Connect	Support for longer ASNs	50 days
AWS Transit Gateway	Support for AWS Direct Connect	34 days
AWS Elastic Beanstalk	Support for Node.js 24	15 days

The difference in dates ranges from one day to fifty days. Smaller differences are more likely to be overlooked, while larger differences can easily lead to the event being incorrectly split into two separate entries.

⚠ Regarding Amazon Athena, there are instances where the same information is published on different dates, and also cases where eight different items have separate heading dates but share the same publication date. AWS History and Timeline regarding Amazon Athena records both. The range of differences is from one to six days.

⚠ This pattern is not limited to AWS. VMware History and Timeline documents instances where the date of the final ownership transfer following an acquisition varies across different records, with a difference of approximately one and a half years.

4.3 The Third Shape - The Dates Agree, the Statements Do Not

This shape cannot be detected by comparing dates alone. Two documents may share the same date, but describe different things regarding what became available on that day.

AWS History and Timeline regarding AWS Direct Connect records a SiteLink case of exactly this kind. The row in the document history says the connection reaches inside the same Region. The body of the same user guide says it reaches inside the same partition. Inside one Region and inside one partition are not the same scope at all. The former connects locations inside one Region; the latter creates routes that span continents.

⇒ That article takes the row as evidence for the date, and not as evidence for the scope. One row answers one question and is refused the other.

AWS History and Timeline regarding Amazon EFS records the same shape. It describes a case where the number of storage classes listed differed between the FAQ page and the console's help panel. The two count inside different frameworks, and each is correct inside its own.

4.4 The Fourth Shape - One Source Disagrees with Itself

One part of a page says one thing, and another part of the same page says another.

On the AWS Direct Connect partner page, one section states that the number of transit virtual interfaces supported for dedicated connections is 4, while another section states it is 1 (verified on the live page 2026-09-21).

Dedicated Connections: 1 Gbps, 10 Gbps or 100 Gbps physical Ethernet ports dedicated to a single
customer that supports 50 private or public virtual interfaces (VIF) and 4 transit VIF.

Customers who need more than one VIF may obtain multiple Hosted Connections or use a Dedicated
Connection which provides 50 private or public VIFs and 1 transit VIF.

⚠ Amazon Linux History and Timeline records a second case of the same kind. On the Kernel Live Patching page, the prerequisites section lists two supported kernels while the first step on that same page allows only one.

⚠⚠ Within the range this article examined, this shape turned up more often in numbers and in scope than in dates themselves. That is not a claim that it does not happen to dates. It is only a statement that no instance was found within the range searched. The fourth shape stays in the classification because researching a date always involves checking numbers and scope, and because a page whose own values do not line up will distort the judgment of the other three shapes.

4.5 Why Four

These four shapes are not a classification invented here. Two of the existing timelines on this site reached a classification within their own subject. And the numbers they reached did not agree.

Timeline	The number the article itself states	Breakdown
The AWS Direct Connect timeline	3	Different dates / One source does not carry it / Different scope
The Amazon EFS timeline	4	Different dates / The history page does not carry it / AWS What's New does not carry it / Different framework

The difference is in how they count. The Amazon EFS article splits the first shape in two according to which source is missing. The AWS Direct Connect article keeps those as one and stands up the difference in scope instead. Each is correct for its own subject, and only reconciling them shows that the two were looking at the same thing at a different grain.

This article treats which side is missing as a subdivision of the first shape (Section 4.1), folds the difference in scope and the difference in framework together into the third shape (Section 4.3), and makes the disagreement inside one source the fourth shape (Section 4.4). That reconciliation is the job this article does. It is not a rearrangement of the conclusions the individual timelines reached. Two other articles borrow these four shapes for a subject other than dates: What Consistent Means, Service by Service on AWS applies them to the word consistent, and Falsehoods AWS Architects Believe About Regions and Availability Zones applies them to Regions and Availability Zones.

Deciding Whether Two AWS Sources Disagree About a Date

5. What Actually Happened Across the Existing Timelines

This chapter is a measurement. The population comes first, because what was measured is not AWS as a whole.

5.1 Population

Population	Count	Measurement Method
Published articles (HTML)	414	`index.html` excluded
Of those, articles whose slug contains `timeline`	80	Timeline articles
Of those timelines, the ones carrying a section on how they were built	69	Subsections of that section included
Unique AWS What's New URLs cited by the published articles	2,320	Duplicates removed
Sampled from those and retrieved	198	200 drawn with the random seed fixed at 20260921. Two were dropped because the extraction pattern had cut them short
Unique history page URLs cited by the published articles	48	All of them retrieved

Every figure above was measured 2026-09-21. ⛔ No AWS-wide proportion can be estimated from it. The URL population is what the existing articles happened to cite, not a random sample of what AWS publishes.

5.2 What the 69 Timelines Wrote

For the 69 timelines that carry a section on how they were built, this article counted the words appearing in that section. The section runs to a median of 364 words.

Term	Timelines	Percentage
`announcement`	65	94%
`differ` or `disagree` or `discrepan`	63	91%
`What's New`	58	84%
`document history`	26	37%
`blog`	19	27%
`general availability` or `GA`	18	26%
`preview`	10	14%
`FAQ`	5	7%
`Posted on`	4	5%

⇒ Nine articles in ten touch on the sources differing. The problem is not particular to one service; it comes up every time a timeline is written.

⚠ At the same time, only 4 of the 69 write down the string Posted on at all. The difference is written about again and again, and yet few of the articles say which column the date was taken from. That is why Chapter 6 sets out a procedure.

5.3 The Timelines That Went as Far as a Classification

Of the 69, four went past a note that the sources differ and reached a classification with counts.

Timeline	How far it went
Amazon EFS	Sorted 36 rows into four groups and counted 20 rows carried by only one source
AWS Elastic Beanstalk	Sorted 47 rows into four groups and observed that the 3 rows with a gap all lean the same way
AWS Direct Connect	Observed that the 2 rows with a gap do not lean the same way, and sorted the disagreements into three
AWS Transit Gateway	Tabulated the size of the gap and the date adopted for 4 rows

⚠ 35 of the existing articles carry a section heading holding both Primary Sources and Disagree, but only 3 of them are timelines (measured 2026-09-21). The remaining 32 are not timelines; they deal with sources disagreeing about a specification rather than about a date. Those 35 and the 69 in this chapter are different populations.

5.4 What This Measurement Cannot Show

It cannot be said that the AWS sources always disagree about dates. What was counted is whether the existing articles touch on a difference, not an exhaustive comparison of AWS pages against each other.
No rate of disagreement follows from it. The breakdown in those four timelines depends on which pair of sources each of them chose.
No per-service tendency follows either. There is one timeline per service, so the sample size is one.

6. Deciding Which Date to Record

This is where the article lands. It is not the advice to look at more than one source. It is about settling an order in advance, and deciding what to write when the sources split.

6.1 The First Decision Is Which Kind of Date Will Be Written

Before the research begins, decide which row of the table in Section 1.1 is being filled in. If that cannot be settled, the question does not have one date. Widen the record to two columns, or say in the wording which kind of date it is.

If the decision is to record the general availability date, the preview announcement is not used. If the decision is to record the announcement date, the general availability announcement is not used either, even when a separate one exists. Finding a different kind of source first is not a reason to change the decision.

6.2 Priority Order

Work down this order against the kind of date chosen.

Rank	Document	Information to Extract
1	The AWS What's New announcement for the change	The date on the `Posted on:` line
2	The history page of the user guide for the feature	The date in the matching row, whatever that column is named
3	The dedicated page for the feature, where it states a date outright	The effective date or the deadline that the body of the page states
4	The official AWS blog	The post date of the article

⚠ The order ranks the questions that each source can answer, not the reliability of the sources. A history page may hold the earlier date, and if the kind chosen is the announcement date, rank 1 is still the answer. If the kind chosen is the document update date, rank 2 is the answer.

⚠⚠ For lifecycle dates only, the order is reversed. As Section 3.5 shows, the value on the individual service page is the correct one, not the umbrella sentence. Find the individual statement first, then read the umbrella one.

6.3 What to Write When the Sources Split

If a difference survives Chapter 3, that is, when it falls into one of the four shapes in Chapter 4, write the following:

Record a single date. Do not present multiple options for the reader to choose from.
Say which source, and which column of it, the date came from. Name the column exactly, whether that is Posted on: or Date or Release Date.
Say that the sources disagree, and by how much. Noting which way the gap leans is fine, but do not turn that direction into a rule (see Section 3.2).
Also include the value from the source that was not used. This allows readers to compare the data with their own records and determine which value corresponds to which source.

⚠ The first of those four applies to a date, not to everything. Where the sources disagree about a specification rather than a date, presenting both and declining to choose is a defensible answer: Amazon Linux History and Timeline sets out eight such cases side by side and states outright that it does not decide which description is correct. A date in a row of a timeline has to be one value; a sentence about what a feature covers does not.

⚠ The second point is the most frequently overlooked. Many articles say that the sources differ, and few say which column the date came from (see Section 5.2).

6.4 The Minimum a Record Must Carry

For each date, you must retain at least the following four items:

Item to Retain	Reason
The date itself	—
Source URL	Cannot be reconstructed through guesswork (Section 2.2)
The name of the column it came from	A single page can carry two different column names (Section 2.3)
The day it was checked	A source changes after the fact, and a URL can keep its address while changing where it lands (Section 7.1)

⚠ The day it was checked is not optional. History pages gain rows. Announcement slugs change form. A URL keeps its address and changes where it lands. Without that day, nobody can say when the date was true.

7. Failure Modes

The failures below belong to the work of researching a date. All of these pass mechanical checks. The URLs respond correctly, the citations match the primary sources word for word, and the date formats are accurate. The only thing wrong is that the value retrieved answers a different question from the one being asked.

7.1 Reading HTTP 200 as Having Read the Page

This is the quietest of the failures. A URL can return 200 without the request having landed on the intended page.

Retrieving 198 of the AWS What's New URLs cited by the existing articles on this site shows that 15 of them (7.6%) returned HTTP 200 and still landed on a listing page (measured 2026-09-21). The requests landed on either /new/?audit=2019q1 or /about-aws/, and neither page carries a date at all. The URLs that behaved this way run from 2004 to 2016, and they include the older form built from a date alone, with no slug.

⚠⚠ Those 15 are exactly the same set as the 15 whose postDateTime value could not be read in Section 2.1. Not one page changed its destination and still yielded a value, and not one page kept its destination and failed to yield one. ⇒ In this dataset, the inability to retrieve a date and the failure to land on the intended destination are the same phenomenon.

⇒ An HTTP status code does not say whether the request landed where it was aimed. Check whether the final URL matches the one that was requested. The Amazon S3 history page in Section 2.2 is the same shape of failure.

7.2 Treating a Search Summary as the Primary Source

A search summary can add an item that does not appear on the page itself.

During the writing of this article, regarding the AWS Service Availability Updates from June 2026, the search summary listed three items as reaching end of support. The actual page listed only two items. One item that the summary included did not exist on the actual page.

⚠ This pattern is already documented in AWS History and Timeline regarding AWS Elastic Beanstalk. That article, also concerning the June 2026 announcement, notes that the search summary listed three items while the actual page listed two. This article observed the same thing independently, on a different day.

7.3 Treating the Year and Month in the URL as the Posting Date

As Section 3.4 shows, the year and month in the URL need not match the posting date. The proportion is small, but one hit puts the date a month out. Read the Posted on: line.

7.4 Applying the Umbrella Date to an Individual Service

As Section 3.5 shows, a lifecycle announcement carries its exceptions in parentheses inside the list. Copying the list and applying the umbrella date to every row makes the rows with an exception wrong.

⚠ This error actually occurred during the preparation of this article. A working table prepared for this article recorded the date on which AWS CloudTrail Lake closes to new customers as April 30, 2026, which is the umbrella date. The correct value is May 31, 2026. The list was read; the parenthesis was not.

7.5 Reading Silence in the Record as Nothing Having Happened

As Section 4.1 shows, a gap in a history page is a gap in the record, not a gap in events. The absence of entries for a particular year does not necessarily mean that nothing occurred during that year.

7.6 Fixing on a Single URL Form and Querying Only That

Announcements of the same kind are not guaranteed to keep the same slug. While the lifecycle announcements mentioned in Section 2.5 all use the slug aws-service-availability from the second instance onwards, the first instance uses a different title and slug.

⚠⚠ This error occurred here as well. Querying the consistent slug and varying the year and month turned up three posts, and three went down as the count. The missing fourth surfaced only because the existing AWS Service Lifecycle States lists four. The number that could be retrieved was being written down as the number that exists.

⇒ Do not count occurrences based on the URL structure. If you are counting, clearly define your collection criteria and explicitly state that you are not guaranteeing complete coverage (as is done in Section 2.5).

7.7 Settling for a Single Family of Primary Sources

There are multiple pages answering the same question, but with varying levels of detail. Examining only a single line from the history page, as in the SiteLink example in Section 4.3, can lead to a misinterpretation of the functionality's scope. Cross-check the overview page, the page it links to, and the reference.

7.8 Claiming Comprehensiveness

Collecting dates makes a complete list look attractive. A list goes stale. The record behind it stops (Section 4.1), a URL keeps its address and changes where it lands (Section 7.1), and an announcement changes the form of its slug (Section 7.6). The rule used to build the list outlives the list. Keep the rule and a few representative examples, and leave the current list to the official source.

8. Frequently Asked Questions

The following are common questions that frequently arise when trying to determine the AWS launch date. Most of the answers lead back to the separation drawn in Chapter 3 and the procedure set out in Chapter 6.

8.1 Is there a launch date field somewhere in AWS?

No. No single field exists. The Posted on: date on AWS What's New is the day the announcement was published. The date in a history page column is the day the document was updated. The date in a lifecycle announcement is the day the change takes effect. Which of them gets called the launch date is the writer's decision (Section 1.1).

8.2 Which is correct, AWS What's New or the history page?

Both are correct. They simply record different information. If both carry the same event under different dates, that is the second shape (Section 4.2), and no rule can be derived from the direction of the gap (Section 3.2). The choice of which to use depends on the type of date being recorded (Section 6.2).

8.3 Is the oldest row on a history page the day the service began?

No. It is the day the document began. The oldest row on the Amazon EFS history page is the first publication of the user guide, not the announcement of the service. The release notes for AWS Elastic Beanstalk begin 2,738 days after the service's launch.

8.4 Which name should be searched for in the date column of a history page?

Date is the most common, and Release Date also exists. The name used in the upper and lower tables on the same page can sometimes be different (see Section 2.3). Instead of searching by column name, first read the sentence describing the scope, which appears directly above the table (see Section 2.4).

8.5 If `curl` returns 200, is the URL safe to cite?

No. It is necessary to verify the final destination. In the measurement for this article, 15 of the 198 URLs retrieved returned 200 and landed on a listing page (Section 7.1).

8.6 Can a one-day difference be ignored?

It depends on what the record is for. The question can only be answered after the two events behind that one day have been identified. A one-day gap between the announcement date and the document update date falls under Section 3.2: the two are different events to begin with. A one-day gap on the same event falls under Section 4.2, and there one of the two has to be chosen.

8.7 Do the measurements here show how often the AWS sources disagree?

No. The population in question is the collection of previously cited URLs, and it is not a random sample (see Section 5.1 and Section 5.4). This article shows only the shapes a disagreement takes, and how to tell them apart.

9. Summary

AWS has no single field named launch date. Several document systems carry a date, and each puts a different kind of day into a differently named column (Chapter 2).
Most of the cases where two values differ are not disagreements at all. The announcement date, the general availability date, the document update date, the effective date, the year and month in a URL path, and the umbrella date beside its per-service exception all record different things from the outset (Chapter 3).
A real disagreement takes one of four shapes. Only one source carries it, the same event carries different dates, the dates agree but the statements do not, and one source disagrees with itself (Chapter 4).
These four shapes reconcile the classifications that the existing timelines reached one at a time. The AWS Direct Connect timeline arrived at three, the Amazon EFS timeline at four, and the two numbers did not agree (Section 4.5).
Settle which kind of date is being recorded before the research starts. Then work down the order for that kind, and write the value adopted, the column it came from, the size of the gap, and the value not taken (Chapter 6).
Always record the verification date. Records may be added, the format of the announcement slug may change, and URLs may remain the same while the destination changes (Section 6.4).
An HTTP 200 status code does not necessarily mean the content was successfully read. Examine the final destination (Section 7.1).

10. References

This article referenced the primary sources listed below, all of them verified 2026-09-21.

References:
Tech Blog with curated related content

Written by Hidekazu Konishi