awsFeb 3, 2026

AWS IAM Identity Center now supports multi-Region replication for AWS account access and application use | Amazon Web Services (opens in new tab)

AWS IAM Identity Center now supports multi-Region replication for organizations using an external identity provider such as Microsoft Entra ID or Okta. Workforce identities, permission sets, and related metadata can be replicated from a primary Region, allowing users to access AWS accounts and managed applications if the primary service is disrupted. The feature also supports regional application deployment for improved performance and data residency compliance, with centralized configuration remaining in the primary Region. ## Multi-Region Replication and Resilience - Replication provides an active AWS access portal endpoint in each additional Region. - Users can continue accessing AWS accounts with already-provisioned permissions during a primary-Region disruption. - AWS managed applications can access replicated identities locally, improving reliability and proximity to users or datasets. - IAM Identity Center configuration remains centrally managed from the primary Region. ## Prerequisites and Setup - The feature requires: - An organization instance of IAM Identity Center. - An external IdP, such as Okta or Microsoft Entra ID. - Primary and additional Regions that are enabled by default. - Before replication, the customer-managed AWS KMS key must be replicated to the target Region. - AWS recommends multi-Region KMS keys because they maintain consistent key material across Regions while preserving independent regional infrastructure. - In the IAM Identity Center console, administrators select **Settings → Management → Add Region** and choose the target Region. - Initial replication time depends on the size of the Identity Center instance. ## User Authentication and Access - Administrators must add the additional Region’s SAML Assertion Consumer Service (ACS) URL to the external IdP configuration. - A bookmark application can be created in the IdP to provide users with direct access to the new Region’s AWS access portal. - Users can access accounts and applications through existing methods, including: - The AWS access portal - Application links - The AWS CLI ## Regional Application Deployment - AWS managed applications can be deployed in additional Regions using existing deployment workflows. - Organizations can place applications near regional datasets to satisfy performance or data residency requirements. - Administrators should verify that each required managed application supports both the selected Region and multi-Region deployment. ## Operational Considerations - Additional Regions provide a limited-management console experience. - Most operations outside the primary Region are read-only, except application management and user session revocation. - Workforce activity is recorded in AWS CloudTrail in the Region where it occurs. - Break-glass access is recommended for privileged users if the external IdP becomes unavailable. - Account instances, Microsoft Active Directory identity sources, and the built-in IAM Identity Center directory are not supported at launch. ## Availability and Cost - The feature is available at no additional IAM Identity Center cost in 17 enabled-by-default commercial AWS Regions. - Standard AWS KMS charges apply for customer-managed key storage and use. Organizations using supported external IdPs should replicate IAM Identity Center into strategically selected Regions, configure the required KMS replicas and ACS URLs, and test regional access and emergency procedures before relying on the setup for disaster recovery.

oktasamlsingle-sign-onidentity-and-access-management+4

figmaSep 1, 2021

Inside Figma: getting out of the (secure) shell | Figma Blog (opens in new tab)

Figma replaced its traditional bastion-host SSH model with a zero-trust shell-access system built on AWS Systems Manager Session Manager. The design combines Okta, AWS SSO, phishing-resistant WebAuthn MFA, short-lived IAM credentials, and centralized session logging. This eliminated exposed SSH ports while making access easier to manage, audit, and roll out incrementally. ## Why Figma moved beyond bastion hosts - Bastion hosts became increasingly difficult and time-consuming to secure and manage as Figma scaled. - Because bastions are critical security controls, attackers may target them to gain access to production systems and user data. - Figma’s replacement aimed to provide: - A smooth and reliable developer experience - Zero-trust networking - Strong authentication and phishing-resistant MFA - Short-lived, automatically rotating credentials - Centralized auditing and session tracing - Minimal operational maintenance - Incremental, backwards-compatible adoption ## Choosing AWS Systems Manager - Figma evaluated commercial products such as Okta Advanced Server Access. - These products lacked flexibility for existing workflows, were not always available to Figma, and could introduce external availability dependencies. - Since Figma already relied heavily on AWS, the team built a proof of concept using AWS services. - Systems Manager Session Manager provides: - Authenticated, encrypted TLS connections between users and managed instances - Interactive shells and command execution - SSH tunneling when needed - Access to EC2 and ECS without exposing SSH ports or making instances externally reachable - Centralized permission management through IAM roles ## SSO, authentication, and access control - Okta integrates with AWS SSO to provide centrally managed authentication. - Figma requires device trust and WebAuthn-based multi-factor authentication. - Authenticated users assume dedicated, minimally privileged IAM roles. - AWS access tokens are short-lived, limiting the impact of stolen credentials. - Session Manager records session transcripts in an encrypted S3 bucket for investigation and auditing. - Okta group synchronization makes access management straightforward for IT teams. - Engineers can start sessions either through the AWS Systems Manager console or through Figma’s custom command-line tool. ## Mitigating AWS SSO phishing risks - AWS SSO can be abused through device-code phishing, where attackers trick users into approving an authorization request created by the attacker. - Figma added monitoring and alerts to detect suspicious authentication activity. - Engineers are also expected to treat unexpected SSO authorization pages as suspicious. ## Setting up Session Manager - AWS provides configuration guides for both EC2 and ECS. - Figma’s approach uses Session Manager as the secure access layer while relying on IAM policies, SSO groups, and encrypted logging to control and audit sessions. - The system preserves existing workflows where necessary while removing the need for publicly accessible SSH infrastructure. Figma’s experience suggests that teams already invested in AWS can build a practical zero-trust shell-access system with native services. Session Manager, combined with strong SSO controls, least-privilege IAM, short-lived credentials, and centralized logging, offers a simpler and more secure alternative to bastion-based SSH.

oktaiamzero-trust-securityssh+3

figmaAug 11, 2021

Inside Figma: securing internal web apps | Figma Blog (opens in new tab)

Figma built a reusable system for securely exposing internal web applications while preserving a smooth employee experience. The design combines AWS Application Load Balancers, Cognito, Okta, SAML, Lambda, and Terraform to enforce zero-trust authentication and centralized authorization. Its main conclusion is that carefully integrated, managed cloud components can provide strong security without creating excessive operational work for a small security team. ## Security Requirements for Internal Applications Figma’s internal web tools support critical workflows such as software deployment and customer support, making them attractive targets for attackers. The system was designed around five requirements: - **Smooth user experience:** Authentication should be fast, reliable, and convenient. - **Zero-trust access:** Network location alone should not establish trust. - **Modern authentication:** Applications should be able to use protections such as WebAuthn. - **Centralized authorization:** IT and security teams should centrally assign, monitor, and revoke permissions. - **Low operational overhead:** The system should minimize ongoing SRE and security-team toil. ## Technologies Used The architecture relies primarily on managed services and infrastructure-as-code: - **SAML:** Exchanges identity, group membership, and role assertions between services. - **AWS Application Load Balancer:** Acts as a managed reverse proxy and routes authenticated HTTP/HTTPS traffic. - **AWS Cognito:** Provides user-pool functionality and integrates with federated SAML identity providers. - **AWS Lambda:** Runs code in response to configured events without managing servers. - **Terraform:** Defines and automates AWS and Okta configuration through reusable modules. ## Application Load Balancers, Cognito, and Okta Figma uses AWS for infrastructure and Okta for employee authentication and authorization. - ALBs can authenticate traffic using OIDC, but Okta charges extra for OIDC support. - Figma instead uses the ALB’s SAML authentication capability together with an AWS Cognito user pool. - Terraform modules automate the creation and configuration of the required ALB and Cognito resources. - These modules allow infrastructure engineers to quickly deploy internal applications protected by the company’s Okta environment. - The Cognito user pool disables self-registration. - Each pool connects to a Cognito identity provider backed by a SAML Okta application created for the specific internal application. - Attribute mappings are configured so user information such as `email` and `profile` is passed through the authentication flow.

oktazero-trustaws-lambdaterraform+4