How to terminate resources on AWS which are created by user through STS also

Hello.

For example we have created a lab where we teach student to run NodeJs backend Server on EC2 but after the lab completion we also want to delete those resources.

After completing the lab, try using aws-nuke to delete all AWS resources in your account.
https://github.com/ekristen/aws-nuke

Also currently all users can list each others Resources like User A creates EC2 will be visible to User B so how to solve that issue should we switch our flow from using single AWS account and creating credentials through STS for User to Creating Sandbox environment using AWS Organization Account.

Unfortunately, IAM policies often do not support resource-based access permissions for "Describe" actions, meaning you cannot restrict their display to specific EC2 instances in the Management Console.
Therefore, if you want complete separation, you will need to separate your AWS accounts.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-policies-for-amazon-ec2.html

Currently, the Amazon EC2 Describe* API actions do not support resource-level permissions. For more information about resource-level permissions for Amazon EC2, see Identity-based policies for Amazon EC2.

If we also switch towards AWS Org account then also Account creation and assigning user the account takes lots of time so how can we solve that? Should we have pool of accounts but then if our scale increases then it would be difficult to manage so many pool.

One limitation of AWS Organizations is the maximum number of accounts that can be managed within a single organization.
While it is technically possible to create up to 50,000 accounts, creating this many AWS accounts requires explaining your use cases and other details to AWS and obtaining their approval through service quotas.
In the past, I've set up many AWS accounts for similar purposes as yours, but it took quite a long time for the application to be approved.
If you're a company with a long history of using AWS accounts, rather than an individual, your application might be approved more quickly.
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_reference_limits.html

Note: Only the Management account of an organization can submit this quota increase request. Limit increases can be granted up to 50,000 accounts based on customer qualifications and requirements. Newly created accounts and organizations might experience a quota below the default of 10 accounts.

There is also an AWS Skill Builder Lab, although it is a paid service, so depending on the content of your hands-on session, it might be better to use that instead.
https://skillbuilder.aws/search?searchText=AWS%20Builder%20Labs

Recommended Architecture: Multi-Account Sandbox Strategy

To solve your lab isolation, visibility, and cleanup challenges, you should transition from a single AWS account using STS to a multi-account sandbox model. Attempting to isolate and clean up resources within a single AWS account creates massive management overhead and security risks.

Below is the architectural blueprint to resolve your visibility issues, automate cleanups, and manage account pools efficiently at scale.

1. Solving the Visibility Issue (Console Isolation) In AWS, the ec2:DescribeInstances and other resource description APIs are account-wide. You cannot restrict Student A from seeing Student B’s resources in the AWS Management Console using IAM policies alone.

The Fix: Move to a multi-account structure where each student gets a dedicated, isolated AWS sandbox account. This guarantees 100% security isolation and fixes the console visibility issue natively.

2. Solving the Account Pooling & Scaling Problem Your concern about account creation lag and pooling complexity is common. The industry-standard solution is to build a Pre-Warmed Account Pool combined with an asynchronous reset pipeline.

The Lifecycle Workflow:

• Maintain a Pre-Warmed Pool: Keep a steady buffer of empty, ready-to-use AWS accounts (e.g., 20 or 50 accounts created ahead of time).

• Instant Assignment: When a student starts a lab, your portal instantly issues credentials to an active account from the pool. This takes milliseconds, completely bypassing account creation delays.

• Asynchronous Teardown: When the lab ends, revoke the student's access and move the account to a "Cleanup" queue.

• Wipe and Recycle: Run an automated wiping tool on the account. Once clean, return it to the active pool.

Tools to Automate This:

Instead of building this from scratch, look at these standard frameworks:

• AWS Control Tower Account Factory:

Automates the creation and baseline configuration of new accounts.

• AWS Sandbox Accounts Automated Lifecycles (SAAL): An open-source AWS framework specifically designed to manage the lifecycle, pooling, and automated wiping of temporary sandbox accounts.

3. Alternative: How to Handle Cleanup If You Must Stay on One Account If you cannot switch to a multi-account model immediately, you must rely heavily on Resource Tagging and automated management roles to handle deletion, since the students' temporary STS sessions will expire.

• Enforce Session Tagging: Configure your lab creation engine to force principal tagging on the STS session. Use IAM policies to ensure every resource created is tagged with the student's unique ID (e.g., Owner: Student-123).

• Deploy Cloud Custodian or AWS Nuke: Set up an administrative Cron job (via AWS Lambda or Amazon ECS) that runs at the end of the lab. Use Cloud Custodian or AWS Nuke to scan the account and delete any resource matching Owner: Student-123 or any resource older than the lab duration (e.g., 2 hours).

• AWS Config Remediations: Set up AWS Config rules to monitor compliance. If an unapproved or student-owned resource is detected after hours, trigger an AWS Systems Manager (SSM) Automation document to terminate it.