Welcome to the first lesson of Developing with Core AWS Services. In this lesson, you will learn how AWS credentials work on EC2 instances and how IAM roles make it possible for your code to securely access AWS services. This is a foundational topic for anyone who wants to build or automate tasks using AWS.

When you launch an EC2 instance, you often want it to interact with other AWS services, such as S3, DynamoDB, or Lambda. To do this, the instance needs credentials — just like you need a username and password to log in to a website. However, hardcoding credentials (putting them directly in your code) is risky and not recommended. If someone gets access to your code, they could also get your credentials and misuse your AWS account.

In this lesson, you will see how AWS provides a secure and automatic way for EC2 instances to get credentials using IAM roles and the EC2 metadata service.

Before we dive in, let's quickly remind ourselves what AWS credentials are and how SDKs use them.

AWS credentials are a pair of keys (an access key and a secret key) that allow you to make API calls to AWS services. In previous lessons, you may have seen how to use these credentials with the AWS SDK for Python, called boto3. The SDK uses these credentials to sign requests and prove your identity to AWS.

For example, you might have seen code like this:

Here, boto3 automatically looks for credentials in several places, such as environment variables, configuration files, or the EC2 metadata service (which we'll cover next).

Hardcoding credentials in your code is not safe. Instead, AWS recommends using IAM roles, especially for EC2 instances.

When you launch an EC2 instance, AWS provides a special service called the metadata service. This service is only accessible from inside the instance. It provides information about the instance, such as its ID, type, and, most importantly, temporary credentials if an IAM role is attached.

The metadata service is available at a special IP address: http://169.254.169.254/latest/meta-data/

You can use simple tools like curl to access this information from within the instance. For example:

This command returns the instance ID, such as:

The metadata service provides much more than just the instance ID. You can explore various endpoints to get information about the instance's AMI, security groups, network interfaces, and more. Try running these commands directly on an EC2 instance to see the full range of available metadata:

Running these commands directly will give you a complete view of what AWS-related information is accessible from within your instance.

If your instance has an IAM role attached, you can also get temporary credentials from the metadata service. These credentials are rotated automatically and are only valid for a short time, making them much safer than hardcoded keys.

An IAM role is a set of permissions that you can assign to AWS resources. When you attach an IAM role to an EC2 instance, AWS automatically provides temporary credentials to that instance through the metadata service.

This means your code running on the instance can access AWS services securely, without you ever needing to put credentials in your code.

For example, if you attach a role that allows access to S3, any code running on the instance can use boto3 to interact with S3, and the SDK will automatically use the credentials provided by the metadata service.

This is how AWS keeps your credentials safe and makes development easier.

Let's walk through a simple example that shows how an EC2 instance can access its own metadata and check for IAM role credentials. We'll build this step by step.

When you launch an EC2 instance, you can provide a user data script. This script runs automatically when the instance starts. Here's a simple Bash script that prints out some instance information and checks for an IAM role:

Explanation:

• The script uses curl to fetch information from the metadata service.
• It prints the instance ID, AMI ID, instance type, and region.
• It checks if an IAM role is attached by trying to access the iam/security-credentials/ endpoint.
• If a role is found, it prints the role name; otherwise, it says no role is attached.

Sample Output:

Now, let's see how you can launch an EC2 instance and provide this script as user data using Python and boto3.

First, you need to load the script from a file:

Explanation:

• This function reads the contents of ec2_demo.sh (the script above) so it can be passed to the EC2 instance as user data.

Next, you need a function to get the latest Amazon Linux 2 AMI ID:

Explanation:

• This function uses the AWS Systems Manager Parameter Store to get the latest Amazon Linux 2 AMI ID.
• AWS automatically maintains these parameters with the most current AMI IDs for each region.
• This ensures you're always using an up-to-date AMI without hardcoding specific IDs.

Now you can launch the EC2 instance:

After the instance starts, you can retrieve the output of the user data script by checking the instance's console output:

Explanation:

• This function waits for the instance to start and then checks the console output for the results of your script.
• It looks for the markers EC2 DEMO START and EC2 DEMO END to find your script's output.

Sample Output:

If you attach an IAM role, you will see the role name instead of the "No IAM role attached" message.

In this lesson, you learned:

• Why EC2 instances need credentials to access AWS services.
• The risks of hardcoding credentials and why it's not recommended.
• How the EC2 metadata service provides instance information and, if available, IAM role credentials.
• How IAM roles allow EC2 instances to securely and automatically get temporary credentials.
• How to use a user data script and Python code to discover and display these credentials on a real EC2 instance.

You are now ready to practice these concepts in hands-on exercises. In the next section, you'll get to try launching EC2 instances, attaching IAM roles, and exploring the metadata service yourself. This will help you build a strong foundation for working securely and efficiently with AWS services from your EC2 instances.