https://aws.amazon.com/identity/federation/outbound-federation/ now supports Amazon Virtual Private Cloud (VPC) endpoints for the OpenID Connect (OIDC) discovery APIs. You can now access the OIDC discovery metadata and JSON Web Key Set (JWKS) verification key endpoints from within your VPC using https://aws.amazon.com/privatelink/, without requiring traffic to traverse the public internet. IAM outbound identity federation eliminates the need to use long-lived credentials when your AWS workloads access external services. Instead, your workloads request short-lived JSON Web Tokens (JWTs) from AWS Security Token Service (AWS STS). External services verify these tokens using public verification keys and metadata available at OIDC discovery endpoints. Previously, the OIDC discovery endpoints were only reachable over the public internet, so a verifying workload running in a VPC without internet access could not retrieve them. With this launch, you can create an interface VPC endpoint to reach these endpoints privately, keeping the verification key retrieval traffic within the AWS network. This capability helps you meet network security requirements for workloads that operate in VPCs with restricted internet access, while still enabling external services to verify JWTs. This feature is available in all commercial AWS Regions, the AWS GovCloud (US) Regions, and China Regions. There is no additional charge for this feature beyond standard https://aws.amazon.com/privatelink/pricing/. To learn more, see the https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sts_oidc_vpc_endpoint_create.html.

AWS Identity and Access Management (IAM) outbound identity federation now supports Amazon Virtual Private Cloud (VPC) endpoints for the OpenID Connect (OIDC) discovery APIs. You can now access the OIDC discovery metadata and JSON Web Key Set (JWKS) verification key endpoints from within your VPC using AWS PrivateLink, without requiring traffic to traverse the public internet. IAM outbound identity federation eliminates the need to use long-lived credentials when your AWS workloads access external services. Instead, your workloads request short-lived JSON Web Tokens (JWTs) from AWS Security Token Service (AWS STS). External services verify these tokens using public verification keys and metadata available at OIDC discovery endpoints. Previously, the OIDC discovery endpoints were only reachable over the public internet, so a verifying workload running in a VPC without internet access could not retrieve them. With this launch, you can create an interface VPC endpoint to reach these endpoints privately, keeping the verification key retrieval traffic within the AWS network. This capability helps you meet network security requirements for workloads that operate in VPCs with restricted internet access, while still enabling external services to verify JWTs. This feature is available in all commercial AWS Regions, the AWS GovCloud (US) Regions, and China Regions. There is no additional charge for this feature beyond standard AWS PrivateLink pricing. To learn more, see the IAM User Guide.

AWS IAM now enables outbound identity federation, allowing developers to securely authenticate AWS workloads with external services using short-lived JSON Web Tokens instead of storing long-term credentials like API keys and passwords.

AWS introduces Attribute-Based Access Control (ABAC) for S3 general purpose buckets, enabling administrators to automatically manage permissions through tag-based policies that match tags between users, roles, and buckets—eliminating the need to constantly update IAM policies as organizations scale.

To be honest, I’m still recovering from the AWS Summit in New York, doing my best to level up on launches like Amazon Bedrock AgentCore (Preview) and Amazon Simple Storage Service (S3) Vectors. There’s a lot of new stuff to learn! Meanwhile, it’s been an exciting week for AWS builders focused on reliability and observability. […]

Last week, the OpenSearch and Valkey teams visited Seoul to meet open source developers and contributors in the Open Source Summit Korea 2026 and MCP DevSummit Seoul 2026. At the four-day event, community leaders and users of open source projects and emerging agent AI gathered to share knowledge, collaborate on solutions, and push the projects […]

AWS Sign-in now supports resource-based policies and resource control policies (RCPs) for the AWS Management Console. You can use these policies to restrict console sign-in to expected networks. Policies are evaluated during sign-in and whenever the console session requests new credentials. Resource-based policies apply to individual AWS accounts. Resource control policies apply organization-wide through AWS Organizations. You can combine these policies with https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/console-private-access.html to control both which networks users can sign in from and which accounts they can access. AWS Sign-in resource-based policies and RCPs are available at no additional cost in all AWS commercial Regions. To learn more, see the https://docs.aws.amazon.com/signin/latest/userguide/what-is-sign-in.html. For API details, see the https://docs.aws.amazon.com/signin/latest/APIReference/.

You can now connect AI agents directly to the AWS MCP Server using AWS Sign-In. Agents connect using industry-standard OAuth without requiring additional authentication software. Existing AWS identities, sign-in methods, IAM permissions, and governance controls you have already set up continue to apply. Developers can authorize agents interactively through a browser or programmatically using non-interactive (headless) authorization. Administrators can govern OAuth access using familiar IAM policies together with new OAuth capabilities, including global condition keys, token introspection and revocation APIs, dynamic client registration, and CloudTrail audit events. To learn more, see the https://aws.amazon.com/blogs/security/introducing-oauth-support-for-aws-mcp-server/, https://docs.aws.amazon.com/signin/latest/userguide/oauth-sign-in-overview.html in the AWS Sign-In User Guide, and https://docs.aws.amazon.com/agent-toolkit/latest/userguide/getting-started-aws-mcp-server.html in the Agent Toolkit for AWS User Guide.

https://aws.amazon.com/iam/ has increased maximum quotas for six resources: Customer managed policies per account (5,000 to 10,000) Instance profiles per account (5,000 to 10,000) Managed policies per role (20 to 25) Role trust policy length (4,096 to 8,192 characters) Roles per account (5,000 to 10,000) OpenId connect providers per account (100 to 700) These updates address common scaling constraints customers encounter as their AWS environments grow. With these higher maximum quotas, customers have more flexibility to customize IAM controls and support additional workloads that require creation of IAM resources. Customers can view the latest IAM quotas in the https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html documentation. To request quota increases for accounts in AWS commercial regions, use https://docs.aws.amazon.com/servicequotas/latest/userguide/intro.html in US East (N. Virginia). In AWS GovCloud (US) and China Regions, customers can request increases through AWS Support. For more information, see https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html in the Service Quotas User Guide.

AWS is expanding service reference information to include which operations are supported by AWS services and which IAM permissions are needed to call a given operation. This will help you answer questions such as “I want to call a specific AWS service operation, which IAM permissions do I need?” You can automate the retrieval of service reference information, eliminating manual effort and ensuring your policies align with the latest service updates. You can also incorporate this service reference information directly into your policy management tools and processes for a seamless integration. This feature is offered at no additional cost. To get started, refer to the documentation on programmatic service reference information.

AWS today launched three new condition keys that help administrators govern https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys.html. The new condition keys help you control the generation, expiration, and the type of API keys allowed. Amazon Bedrock supports two types of API keys: short-term API keys valid for up to 12 hours or long-term API keys which are https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_service-specific-creds.html for use with Bedrock only. The new iam:ServiceSpecificCredentialServiceName condition key lets you control what target AWS services are allowed when creating IAM service-specific credentials. For example, you could allow the creation of Bedrock long-term API keys but not credentials for AWS CodeCommit or Amazon Keyspaces. The new iam:ServiceSpecificCredentialAgeDays condition key lets you control the maximum duration of Bedrock long-term API keys at creation. The new bedrock:BearerTokenType condition key let’s you allow or deny Bedrock requests based on whether the API key is short-term or long-term. These new condition keys are available in all AWS Regions. To learn more about using the new condition keys, visit the https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#available-keys-for-iam or https://docs.aws.amazon.com/bedrock/latest/userguide/api-keys-permissions.html.

AWS today launched three new condition keys that help administrators govern API keys for Amazon Bedrock. The new condition keys help you control the generation, expiration, and the type of API keys allowed. Amazon Bedrock supports two types of API keys: short-term API keys valid for up to 12 hours or long-term API keys which are IAM service-specific credentials for use with Bedrock only. The new iam:ServiceSpecificCredentialServiceName condition key lets you control what target AWS services are allowed when creating IAM service-specific credentials. For example, you could allow the creation of Bedrock long-term API keys but not credentials for AWS CodeCommit or Amazon Keyspaces. The new iam:ServiceSpecificCredentialAgeDays condition key lets you control the maximum duration of Bedrock long-term API keys at creation. The new bedrock:BearerTokenType condition key let’s you allow or deny Bedrock requests based on whether the API key is short-term or long-term. These new condition keys are available in all AWS Regions. To learn more about using the new condition keys, visit the IAM User Guide or Amazon Bedrock User Guide.

AWS Identity and Access Management (IAM) Access Analyzer now identifies who within your AWS organization has access to your Amazon S3, Amazon DynamoDB, or Amazon Relational Database Service (RDS) resources. It uses automated reasoning to evaluate all identity policies, resource policies, service control policies (SCPs), and resource control policies (RCPs) to surface all IAM users and roles that have access to your selected critical resources. After the new internal access analyzer is enabled in the IAM console, the analyzer monitors your selected resources daily, and surfaces findings in a unified dashboard. The updated dashboard combines internal and external access findings to provide a 360-degree view of all access granted to your critical resources. Security teams can respond to new findings in two ways: taking immediate action to fix unintended access, or setting up automated notifications through Amazon EventBridge to engage development teams for remediation. Internal access findings provide security teams the visibility to strengthen access controls on their critical resources and help compliance teams demonstrate access control audit requirements. Internal access findings are available in all AWS commercial Regions. To learn more about IAM Access Analyzer internal access findings: Read the AWS news blog post Review the pricing page Visit the IAM Access Analyzer documentation

AWS Identity and Access Management (IAM) Access Analyzer now identifies who within your AWS organization has access to your Amazon S3, Amazon DynamoDB, or Amazon Relational Database Service (RDS) resources. It uses automated reasoning to evaluate all identity policies, resource policies, service control policies (SCPs), and resource control policies (RCPs) to surface all IAM users and roles that have access to your selected critical resources. After the new internal access analyzer is enabled in the IAM console, the analyzer monitors your selected resources daily, and surfaces findings in a unified dashboard. The updated dashboard combines internal and external access findings to provide a 360-degree view of all access granted to your critical resources. Security teams can respond to new findings in two ways: taking immediate action to fix unintended access, or setting up automated notifications through Amazon EventBridge to engage development teams for remediation. Internal access findings provide security teams the visibility to strengthen access controls on their critical resources and help compliance teams demonstrate access control audit requirements. Internal access findings are available in all https://aws.amazon.com/about-aws/global-infrastructure/regional-product-services/. To learn more about IAM Access Analyzer internal access findings: Read the https://aws.amazon.com/blogs/aws/verify-internal-access-to-critical-aws-resources-with-new-iam-access-analyzer-capabilities Review the https://aws.amazon.com/iam/access-analyzer/pricing Visit the https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html 

AWS Security Token Service (STS) now supports Internet Protocol version 6 (IPv6) addresses via new dual-stack endpoints. You can connect to STS over the public internet using IPv6, IPv4, or dual-stack (both IPv4 and IPv6) clients. Dual-stack support is also available when you access STS endpoints privately from your Amazon Virtual Private Cloud (VPC) using AWS PrivateLink, allowing you to invoke STS APIs without traversing the public internet. Support for dual-stack STS endpoints is available in all AWS Commercial Regions, AWS GovCloud (US) Regions, and China Regions. To get started, configure your STS client to use the new dual-stack endpoints using the configuration instructions in the https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_dual-stack_endpoint_support.html.

AWS is expanding service reference information to include which operations are supported by AWS services and which IAM permissions are needed to call a given operation. This will help you answer questions such as “I want to call a specific AWS service operation, which IAM permissions do I need?” You can automate the retrieval of service reference information, eliminating manual effort and ensuring your policies align with the latest service updates. You can also incorporate this service reference information directly into your policy management tools and processes for a seamless integration. This feature is offered at no additional cost. To get started, refer to the documentation on https://docs.aws.amazon.com/service-authorization/latest/reference/service-reference.html.

AWS root user sign-in is now served across US East (N. Virginia), US East (Ohio), and US West (Oregon), with sign-in traffic distributed across all three Regions. This change reduces reliance on US East (N. Virginia) and improves resiliency during service disruptions. AWS automatically routes your root user sign-in to a supported Region without requiring you to select a Region or change how you sign in. This improvement is available now for all AWS accounts. In AWS CloudTrail, ConsoleLogin events for root user sign-ins are recorded in the Region that processed the sign-in request. To maintain full visibility into root user sign-in activity, update your monitoring and alerting to cover US East (N. Virginia), US East (Ohio), and US West (Oregon). To learn more, see the AWS Sign-In documentation and the CloudTrail ConsoleLogin event reference.

AWS root user sign-in is now served across US East (N. Virginia), US East (Ohio), and US West (Oregon), with sign-in traffic distributed across all three Regions. This change reduces reliance on US East (N. Virginia) and improves resiliency during service disruptions. AWS automatically routes your root user sign-in to a supported Region without requiring you to select a Region or change how you sign in. This improvement is available now for all AWS accounts. In AWS CloudTrail, ConsoleLogin events for root user sign-ins are recorded in the Region that processed the sign-in request. To maintain full visibility into root user sign-in activity, update your monitoring and alerting to cover US East (N. Virginia), US East (Ohio), and US West (Oregon). To learn more, see the https://docs.aws.amazon.com/signin/latest/userguide/introduction-to-root-user-sign-in-tutorial.html and the https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-aws-console-sign-in-events.html#cloudtrail-event-reference-aws-console-sign-in-events-root.

https://aws.amazon.com/iam/roles-anywhere/ now provides a plugin for the https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/home.html that enables workloads running outside of AWS to obtain temporary AWS credentials directly within the Java application process. The plugin runs in the same Java Virtual Machine (JVM) as your application, removing the need to run the IAM Roles Anywhere credential helper as a separate process or configure credential_process in your AWS profile. You configure the plugin on your AWS SDK for Java v2 service client builder to automatically resolve temporary credentials without writing credential-fetching logic. The plugin handles calling CreateSession and automatically refreshing credentials before they expire. It supports RSA, Elliptic Curve (EC), and ML-DSA key types and requires Java 8 or higher. There is no additional charge for using the plugin. IAM Roles Anywhere is available in all https://docs.aws.amazon.com/general/latest/gr/rolesanywhere.html, including the AWS GovCloud (US) Regions, AWS European Sovereign Cloud (Germany) Region, and China Regions. To get started with the Java plugin, see the https://docs.aws.amazon.com/rolesanywhere/latest/userguide/java-plugin.html. For the current version, release notes, and signature verification instructions, see the https://central.sonatype.com/artifact/software.amazon.rolesanywhere.plugin/roles-anywhere-java on the Maven Central website and the https://github.com/aws-sdk-plugin/roles-anywhere-java on GitHub.

AWS Identity and Access Management (IAM) Roles Anywhere now provides a plugin for the AWS SDK for Java v2 that enables workloads running outside of AWS to obtain temporary AWS credentials directly within the Java application process. The plugin runs in the same Java Virtual Machine (JVM) as your application, removing the need to run the IAM Roles Anywhere credential helper as a separate process or configure credential_process in your AWS profile. You configure the plugin on your AWS SDK for Java v2 service client builder to automatically resolve temporary credentials without writing credential-fetching logic. The plugin handles calling CreateSession and automatically refreshing credentials before they expire. It supports RSA, Elliptic Curve (EC), and ML-DSA key types and requires Java 8 or higher. There is no additional charge for using the plugin. IAM Roles Anywhere is available in all AWS Regions, including the AWS GovCloud (US) Regions, AWS European Sovereign Cloud (Germany) Region, and China Regions. To get started with the Java plugin, see the IAM Roles Anywhere Java plugin documentation. For the current version, release notes, and signature verification instructions, see the plugin's page on the Maven Central website and the roles-anywhere-java repository on GitHub.

https://aws.amazon.com/iam/ has increased the default quota for managed policies per role from 10 to 20. This higher default quota reduces the need to make Service Quota requests when following IAM best practices like separating permissions into purpose-specific policies or when onboarding to AWS Partner products that require attaching additional managed policies. If you need more than 20 managed policies per role, you can https://docs.aws.amazon.com/servicequotas/latest/userguide/request-quota-increase.html up to 25 using Service Quotas. This change is available in all commercial AWS Regions, AWS GovCloud (US) and China Regions and applies automatically to all IAM roles in your account with no action required. To learn more, see https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html in the IAM User Guide.

AWS Identity and Access Management (IAM) has increased the default quota for managed policies per role from 10 to 20. This higher default quota reduces the need to make Service Quota requests when following IAM best practices like separating permissions into purpose-specific policies or when onboarding to AWS Partner products that require attaching additional managed policies. If you need more than 20 managed policies per role, you can request a quota increase up to 25 using Service Quotas. This change is available in all commercial AWS Regions, AWS GovCloud (US) and China Regions and applies automatically to all IAM roles in your account with no action required. To learn more, see IAM and AWS STS quotas in the IAM User Guide.

AWS Identity and Access Management (IAM) now enables AWS workloads in the AWS European Sovereign Cloud (Germany) Region to securely authenticate with external services using short-lived JSON Web Tokens (JWTs). The AWS European Sovereign Cloud is an independent cloud for Europe entirely located within the European Union (EU), designed to help customers meet their evolving sovereignty requirements. With outbound identity federation, AWS workloads can securely authenticate with third-party cloud providers, SaaS providers, and self-hosted applications without using long-term credentials or implementing complex workarounds. Customers can exchange their AWS IAM credentials for cryptographically signed, short-lived JWTs, providing a simple and secure mechanism to access external services. These tokens contain rich context about the AWS workloads, enabling external services to implement fine-grained access control. Administrators can control access to token generation and enforce token properties (such as lifetime, audience, and signing algorithms) using IAM policies and audit token usage using CloudTrail logs, allowing them to meet their organization's security and compliance requirements. To learn more, visit the outbound identity federation product page, see the IAM user guide, or read the AWS News Blog Post.

AWS Identity and Access Management (IAM) now enables AWS workloads in the AWS European Sovereign Cloud (Germany) Region to securely authenticate with external services using short-lived JSON Web Tokens (JWTs). The AWS European Sovereign Cloud is an independent cloud for Europe entirely located within the European Union (EU), designed to help customers meet their evolving sovereignty requirements. With outbound identity federation, AWS workloads can securely authenticate with third-party cloud providers, SaaS providers, and self-hosted applications without using long-term credentials or implementing complex workarounds. Customers can exchange their AWS IAM credentials for cryptographically signed, short-lived JWTs, providing a simple and secure mechanism to access external services. These tokens contain rich context about the AWS workloads, enabling external services to implement fine-grained access control. Administrators can control access to token generation and enforce token properties (such as lifetime, audience, and signing algorithms) using IAM policies and audit token usage using CloudTrail logs, allowing them to meet their organization's security and compliance requirements. To learn more, visit the https://aws.amazon.com/identity/federation/outbound-federation/, see the https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_outbound.html, or read the https://aws.amazon.com/blogs/aws/simplify-access-to-external-services-using-aws-iam-outbound-identity-federation/.

You can now connect AI agents directly to the AWS MCP Server using AWS Sign-In. Agents connect using industry-standard OAuth without requiring additional authentication software. Existing AWS identities, sign-in methods, IAM permissions, and governance controls you have already set up continue to apply. Developers can authorize agents interactively through a browser or programmatically using non-interactive (headless) authorization. Administrators can govern OAuth access using familiar IAM policies together with new OAuth capabilities, including global condition keys, token introspection and revocation APIs, dynamic client registration, and CloudTrail audit events. To learn more, see the OAuth Support for the AWS MCP Server blogpost, Sign-In with OAuth 2.0 in the AWS Sign-In User Guide, and Setting up the AWS MCP Server in the Agent Toolkit for AWS User Guide.