DEV Community: nⓐtⓐLiⓔ

Things to consider before using EKS Auto Mode

nⓐtⓐLiⓔ — Tue, 03 Dec 2024 07:35:35 +0000

AWS just announced the new AWS EKS Auto Mode feature that automatically manages the scaling of the EKS nodes in an Amazon EKS cluster. This is a great start for the beginning of abstracting k8s management. I heard a lot about this feature (from the K8s community) at the beginning of the K8s Era, but it seems like it is slowly becoming a reality only now.

So far, it feels like AWS EKS Auto Mode is a great option if your team is trying to scale the EKS env but doesn't want to spend a lot of time understanding how to scale EKS nodes, basically hands-off teams.

But there are still some things to consider before enabling this, the main one is Cost.

What is the price for AWS Auto Mode?

While using AWS EKS Auto Mode, you are paying for:

AWS EKS cluster (per hour fee) based on the cluster’s Kubernetes version. See the screenshot from the official AWS Documentation.

AWS EKS Auto Mode (per hour fee) for the duration and type of Amazon EC2 instances launched and managed by EKS Auto Mode (for Worker Nodes). Pricing can be found in the AWS pricing calculator. Below is an example of the price in us-east-1 popular general purpose instances usage (m5.2xlarge, m5.24xlarge). Simply, there are extra management fees for the used EC2 instance type.

EC2 charges that are still applied are:

Storage: EC2 instances come with root volumes, and additional EBS volumes are commonly used for persistent storage. EBS storage (like gp3 or io1) comes with its pricing for storage capacity and IOPS.
Elastic IP addresses: If you are using any Elastic IPs (for external access to worker nodes or load balancers), these are charged when not in use.

Additional EKS Costs that are staying the same:

EBS Storage: Costs for persistent storage depend on volume type and size, as well as snapshot charges for backups.
Fargate: For serverless Kubernetes (Fargate), you pay based on CPU and memory usage, which is cost-effective for variable workloads but may be pricier for steady workloads.
Networking: Charges for VPC and cross-AZ/region data transfer.
IAM Roles: While free, complex IAM configurations could incur additional costs.
Add-ons (e.g., Helm charts, Route 53, third-party integrations)

How is EKS Auto Mode working within Spot instances ( and spot reservations)?
AWS EKS Auto Mode does support Spot Instances, but it doesn't provide native, flexible integration within a single node group. Instead, users must create separate node groups for On-Demand and Spot Instances, which require more management and configuration.

There are other considerations about the usage and pricing for AWS EKS Auto Mode.
I answered some of them, but do let me know if I missed something.

Can we leverage the Amazon EC2 instance purchase options with EKS Auto Mode?
Yes, absolutely. On-Demand, Compute Savings Plans, and Spot Instances plans are all included.

Is EKS Auto Mode similar to managed Karpenter? Or is it the same feature?
Unlike Karpenter, EKS Auto Mode also manages and patches core EKS addons (CoreDNS, kube-proxy, VPC CNI) and other EBS CSI controllers and AWS load balancer controllers. Basically, as users, we are now managing fewer things.

Can I use AWS Autoscaler with EKS Auto mode?
[Update, thank you @bryantbiggs]: EKS Auto Mode uses Karpenter for compute autoscaling, which automatically provisions and scales EC2 instances based on demand. However, pod autoscaling (such as Horizontal Pod Autoscaler - HPA) must still be configured by the user.

Can EKS Auto Mode be enabled on the current clusters?
Yes, this AWS official article shows steps on how to do it manually, so you can get an idea, but do not follow this - use any IaC to enable it.

If EKS Auto Mode is enabled on the current clusters, can I disable it?
Yes, here is the AWS official article that shows how to disable it.

Does EKS Auto Mode simplify the IAM role and policy management for worker nodes?
Yes, by handling the creation and assignment of required roles and permissions automatically.
EKS Auto Mode automatically provisions:

the necessary IAM roles for EC2 instances (worker nodes) during node group creation.
applies predefined, least-privileged policies to the roles, ensuring worker nodes have only the required permissions to interact with EKS and AWS services.
manages IAM roles and permissions for core add-ons like CoreDNS, kube-proxy, and VPC CNI, reducing configuration overhead.
If customization is needed, as users we can still modify IAM roles and policies attached to worker nodes via the AWS Management Console, CLI, or SDK.

Terraform support?
It is coming. The terraform PR is on the way. Tag v5.79.0.
Support for aws-terraform modules is out from v20.31.0.

In short, AWS EKS Auto Mode is great for simplifying management, but it’s important to understand the pricing structure and consider your scaling needs.

Exploring the "Requester Pays" Feature for AWS S3 Buckets. Use Cases and Cost Analysis

nⓐtⓐLiⓔ — Wed, 08 May 2024 01:55:30 +0000

As infrastructure architects, we need to manage cloud resources with cost in mind, so understanding features like Requester Pays for AWS S3 is useful for cost optimization.

The Requester Pays feature of AWS S3 buckets is a good option to explore in "some cases" because it can potentially help with optimizing the cost of AWS S3 buckets.

Note: Please keep in mind that I used the term "some cases" because different use cases will likely require different resources and configurations.

Examples of such practical cases include:

Large Data Sets: Companies provide large datasets used for training machine learning (ML) models.

Benefit from enabling Requester Pays because they can reduce the high costs associated with accessing training datasets for AI and ML.

Commercial Distribution: Platforms that offer video editing directly in the cloud, where users stream large video files during the editing process (an example of such an app mostly likely already installed on your phone :) )

Benefit: Users will pay for the data they consume, and the platform will provide high-performance editing tools, saving on costs with usage for scalable service offerings.

Cross-Account Access: This is when users from other AWS accounts frequently access S3 objects.

Benefit: Users will pay the cross-account data transfer costs

How to enable the Requester Pays feature

Using Terraform, we can create the aws_s3_bucket_request_payment_configuration resource for an AWS S3 bucket. For the payer attribute (described later in this blog), we can select BucketOwner or Requester.

BucketOwner is the default setting for all new S3 buckets if no specific request payment configuration is applied.

Simple terraform code snippet ( of course, not production-friendly):

provider "aws" {
  region = "us-east-1"
}

variable "request_payer" {
  description = <<-EOD
    (Optional) Specifies who should bear the cost of Amazon S3 data transfer. 
    It can be either BucketOwner or Requester. By default, the owner of the S3 
    bucket would incur the costs of any data transfer. See Requester Pays 
    Buckets developer guide for more information.
  EOD
  type        = string
  default     = "Requester" 
}

resource "aws_s3_bucket" "this" {
  bucket        = "in-n-out-editme"
  force_destroy = false
  tags = {
    foo = "bar"
  }
}

resource "aws_s3_bucket_request_payment_configuration" "this" {
  bucket = aws_s3_bucket.this.id
  payer  = var.request_payer
}

output "bucket_name" {
  value = aws_s3_bucket.this.bucket
}

output "requester_pays_status" {
  value = aws_s3_bucket_request_payment_configuration.this.payer
}

Note: aws_s3_bucket_request_payment_configuration resource cannot be used with S3 directory buckets.

View in the AWS Console UI

The result of the above code (Enabled feature) can be found in the AWS console under the S3 Bucket overview and navigating to the Requester Pays UI view (refer to the screenshot below)

Understanding the Cost breakdown

Charges are handled differently in AWS S3 when using the Requester Pays feature compared to the standard S3 pricing model.

Normally, the bucket owner pays for all data transfer and request charges associated with the bucket. However, in the Requester Pays model, these costs are shifted to the person or service accessing the data (requester).

Bucket Owner Costs:

Storage: the data stored in the S3 bucket regardless of access patterns.

Requester Costs:

Data Transfer Out: When data is transferred from the S3 bucket to the internet or another AWS region, the requester pays for the data transfer costs.

S3 Requests: for initiated operations, such as PUT, GET, POST, and LIST.

Including when request authentication fails and the request is anonymous, both resulting in an HTTP 403 error.

How are Requesters billed?

When accessing the Requester Pays S3 buckets, requesters must include billing details: x-amz-request-payer: requester in the request header. This indicates that they agree to pay for the data transfer and request costs. AWS utilizes this header to ensure that costs are billed to the requester.

This setup prevents unauthorized requesters from being charged without their consent.

Requesters also need IAM permissions to ensure that only authorized users can access the data.

How to View Payment Split in AWS Console

Here are the steps to check how the payment is split for Requester Pays S3 buckets:

*Billing and Cost Management Dashboard
*

Navigate to the Billing and Cost Management Dashboard.
Use the Cost Explorer to get detailed information about S3.
Go to Cost Explorer: filter your data by service ( which in this case would be Amazon S3)

Detailed Billing Reports:

Enable Detailed Billing Reports with Resources and Tags to see detailed information about your S3 usage. If you have Requester Pays enabled, these reports will include information on requester-initiated transactions.

Reports can be set to show which bucket incurred which costs so you can see the split between what you pay as the bucket owner (for storage and owner-initiated data transfers) and what requesters pay (for their data transfers).

Tagging:

Add cost allocation tags on your S3 buckets. Once tagged, activate these tags in the Cost Allocation Tag section of the Billing Dashboard to include them in your reports.

Visualizing with AWS QuickSight Integration:

It is possible to download Detailed Billing Reports reports from the S3 bucket specified and analyze them using tools like Amazon QuickSight.

Summary

When implementing the Requester Pays model on an S3 bucket, it's important to ensure that potential data users are aware that they will incur charges for their data access.

It is important to Monitor Access to your S3 buckets at all times. Use S3 access logs or AWS CloudTrail to monitor who is accessing your S3 buckets to manage data transfer and associated costs (maybe one day I will write a blog about this setup)

Understanding the Requester Pays model allows all of us, AWS users, to:

deploy cost-effective data-sharing solutions in AWS
manage costs associated with data stored in AWS S3
help to build cost-effective services aligned with organizational or project goals.

Official documentation link:

https://docs.aws.amazon.com/AmazonS3/latest/userguide/RequesterPaysBuckets.html?icmpid=docs_amazons3_console

Navigating AWS IAM Policies: Restricting Access to Billing and Cost Management

nⓐtⓐLiⓔ — Mon, 25 Dec 2023 08:13:26 +0000

You most likely heard that AWS has retired AWS Identity and Access Management (IAM) actions for the Billing, Cost Management, and Account Consoles under the service prefix aws-portal and two actions under the purchase order namespace. These have been replaced by more granular, service-specific permissions, enhancing control over Billing, Cost Management, and Account Services access. As a result, if your AWS organization hadn't previously set up strict access controls, you might now find that all members can view sensitive financial information such as billing, taxes, and cost data.

Not every employee in an organization needs, or should have, access to sensitive financial details like billing and taxes. Not every employee should have access to sensitive financial details like billing and taxes. This kind of information is typically meant for the eyes of specific departments, such as Finance or Accounting.

One of the ways to address this is to create a policy to restrict access to Billing, Cost Management, Account Services, and Tax information. A practical approach is to develop a policy that specifically limits access and apply it across the organization at the account level. It’s important to note that the implementation of this policy will vary based on your organization’s account setup, whether it’s IAM policy-based, uses SSO with permission sets, or Service Control Policies (SCP). For more detailed guidance on these setups, refer to the AWS documentation.

*IAM Policy Example: *
Here’s an IAM policy snippet designed to deny access to various billing and cost-related actions across AWS resources:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyBillingViewOnHomepage",
            "Effect": "Deny",
            "Action": [
                "aws-portal:View*",
                "billing:*",
                "purchase-orders:*",
                "tax:*",
                "payments:*",
                "cur:*",
                "ce:*"
            ],
            "Resource": "*"
        }
    ]
}

ONE MORE TIP:

Unchecking “Linked Account Access” in Cost Management Preferences under Billing and Cost Management might seem like a quick fix to restrict access to cost and usage data in Cost Explorer and the AWS Console HomeView. However, this doesn’t completely solve the issue, as users will still see a link to access Bills, Tax information, etc. Therefore, I recommend implementing a comprehensive IAM policy rather than relying on this setting.