DEV Community

Dipali Kulshrestha
Dipali Kulshrestha

Posted on

AWS Development Environment

#aws #architecture #security

Module Objectives

By the end of this module, participants will be able to:

  • Introduction
  • Set up a secure AWS development environment
  • Configure CLI & SDK access securely

Introduction: AWS Global Infrastructure

Key Concepts

AWS Regions

A Region is a geographical area with multiple, isolated Availability Zones

Examples: us-east-1, eu-west-1, ap-south-1

Developers choose Regions based on:

  • Latency
  • Compliance & data residency
  • Service availability

Availability Zones (AZs)

An AZ is one or more physically separate data centres within a Region

AZs are:

  • Connected via high-speed, low-latency links
  • Isolated to prevent failure propagation

Best practice:

Deploy applications across multiple AZs for high availability

Edge Locations

Used by services such as:

  • Amazon CloudFront
  • AWS WAF
  • AWS Shield

Purpose:

  • Reduce latency by serving content closer to users
  • Improve performance for global applications

Regional vs Global Services (Developer View)

Global services:

  • IAM
  • Route 53
  • CloudFront

Regional services:

EC2, Lambda, RDS, DynamoDB

1. AWS Development Environment – Overview

A controlled AWS setup that allows developers to:

  • Write, build, test, and deploy applications
  • Access AWS services securely
  • Use automation tools (CLI, SDK, IaC)

Typical Components

  • AWS Account (or sandbox)
  • IAM Users / Roles
  • AWS Management Console
  • AWS CLI
  • SDKs (Java, Python, Node.js, etc.)
  • CloudShell / Cloud9 (optional)
  • Source control (GitHub / CodeCommit)

2. AWS Account & Environment Setup

  • Why not to use root account for development. Root account has unrestricted access – IAM policies do NOT apply to root.

Common models:

  • Single Account (training / sandbox)
  • Multi-Account (prod, non-prod, dev) – mention AWS Organizations
  • Root Account – Best Practices
  • Enable MFA
  • Do not use root for daily tasks
  • Secure root credentials

7. Development Access Options

AWS Management Console

  • Browser-based
  • For learning, debugging, configuration

AWS CLI

  • Used for automation and scripting
  • Uses IAM credentials or roles

AWS SDKs

  • Used in application code
  • Automatically picks credentials from environment

Credential resolution order (important concept):

  • Environment variables
  • Shared credentials file
  • IAM role (EC2/Lambda)
  • Default profile

8. AWS CloudShell

  • Browser-based shell
  • Pre-configured AWS CLI
  • Uses IAM permissions automatically

Benefits

  • No local setup
  • Secure
  • Ideal for training labs

Lab: Configure AWS CLI Securely

Objective

Set up AWS CLI using IAM user credentials.

Steps

Install AWS CLI
Run:aws configure

Provide:
Access Key
Secret Key
Region

Verify:

aws sts get-caller-identity

Security Note

Explain .aws/credentials file and risks.

Hands on Lab Prerequisites:

pip3 install boto3
aws configure

Lab: Create script to list bucket(vi or any editor)

import boto3

def list_buckets():
    s3 = boto3.client('s3')
    response = s3.list_buckets()

    print("S3 Buckets:")
    for bucket in response['Buckets']:
        print(f"- {bucket['Name']}")

if __name__ == "__main__":
    list_buckets()
Enter fullscreen mode Exit fullscreen mode

3. IAM Fundamentals (Core Concepts)

IAM Components
Component Purpose
User Human or application identity
Group Collection of users
Role Assumed identity with temporary credentials
Policy Permissions document (JSON)

Authentication vs Authorization

Authentication: Who are you?
Authorization: What are you allowed to do?

4. IAM Policies – Deep Dive

Policy Types

  • AWS Managed Policies
  • Customer Managed Policies
  • Inline Policies

Policy Structure (JSON)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "*"
}
]
}

Key Elements Explained

Effect: Allow / Deny

Action: API calls

Resource: ARN

Condition (advanced, optional)

Tip: Explicit Deny always wins.

5. IAM Best Practices

Security Best Practices

  • Least privilege
  • Use roles instead of long-term credentials
  • Enable MFA
  • Rotate credentials
  • Use managed policies where possible

What NOT to Do

❌ Hardcode access keys in code
❌ Use IAM users for EC2/Lambda
❌ Share credentials

6. IAM Roles

What is an IAM Role?

  • An identity assumed temporarily
  • Uses STS (Security Token Service)
  • No permanent credentials

Common Role Use Cases

  • EC2 accessing S3
  • Lambda accessing DynamoDB
  • Cross-account access
  • CI/CD pipelines

Trust Policy vs Permission Policy

Trust policy: Who can assume the role

Permission policy: What the role can do

Hands-On Labs (Step-by-Step)

Lab: Create IAM Users and Groups

Objective

Create a developer IAM user with controlled permissions.

Steps

  1. Login as root / admin
  2. Open IAM Console
  3. Create Group: Developers
  4. Attach policy: AmazonS3ReadOnlyAccess
  5. Create IAM User with Access type: Console + Programmatic
  6. Add user to Developers group
  7. Enable MFA for the user
  8. Test login

Validation

  • User can list S3 buckets
  • User cannot create EC2 instances

Lab: Create and Test IAM Role for EC2

Objective

Allow EC2 instance to access S3 without access keys.

Steps

  1. Create IAM Role
  2. Trusted entity: EC2
  3. Attach policy: AmazonS3ReadOnlyAccess
  4. Launch EC2 instance
  5. Attach role during launch
  6. SSH into EC2
  7. Run: aws s3 ls

Expected Result
S3 list works without configuring credentials

9. Common Developer IAM Scenarios

Lambda → DynamoDB

ECS task → SQS

CI/CD pipeline → CloudFormation

Cross-account role for deployment

Tie these back to roles, not users.

Next

dipalikulshrestha

Compute options for Developers

Dipali Kulshrestha ・ Jan 10

#architecture #aws #devops

Top comments (0)