5 Ways to Keep AWS Fast with Just-in-Time Access – Teleport
Solving for the Human Risk Factor in AWS Environments
Modern AWS environments move fast. Engineers spin up EKS clusters for testing, automation pipelines deploy to production, and AI agents trigger infrastructure workflows via Amazon Bedrock.
AWS provides ways to manage access primitives such as roles and privileges to keep up with this velocity, such as STS AssumeRole, OIDC federation, IAM Authenticator, and Identity Center. But the challenge isn’t in these primitives themselves.
It’s the human factor behind the primitives. Platform and security teams are tasked with manually orchestrating and maintaining hundreds of accounts and resources, all while enforcing policies at scale. Incidents of misconfiguration or overprovisioning are almost inevitable.
This is where Teleport brings fast time to value. With the Infrastructure Identity Platform, Teleport unifies identities, just-in-time access, and a granular audit trail, reducing the operational burden on teams and making fast-moving AWS environments easier to govern with consistent least privilege.
Inside this blog, we’ll highlight what makes Teleport’s unified identity and just-in-time (JIT) access model so beneficial for AWS applications — including a look at the real world engineering use cases where it shines brightest.
How Just-in-Time Access Builds AWS Velocity
AWS provides multiple ways to grant access: IAM keys, role assumptions, or administrative policies. In practice, these can be difficult to manage consistently across a scaling AWS environment.
Teleport builds on top of these AWS-native capabilities by issuing ephemeral privileges with a policy-defined time-to-live (TTL) whenever a user, machine, or AI agent requests access
For example, if an engineer needs temporary access to a production Amazon RDS PostgreSQL database, Teleport provides a short-lived certificate that automatically expires when the TTL ends.
In short, Teleport ensures several things remain consistent across any size AWS deployment.
- Access is least privileged by default
- Identity governance is consistent for all actors (humans, CI/CD, and AI)
- Approvals, TTLs, and expirations are based on task
5 Use Cases for Just-in-Time Access to AWS
1. EKS access
Before JIT: Kubeconfig management for days
Kubernetes access in AWS often involves distributing kubeconfig files or configuring the AWS IAM Authenticator.
These kubeconfigs are rarely rotated, can be copied or shared, and leave clusters unmanaged if an engineer leaves the organization. Governance gaps emerge when multiple teams manage kubeconfigs differently across environments.
After JIT: Secure EKS access with no kubeconfigs
Teleport connects directly to the AWS IAM Authenticator for Kubernetes, so kubeconfig files never need to be distributed in the first place.
Instead, engineers receive short-lived Kubernetes privileges linked to their Teleport role. Those roles map to cluster RBAC, so access is always limited to the right namespace or resources. Every kubectl command is recorded and tied back to the person or system that ran it.
For more detail, read this practical guide to learn how to implement EKS JIT access step-by-step.
Use case in action
An SRE needs to troubleshoot a production EKS service. They request cluster access via the CLI, specifying a two-hour TTL.
Teleport issues a temporary Kubernetes certificate tied to their IAM identity, and all kubectl activity is recorded. When time is up, the certificate expires automatically.
2. On-demand EC2 access
Before JIT: Static keys and shadow access paths
Many AWS teams still rely on static IAM roles or SSH keys for EC2 management. These keys can linger on laptops and shared systems, creating shadow access paths untraceable by audit logs and ungoverned by policy.
Even with SSM Session Manager, access can be provisioned too broadly; no live approval controls limit visibility into active sessions and approval chains.
After JIT: Keyless, time-bound EC2 sessions with full audit
Teleport uses AWS SSM Session Manager to create secure shell or port-forwarding sessions to EC2 instances without opening network ports or using SSH keys. Instead, engineers get short-lived certificates that expire automatically after their approved time window.
All session activity (including command execution) is streamed to Teleport’s audit log. This can be optionally exported to CloudTrail for unified AWS visibility. Watch our recent webinar, Simplifying Zero Trust Security for AWS, for a look at how this works in action (and additional insight from AWS experts).
Use case in action
During an incident, a platform engineer requests EC2 access through PagerDuty. Approval triggers Teleport to generate a one-hour X.509 certificate bound to their IAM role. The engineer connects over SSM, executes fixes, and the certificate expires automatically when the hour ends.
3. AWS console access
Before JIT: Over-permissioned sessions and unclear audit trails
Federated AWS Console access often gives engineers more permissions than they need and keeps them active for hours. Session logs don’t always clearly link console actions to a specific request, making it easy for privilege creep to go unnoticed.
After JIT: Task-based console sessions with MFA and audit
Teleport provisions AWS console access through the tsh apps login workflow, generating an AWS Console sign-in URL valid only for the approved session duration.
Role assumptions are tightly bound by the Teleport role definition (aws_role_arns), and each session can require WebAuthn MFA before issuing the console link. Console events are correlated with CLI and API actions in Teleport’s unified audit log, providing a complete view of activity.
Use case in action
A security engineer needs to inspect IAM role trust policies in the AWS Console. They submit a request via Slack, receive a console link valid for 45 minutes, and must complete WebAuthn MFA before entry. All console clicks are linked to the request in Teleport’s logs.
4. CI/CD pipeline access
Before JIT: Long-lived secrets in automation
Pipelines often store AWS keys in environment variables or secret managers. If these credentials are leaked or the pipeline is compromised, attackers may gain extended access to the AWS environment. Even rotating these keys can leave secrets stored in multiple places and increase the likelihood of a missed rotation or other misconfiguration.
After JIT: Ephemeral AWS credentials for every job
Teleport integrates with CI/CD platforms like GitHub Actions, CircleCI, and Terraform to issue AWS credentials only when a job starts. These credentials expire as soon as the job ends and are bound to the exact task, and every AWS API call made during the job is logged and linked to the pipeline’s identity.
Use case in action
A Terraform job deploys changes to an EKS cluster. When the job starts, Teleport issues AWS credentials valid for 20 minutes. Once the job completes, the credentials expire automatically, leaving nothing stored to rotate or secure.
5. Bedrock agent access
Before JIT: Persistent permissions for AI agents
AI agents and services connected through Model Context Protocol (MCP) and Amazon Bedrock may act with high-level privileges in AWS environments. If these agents are given static credentials or persistent role access, they may operate beyond their intended purpose, creating blind spots in governance and audit logs.
After JIT: Short-lived, context-aware access for AI
Teleport treats AI agents like any other identity. When an agent triggers a workflow, it also gets a short-lived certificate tied to the specific task and approved time window. The same policies, MFA, and time constraint rules applied to humans apply equally to AI actors, and every action they take in AWS is logged and linked back to the request.
Use case in action
A Bedrock agent needs to update an S3 bucket with new training data. An automated approval process grants a 10-minute window for access only to the designated bucket. Once the task completes, the certificate expires and leaves no lingering permissions.
The Security and Compliance Impact
Every AWS session through the CLI, Console, or an automated pipeline is tied to a specific identity and documented access request, making it clear who did what, when, and under what policy. This continuous attribution creates a forensic-quality audit trail that is ready for compliance frameworks such as SOC 2, HIPAA, and FedRAMP without additional manual evidence gathering.
In addition, Teleport correlates all AWS activity logs with broader infrastructure audit data from systems like CloudTrail and SIEM platforms, providing a single source of truth for both operational and compliance teams. This unified visibility reduces the time and complexity of audits while accelerating resolution of incident investigations.
As a result, organizations can maintain strong security controls while meeting compliance obligations. At the same time, engineers get faster access and security leaders close governance gaps.
Conclusion
The dynamic nature and scale of AWS environments makes static keys and long-lived permissions risky and operationally complex. Teleport’s just-in-time model, coupled with short-lived privileges and trusted, unified identity, turns access into a controlled, temporary, and fully auditable event.
By applying this approach across EKS, EC2, the AWS Console, CI/CD pipelines, and AI-driven workflows, organizations can reduce risk, streamline compliance, and keep engineers moving at full speed while hardening security.
Simplify and secure AWS access
Learn more about how Teleport simplifies and secures AWS environments: EKS, Bedrock, and beyond.
