AWS Security Defaults History - Block Public Access, Default Encryption, IMDSv2, and How Far Each Changed Default Reached

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

AWS has repeatedly modified its security default settings. A bucket created today is born with public access blocked, and an object uploaded today is encrypted without anyone asking for it. While these changes are positive developments, organizations managing numerous accounts and generations of resources may find the story does not end there. New resources are secure by default, but older ones are not. Without understanding the source of this discrepancy, audits and design processes can stall.

Readers exploring this topic typically encounter one of three questions. The first is a need to demonstrate, during an audit, when a particular default setting came into effect. The second involves designing an organization's baseline security posture and determining how much to rely on AWS's default settings. The third involves explaining to stakeholders why existing resources within an account have not been updated despite awareness of recent default changes.

Simply identifying the dates of these changes is not enough to provide a complete answer. How far the words saying a default changed actually reach varies with each individual change. Some changes retroactively modified the configurations of existing resources, while others only applied to newly created resources. Still others applied conditionally, based on the state of an account at the time of the change.

This article presents a timeline of AWS's changes to security-related default settings, based on the official dates published by AWS. It sets out which layer each change reached, and which layer it did not. This is not a collection of best practices, nor does it cover how to configure individual features. Instead, it focuses on what happened – and what did not happen – to existing resources.

Related articles on this site:

1. What This Article Answers, and What It Does Not
2. What This Article Includes, and How It Was Built
3. Defaults, Enforcement, and Grandfathering Are Three Different Things
4. Where a Default Comes From, and What Overrides What
5. The Days AWS Security Defaults Moved
6. How Far Each Change Reached
7. A Default Change Arrives in Three Phases
8. Finding Out Which Default Your Account Received
9. Where the Primary Sources Disagree
10. Failure Modes and Anti-Patterns
11. Frequently Asked Questions about AWS Security Defaults
12. Summary
13. References

1. What This Article Answers, and What It Does Not

What readers typically want to know is not how to configure a setting. Rather, they want to know which of the resources they still hold never received a given default. Only by knowing when a default moved can you decide which generation of resources to go and check.

Therefore, this article will proceed as follows: First, this article separates the word default into three distinct senses. Next comes where each default setting is determined and what overrides what. Then the timeline shows when each default setting took effect, sorted by how far it reached. Finally comes how to verify which default settings your own account received.

This article also states upfront what it will not address. It does not cover how to configure individual features, nor where the public access controls sit in the policy evaluation process. These topics are covered in the Amazon S3 Security and Access Control Guide, specifically its Blocking Public Access and Encryption sections. The IAM Policy Evaluation Logic Step-by-Step article covers the logic for evaluating policies themselves. The AWS Service Lifecycle States article defines the terminology used to describe the state of a service, and this article does not redefine it. The lineage and the expiry dates of the Amazon Linux generations are covered by Amazon Linux History and Timeline. This article will only briefly mention Amazon Linux in relation to the fact that the AL2023 AMI registers imds-support as v2.0; beyond that, this article defers to that document. The feature timelines for individual services are held by their own articles on this site. For the single AWS KMS entry that Section 5 cites, the evolution of the key-rotation mechanism itself is covered by AWS History and Timeline regarding AWS Key Management Service. This article will only address the reach of that change, namely that it also applied to existing keys. It will not discuss pricing.

1.1 The Word `default` Carries Three Meanings

This is the first word that gets in the way. Both the AWS documentation and this article use default in at least three different senses:

Default Value: The value that goes in when you specify nothing. For example, the public access setting on a new bucket.
Enabled by Default: A state where a feature is active from its initial configuration. For example, encryption for new objects.
Account Default: A setting configured by the user at the account and Region level, which is then applied to subsequent creations.

These three meanings are separate and distinct. In particular, the third meaning is a setting configured by the user, not by AWS, and therefore is treated differently in the discussion of reach that follows. This article spells out the intended meaning whenever a distinction is necessary.

The term new also has two meanings. It can refer to a newly created resource, or it can refer to a newly added feature. This article uses the term new resource for the former and new feature for the latter.

2. What This Article Includes, and How It Was Built

⚠ This timeline is not exhaustive. Nor could this article find anywhere to delegate the exhaustive list to. As of the verification date, and within the range this article searched, no official page consolidates changes to default settings across services. Instead, changes are documented in individual service user guides, FAQs, What's New postings, and official blogs. Therefore, this article outlines its inclusion criteria and presents a selection of representative examples; it does not aim to provide a complete overview of all AWS default settings.

The inclusion criteria are as follows:

Information explicitly stated by AWS in a primary source, indicating a change to a default setting or the addition of a control that affects a default setting.
Information that specifies the reach of the change, as documented in the primary source. This includes whether the change applies only to new resources, existing resources, or if there are any conditions. Changes without this reach stated are not included.
Information with a verifiable date, confirmed through one of the following sources: the Posted on: line in AWS What's New, the document history of a user guide or release notes, or the publication date of an AWS official blog post.

Any entry that could not meet the third criterion was left out. For example, regarding Amazon EMR's block public access feature, the primary sources give two different dates for when it became the default. Because of that discrepancy, this article cannot fix the date, and the entry does not appear in the timeline with a date. This discrepancy is addressed in Section 9.

Track Values: The second column in the timeline indicates the kind of event represented by each row.

Control: A control arrived that affects the default. At this point the default itself has not yet moved.
Notice: AWS announced a change to the default in advance.
Default: The default setting was actually changed.
Enforce: Not a default, but a mechanism that refuses the override.

Accuracy: Dates are, in principle, formatted as YYYY-MM-DD. An exception is one entry for AWS KMS, where the primary source only provides the month. Therefore, it is listed as 2022-05.

Sourcing Policy: This article draws only on primary AWS sources: user guides, API references, AWS CLI references, product page FAQs, AWS What's New, and the AWS official blog. No summary site or news article backs any date here. This article does not offer any judgments or comparisons regarding the selection of default settings.

The same fact can appear in different words on different pages. This article compiles three kinds of page for each claim: pages describing functionality, pages stating limitations, and API or CLI reference pages. Section 9 lists the discrepancies that resisted resolution.

The verification date is September 10, 2026. Availability, default values, and reach were all confirmed against the primary sources on that date.

3. Defaults, Enforcement, and Grandfathering Are Three Different Things

It is important to differentiate these three terms. Failing to do so when reviewing a timeline can lead to misinterpreting events and drawing incorrect conclusions.

3.1 A Default Can Be Overridden

A default is simply the value that goes in when you specify nothing. Specify a value and that one goes in instead. Even if access control on a new bucket is enabled, authorized users can disable it. A notification that the default has changed does not mean that the option to override it is no longer available.

3.2 Enforcement Refuses the Override

Enforcement refuses the override outright. Amazon EC2's Instance Metadata Service offers a setting that enforces IMDSv2, configured on an account and Region basis. This is not a default value. The user guide explicitly states that this setting is evaluated after the order of precedence has settled the value.

The account-level IMDSv2 enforcement setting is evaluated after the order of
precedence has determined the instance's IMDS settings. When IMDSv2 enforcement is
enabled, instances enabled with IMDSv1 will fail.

In other words, even with a value given at launch, and even with an AMI carrying a different value, this check runs last. A default can be overridden; enforcement cannot. A passage you read as a change of default can turn out to be enforcement instead.

3.3 Grandfathering Looks at Your Account's Past

This section is the core of this article. When AWS changes its default settings, it may split where that change reaches, based on what the account held at that specific time. While designed to avoid disrupting existing users, this can result in two accounts using the same service on the same day receiving different default settings.

Crucially, this condition is evaluated based on a snapshot of your account at a specific point in the past, and is not undone by subsequent changes of state. Section 6 gives the specific examples.

4. Where a Default Comes From, and What Overrides What

A single configuration setting does not necessarily have a default value defined in one specific location. The configuration of Amazon EC2 instance metadata provides the clearest example of this structure.

4.1 Three Levels of Precedence

The Amazon EC2 User Guide states that the value of each instance metadata option is determined at instance launch, outlining three levels of precedence. From highest to lowest, these are: launch-time settings, account settings, and AMI settings.

The first tier is launch-time settings. The user guide describes this tier as follows:

Values can be specified either in the launch template or in the instance
configuration. Any values specified here override values specified at the account
level or in the AMI.

The second tier is account settings.

If a value is not specified at instance launch, then it is determined by the
account-level settings (which are set for each AWS Region).

The third tier is AMI settings.

If a value is not specified at instance launch or at the account level, then it is
determined by the AMI configuration. This applies only to HttpTokens and
HttpPutResponseHopLimit.

A key point that is often overlooked is that each option is evaluated independently. The user guide explains:

Each metadata option is evaluated separately. The instance can be configured with a
mix of direct instance configuration, account-level defaults, and the configuration
from the AMI.

Therefore, the metadata settings for a given instance can be a combination of launch-time settings, account defaults, and AMI settings. It is not possible to determine the default for an instance by examining only one of these tiers.

4.2 The Rule for a Default Has a Condition Attached

Precedence alone does not determine the value in all cases. If a default response hop count is not specified for an account, the value is determined by the settings on the AMI.

When no preference is specified, at launch, the value defaults to 2 if the AMI has the
setting ImdsSupport: v2.0; otherwise it defaults to 1.

In other words, if you leave the default setting unspecified for an account, the default hop count can vary depending on the AMI. AMIs for AL2023 are registered with imds-support set to v2.0, so such an AMI falls on one side of that branch. The Amazon Linux History and Timeline document describes what AL2023 enables by default.

4.3 For a Time, the Default Depended on Which Path You Called

Furthermore, there were times when even for the same service and the same operation, the default settings differed depending on whether the resource was created through the console or via the API. An Amazon S3 blog post announcing changes in April 2023 explicitly stated this condition.

Both of these options are already console defaults and have long been recommended as
best practices. The options will become the default for buckets that are created using
the S3 API, S3 CLI, the AWS SDKs, or AWS CloudFormation templates.

While the console already used these default settings, buckets created through the API, CLI, SDK, and AWS CloudFormation did not. During this period, buckets created through automation received different default settings than those created manually. The dates in the timeline indicate when the API caught up, not when the console's default settings changed.

4.4 Five Places a Default Can Be Decided

Summarizing the previous examples, the locations where defaults are determined can be organized as follows:

Category	Specific Examples	Determined By
Individual Resource Settings	Bucket public access settings, instance metadata settings	User
Creation Requests or Launch Templates	Specifications in `RunInstances`, calls to `CreateBucket`	User
Account and Region Defaults	IMDS account defaults, Amazon EBS encryption defaults	User
Image or Parameter Families	AMI `imds-support`, DB parameter group families	AWS and User
Organizational Policies	Declarative policies, organization-level public access settings	Organization Administrator

Each of these five places only determines the value that goes into a new resource. Existing resources are not re-evaluated by any of these layers. As discussed in Section 6, only bulk changes initiated by the service itself fall outside of this principle.

5. The Days AWS Security Defaults Moved

The events gathered under the criteria above follow in date order. Each entry includes a link to the primary source document confirming the date. This timeline does not represent all changes to AWS default settings; it is a selection of representative examples that meet the stated criteria.

5.1 2018 to 2022 - The Controls Arrive, and the First Sweeping Change Lands

Date	Track	Summary
2018-11-15	`Control`	Amazon S3 Block Public Access was introduced. This control, available at the account and bucket levels, prevents public access. At this point, it did not change the default settings for newly created buckets. The announcement explained that it could both stop existing public access and keep new resources from being granted public access. References: Amazon S3 Block Public Access - Another Layer of Protection for Your Accounts and Buckets
2019-09-20	`Control`	Amazon EMR's block public access feature was detailed in an official blog post. This setting prevents the launch of clusters that allow inbound connections from public IP addresses, operating at the account and Region levels. It was not possible to determine from primary sources when this control became the default. See Section 9 for more details. References: Secure your Amazon EMR cluster from unintentional network exposure with Block Public Access configuration
2019-11-19	`Control`	Instance Metadata Service Version 2 (IMDSv2) was released. It utilizes a session-based approach, requiring users to obtain a token before use. At this point, it was not enabled by default on existing instances nor on newly created ones; it was enabled through three subsequent control updates. References: Document history for Amazon EC2 User Guide
2020-05-03	`Notice`	AWS IAM announced a change to establish new default password policies. The announcement stated that the change would be implemented 90 days later. The implementation date shifted four times, and that history survives only in the three update notes stacked at the top of the announcement. References: AWS IAM introduces updated policy defaults for IAM user passwords
2020-11-18	`Default`	The default password policy for IAM users was implemented across the entire IAM service. A default policy was applied to existing accounts that did not already have a password policy. Accounts that already had a password policy were not affected, and existing user passwords remained unchanged. References: AWS IAM introduces updated policy defaults for IAM user passwords
2022-05	`Default`	AWS KMS changed the rotation period for key material for AWS managed keys from approximately 1,095 days to approximately 365 days. This change applied to existing keys as well. For AWS managed keys, users are unable to enable or disable this behavior. The primary source only provides the month, making it impossible to determine the exact date. The evolution of the key rotation mechanism itself is documented in AWS History and Timeline regarding AWS Key Management Service. References: EnableKeyRotation - AWS KMS API Reference
2022-10-03	`Control`	An AMI can now carry a setting that requires IMDSv2 on the instances launched from it. This entry adds a way to carry a default at the third level of precedence. References: Document history for Amazon EC2 User Guide
2022-12-13	`Notice`	Amazon S3 announced in advance that it would change two defaults in April 2023. The change enables the public access controls on newly created buckets and disables access control lists. The announcement states that the change would be applied Region by Region. References: Heads-Up: Amazon S3 Security Changes Are Coming in April of 2023

5.2 2023 to 2026 - Conditions Start Appearing on the Reach

Date	Track	Summary
2023-01-05	`Default`	Amazon S3 now automatically encrypts all new object uploads by default, and this change also applies to bucket settings. AWS is configuring default encryption for existing buckets that did not previously have it enabled. However, objects already stored in those existing buckets are not encrypted. This represents a single change that draws a distinction based on different layers. References: Default encryption FAQ - Amazon S3
2023-02-28	`Control`	It is now possible to modify existing AMIs to require IMDSv2. A way to rewrite the default carried on the image layer after the fact was added. References: Document history for Amazon EC2 User Guide
2023-04-27	`Default`	Two default changes to Amazon S3 have now been implemented across all Regions. Newly created buckets are now born with public access control enabled, and access control lists are disabled by default. This completion is only mentioned in an update note added to the beginning of a 2018 announcement article. An independent announcement page was not found in the range this article searched. Settings for existing buckets have not changed. References: Amazon S3 Block Public Access - Another Layer of Protection for Your Accounts and Buckets
2023-09-12	`Control`	Block public access for AMIs, which prevents an AMI from being shared publicly, became available. This setting, applied at the account level, prevents attempts to publicly share AMIs. It is not yet the default setting. References: Document history for Amazon EC2 User Guide
2023-10-20	`Default`	Block public access for AMIs became enabled by default. This applies to new accounts and existing accounts that do not have public AMIs. For existing accounts that do have public AMIs, the setting remains disabled. The default setting became active 38 days after its introduction. References: Document history for Amazon EC2 User Guide / Understand block public access for AMIs
2023-11-09	`Control`	Block public access, which prevents the public sharing of Amazon EBS snapshots, is now available. This feature has two modes. One treats existing publicly shared snapshots as private, and the other prevents only new public sharing. Whether the setting applies to existing snapshots is left to the user to choose. References: New - Block Public Sharing of Amazon EBS Snapshots
2024-03-25	`Control`	It is now possible to configure IMDSv2 as the default for new instances, on an account and Region basis. This is the second level of precedence. This setting does not modify existing instances. References: Document history for Amazon EC2 User Guide
2025-11-19	`Notice`	Amazon S3 has announced that it will begin disabling server-side encryption with customer-provided keys (SSE-C) by default, starting in April 2026. This applies to new buckets, as well as select existing buckets that meet a condition. References: Advanced notice: Amazon S3 to disable the use of SSE-C encryption by default for all new buckets and select existing buckets in April 2026
2025-11-26	`Enforce`	Amazon S3 Block Public Access now supports organization-level enforcement through AWS Organizations. Applying a policy to an organization's root or organizational unit propagates that policy to all member accounts. It is stated that this applies automatically to any newly added member accounts. References: Amazon S3 Block Public Access now supports organization-level enforcement
2026-02-24	`Enforce`	Amazon EC2 now supports the ability to enforce the use of IMDSv2 at the account and Region level. When enforcement is enabled, an instance not configured to require IMDSv2 will not be able to launch. This setting does not modify existing instances, but it prevents existing instances that have IMDSv1 disabled from re-enabling IMDSv1. References: Document history for Amazon EC2 User Guide
2026-04-06	`Default`	Amazon S3 has begun rolling out a change that disables server-side encryption with customer-provided keys by default. This applies to all new buckets, and for existing buckets, it only applies if there are no existing encrypted objects associated with the account. It is stated that the rollout is complete in 37 Regions, with 2 Regions excluded. References: Amazon S3 starts rolling out new security best practice to new and existing buckets by default / Default SSE-C setting for new buckets FAQ

As of the verification date of 2026-09-10, there are no entries posted to AWS What's New on or after August 29, 2026 that meet the inclusion criteria for a change of default. This window was reviewed in its entirety, encompassing 97 items.

6. How Far Each Change Reached

Reading the timeline in chronological order, each entry appears to describe a similar kind of event. However, when reorganized by reach, they can be divided into seven distinct shapes. This is the core focus of this article.

6.1 Shape 1 - Applied to Existing Resources, With No Setting to Override

This shape reaches the furthest. When AWS KMS changed the key material rotation period for AWS managed keys in May 2022, the change applied to both new keys and existing keys.

In May 2022, AWS KMS changed the rotation schedule for AWS managed keys from every three
years (approximately 1,095 days) to every year (approximately 365 days).

New AWS managed keys are automatically rotated one year after they are created, and
approximately every year thereafter.

Existing AWS managed keys are automatically rotated one year after their most recent
rotation, and every year thereafter.

This shape resists override not because AWS enforces it, but because no setting exists for a user to touch.

You cannot enable or disable automatic rotation of AWS managed KMS keys. AWS KMS always
rotates the key material of AWS managed keys every year.

Whether to call this a change of default is genuinely debatable. With no setting to hold the value, it looks more like the behavior of the service itself. It appears here because AWS describes it in the same framework as a default change. Readers should treat it as an item that does not require inspection. Anything that cannot be touched cannot be altered.

6.2 Shape 2 - One Change Draws a Different Line at Each Layer

This is the most easily misunderstood shape. When Amazon S3 changed the default encryption on January 5, 2023, this single change produced three different outcomes depending on the layer.

First, regarding new objects.

Starting January 5, 2023, all new object uploads to Amazon S3 are automatically
encrypted at no additional cost and with no impact on performance.

Next, regarding existing bucket settings. This one is easy to miss.

Yes. Amazon S3 now configures default encryption on all existing unencrypted buckets to
apply server-side encryption with S3 managed keys (SSE-S3) as the base level of
encryption for new objects uploaded to these buckets.

AWS rewrote the configuration of existing buckets. This line gets missed by anyone holding the general rule that a change of default reaches only new resources. However, this does not apply to buckets where the default encryption had already been configured.

Finally, regarding objects that already existed.

Objects that are already in an existing unencrypted bucket won't be automatically
encrypted.

No. Beginning on January 5, 2023, Amazon S3 only automatically encrypts new object
uploads.

On the same day, in the same service, one change rewrote the bucket configuration and left the objects alone. When examining changes of this shape, the question to ask is not whether the change applied to existing resources, but rather, which layer was affected.

6.3 Shape 3 - The Reach Is Decided by Your Account's History

This shape is the one that matters most in practice. AWS may split where a change reaches, based on what an account held at a specific point in time. Independent examples demonstrate this pattern consistently across different services over a period of more than five years.

One example is when the default for block public access for AMIs was enabled on October 20, 2023. The user guide illustrates this default with a three-row table:

AWS account	Block public access for AMIs default setting
New accounts	Enabled
Existing accounts with no public AMIs	Enabled
Existing accounts with one or more public AMIs	Disabled

The part worth reading is the note attached to that table.

If your account had one or more public AMIs on or after July 15, 2023, Block public
access for AMIs is disabled by default for your account, even if you subsequently made
all the AMIs private.

The condition is not whether an account holds a public AMI today. It is whether the account held one at any point on or after July 15, 2023. Making every AMI private afterward does not put the default back. The decision reads a moment in the past, and nothing re-reads it.

Another example is the Amazon S3 change of April 2026.

If your AWS account did not have any SSE-C encrypted objects, then AWS disabled SSE-C
encryption on all of your existing buckets. If any bucket in your AWS account had SSE-C
encrypted objects, then AWS did not change the bucket configurations on any of your
buckets in that account.

The condition is evaluated on a per-account basis, and the resulting setting applies uniformly to all buckets within that account. A single qualifying object anywhere in the account takes every bucket in that account out of scope.

A third example is the oldest. When the default policy for IAM user passwords was introduced in November 2020, it only applied to accounts that did not already have a password policy.

A default password policy will be set for all AWS accounts that do not currently have
one.

AWS accounts with an existing IAM password policy will not be affected by this change.

The Condition That All Four Share

Four changes so far have reached into the configuration of existing resources or existing accounts: the IAM password policy, Amazon S3 default encryption, block public access for AMIs, and Amazon S3 encryption with customer-provided keys. One of the four was covered as Shape 2 in Section 6.2, but the shape of the condition is easier to see when they sit together. All four carry the same kind of condition.

Change	Condition under which it reached existing resources
IAM password policy	The account has no password policy of its own.
Amazon S3 default encryption	The bucket has no default encryption configured.
Block public access for AMIs	The account does not have any public AMIs.
Amazon S3 encryption with customer-provided keys	The account holds no objects encrypted with customer-provided keys.

In each case, the condition relates to a situation where the user has not yet explicitly configured that particular setting. Settings that the user has already configured remain unaffected. It appears that AWS only intervenes to fill in these gaps.

⚠ Do not read this as an AWS policy. Only four instances appear here, and AWS does not publish this as a rule. However, it can be useful when determining the order of checks. Settings that you have explicitly configured are likely to remain unchanged even if the default settings change. Conversely, settings that you have never touched may unexpectedly have a value assigned to them.

The challenge with this pattern is that it can be difficult to determine, even after reading the documentation, which side you landed on. You can only determine this by examining your own account, which Section 8 goes into.

6.4 Shape 4 - New Resources Only

This is the most straightforward shape, and it is the one most widely believed to be a general rule. When Amazon S3 changed the defaults for the public access controls and for access control lists in April 2023, the change reached only newly created buckets.

Update (4/27/2023): Amazon S3 now automatically enables S3 Block Public Access and
disables S3 access control lists (ACLs) for all new S3 buckets in all AWS Regions.

Existing buckets were not affected. Therefore, buckets created before April 2023 still retain their original settings. For changes that fall under this shape, the explanation that new resources are secure while older ones are not is accurate.

It is important to note that this shape represents only a portion of the overall picture. Shapes 1 through 3 were announced using similar language, but their reach differed.

6.5 Shape 5 - The Default Is Bound to the Engine Major Version

This shape does not have a date associated with it. Amazon RDS for PostgreSQL has a setting that rejects unencrypted connections. The default setting for this feature is determined by the engine's major version, not a specific date.

The rds.force_ssl parameter default value is 1 (on) for RDS for PostgreSQL version 15
and later. For all other RDS for PostgreSQL major versions 14 and older, the default
value of this parameter is 0 (off).

This default setting does not have a change date associated with it at a service level. For your DB instance, the relevant change date is the date you upgraded to a new major version. Since the default parameter group cannot be modified, if you need to change the value on an older version, you will need to create and apply a custom parameter group.

This shape cannot be included in the timeline. This is because it does not meet the third inclusion criterion, which requires that the date be verifiable from primary sources. The fact that it cannot be included does not mean that the default setting does not exist. When building a timeline per service, this shape drops out structurally.

6.6 Shape 6 - The Account Default You Turn On Yourself

This is not a change made by AWS; it is a default setting that users can choose. This shape has a clear commonality: it does not apply to existing resources.

The default encryption setting for Amazon EBS is stated in one sentence in the primary source.

Encryption by default has no effect on existing EBS volumes or snapshots.

The account-level default for instance metadata says the same thing.

Setting the account-level default does not reset existing instances. For example, if
you set the account-level default to IMDSv2, any existing instances that are set to
IMDSv1 are not affected.

What is particularly interesting about this shape is block public access for Amazon EBS snapshots. This setting has two modes, and users can choose whether or not to apply it to existing resources.

Blocks all public sharing of your snapshots. Users in the account can't request new
public sharing. Additionally, snapshots that were already publicly shared are treated
as private and are no longer publicly available.

Blocks only new public sharing of your snapshots. Users in the account can't request
new public sharing. However, snapshots that were already publicly shared, remain
publicly available.

The question this article addresses is directly reflected in the product's configuration options. Does it apply to existing resources, or only to new ones? The fact that AWS allows users to make this choice indicates that reach is a design variable.

Even if users select the mode that blocks all sharing, the primary source states that the attributes of existing, publicly shared snapshots will not change. If the setting is later reverted, those snapshots will revert to their previous public state. A snapshot ceasing to be visible is not the same as its public sharing being removed.

6.7 Shape 7 - Enforcement, Not a Default

This final shape is not a default at all. The IMDSv2 enforcement added on February 24, 2026 affects existing instances in a way of its own.

This setting does not change the IMDS version of existing instances, but blocks
enabling IMDSv1 on existing instances that currently have IMDSv1 disabled.

While it does not alter the current state of existing instances, it prevents reverting to a previous state. Existing instances that continue to use IMDSv1 will continue to function as before, while those that have already disabled IMDSv1 will be unable to re-enable it. The reach of the change depends on the current state of the resources.

The organization-level enforcement of Amazon S3 Block Public Access, added on November 26, 2025, is also not a default. It is applied as an organizational policy and propagates to subordinate accounts. The evaluation of this policy itself is outside the scope of this article, and is covered in IAM Policy Evaluation Logic Step-by-Step.

6.8 The Seven Shapes Side by Side

Shape	New resources	Configuration of existing resources	Data already written	Override
1 Service behavior	Applied	Applied	Unchanged	No setting exists
2 A different line at each layer	Applied	Applied on a condition	Unchanged	Possible
3 Account history as the condition	Applied	Applied on a condition	Unchanged	Possible
4 New resources only	Applied	Unchanged	Unchanged	Possible
5 Bound to the engine major version	Applied at the upgrade	Unchanged until the upgrade	Unchanged	Possible
6 The account default you turn on	Applied	Unchanged	Unchanged	Possible
7 Enforcement	Launch is refused	The way back is blocked	Unchanged	Not possible

Across all seven shapes, data already written stays as it was. This was the only column without exceptions across the seven. The contents of existing objects, existing snapshots, and existing volumes will not be re-encrypted even if the default settings change.

7. A Default Change Arrives in Three Phases

The Three Phases of a Default Change, and Where Each Date Is Recorded

A sweeping change made by the service does not flip everything on the day it is announced. The three changes in the timeline that came with advance notice all took the same three-phase shape.

7.1 Phase 1 - Advance Notice

AWS gave advance notice of all three changes on the official blog, several months before each took effect. The notice for the November 2020 change came on May 3, 2020, the one for April 2023 on December 13, 2022, and the one for April 2026 on November 19, 2025.

⚠ The intervals are not consistent. From the announcement to implementation, the timeframes, in chronological order, are approximately six and a half months, four months, and four and a half months. Furthermore, the timeframe for the first change does not correspond to the schedule indicated at the time of the announcement. The announcement stated a 90-day implementation period.

During the advance notice phase, only the month was often specified. Dates were either not finalized or, even if initially set, were subject to change. The 2020 announcement stated a 90-day period in its body and then moved the implementation date four times. That history survives only in the three update notes stacked at the top of that post.

July 27, 2020: This post has been updated to reflect the change in date for the default
password policy from August 3 to October 2.

October 20, 2020: This post has been updated to reflect the change in date for the
default password policy from October 2 to October 21 to October 28.

November 2, 2020: This post has been updated to reflect the change in date for the
default password policy from October 28 to November 18.

Reading only the main body of the announcement can lead to confusion regarding the implementation date. It is only by reading the update notes from top to bottom that one arrives at the final date.

⚠ And the main body has not been updated. As of the verification date, the main body of the same article still contains the following text:

To provide time for you to evaluate potential impact by this change, AWS is updating the
default password policy in 90 days, which will take effect in October 2020.

The actual implementation date was November 18, 2020, which was 199 days after the announcement, not the stated 90 days. The note and the body remain in disagreement, and both are still published. This issue will also be addressed in Section 9.

⚠ There are also changes listed in the timeline for which no advance notice could be verified. It is safest to assume that not all default changes are accompanied by advance notice.

7.2 Phase 2 - Region-by-Region Rollout

Next, the change lands Region by Region. The December 2022 announcement states the nature of this phase plainly.

The changes will begin to go into effect in April and will be rolled out to all AWS
Regions within weeks.

In other words, on a given day one Region already carries the new default while another has not received it yet. In environments operating across multiple Regions, resources created by the same process in the same week can have different settings depending on the Region.

For the 2026 change, the outcome of this phase survives as a number. The rollout is stated to be complete in 37 Regions, with specific Regions explicitly listed as exceptions.

All newly created buckets in all AWS Regions except Middle East (Bahrain) and Middle
East (UAE) will have SSE-C disabled by default.

An announcement that reads as though the change landed in every Region can still carry exceptions.

7.3 Phase 3 - Completion, and Where It Is Recorded

Finally, the rollout is complete. This is the phase where records are the most difficult to locate. The completion of the changes across all Regions in April 2023 was not publicly announced on a dedicated page. Instead, the record of this completion is found in a single line of an update note added to the beginning of another article, originally written in 2018.

Update (4/27/2023): Amazon S3 now automatically enables S3 Block Public Access and
disables S3 access control lists (ACLs) for all new S3 buckets in all AWS Regions.

This single line is the only primary source documenting the completion date of this change. The entry for 2023-04-27 in the article's timeline refers not to the main body of the article itself, but to this update note.

⚠ The update note may contain a date unrelated to the article's publication date. Checking the article's publication date only reveals the year 2018. If you only extract the article's date without reading the note, you could be off by five years.

And there may not be just one note. As seen in the announcement article from 2020 (discussed in Section 7.1), there are three update notes stacked together, each indicating a change in the implementation date. If you only read the most recent note, you will miss important context. When recording the date in your own article or ledger, it is safer to quote the wording of the update note itself.

⚠ Even after an update note is added, the main body of the article may not be updated. In the same 2020 article, the main text still retains the original planned dates, while the update note has adjusted the date four times. The answer you get will depend on whether you read the main text or the update note.

8. Finding Out Which Default Your Account Received

For a change of Shape 3, reading the announcement does not tell you which side you landed on. The way to find out is not to read the documentation but to query your own account.

8.1 The User Guide Describes the Current Default as Universal

This is the first potential pitfall. The Amazon EMR Management Guide states the following regarding the default setting for block public access.

Block public access is enabled by default for all clusters in every AWS Region for your
AWS account.

However, the conditions are not described. In contrast, the AWS CLI reference explicitly records the grandfathering for the same feature.

For accounts that created clusters in a Region before November 25, 2019, block public
access is disabled by default in that Region. To use this feature, you must manually
enable and configure it.

The guide written for users describes the present state, and only the API and CLI references record the condition of the grandfathering. Reading the guide and inferring your own account's state from it gets the answer wrong.

8.2 Query the Setting Instead of Reading About It

To establish the reach, use the API that returns the current value of that setting. A few examples follow.

aws emr get-block-public-access-configuration --region us-east-1

aws ec2 get-instance-metadata-defaults --region us-east-1

aws ec2 get-image-block-public-access-state --region us-east-1

aws s3api get-public-access-block --bucket amzn-s3-demo-bucket

Configuration settings are maintained on a per-Region basis for each account. Checking the settings in one Region will not provide information about settings in other Regions. The user guide states the following regarding instance metadata defaults:

The settings for these options are configured at the account level, either directly in
the account or by using a declarative policy. They must be configured in each AWS
Region where you want to configure instance metadata options.

The response from the API that returns instance metadata defaults includes a field that indicates who set the configuration. A value of account means someone set it directly in the account. A value of declarative-policy means an organizational policy governs it. While an organizational policy governs the setting, nobody can change it from inside the account.

8.3 Three Questions That Establish the Reach

When you map a row of the timeline onto your own environment, working through these three in order tells you which shape you are looking at.

At which layer did the change draw its line? Is it related to resource configuration, data within a resource, or the behavior of a service?
Does the reach of the change have any conditions? If so, what account state is being evaluated based on those conditions? And will it be re-evaluated based on subsequent state changes?
When did your Region receive this change? In cases where changes are rolled out sequentially by Region, this answer may differ from the date.

8.4 Detecting the Change Itself

There are a few ways to notice that a default has moved at all: the AWS What's New posting, the document history of each service's user guide and release notes, and the update notes on the official blog.

⚠ All three have to be watched together. The seven entries about Amazon EC2 in this timeline are all sourced from the document history. Conversely, the April 2023 completion appears only in an update note on the official blog. Monitoring only one of these sources will inevitably lead to missed updates.

9. Where the Primary Sources Disagree

This section records the discrepancies that remained unresolved as of the verification date.

9.1 The Day the Amazon EMR Block Public Access Default Changed

Three different pages state three different things. The management guide states that the default is enabled, with no condition attached. The AWS CLI reference draws the line at November 25, 2019. The API reference draws it at July 2019.

By default, the value is false for accounts that have created Amazon EMR clusters
before July 2019. For accounts created after this, the default is true.

The conditions themselves are also inconsistent. The CLI reference specifies whether the account has previously created a cluster in that Region. The API reference specifies whether the account was created after that date. The former refers to the account's usage history within a Region, while the latter refers to the account's creation date; they are saying different things.

This article does not resolve this discrepancy. It would be possible to choose one version and write accordingly, but there is no justification for making that choice. Instead of adding a date-specific Default entry in the timeline, a note was added to the Control entry dated September 20, 2019. You can check the status of your own account using the API described in Section 8.

9.2 The Three Dates Behind Block Public Access for AMIs

One change carries three dates that mean different things. The control shipped on September 12, 2023, the default moved on October 20, 2023, and the moment the condition looks at is July 15, 2023.

The third is the odd one, sitting more than three months before the default moved. Without understanding that the condition refers to the past, it becomes difficult to explain the state of holding no public AMI today and yet finding the default disabled.

Two dates associated with Amazon EMR may also appear to follow a similar structure. One could represent the point at which the condition is observed, while the other could represent the deployment point. This interpretation is plausible, but this is this article's own inference, and no primary source states it. This article does not present the unconfirmed as fact.

9.3 The Body of an Announcement Disagrees With the Notes Added to It

The 2020 password policy announcement, discussed in Section 7, yields different answers depending on whether you read the main body or the added notes. The main body states an implementation date of 90 days and mentions the month of October, and this description remains unchanged as of the verification date. However, the three notes at the beginning indicate that the implementation date was ultimately November 18, 2020.

The main body still contains a different date that was determined later. A paragraph encouraging preparation states that users should comply by October 28th, but this date has been superseded by the final note, which specifies November 18th. The body still carries the date from before that move.

This article does not rule on which one is wrong. The dates make clear that the notes are newer, but AWS does not say which it treats as authoritative. When quoting, note whether the wording came from the body or from the note.

9.4 A Documentation URL Quietly Moves to a Different Page

Beyond issues related to dates and conditions, there are important considerations regarding the verification process itself. The order of precedence for instance metadata options once had a page of its own. As of the verification date, that URL redirects to the service overview page. The redirection is reported as a success, so if you do not carefully check the content of the retrieved page, you might mistakenly believe that the description of the order of precedence has been removed. In reality, the information has moved to a section of the configuration procedure page.

Record a citation by URL alone and this move breaks the trail. That is why the quoted sentences themselves sit in the body of this article.

10. Failure Modes and Anti-Patterns

⚠ Reading an announcement as applying to all resources. This is the most common mistake. Out of the 6 entries in the timeline's Default rows, 4 affected existing configurations, and all 4 of those had conditions attached. Read only the announcement headlines and skip the inventory, and the older generations of resources stay unexamined.

⚠ Building the opposite general rule out of the cases that did reach existing resources. This is just as dangerous. Knowing that Amazon S3's changes in January 2023 modified existing bucket configurations might lead you to assume that AWS will apply similar changes to existing resources as well. However, those same changes did nothing to existing objects. The fact that the answer varies depending on the layer is more accurate than either general rule.

⚠ Reading an account default as enforcement. Even if you set IMDSv2 as the default at the account and Region level, instance launch configurations can override that setting. If you want to enforce it, you need a dedicated configuration or a policy that uses conditional keys. These are separated into Control and Enforce in the timeline.

⚠ Applying what the guide calls the default to your own account. As mentioned in Section 8.1, a guide written for users sometimes omits the grandfathering. Query the setting rather than read about it.

⚠ Trusting the default on the image without verifying the precedence. Even if an AMI has configurations that require IMDSv2, the launch configuration and account settings take precedence. Freezing an image does not guarantee that the instance launched from it holds that setting.

⚠ Checking one Region and assuming that is the answer for all of them. Account-level settings are Region-specific, and even changes made by the service are applied to each Region sequentially. The answer can change when you cross Regions.

⚠ Overlooking an update note and citing the article's publication date as the change date. An example with a 5-year discrepancy is included in the timeline.

⚠ Keeping an exhaustive table of your own. The reason this article focuses on a limited set of representative examples, along with the criteria, is due to this issue. As mentioned in Section 2, no cross-service list of default changes was found in the range this article searched. Creating your own table leaves you responsible for updates, and if you miss something, no one will notice.

11. Frequently Asked Questions about AWS Security Defaults

Does a default change apply to resources that already exist?

It depends on the change. In the range confirmed here, four changes reached into the configuration of existing resources and existing accounts. All four of these changes were applied only to items that the user had not yet configured. Items that the user had already set up remained untouched. Furthermore, none of the changes examined here modified existing data. While the general rule that changes do not apply to existing configurations is often correct, relying on this rule without verification can lead to errors.

Is it accurate to say new buckets are safe and old buckets are not?

For the public access controls and access control lists, yes. The April 2023 change reached only newly created buckets. Default encryption is different. In the January 2023 change, AWS applied default encryption settings to existing buckets that previously did not have it configured. For the same bucket, the answer varies depending on the specific item.

What happens to running instances when I set IMDSv2 as the account default?

Setting IMDSv2 as the default at the account level does not affect currently running instances. The primary source explicitly states that the account-level default setting will not reset existing instances. To modify the values of existing instances, you must change them individually.

How does a default differ from enforcement?

A default can be overridden; enforcement cannot. In Amazon EC2, the enforcement setting for IMDSv2 runs after precedence settles the value. So a launch that does not meet the requirement fails while enforcement is on, whatever the launch request or the AMI says.

How do I find out which default my account received?

Call the API that returns the current value of the settings. Avoid inferring the answer from documentation, as a user guide may omit the grandfathering condition. Account-specific settings are managed on a Region-by-Region basis, so verification should also be performed within each Region.

How do I notice that a default has changed?

Check all three sources simultaneously: AWS What's New, the user guides and release notes for each service, and updates to the official blog. In this timeline, the seven Amazon EC2 entries are sourced from the document history, while the April 2023 completion appears only in an update note on the official blog. Relying on just one source can lead to missed information.

Which is more likely to have moved, a setting I configured or one I never touched?

The latter. In the range confirmed here, the four cases where AWS reached into existing configuration all shared one condition: the user had not yet configured those specific items. These included accounts without a password policy, buckets without a default encryption setting, accounts without a public AMI, and accounts holding no SSE-C encrypted objects. While AWS does not publicly state this as an official rule, it can be a useful factor to consider when prioritizing your checks.

Does the date given in an advance notice hold?

Not necessarily. The 2020 announcement in this timeline moved its implementation date four times after the notice went out. The only record of these changes can be found in the three update notes at the beginning of the article; the main text itself has not been updated to reflect the actual dates. When extracting dates from these announcement articles, it is advisable to document whether the date was taken from the main text or from the update notes.

Can resources created on the same day have different defaults in different Regions?

Yes. A sweeping change made by the service lands Region by Region. An announcement from December 2022 stated that these changes would be rolled out to all Regions over a period of several weeks. During this rollout process, default settings may vary by Region.

Does this timeline cover every AWS security default?

No. This article presents a selection of representative examples under a stated set of inclusion criteria. The search did not turn up an official, comprehensive list. In particular, default settings that are tied to a specific major version of the engine do not have a global change date, making it structurally impossible to include them based on date-dependent criteria.

Can I bring older resources into line in bulk?

For configuration, yes: it means calling the API that rewrites the setting against every resource. For data, no: it is not a rewrite but a rebuild. The Amazon S3 default encryption FAQ states that to encrypt existing, unencrypted objects, you can use S3 Batch Operations to create encrypted copies. Changing a configuration and modifying data that already exists are fundamentally different tasks.

Can I get ahead of default changes across an organization?

Not exactly. An organizational policy can distribute the setting: Amazon S3 Block Public Access gained organization-level enforcement in November 2025, and both the instance metadata settings for Amazon EC2 and block public access for AMIs fall under declarative policies. However, this does not proactively align settings with the default; instead, it establishes a higher-level mechanism to fix values. When organizational policies are in effect, the setting can no longer be changed from inside the account.

12. Summary

This article has compiled a timeline of changes AWS has made to its default security settings, built only from primary sources published as of the verification date of September 10, 2026. The reach of those changes is sorted into seven distinct shapes.

Three key observations can be drawn.

First, the meaning of a changed default varies depending on the specific change. For example, the rotation interval for AWS managed keys affected existing keys. While Amazon S3's default encryption modified existing bucket configurations, it did not affect existing objects. The control of public access only applied to newly created buckets. All three are recorded as a default having changed.

Second, the reach of these changes sometimes depends on the account's state. The default for block public access on AMIs split on whether the account held a public AMI on or after July 15, 2023, and making every AMI private afterward does not put it back. The 2026 changes to Amazon S3 mean that if an account holds even one qualifying object, all of that account's buckets are excluded from the change. Even after reading the announcement, it is not possible to determine which side your account landed on. The announcement gives the condition, and nothing more.

And that condition had the same shape in all four cases. The four changes that affected existing configurations all have one thing in common: they only apply when a user has not yet configured that particular setting. This includes IAM password policies, Amazon S3 default encryption, block public access for AMIs, and encryption using customer-provided keys in Amazon S3. AWS only intervenes to fill in gaps. While AWS does not publicly state this as a general rule, it can be useful when prioritizing checks. Items that have never been touched often have a value already assigned.

Third, across all seven shapes, data already written stays as it was. This was the only point with no exception across the seven. Aligning configurations and aligning data are separate processes, and the latter requires rebuilding.

These three observations are faces of one design. As AWS strengthens its default settings, it must simultaneously ensure that existing systems are not disrupted. The result of this balancing act is the need to draw the line at a different layer for each change and to use an account's history as a condition. In exchange for the guarantee of stability, users are left with the task of identifying and aligning older resources.

It is also worth noting how to interpret dates. When tracking changes to default settings, it is safest to consult three sources simultaneously: AWS What's New, the user guide and the document history in the release notes, and the update notes on the official blog. As of the verification date, these three sources each maintained separate, distinct entries. It is important to remember that the page describing the current default is separate from the page recording the condition of the grandfathering. To check the status of your account, refer to the API, not the documentation.

This timeline will be updated as AWS default settings change.

A default that moves does not move what has already been built, and that gap is not confined to account settings. Inside a Kubernetes cluster, a certificate can be reissued on schedule while the process still presenting the old one never finds out, and the layer where that stops is examined in Certificate Distribution in Kubernetes with AWS Private CA. In both places, the change and the running system are two different things.

There are related articles on this site as well, so please read them if they are of interest.

Amazon S3 Security and Access Control Guide - Bucket Policies, IAM, Access Points, Block Public Access, and Encryption

IAM Policy Evaluation Logic Step-by-Step - Explicit Deny, RCP, SCP, Resource Policy, Identity Policy, Permission Boundary, and Session Policy

AWS Service Lifecycle States - Maintenance, Sunset, Full Shutdown, and What Each One Takes Away

Amazon Linux History and Timeline - Amazon Linux AMI, Amazon Linux 2, AL2023, AL2027, and the Clocks That Do Not Move Your Instances

AWS History and Timeline regarding Amazon S3 - Focusing on the evolution of features, roles, and prices beyond mere storage

AWS History and Timeline regarding Amazon EBS - Overview, Volume Types, Features, Summary of Updates, and Introduction

AWS History and Timeline regarding AWS Key Management Service - Overview, Functions, Features, Summary of Updates, and Introduction to KMS

13. References

Amazon S3 Block Public Access - Another Layer of Protection for Your Accounts and Buckets

Heads-Up: Amazon S3 Security Changes Are Coming in April of 2023

Default encryption FAQ - Amazon S3

Configuring default encryption - Amazon S3

Blocking public access to your Amazon S3 storage

Advanced notice: Amazon S3 to disable the use of SSE-C encryption by default for all new buckets and select existing buckets in April 2026

Amazon S3 starts rolling out new security best practice to new and existing buckets by default

Default SSE-C setting for new buckets FAQ - Amazon S3

Security best practices for Amazon S3

Amazon S3 Block Public Access now supports organization-level enforcement

Configure the Instance Metadata Service options - Amazon EC2

Configure instance metadata options for new instances - Amazon EC2

Transition to using Instance Metadata Service Version 2 - Amazon EC2

Understand block public access for AMIs - Amazon EC2

Manage the block public access setting for AMIs - Amazon EC2

Document history for Amazon EC2 User Guide

Enable Amazon EBS encryption by default

Block public access for Amazon EBS snapshots

New - Block Public Sharing of Amazon EBS Snapshots

AWS IAM introduces updated policy defaults for IAM user passwords

EnableKeyRotation - AWS Key Management Service API Reference

Using Amazon EMR block public access

BlockPublicAccessConfiguration - Amazon EMR API Reference

get-block-public-access-configuration - AWS CLI Command Reference

Secure your Amazon EMR cluster from unintentional network exposure with Block Public Access configuration

Using SSL with a PostgreSQL DB instance - Amazon RDS

AWS What's New

References:
Tech Blog with curated related content

Written by Hidekazu Konishi