The following IAM policies use condition keys to create tag-based restriction.

• Before you use tags to control access to your AWS resources, you must understand how AWS grants access. AWS is composed of collections of resources. An Amazon EC2 instance is a resource. An Amazon S3 bucket is a resource. You can use the AWS API, the AWS CLI, or the AWS Management Console to perform an operation, such as creating a bucket in Amazon S3. When you do, you send a request for that operation. Your request specifies an action, a resource, a principal entity (user or role), a principal account, and any necessary request information.

• You can then create an IAM policy that allows or denies access to a resource based on that resource's tag. In that policy, you can use tag condition keys to control access to any of the following:

• Resource – Control access to AWS service resources based on the tags on those resources. To do this, use the_ aws:ResourceTag/key-name_ condition key to determine whether to allow access to the resource based on the tags that are attached to the resource.

ResourceTag condition key

Use the _aws:ResourceTag/tag-key _condition key to compare the tag key-value pair that's specified in the IAM policy with the key-value pair that's attached to the AWS resource. For more information, see Controlling access to AWS resources.

You can use this condition key with the global aws:ResourceTag version and AWS services, such as ec2:ResourceTag. For more information, see Actions, resources, and condition keys for AWS services.

• The following IAM policy allows users to start, stop, and terminate instances that are in the test application tag

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ec2:StartInstances",
                "ec2:StopInstances",
                "ec2:TerminateInstances"
            ],
            "Resource": "arn:aws:ec2:*:3817********:instance/*",
            "Condition": {
                "StringEquals": {
                    "ec2:ResourceTag/application": "test"
                }
            }
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeInstances",
                "ec2:DescribeTags"
                "ec2:Describedescribe-instance-status"
            ],
            "Resource": "*"
        }
    ]
}

Create the policy and attach the policy to user or role.

• Created 2 instance one is with application tag and other is non tagged.

You can see the tagged instance are able to perform Start and Stop action using the IAM resources tag condition.
non-tagged instance we are not able to perform the same.

• check the status of the instance

• perform the Termination action

reference commands

aws ec2 start-instances --instance-ids "instance-id"

aws ec2 stop-instances --instance-ids "instance-id"

aws ec2 describe-instance-status  --instance-ids "instance-id"

aws ec2 terminate-instances --instance-ids "instance-id"

String condition operators

String condition operators let you construct Condition elements that restrict access based on comparing a key to a string value.

• StringEquals - Exact matching, case sensitive

• StringNotEquals - Negated matching

• StringEqualsIgnoreCase - Exact matching, ignoring case

• StringNotEqualsIgnoreCase - Negated matching, ignoring case

• StringLike - Case-sensitive matching. The values can include multi-character match wildcards (*) and single-character match wildcards (?) anywhere in the string. You must specify wildcards to achieve partial string matches.
  Note
  If a key contains multiple values, StringLike can be qualified with set operators—ForAllValues:StringLike and ForAnyValue:StringLike.

• StringNotLike - Negated case-sensitive matching. The values can include multi-character match wildcards (*) or single-character match wildcards (?) anywhere in the string.

If we need to fetch the S3 bucket storage size we need to trace via individual bucket under metrics we get the storage size.
on one go use the below script to get the bucket name with storage size.

s3list=`aws s3 ls | awk  '{print $3}'`
for s3dir in $s3list
do
    echo $s3dir
    aws s3 ls "s3://$s3dir"  --recursive --human-readable --summarize | grep "Total Size" 
done

1. create the .sh file
2. copy the code on the file
3. Excecute the script to get the s3 bucket details

In this blog, i write about SLI, SLA, SLO . I got a refreshing session from a podcast https://open.spotify.com/episode/2Ags7x1WrxaFLRd3KBU50K?si=vbYtW_YVQpOi8HwT9AOM1g. This blog is about that.

In the world of service reliability and performance, the terms SLO, SLA, and SLI are often used interchangeably but have distinct meanings. This blog explains these terms in detail, their importance, and how they relate to each other with practical examples.

1. What are SLIs, SLOs, and SLAs?

Service Level Indicators (SLIs)

An SLI is a metric that quantifies the level of service provided by a system. It measures specific aspects of performance or reliability, such as response time, uptime, or error rate.

Example:

• Percentage of successful HTTP requests over a time window.
• Average latency of API responses.

Service Level Objectives (SLOs)

An SLO is a target value or range for an SLI. It defines what “acceptable” performance or reliability looks like from the perspective of the service provider or user.

Example:

• “99.9% of HTTP requests must succeed within 500ms.”
• “The application should have 99.95% uptime per quarter.”

Service Level Agreements (SLAs)

An SLA is a formal contract between a service provider and a customer that specifies the agreed-upon SLOs and the consequences of failing to meet them, such as penalties or compensations.

Example:

• “If the uptime drops below 99.5% in a calendar month, the customer will receive a 10% credit on their monthly bill.”

2. Relationship Between SLIs, SLOs, and SLAs

• SLIs are the metrics measured.
• SLOs are the goals or benchmarks derived from SLIs.
• SLAs are agreements that formalize SLOs and include penalties or incentives.

SLI: Average latency of API requests.
SLO: 95% of API requests should have latency under 200ms.
SLA: If latency exceeds the SLO for two consecutive weeks, the provider will issue service credits.

3. Practical Examples

Example 1: Web Hosting Service

• SLI: Percentage of time the website is available.
• SLO: The website must be available 99.9% of the time per month.
• SLA: If uptime falls below 99.9%, the customer will receive a refund of 20% of their monthly fee.

Example 2: Cloud Storage Service

• SLI: Time taken to retrieve a file from storage.
• SLO: 95% of retrieval requests must complete within 300ms.
• SLA: If retrieval times exceed 300ms for more than 5% of requests in a billing cycle, customers will get free additional storage for the next month.

Example 3: API Service

• SLI: Error rate of API responses.
• SLO: Error rate must be below 0.1% for all requests in a day.
• SLA: If the error rate exceeds 0.1% for more than three days in a row, the customer is entitled to a credit worth 5% of their monthly subscription fee.