hidekazu-konishi.com

AWS History and Timeline regarding AWS Identity and Access Management - Overview, Functions, Features, Summary of Updates, and Introduction to IAM

First Published: 2026-05-16
Last Updated: 2026-05-16

Background and Method of Creating AWS IAM Historical Timeline

• Tracking the history of AWS IAM and organizing the transition of updates
• Summarizing the feature list and characteristics of AWS IAM
• Including the immediately adjacent identity services (Organizations SCP/RCP, IAM Identity Center, Amazon Verified Permissions, Cedar) that are essential context for any modern IAM design, clearly marked as adjacent services rather than parts of IAM itself

• What's New with AWS?
• AWS News Blog
• AWS Security Blog
• Document history for the IAM User Guide

AWS IAM Historical Timeline (Updates from May 3, 2011)

AWS IAM is one of the rare AWS services where the original 2011 evaluation logic (Explicit Deny precedence, union of Identity-based and Resource-based Allows for same-account access, implicit deny otherwise) is still intact today. Almost every major addition in this timeline arrived as either a new policy type (SCP in 2016, Permissions Boundary in 2018, Session Policy in 2018, RCP in 2024) or as a sibling service (AWS Organizations, AWS SSO/Identity Center, IAM Roles Anywhere, Amazon Verified Permissions and Cedar) — not as a breaking change to the core. This makes the IAM timeline less about feature churn and more about the steady accumulation of additional intersection stages around the unchanging granting core.
The implication for engineers is that designing IAM today is less the question "what does IAM allow?" and more the question "which of the seven Decision Diamond stages is the right place for this guardrail?" The next section organizes the resulting policy landscape and tooling.

Current Overview, Functions, Features of AWS IAM

From here, I introduce the current list of AWS IAM features and overview.
AWS Identity and Access Management (AWS IAM) is the foundational AWS service that defines, authenticates, and authorizes principals (users, roles, federated identities) to perform actions on AWS resources. IAM is free, global, and required for every API call to AWS.

A terminology note before we proceed: "IAM User" and "IAM Identity Center user" are distinct concepts.
IAM Users are long-lived identities within a single AWS account, with their own sign-in credentials and access keys.
IAM Identity Center users live in a separate identity store (or are synchronized from an external IdP) and access AWS accounts by assuming IAM Roles for permission sets.
Since the 2022 rename, the recommended path for workforce identity is IAM Identity Center, not new IAM Users. This article uses "IAM User" only in its original, single-account sense.

Use Cases for AWS IAM

The principal use cases of AWS IAM in current deployments are:

• Granting AWS Management Console and API access to internal developers and operators
• Granting workloads (Amazon EC2, AWS Lambda, Amazon ECS, Amazon EKS, Amazon Bedrock AgentCore, on-premises workloads) temporary credentials via IAM Roles
• Enforcing organization-wide guardrails through AWS Organizations Service Control Policies (SCP) and Resource Control Policies (RCP)
• Implementing least-privilege when delegating IAM creation through Permissions Boundaries
• Attribute-Based Access Control (ABAC) for multi-tenant SaaS, where the tenant identifier in the session is matched against resource tags
• Federation from external identity providers (Okta, Microsoft Entra ID, Google, custom SAML/OIDC providers) for single sign-on
• Hybrid workload identity via IAM Roles Anywhere using X.509 certificates from a trusted private certificate authority
• Cross-account access via assumed roles for centralized logging, security tooling, and platform-team operations

Conceptual Model of AWS IAM — The IAM Decision Diamond

Every AWS API request passes through a fixed sequence of seven evaluation stages that together determine whether it is allowed or denied. The canonical naming frame for this sequence on this site is The IAM Decision Diamond, defined and walked through case-by-case in AWS IAM Policy Evaluation Logic Step-by-Step — The IAM Decision Diamond. This section recaps the seven stages in the same order so that each timeline entry above can be located in the evaluation pipeline; for a deeper walkthrough with twelve concrete request traces, see the dedicated article.

                        AWS API Request
                                |
                                v
              +-----------------------------------+
              | Stage 1: Explicit Deny            | --[any Deny matches]--> FINAL DENY
              | (universal short-circuit across   |
              |  Identity/Resource/SCP/RCP/       |
              |  Boundary/Session policies)       |
              +-----------------------------------+
                                |
                                v
              +-----------------------------------+
              | Stage 2: SCP                      | --[no Allow]--> FINAL DENY
              | (Organizations identity-side cap) |
              +-----------------------------------+
                                |
                                v
              +-----------------------------------+
              | Stage 3: RCP                      | --[no Allow]--> FINAL DENY
              | (Organizations resource-side cap) |
              +-----------------------------------+
                                |
                                v
              +-----------------------------------+
              | Stage 4: Resource-Based Policy    |
              | (S3 bucket / KMS key / Lambda /   |
              |  SQS / SNS / Role trust policy)   |
              +-----------------------------------+
                                |
                                v
              +-----------------------------------+
              | Stage 5: Identity-Based Policy    |
              | (User / Group / Role attached     |
              |  policies)                        |
              +-----------------------------------+
                                |
       (Stage 4 union Stage 5 in same-account;
        Stage 4 AND Stage 5 in cross-account)
                  --[no Allow]--> IMPLICIT DENY
                                |
                                v
              +-----------------------------------+
              | Stage 6: Permissions Boundary     | --[outside cap]--> FINAL DENY
              | (identity ceiling, used when      |
              |  delegating IAM creation)         |
              +-----------------------------------+
                                |
                                v
              +-----------------------------------+
              | Stage 7: Session Policy           | --[outside cap]--> FINAL DENY
              | (STS AssumeRole / GetFederation   |
              |  Token session ceiling)           |
              +-----------------------------------+
                                |
                                v
                            FINAL ALLOW

The following table summarizes the seven stages in evaluation order. Stages 2, 3, 6, and 7 are intersection (ceiling) stages that can only cap permissions, while Stages 4 and 5 are union (granting) stages that produce the Allow under same-account semantics or the joint requirement under cross-account semantics. Once any stage ends in Deny, no later stage can override it.

IAM Identities — Users, Groups, Roles, and Federated Identities

IAM Users are long-lived identities scoped to a single AWS account, with sign-in credentials such as a console password, programmatic access keys, and registered MFA devices. AWS guidance now strongly recommends avoiding new IAM Users in favor of federation through AWS IAM Identity Center for workforce users and IAM Roles (or IAM Roles Anywhere) for workloads.

IAM Groups are a way to attach the same set of Identity-based policies to multiple users at once. A group is not a principal — an API request can never be made "as the group"; the group simply aggregates policy attachments for its member users.

IAM Roles are identities with no permanent credentials, designed to be assumed temporarily by trusted principals via the AWS Security Token Service (STS) AssumeRole family of APIs. IAM Roles are used by:

• Amazon EC2 instances (via Instance Profiles)
• AWS Lambda functions (via execution roles)
• Amazon ECS tasks and Amazon EKS pods (via task roles and IRSA / Pod Identity)
• Cross-account access, where a principal in account A assumes a role in account B
• Federated SSO sessions (SAML 2.0, OIDC, IAM Identity Center permission sets, Amazon Cognito Identity Pools)
• AWS services acting on your behalf (service-linked roles)
• Hybrid workloads via IAM Roles Anywhere

Federated Identities are external identities — from SAML 2.0 IdPs, OIDC providers, custom identity brokers, or IAM Identity Center — that obtain temporary AWS credentials by assuming an IAM Role. The original identity is preserved as the role session name and, since 2018, as Session Tags that can be referenced via aws:PrincipalTag/<key> in policies.

IAM Policies — Policy Types Cheat Sheet

AWS IAM today involves several major policy types, each attached to a different kind of entity and serving a different purpose in the IAM Decision Diamond. The following table summarizes them.

Two more adjacent policy concepts are worth recognizing:
→ Cedar policies attached to Amazon Verified Permissions policy stores handle application-level (not infrastructure-level) authorization. They live outside IAM's evaluation engine and are evaluated by an application calling the Verified Permissions API.
→ Declarative Policies in AWS Organizations (2024-11) enforce baseline service configurations (e.g., default VPC properties) across all member accounts. These are not access policies in the IAM sense; they are configuration enforcement.

Policy Evaluation Logic — The IAM Decision Diamond in Detail

When a principal makes an AWS API request, AWS evaluates the request through the following seven stages in order. Understanding this order is the difference between a correct least-privilege design and a mysteriously denied production request. For a full walkthrough including twelve concrete request traces and the corresponding policy JSON, see AWS IAM Policy Evaluation Logic Step-by-Step — The IAM Decision Diamond; for the term-by-term definitions used below, see the AWS IAM Glossary; for representative misreadings of this evaluation order observed in production, see IAM Anti-Patterns - Real-World Mistakes and Their Root Causes.

1. Stage 1 — Explicit Deny: any explicit Deny statement in any of the six other policy types (Identity-based, Resource-based, SCP, RCP, Permissions Boundary, Session Policy) terminates with a final Deny. Explicit Deny is the only universal short-circuit in IAM; no later stage and no Allow statement anywhere can override it.
2. Stage 2 — Service Control Policy (SCP): the SCPs applied to the calling principal's account chain (Root, OU chain, account) must permit the action. SCP is an identity-side ceiling that can only cap permissions, never grant them. Removing the default FullAWSAccess SCP from an OU implicit-denies every action in that OU regardless of identity policies.
3. Stage 3 — Resource Control Policy (RCP): the RCPs applied to the resource's account chain must permit the action. RCP is a resource-side ceiling and is the symmetric counterpart of SCP, available on Amazon S3, AWS STS, AWS KMS, Amazon SQS, and AWS Secrets Manager at launch. RCP enables organization-wide rules such as "no anonymous public access to any bucket" without relying on every individual bucket policy being correct.
4. Stage 4 — Resource-Based Policy: the policy attached to the resource (Amazon S3 bucket policy, AWS KMS key policy, AWS Lambda resource policy, Amazon SQS / Amazon SNS policy, IAM role trust policy, etc.) is evaluated for an Allow that lists the caller as a Principal.
5. Stage 5 — Identity-Based Policy: the policies attached to the calling User, Group memberships, and Role are evaluated for an Allow. Together with Stage 4 this produces the grant decision under the same-account-vs-cross-account split: in same-account access, an Allow from either Stage 4 or Stage 5 is sufficient (union semantics); in cross-account access, an Allow is required from both Stage 4 (the resource owner's side) and Stage 5 (the caller's side). If neither stage produces an Allow, the request is denied by implicit deny.
6. Stage 6 — Permissions Boundary: if the calling identity has a Permissions Boundary attached, the effective permissions are intersected with that boundary. The boundary can shrink permissions but never widen them — an action allowed by the identity policy but outside the boundary is denied. This is the primitive that makes delegated IAM creation safe.
7. Stage 7 — Session Policy: if the session was created with a Session Policy (via the Policy / PolicyArns parameters of sts:AssumeRole, sts:AssumeRoleWithSAML, sts:AssumeRoleWithWebIdentity, or sts:GetFederationToken), the granted permissions are intersected with that policy for the lifetime of the session. Session policies enable least-privileged downscoping per CI/CD job, per request handler, or per delegated invocation.

Two practical consequences fall out of this evaluation order:

• You can never use IAM to grant access that is forbidden by an SCP, RCP, Permissions Boundary, or Session Policy. If a developer reports "my role has s3:* but I get Access Denied", the answer is almost always one of the four intersection stages (Stages 2, 3, 6, 7), not the Identity-based policy itself. The IAM Anti-Patterns catalog enumerates the most common misreadings of this evaluation order.
• Resource-based policies enable cross-account access without an explicit AssumeRole. An S3 bucket policy in account A that allows a principal in account B is sufficient (subject to RCP, SCP, and the calling principal's Identity-based policy) — account B does not need to assume a role in account A first. This is the basis of the multi-account data sharing patterns described in AWS Multi-Account Operational Patterns.

Attribute-Based Access Control (ABAC) and Session Tags

Attribute-Based Access Control (ABAC) in IAM is the pattern of matching tags on the principal session against tags on the resource using the condition keys aws:PrincipalTag/<key>, aws:ResourceTag/<key>, aws:RequestTag/<key>, and aws:TagKeys. ABAC is particularly useful for multi-tenant SaaS workloads, where the tenant identifier in the session can scope access to only that tenant's resources without writing one IAM policy per tenant.

Session Tags (the aws:PrincipalTag family) are passed in sts:AssumeRole, sts:AssumeRoleWithSAML, sts:AssumeRoleWithWebIdentity, or sts:GetFederationToken calls and become part of the request context for the lifetime of the session. Identity providers can map external attributes (department, project, cost center, tenant ID) to Session Tags via SAML attribute statements or OIDC claims, completing the ABAC story for federated identities.

A canonical ABAC pattern is:

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": "secretsmanager:GetSecretValue",
        "Resource": "*",
        "Condition": {
            "StringEquals": {
                "aws:ResourceTag/tenant": "${aws:PrincipalTag/tenant}"
            }
        }
    }]
}

One policy, any number of tenants. The same principle scales to project-based access, cost-center segmentation, and many other multi-dimensional authorization models.

Federation and Cross-Account Trust

IAM supports several federation models, each suited to a different identity source.

• SAML 2.0 federation: enterprise identity providers (Active Directory Federation Services, Okta, Ping, etc.) federate via SAML 2.0; users obtain AWS credentials by assuming an IAM Role whose Trust Policy validates the SAML issuer and audience. This is the long-standing path for workforce SSO into the AWS Management Console.
• OIDC federation: GitHub Actions, Kubernetes service accounts (via IRSA / Pod Identity), and other modern systems federate via OIDC. Trust is established by configuring an OIDC identity provider in IAM and a role Trust Policy that validates the issuer, audience, and subject claim — for example, restricting GitHub Actions to a specific repository and branch.
• IAM Roles Anywhere: workloads outside AWS use X.509 certificates issued by a trusted private certificate authority to obtain AWS credentials, eliminating the need for long-lived IAM user access keys on on-premises servers or third-party clouds.
• IAM Identity Center (formerly AWS Single Sign-On): the recommended workforce SSO experience for AWS accounts within an Organization. Permission sets materialize as IAM Roles in each member account, with Identity Center handling the federation and short-lived credentials. Setup is documented in AWS IAM Identity Center Setup Guide.
• Amazon Cognito Identity Pools: federate end-user identities (mobile and web app users) to assume IAM Roles, used in mobile backends and game backends where the end user is not an employee. The full Cognito federation pattern is described in Amazon Cognito Federation Implementation Guide, and the history of Cognito itself is in AWS History and Timeline regarding Amazon Cognito.

Visibility and Governance Tooling

IAM has accumulated a substantial visibility surface over the years, much of it concentrated in the IAM Access Analyzer family.

• IAM Access Analyzer — External Access findings (2019-12 launch): provable-security-based detection of resources shared outside a defined zone of trust (account or Organization).
• IAM Access Analyzer — Policy Validation (2021-04): more than 100 policy checks during authoring time, surfaced both in the AWS Management Console and via API for CI/CD integration.
• IAM Access Analyzer — Policy Generation (2021-11): generates least-privilege policies from CloudTrail activity, automating the path from over-permissive starter policies.
• IAM Access Analyzer — Unused Access (2023-11): surfaces unused IAM roles, unused IAM user access keys, unused IAM user passwords, and unused services and actions within IAM roles and IAM users.
• IAM Access Analyzer — Custom Policy Checks (2023-11): CI/CD-friendly validation of IAM policies against custom security standards.
• IAM Access Advisor: shows when each service (and, for some services, each action) was last accessed under an IAM identity or SCP. This is the primary tool for refining least-privilege by deleting services that have not been used in the past N days.
• Credential Report: a CSV report of all IAM users in the account, including MFA status, password and access key age, and last sign-in time. Frequently consumed by compliance tools.
• AWS CloudTrail: every IAM API call and every sts:AssumeRole is logged to CloudTrail, including the conditions under which the session was issued. This is what makes Policy Generation and Unused Access possible.

Amazon Verified Permissions and Cedar (Adjacent Service)

Amazon Verified Permissions and the Cedar policy language are adjacent to AWS IAM but are not part of the IAM service surface. They target a different problem: fine-grained authorization inside an application (for example, "user X can edit document Y because they are listed as an editor on document Y, but cannot delete document Z because they are not the owner") rather than authorization to AWS APIs (which remains IAM's domain).

Cedar is an open-source policy language with formal verification techniques applied to its design — the syntax was deliberately constrained so that policies can be analyzed for properties such as "does any combination of inputs allow user X to access resource Y?". Amazon Verified Permissions is the managed evaluation service that hosts Cedar policy stores and answers authorization queries from applications.

In a typical modern AWS application:

• IAM authorizes whether the application's compute identity (a Lambda execution role, an ECS task role) can call AWS APIs at all.
• Verified Permissions / Cedar authorizes whether the application's end user is allowed to perform a particular application-level operation.

This is the long-awaited separation between infrastructure authorization (IAM) and application authorization (Cedar / Verified Permissions) that AWS customers had previously implemented in ad-hoc custom code or, less wisely, by trying to encode application-level authorization into IAM Identity-based policies.

IAM Best Practices — Current Recommendations

The AWS IAM best practices have evolved over the timeline above. The current recommendations distilled from official AWS guidance and field experience are:

• Prefer IAM Identity Center over new IAM Users for workforce identity. If you must keep existing IAM Users, enforce MFA for all of them and rotate access keys aggressively.
• Prefer IAM Roles over IAM Users for workloads. EC2 Instance Profiles, Lambda execution roles, ECS task roles, and IRSA / Pod Identity for EKS eliminate the need for long-lived access keys on instances.
• Use IAM Roles Anywhere for hybrid workloads instead of issuing long-lived IAM user access keys to on-premises servers.
• Apply Service Control Policies (SCP) at the AWS Organizations level for identity-side guardrails, and Resource Control Policies (RCP) for resource-side guardrails. RCPs are particularly important for "no public S3 bucket, ever" and "every KMS key requires a specific condition" patterns that were previously fragile.
• Use Permissions Boundaries when delegating IAM creation, so that the delegated developer cannot escape the intended cap by creating a more-permissive role.
• Apply ABAC for multi-tenant SaaS and project-based access instead of writing one IAM policy per tenant or project.
• Run IAM Access Analyzer continuously, including Unused Access findings, External Access findings, and Custom Policy Checks integrated into CI/CD pipelines.
• Use IAM Access Advisor to refine least-privilege by removing services that have not been called in the past N days.
• Use AWS CloudTrail and AWS Config to detect drift from the intended IAM posture.
• Learn from prior incidents. Many of the most common IAM misconfigurations — wildcard actions on production roles, missing condition keys, Confused Deputy via missing external IDs — are documented in the AWS Postmortem Case Studies and Design Lessons with concrete failure modes and the lessons learned.

Integration with Other AWS Services

Every AWS service that exposes an API integrates with IAM for authentication and authorization. Several services have particularly tight integration that is worth calling out:

• AWS Key Management Service (KMS): KMS key policies use the same JSON policy syntax as IAM, and IAM Identity-based policies must be combined with KMS key policies to grant the right to use a customer-managed key. The encryption side of every multi-account data sharing pattern is described in AWS History and Timeline regarding AWS KMS.
• AWS Organizations: hosts SCP and RCP, and provides the Organization context that aws:PrincipalOrgID, aws:PrincipalOrgPaths, and aws:ResourceOrgID condition keys reference.
• AWS CloudTrail: logs every IAM API call and every sts:AssumeRole, providing the audit trail and the data source for Policy Generation.
• AWS Config: continuously evaluates IAM-related configuration (e.g., "is MFA enabled for all IAM users?", "do any IAM users have console access without MFA?") through managed rules.
• AWS Security Hub: aggregates IAM Access Analyzer findings and Config rule failures into a single security view.
• Amazon GuardDuty: detects anomalous IAM credential usage (e.g., access keys used from unusual geographies or from Tor exit nodes).

Frequently Asked Questions about AWS IAM

The following are direct answers to the most common AWS IAM history and feature questions. Each answer is intentionally short (1–3 sentences) so that it can be lifted directly into AI search results and human conversations alike, and each links back to the corresponding row in the timeline above.

Q1. When did AWS IAM launch?

AWS IAM was launched in Preview on August 31, 2010, and announced as Generally Available on May 3, 2011. The 2011 GA established the core model (Users, Groups, Identity-based Policies, Resource-based Policies, Explicit Deny precedence) that remains intact today.

Q2. When did IAM introduce IAM Roles?

IAM Roles for cross-account access were launched on November 3, 2011, only six months after the IAM GA. IAM Roles for Amazon EC2 (Instance Profiles) followed on June 11, 2012, which is when AWS workloads first stopped needing long-lived access keys on instances.

Q3. When did Service Control Policies (SCP) become available via AWS Organizations?

AWS Organizations launched in Preview at re:Invent 2016 (December 1, 2016) with SCP as its first guardrail policy type. AWS Organizations and SCP were announced as Generally Available on February 27, 2017.

Q4. When did IAM add Permissions Boundaries?

IAM Permissions Boundaries were launched on July 12, 2018. They allow administrators to delegate the ability to create IAM users and roles while capping the maximum permissions that those new identities can hold — a key primitive for safe self-service IAM in larger organizations.

Q5. When did IAM Access Analyzer launch, and when did it add Unused Access?

IAM Access Analyzer launched on December 2, 2019 at re:Invent 2019, using automated reasoning (provable security) to find resources shared outside a defined zone of trust. Unused Access findings were added on November 26, 2023 at re:Invent 2023, surfacing unused IAM roles, access keys, passwords, services, and actions in a single dashboard.

Q6. When did AWS launch Identity Center (formerly AWS SSO)?

AWS Single Sign-On (AWS SSO) launched on December 5, 2017, providing centralized sign-in across AWS accounts in an AWS Organization. AWS SSO was renamed to AWS IAM Identity Center on July 26, 2022 and repositioned as the recommended workforce identity service for AWS.

Q7. When did AWS launch Amazon Verified Permissions and Cedar?

Amazon Verified Permissions and the Cedar open-source policy language were announced as Generally Available on June 13, 2023. They sit adjacent to AWS IAM and target fine-grained application-level authorization, not infrastructure access (which remains IAM's domain).

Q8. When did Resource Control Policies (RCP) launch?

Resource Control Policies (RCP) launched on November 13, 2024 at re:Invent 2024 as a new policy type in AWS Organizations. RCPs apply to resources (such as Amazon S3 buckets and AWS KMS keys) as the resource-side counterpart to identity-side SCPs.

Q9. When did IAM support ABAC, session tags, and aws:PrincipalTag?

IAM introduced policy variables (the primitive that enables ABAC) on April 3, 2013. Tag-based condition keys (aws:RequestTag, aws:ResourceTag) followed on April 13, 2017. Session Tags and the aws:PrincipalTag condition key for STS AssumeRole were launched on November 29, 2018, completing the ABAC story for federated identities.

Summary

This article extracted the history of AWS Identity and Access Management from preview in 2010, to GA in 2011, through SCP and AWS Organizations in 2016–2017, Permissions Boundaries and Session Tags in 2018, IAM Access Analyzer in 2019, the AWS SSO → IAM Identity Center rebrand and IAM Roles Anywhere in 2022, Amazon Verified Permissions, Cedar, and Trusted Identity Propagation in 2023, and Resource Control Policies in 2024.

The most striking feature of the AWS IAM timeline is what has not changed: the policy evaluation logic established at the 2011 GA — Explicit Deny precedence, the union of Identity-based and Resource-based Allows, the default-deny ground state — is still intact today, fifteen years later. Every major addition since then has arrived as a new policy type layered on top (SCP, Permissions Boundary, Session Policy, RCP) or as a sibling service (AWS Organizations, IAM Identity Center, IAM Roles Anywhere, Verified Permissions), not as a breaking change to the core.

The seven-stage IAM Decision Diamond (Explicit Deny / SCP / RCP / Resource-Based Policy / Identity-Based Policy / Permissions Boundary / Session Policy, defined canonically in AWS IAM Policy Evaluation Logic Step-by-Step — The IAM Decision Diamond) gives engineers a shared vocabulary for diagnosing unexpected denies and for designing defense-in-depth. The question "why was this request denied?" becomes the question "which stage killed it?" — and the answer is always one of those seven stages.

Looking ahead, two long-running trends are now playing out in IAM. First, Cedar and Amazon Verified Permissions point toward a future where application-level authorization is no longer abused into IAM Identity-based policies. Second, Resource Control Policies close the resource-side organization gap that previously required custom resource policies on every bucket, key, and queue — making "no public S3 bucket, ever" enforceable at the Organization level rather than per-bucket. Together these arrivals suggest that the next wave of IAM design will be less about writing more Identity-based policies, and more about choosing the right policy type at the right layer.

In addition, there is also a historical timeline of all AWS services including services other than AWS IAM, so please have a look if you are interested.

AWS History and Timeline - Almost All AWS Services List, Announcements, General Availability(GA)