Skip to main content
Welcome — this short tour reviews the KodeKloud AWS Playgrounds and how to get started. The goal is to show where to find the AWS sandbox, typical limits and access methods, and a quick walkthrough for launching resources. This is a high-level overview, not a deep dive into every AWS service. We have Learn, Practice, and Challenges sections. If you’re following KodeKloud courses such as 100 Days of Cloud - Hands-on Labs or Fundamentals of DevOps, try the Challenges — they’re a great way to reinforce hands-on skills. Below is an example output you might see when running a container (for example, launching Redis via Docker inside an EC2 instance):
Under Practice → All Playgrounds you’ll find the AWS Playground (alongside other sandboxes such as Kubernetes). Use it to experiment with AWS resources without an AWS account of your own.
A website page for KodeKloud advertising an "AWS Sandbox Playground" with a prominent orange "Launch now" button and the AWS logo. Below are navigation tabs and text sections explaining "What is AWS" and cloud computing.
Playgrounds are more permissive than labs but not unrestricted. Always review the playground limits before starting resource-heavy tasks (for example, certain instance sizes, stopped-instance counts, or managed services may be limited).

​
What to expect: limits and why they exist

KodeKloud Playgrounds enforce resource and service limits to balance cost and availability for all users. Typical constraints include:
  • Instance families and sizes limited (commonly up to t3.medium or t3.micro depending on the playground)
  • A cap on the number of stopped instances
  • Session duration limits (example: 180 minutes)
  • Some managed or high-cost services (like SageMaker) may be restricted or unavailable
  • Terminate-on-shutdown behavior instead of stop for some instances
These restrictions prevent abuse and ensure fair access for the community, while still allowing realistic, hands-on practice.
A dark-themed KodeKloud webpage screenshot showing two service panels for EC2 (Elastic Compute Cloud) and AWS Lambda with lists of allowed features and resource limits. The top navigation and a "Launch now" button are also visible.

​
Typical limits (example)

​
Quick walkthrough — launching an AWS sandbox and an EC2 instance

  1. Sign in to KodeKloud and navigate: Profile → Practice → All Playgrounds → AWS → Launch Now.
    The playground provisions a sandbox and provides a console URL, a temporary username, and a password.
  2. Open the provided console URL and sign in as the labs user. You will have an AWS Console session for the duration of the sandbox.
  3. Launch an EC2 instance (typical steps):
    • Open EC2 → Instances → Launch instances
    • Choose an AMI (Amazon Linux 2023 is a common choice)
    • Select an allowed instance type (for example, t3.micro)
    • Configure storage, security groups, and subnet
    • Create/download a key pair (PEM or ED25519/RSA options may be shown)
When you create a key pair, the private key is downloaded to your browser. Store it safely — you’ll need it to SSH if the instance has a public IP and the security group allows SSH access.
A screenshot of the AWS EC2 "Launch an instance" console showing AMI options with Amazon Linux 2023 selected. The right-hand Summary panel shows instance details (count, storage, security group) and a "Launch instance" button.

​
Access methods for instances

If a public IP is not available or you prefer not to expose instances publicly, common access methods include:
  • Bastion host (jump box) in a public subnet
  • EC2 Instance Connect (browser-based SSH) — may require specific IAM permissions
  • AWS Systems Manager Session Manager — supports shell access without an SSH key
  • Serial console (for troubleshooting) — may require additional configuration
Some of these endpoints or provisioning steps can take several minutes; the console may display notices that setup could take up to ~15 minutes.
If you encounter permission errors (for example, with Image Builder, Instance Connect, or IAM-restricted APIs), first check the playground limits and available IAM permissions. Many errors stem from attempting restricted actions or exceeding quotas.
The playground console also includes resource and status panels that summarize running instances, key pairs, volumes, and other counts. If you see API errors or cost data that cannot load, these are usually UI-side limitations and don’t necessarily affect your ability to practice core tasks.
A screenshot of the Amazon AWS EC2 console (US N. Virginia) showing the Resources panel with counts like 1 running instance, key pairs, volumes, and some API Error badges. The right side shows EC2 cost data unable to load, a service health error, and a prominent "Launch instance" button.

​
Best practices and troubleshooting tips

  • Review the playground limits page before planning resource-heavy experiments.
  • Choose smaller instance types for routine practice to avoid hitting quotas.
  • Use Systems Manager Session Manager for access when SSH keys or public IPs are not available.
  • Save private keys securely and do not share them.
  • If a service is unavailable, check for an informational note in the playground UI — restricted managed services are a common reason.
  • If you need longer sessions or larger resources, consider using your own AWS account (be mindful of costs and clean up resources afterward).
Enjoy the playgrounds — they provide a convenient, realistic environment to practice AWS skills without needing your own AWS account. Just remember to confirm the stated limits before planning heavier experiments.

Watch Video