DEV Community: Manusha Chethiyawardhana

It’s 2026: Stop Using AWS IAM and Start Using IAM Identity Center

Manusha Chethiyawardhana — Sun, 11 Jan 2026 07:18:17 +0000

For over a decade, AWS Identity and Access Management (IAM) users were the standard for accessing AWS accounts. Developers created IAM users, generated Access Keys and Secret Keys, and stored them in ~/.aws/credentials files or, worse, hardcoded them into applications.

It is now 2026. The cloud landscape has matured, and security best practices have evolved. The era of long-lived IAM user credentials should be over. If you are still managing individual IAM users for your team members, you are incurring unnecessary security risks and operational overhead. The modern standard is AWS IAM Identity Center (formerly AWS Single Sign-On). Even though AWS recommended using Identity Center over IAM users for more than 2 years, I still see industry accounts clinging to the same old setup, fearing migration.

This article explores why traditional IAM users are obsolete for human access, the benefits of Identity Center, and how to migrate your organization today.

The Problem with Traditional IAM Users

While IAM users are still necessary for certain service accounts or specific edge cases, they are fundamentally flawed for human access in a modern, multi-account environment.

The Security Risk of Long-Lived Credentials
When you create an IAM user, you typically generate an Access Key ID and a Secret Access Key. These credentials do not expire by default.

Leakage: If a developer accidentally commits these keys to a public GitHub repository, attackers can access your account within seconds.
Rotation Fatigue: Enforcing key rotation policies is manual and often ignored, leading to “stale” keys that remain valid for years after an employee has left or changed roles.
Operational Overhead at Scale
Managing IAM users becomes a nightmare as your organization grows.

Siloed Identities: If you have three AWS accounts (Dev, Staging, Prod), you often end up creating three separate IAM users for the same developer.
Policy Drift: Ensuring that “John Doe” has the exact same permissions across all accounts requires complex synchronization of policies. Instead of fine-grained access, administrators would likely rely on granting broader access levels.
Onboarding/Offboarding: Revoking access requires an administrator to log into every single AWS account and manually delete the user or keys.
Lack of Centralized Visibility
With individual IAM users scattered across multiple accounts, auditing “who has access to what” requires aggregating data from every single account. There is no single pane of glass for workforce identity, so it is easy for mistakes to go unnoticed.

The Solution: IAM Identity Center

AWS IAM Identity Center is the recommended service for managing human access to AWS resources. It builds on the concepts of Single Sign-On (SSO) to provide a centralized, secure, and user-friendly access management system.

Advantages of Identity Center

Short-Term Credentials: Identity Center uses temporary security credentials. When a user logs in, they receive a token that expires automatically (e.g., after 8 hours). There are no permanent access keys to leak.
Centralized Multi-Account Access: You manage users and groups in one place. You can grant the “Developers” group access to 20 different AWS accounts with a single configuration change.
Integration with Identity Providers (IdP): You don’t need to create new users in AWS. Identity Center connects with Microsoft Entra ID (Azure AD), Okta, Google Workspace, or Ping Identity. Users log in with their existing organization credentials.
Improved CLI Experience: The AWS CLI integrates natively with Identity Center. Developers run aws sso login, authorize via their browser, and their terminal is automatically configured with valid credentials.

Setting Up IAM Identity Center (New Setup)

If you are starting fresh, setting up Identity Center is straightforward.

Prerequisites:

An AWS Organization (Not mandatory, but a recommended best practice).
Administrative access to the Management Account.

Step 1: Enable Identity Center

Navigate to the IAM Identity Center console in your Management Account.
Click Enable.
Choose whether to enable it in the AWS Region where your organization is based.

Step 2: Choose Your Identity Source
By default, AWS provides a built-in Identity Store. However, for most businesses, you might have to connect to an external IdP.

Go to Settings > Identity source.
Select Actions > Change identity source.
Choose External identity provider.
Download the AWS metadata file and upload it to your IdP (e.g., Okta or Google Workspace).
Upload your IdP’s SAML metadata file back to AWS.

Step 3: Create Permission Sets
A Permission Set is essentially a managed IAM Policy template.

Go to Permission sets > Create permission set.
Select a Predefined permission set (e.g., AdministratorAccess or ViewOnlyAccess) or create a Custom one.
Define the session duration (e.g., 8 hours).

Step 4: Assign Users to Accounts

Go to AWS accounts.
Select the AWS accounts you want to grant access to.
Click Assign users or groups.
Select the Users/Groups (synced from your IdP) and the Permission Sets they should have. Note: For more streamlined management, create Groups rather than adding individual users to accounts. Once configured, your users will receive a User Portal URL (e.g., https://my-org.awsapps.com/start). They can log in there and see every AWS account they have access to.

Migration Guide: Moving from IAM to Identity Center

Migrating from an existing IAM user base can be challenging, but with proper planning, it can be completed without disrupting workflows.

Phase 1: Parallel Adoption

Set up Identity Center as described above.
Map Permissions: Audit your existing IAM Groups. Create equivalent Permission Sets in Identity Center.
Onboard Teams: Ask a pilot team to start using the aws sso login workflow instead of their Access Keys.

Tip: If you use complex inline policies, when mapping permissions, convert them to Customer Managed Policies so they can be easily attached to Permission Sets (or you can add them directly as an inline policy to the permission set).

Prerequisite: AWS CLI Version 2 is required. You can follow this guide to install or update it.

Developers need to update their local ~/.aws/config files. Instead of static profiles, they will use SSO profiles.
Run the automatic configuration wizard:

aws configure sso

Or manually update the config file:

[profile my-sso-profile]
sso_session = my-session
sso_account_id = 123456789012
sso_role_name = AdministratorAccess
region = us-east-1
output = json

[sso-session my-session]
sso_start_url = https://my-org.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

Phase 2: The “Scream Test” (Soft Deprecation)
Once teams are comfortable with the new login flow:

Identify IAM users that correspond to humans.
Deactivate (do not delete) their Access Keys in the IAM Console.
Wait for complaints. If a script or tool breaks, you can instantly reactivate the key while you help the user migrate that tool to an IAM Role or the SSO workflow.

Phase 3: Cleanup
After a period of stability (e.g., 30 days):

Delete the IAM Users.
Update your onboarding documentation to point strictly to the Identity Center portal.
Implement Service Control Policies (SCPs) in AWS Organizations to prevent the creation of new IAM Users (except for specific break-glass scenarios).

Conclusion

In 2026, the overhead and risk associated with long-term IAM credentials are no longer acceptable. AWS IAM Identity Center provides a robust, scalable, and secure mechanism for managing workforce identity.

By centralizing access, integrating with your corporate IdP, and enforcing short-term credentials, you significantly improve your security posture while simplifying the login experience for your engineers.

Stop managing keys. Start managing identities.

Troubleshooting Async AWS Lambda Flows

Manusha Chethiyawardhana — Thu, 10 Aug 2023 17:43:32 +0000

Asynchronous invocation of AWS Lambda functions is a powerful feature that allows event producers and consumers to be decoupled, facilitating efficient and scalable event processing.

It enables developers to create highly scalable and responsive applications. However, troubleshooting async Lambda flows may present significant complexities, necessitating familiarity with techniques and tools to overcome these challenges.

This article will provide an overview of troubleshooting techniques for asynchronous AWS Lambda flows and discuss some best practices for handling errors and retries.

Asynchronous Invocation Overview

AWS services such as Amazon S3, Amazon SNS, Amazon SQS, and Amazon EventBridge can invoke Lambda functions asynchronously. When a Lambda function is invoked asynchronously, the event is placed in a queue, and the caller does not need to wait for the function to complete its execution. Instead, Lambda takes over the responsibility of processing the event. It is possible to configure Lambda to handle errors and send invocation records to a downstream resource that supports asynchronous invocations, which allows for connecting various components of your application.

By setting the invocation type parameter to “Event,” you can enable asynchronous invocation. An example AWS CLI command to invoke an async function is shown below. If you are using AWS CLI version 2, the cli-binary-format option is required.

$ aws lambda invoke \
--function-name myAsyncFunction \
--invocation-type Event \
--cli-binary-format raw-in-base64-out \
--payload '{ "name": "value" }' response.json

And the response you get when the event is queued would look like this:

{
 "StatusCode": 202
}

Challenges of Troubleshooting Asynchronous Invocations

Troubleshooting asynchronous AWS Lambda invocations can be challenging due to several factors:

Limited Visibility: When an event is queued, you will receive a status code as confirmation. However, it’s important to note that a separate process handles the execution of your function by reading events from the queue. Therefore, you won’t receive immediate feedback confirming whether the event was successfully processed.
Automatic Retries: If the function encounters an error, Lambda automatically makes two attempts to run it by default. The documentation does not mention the specific time gap between these retries. Function errors can encompass errors returned by the function’s code and runtime errors, such as timeouts.
Delivery Failures: When Lambda encounters difficulties in sending a record to a configured destination, it reports DestinationDeliveryFailures to Amazon CloudWatch. This situation may arise if your configuration includes an unsupported destination type, such as an Amazon SQS FIFO queue or an Amazon SNS FIFO topic. Additionally, errors related to permissions and size limitations can also lead to delivery failures.
Function Invocation Looping: One scenario where this can occur is when your function manages resources within the same AWS service that triggered it. For example, you might create a function that stores an object in an Amazon S3 bucket configured with a notification that triggers the function again, creating a loop of invocations.
Concurrency Limits: Processing delays can arise due to concurrency limits. When a function is invoked repeatedly, the Lambda service may throttle the invocations, causing delays in processing.

Let’s see how we can overcome these challenges.

Error Handling and Automatic Retries

It is important to understand the retry behavior of the invoking service and any other services involved in the request to ensure proper handling of errors in asynchronous invocations.

The get-function-event-invoke-config command can be used to obtain the configuration for the asynchronous invocation of a function. Below is an example response syntax you will receive.

{
   "DestinationConfig": { 
      "OnFailure": { 
         "Destination": "string"
      },
      "OnSuccess": { 
         "Destination": "string"
      }
   },
   "FunctionArn": "string",
   "LastModified": number,
   "MaximumEventAgeInSeconds": number,
   "MaximumRetryAttempts": number
}

Using the put-function-event-invoke-config command, You can configure a function with a maximum event age and maximum retry attempts. This command overwrites any existing configuration on the function.
For example, to configure a function with a maximum event age of two hours and no retries, you can use the AWS CLI command given below:

$ aws lambda put-function-event-invoke-config --function-name myAsyncFunction \
--maximum-event-age-in-seconds 7200 --maximum-retry-attempts 0

You can use the update-function-event-invoke-config command to configure an option without resetting others.

You can also use the AWS Lambda console to configure asynchronous invocation settings on a function.

You can select and edit asynchronous invocation configurations by navigating to the configuration tab.

Lambda Destinations

Lambda Destinations provide a way to send asynchronous invocation records to various services, including SQS queues, SNS topics, Lambda functions, or EventBridge. By utilizing Lambda Destinations, you can effectively handle successful and unsuccessful execution scenarios, enhancing monitoring capabilities and error handling without requiring additional code.

You can use either the AWS CLI or the Lambda console to manage the settings for asynchronous invocation in Lambda Destinations. For instance, you can use the following command to add a failure destination to your asynchronous invocation.

$ aws lambda update-function-event-invoke-config --function-name myAsyncFunction \
--destination-config '{"OnFailure":{"Destination": "arn:aws:sqs:us-east-2:112233445566:destination"}}'

The function execution result is a JSON document containing information about the event, the response, and the reason for sending the record. The JSON format varies depending on the destination.

An example function execution result would look like this:

{
    "version": "string,"
    "timestamp": "string,"
    "requestContext": {},
    "requestPayload": {
        "ORDER_IDS": []
    },
    "responseContext": {},
    "responsePayload": {}
}

You can now monitor the health of your serverless applications using execution status.

Dead-Letter Queues

On the Lambda function, you can also configure a dead-letter queue to capture events that were not successfully processed. They are comparable to failure destinations. However, unlike destinations, dead-letter queues allow you to save failed messages for later debugging and analysis. They are instrumental when isolating problematic messages and investigating why their processing failed.

Use the update-function-configuration command to set up a dead-letter queue with the AWS CLI.

$ aws lambda update-function-configuration --function-name myAsyncFunction \
--dead-letter-config TargetArn=arn:aws:sns:us-east-2:123456789012:my-topic

The response includes the request-id, the error code, and the error message. This information can be used to determine the error returned by the function or to correlate the event with logs or an AWS X-Ray trace.

Monitoring and Troubleshooting

Understanding behavior and errors cannot be based solely on error handling. Monitoring and observability, which include metrics, logs, and tracing, are also a major part of debugging and troubleshooting.

For example, monitoring Lambda functions can help manage Lambda functions’ concurrency limit, preventing throttling and processing delays.

To make things even easier, Lambda integrates with monitoring and tracing tools such as Amazon CloudWatch, AWS X-Ray, and Helios to provide monitoring of async function invocations.

Amazon CloudWatch

When a function completes event processing, Lambda sends metrics about the invocation to Amazon CloudWatch. This includes metrics for errors that occur during the invocation and should be monitored and addressed:

Errors — the number of invocations that result in a function error (include exceptions that both your code and the Lambda runtime throw).
Throttles — the number of invocation requests that are throttled (note that throttled requests and other invocation errors don’t count as errors in the previous metric).

AWS introduced three new Amazon CloudWatch metrics for asynchronous AWS Lambda function invocations:

AsyncEventsDropped — the number of events dropped without successfully running the function.
DestinationDeliveryFailures — the number of times Lambda attempts to send an event to a destination but fails (typically because of permissions, misconfigured resources, or size limits).
DeadLetterErrors — the number of times Lambda attempts to send an event to a dead-letter queue but fails (typically because of misconfigured resources or size limits).

These metrics provide visibility for asynchronous Lambda function invocations.

Using the error metric is highly recommended for alerting function errors. Additionally, leveraging metrics offers valuable insights into retry behavior, including the interval between retries. For instance, if a function fails due to a downstream system overload, you can rely on metrics like AsyncEventAge and Concurrency metrics to better understand the situation.

AWS X-Ray

AWS X-Ray offers powerful visualization capabilities for your application’s components, helping you identify performance bottlenecks and troubleshoot error-causing requests. However, it’s crucial to remember that AWS X-Ray doesn’t track every request. The sampling rate is set to one request per second, with an additional 5% request rate that cannot be configured. This means that relying solely on AWS X-Ray to troubleshoot a failed invocation may not be sufficient, as the failed invocation could be absent from the sampled traces.

Helios

Helios is an OpenTelemetry-based tool that allows developers to install distributed tracing easily. It enables you to gain end-to-end visibility for Lambda function invocations.

With Helios, you can enhance your monitoring capabilities by utilizing labels and alerts. These features allow you to save search queries and identify specific behaviors of interest for each Lambda function. This customization empowers you to focus on the precise data important to you, whether it be applicative events or AWS Lambda metrics. Furthermore, Helios conveniently provides automatic access to CloudWatch logs. With a simple button click, you can effortlessly retrieve the relevant logs from CloudWatch for each span, streamlining the troubleshooting process.

One notable advantage of Helios is its ability to offer users valuable insights through data and visualizations. For instance, you can easily access information such as the execution time, involved services, and error codes returned for each span, allowing for a comprehensive understanding of your application’s behavior.

Furthermore, Helios provides a convenient feature that enables the replay of specific flows. This functionality automatically generates the necessary code, configures and executes it in a different environment, and allows for a thorough investigation of the root cause of an issue. Finally, it enables verification to ensure that the solution is functioning correctly.

These powerful features offered by Helios significantly contribute to the effective troubleshooting of asynchronous AWS function invocations.

Conclusion

In conclusion, troubleshooting asynchronous AWS Lambda flows requires a comprehensive understanding of the error handling and automatic retry mechanisms provided by AWS Lambda and the available monitoring and troubleshooting tools. By utilizing a combination of dead-letter queues, Lambda Destinations, custom parameters, and adapted processing code, you can effectively handle errors and optimize your asynchronous Lambda flows to suit your specific use case.

I hope these tips and tools prove invaluable in troubleshooting your asynchronous Lambda functions easily and efficiently. Thank you for taking the time to read, and happy coding!

Fast and Secure Frontend Serving with AWS CloudFront CDN

Manusha Chethiyawardhana — Mon, 29 Aug 2022 16:35:00 +0000

Modern frontends are blazingly fast and responsive. Moreover, it requires specialized tools and platforms to deliver at scale. One such platform is AWS CloudFront, a CDN (Content Delivery Network), highly customizable.

So, in this article, I will take you through 6 best practices to optimize CloudFront for fast and secure frontend serving. Let's get started.

1. Caching Frontend Assets using the CDN

Reference: A Case Study in Global Fault Isolation

AWS CloudFront CDN acts as the middle man between your frontend hosting and the users. With CloudFront, you can cache HTML, CSS, JavaScript, and images. Since the cache is closer to the user, the content will be delivered with minimal latency.

You can also configure CloudFront with origin failover for fallback handling in scenarios requiring high availability.

And the best advantage is that AWS CloudFront natively supports integrating Amazon S3, where you can host your frontend artifacts. Besides, you can host your frontend anywhere and still serve through AWS CloudFront.

For more details, refer to the AWS article on Using CloudFront to Serve Static Websites.

2. Using Cache Invalidation Upon New Deployments

It is always good to invalidate the cache when performing a new deployment to prevent browsers from retrieving old file versions from the cache.

AWS CloudFront now supports fast cache invalidation, allowing you to deploy updates to your SPA instantly while still having the benefit of CDN caching.

Note: As a practice, you could invalidate only the files that are modified in your deployment. For instance, if you use Webpack with default configuration, you only need to invalidate the index.html since each modified JS and CSS will have new file names.

You could also use AWS Amplify to simplify your deployments and cache invalidations with built-in optimizations.

3. Use Private S3 Buckets and Origin Access Identity for Security

If you’re using an Amazon S3 bucket as the origin for a CloudFront distribution, it’s essential to restrict public access to S3.

Restricting access prevents someone from bypassing CloudFront and accessing content that you want to keep secure via the Amazon S3 URL.

You will wonder why does it matter since it’s frontend assets that are meant to be public? The reason is that serving through AWS CloudFront comes with more control, where you can set Web Application Firewall (WAF) rules and other restrictions on your content for security.

4. For Hash-less URLs, use Lambda@Edge

Lambda@Edge allows you to intercept HTTP requests that go through CloudFront. These functions run in CloudFront Edge Locations closer to the user, making it faster to respond or act upon content at transit.

Some common use cases of Lamda@Edge are,

Dynamically generate custom content based on request or response attributes, such as resizing images based on request attributes.
To add logic to requests and responses, such as creating pretty URLs and managing authentication and authorization for origin requests.
To increase the cache hit ratio, resulting in improved application performance by avoiding latency caused by a cache miss.
To handle custom authentication and authorization.

If you need to explore more about Lamda@Edge, you can look through the documentation provided by AWS.

Note: If you need simple needs like using only Hashless URLs, there is a simple follow-up approach. Since the objective is to serve the index.html even a user directly goes to a route, we can set the CloudFront error handling to server the index.html if S3 returns the error “resource not found” with error code 404.

5. Using Compression (Brotli, Gzip)

Another best practice I encourage you to follow is using a compression method. With AWS CloudFront, you can serve your applications using Brotli or GZip and reduce content download speed drastically.

Faster downloads, especially for JavaScript and CSS files, can result in the faster rendering of your SPA.

Furthermore, because CloudFront data transfer costs are based on the total amount of data served, serving compressed files is less expensive than serving uncompressed files.

Brotli is a widely used lossless compression algorithm that frequently outperforms Gzip in terms of compression ratio. Compared to Gzip, CloudFront’s Brotli edge compression results in up to 24% smaller file sizes.

Compression features can be enabled via the CloudFront Console, SDK, and the CLI. You need to set EnableAcceptEncodingGzip to true to return Gzip compressed objects and EnableAcceptEncodingBrotli to true to return Brotli compressed objects. CloudFront will use Brotli when the viewer supports both formats.

The Chrome and Firefox web browsers support Brotli compression only when the request is sent using HTTPS. Brotli is not supported with HTTP requests in these browsers.

6. Using Versioned File Names

When performing a new deployment, you can either invalidate files or give them versioned file names to control the versions of files served by your distribution. If you frequently update your files, it is best to use file versioning.

Versioning gives you better control over the content that CloudFront serves. slider_v1.js, image_v1.jpg are some example file versioning names you can use.

Versioning makes it easier to analyze the effects of file changes because CloudFront access logs include file names.
Versioning enables different versions of files to be served to different users.
Versioning simplifies rolling back and forth between file revisions.
The cost of versioning is lower. You must still pay CloudFront to transfer new versions of your files to edge locations, but you don’t have to pay for invalidating files.

Conclusion

No matter how well you design and develop applications, users will be less attracted if it is not performing well. Using AWS CloudFront, you could address most of the performance and security challenges that affect your application frontend.

Therefore, I invite you to try out AWS CloudFront and follow these practices to speed up and secure your frontends at scale.

Thank you for reading!