DEV Community: Andy Tan

Installing the AWS CLI, kubectl and eksctl on macOS

Andy Tan — Fri, 04 Sep 2026 14:25:22 +0000

Overview

Working with Amazon Elastic Kubernetes Service (EKS) from a Mac takes three command-line tools, and they build on each other in the order below:

AWS CLI — authenticates you to AWS and is the tool every later step relies on for credentials and identity.
kubectl — the standard Kubernetes client, used to talk to the API server of an EKS cluster once one exists.
eksctl — a higher-level tool that creates and manages EKS clusters, driving CloudFormation underneath. The versions used in the source walkthrough were Kubernetes 1.30 (kubectl v1.30.8-eks-aeac579) and eksctl 0.207.0. Check the AWS documentation for current releases before copying version-pinned URLs — the S3 paths below embed both a version and a build date, and they change.

1. AWS CLI

1.1 Create an access key
Before installing anything, create an access key for the IAM user you intend to work as. In the AWS Management Console this is under IAM → Users → your user → Security credentials → Create access key. The console shows you the Access Key ID and the Secret Access Key once; the secret cannot be retrieved again afterwards, so store it somewhere safe at that moment.

Image note: the original article illustrates this step with screenshots of the IAM console's access-key creation screens. Those images are the author's and are not reproduced here — see the original post if you want the visual reference.
Security note: an IAM access key is a long-lived credential. Prefer a dedicated, least-privilege IAM user or, better, IAM Identity Center / SSO sessions where your organisation supports them, and rotate keys regularly.

1.2 Install or update the CLI
AWS ships a signed macOS installer package. Download it and install it system-wide:

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /

The same two commands also perform an in-place upgrade of an existing AWS CLI v2 installation — there is no separate update path.

1.3 Confirm the shell can find it
Check that the binary resolved onto your $PATH and reports a version:

which aws
aws --version

If which aws returns nothing, open a new terminal session so the shell re-reads its PATH, or add /usr/local/bin to it.

1.4 Configure credentials
Run the interactive configuration and supply the access key you created in step 1.1, along with a default region and output format:

aws configure

AWS Access Key ID     [****************I66M]:
AWS Secret Access Key [****************o4pv]:
Default region name   [us-east-1]:
Default output format [json]:

The bracketed values are the existing settings, shown masked; pressing Return keeps them. Answers are written to ~/.aws/credentials and ~/.aws/config.

1.5 Verify who you are
This call returns the identity AWS resolves your credentials to, and is the quickest way to confirm the CLI is working:

aws sts get-caller-identity

{
    "UserId":  "AIDAxxxxxxxxxxxxxxxxx",
    "Account": "123456789012",
    "Arn":     "arn:aws:iam::123456789012:user/your-user"
}

Make a note of this identity. The eksctl step further down requires that every command be run as the same IAM principal.

2. kubectl

AWS publishes kubectl binaries matched to each supported EKS Kubernetes version. The walkthrough targets Kubernetes 1.30.

2.1 Download the binary
Fetch the binary for your platform from the Amazon EKS S3 bucket. The path encodes the Kubernetes version, the build date and the CPU architecture — use arm64 in place of amd64 on Apple Silicon:

curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/1.30.8/2025-01-10/bin/darwin/amd64/kubectl

The source article's command line ends in kubectl.sha256, which downloads the checksum file rather than the binary itself. The checksum is useful — download it as well and verify with openssl sha1 -sha256 kubectl — but the binary is the file without the .sha256 suffix, as written above.

2.2 Make it executable and put it on your PATH

chmod +x ./kubectl

If you already have another kubectl installed, the recommended approach is a per-user copy in $HOME/bin placed ahead of everything else on the PATH, so it takes precedence without disturbing the existing installation:

mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$HOME/bin:$PATH

Persist that PATH entry in your shell's startup file so it survives new terminal windows:

echo 'export PATH=$HOME/bin:$PATH' >> ~/.bash_profile

~/.bash_profile only applies if your login shell is bash. macOS has defaulted to zsh since Catalina — in that case append the same line to ~/.zshrc instead. Check with echo $SHELL.

2.3 Verify

kubectl version --client

Client Version: v1.30.8-eks-aeac579
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3

The -eks- suffix confirms you are running the AWS-published build rather than an upstream one.

3. eksctl

3.1 Prerequisites
eksctl creates clusters by provisioning CloudFormation stacks, so the IAM principal you use needs permission to work with Amazon EKS IAM roles, service-linked roles, AWS CloudFormation, VPCs and the networking resources that go with them. A user without those permissions will fail partway through cluster creation rather than at the start.
All steps must be carried out as the same user. Re-run the identity check if you are unsure which principal the CLI is currently using:

aws sts get-caller-identity

3.2 Install via Homebrew
On macOS the maintained route is the Weaveworks Homebrew tap:

brew tap weaveworks/tap
brew install weaveworks/tap/eksctl

3.3 Verify

eksctl version

0.207.0

Putting it together

At this point all three tools are installed and the AWS CLI holds working credentials. The usual next step is to create a cluster with eksctl, which also writes the cluster's connection details into your kubeconfig so that kubectl can reach it. If you are attaching to a cluster that already exists, the AWS CLI can generate that kubeconfig entry directly:

aws eks update-kubeconfig --region us-east-1 --name your-cluster-name
kubectl get nodes

A successful kubectl get nodes confirms that all three pieces — credentials, Kubernetes client, and cluster access — are wired together correctly.

Fully Managed DeepSeek-R1 Arrives on Amazon Bedrock

Andy Tan — Fri, 04 Sep 2026 14:06:12 +0000

Abstract
DeepSeek-R1 is now officially available on Amazon Bedrock and can be accessed through Bedrock Marketplace and the Custom Model Import feature. With its robust security controls and reasoning capabilities, the model is already serving thousands of enterprise customers. Amazon Web Services recently added a serverless option, further simplifying deployment. This article explains how to use DeepSeek-R1 securely in Amazon Bedrock and provides a practical walkthrough.

1. Key Advantages: Fully Managed and Enterprise-Grade Security

No infrastructure to manage
DeepSeek-R1 is offered as a fully managed service through Amazon Bedrock. Users do not need to operate the underlying infrastructure; they can integrate the model through a single API and quickly build generative AI applications.
Enterprise-grade security

Data privacy: User inputs and model outputs are not shared with third parties by default. Encryption at rest, encryption in transit, and fine-grained access control through IAM policies are supported.
Compliance certifications: The service aligns with multiple industry security standards, supporting compliant AI deployment at scale.

Capabilities across multiple use cases DeepSeek-R1 is available under the MIT open-source license. It is strong at complex reasoning, code generation, and natural-language understanding, making it suitable for intelligent decision support, software development, mathematical problem solving, data analysis, and knowledge management.

2. Deployment Considerations
When deploying DeepSeek-R1, pay particular attention to the following security practices:

Data security
Use Amazon Bedrock's built-in monitoring and cost-control capabilities to keep data under control throughout the workflow and reduce the risk of sensitive-information exposure.
Responsible AI
Use Amazon Bedrock Guardrails for content filtering and policy management:

Block harmful content, such as violence or biased language.
Define custom filters for sensitive information, such as national identification and bank-card numbers.
Use context-aware controls to reduce model hallucinations.

Model evaluation Use Amazon Bedrock model-evaluation tools to select the best model with automated metrics (such as accuracy and robustness) or human evaluation (such as consistency with brand voice). You can validate performance with built-in or custom datasets.

3. Practical Guide: From Access to Invocation
3.1 Enable model access

Sign in to the Amazon Bedrock console, open the "Model access" page, and request access to DeepSeek-R1.
In "Playgrounds," choose Chat/Text mode and select DeepSeek-R1 as the model category to test it online. Example prompt (to test reasoning): PLAINTEXT

A family has $5,000 to save for their vacation... (example from the original article)

3.2 API invocation examples
AWS CLI

aws bedrock-runtime invoke-model \
    --model-id us.deepseek-r1-v1:0 \
    --body "{\"messages\":[{\"role\":\"user\",\"content\":\"...\"}]}" \
    --region us-west-2 \
    invoke-model-output.txt

PYTHON SDK

import boto3
client = boto3.client("bedrock-runtime", region_name="us-west-2")
response = client.converse(
    modelId="us.deepseek.r1-v1:0",
    messages=[{"role": "user", "content": [{"text": "Describe 'hello world'."}]}]
)
print(response["output"]["message"]["content"][0]["text"])

3.3 Configure Guardrails

In the console, create protection rules under "Safeguards," including keyword filters, denied topics, and blocked-response templates.
Validate the protections through repeated tests to ensure generated content complies with business policies.

4. Supported Regions and Pricing

Currently available regions: US East (N. Virginia), US East (Ohio), and US West (Oregon).

5. Conclusion
DeepSeek-R1's fully managed capabilities, combined with Amazon Bedrock's security tools, give enterprises an efficient and dependable option for deploying AI. Developers can experience the model directly through the Bedrock console.

Amazon Bedrock Deployment Guide: From Environment Setup to Production Operations

Andy Tan — Tue, 30 Jun 2026 11:18:05 +0000

Amazon Bedrock, AWS's fully managed service for foundation models, makes it much easier to build and deploy generative AI applications through a model-as-a-service (MaaS) approach. This guide outlines a structured deployment workflow that covers permissions, network architecture, model onboarding, API integration, and performance optimization, helping teams build AI services that are scalable, secure, and operationally reliable.

Core Benefits and Technical Context

Organizations typically choose Amazon Bedrock for the following reasons:

Resource isolation and elastic scalability: Dedicated compute capacity helps reduce contention with other workloads, while scaling policies can adjust capacity based on demand. Under the right conditions, this can improve cost efficiency significantly.
Security and compliance: Bedrock integrates with AWS security controls such as VPC networking and IAM, helping organizations meet strict security and compliance requirements, including standards such as SOC 2 Type II, HIPAA, and GDPR.
Operational simplicity: Because AWS manages the underlying infrastructure, teams can reduce deployment time and lower operational overhead compared with self-managed model serving stacks.

Pre-Deployment Preparation

2.1 AWS Account and Permission Setup

For better security, use a dedicated IAM user or role instead of the root account, and enable AWS CloudTrail for auditing and operational traceability.

Example IAM policy (JSON):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:*",
        "ec2:Describe*",
        "s3:GetObject"
      ],
      "Resource": "*"
    }
  ]
}

Note: In production environments, always follow the principle of least privilege and scope Resource permissions as narrowly as possible.

2.2 Local Environment Configuration

Install and configure the AWS CLI (version 2.15 or later is recommended) so that you can manage resources from the command line.

aws configure
# Enter your Access Key ID, Secret Access Key, Region (for example, us-west-2), and preferred output format (such as json)

2.3 Network and Storage Architecture

A three-tier architecture is commonly recommended to support high availability and security:

Frontend layer: Use an Application Load Balancer (ALB), ideally protected by AWS WAF against common web threats.
Application layer: Deploy Bedrock-related application components across multiple Availability Zones (AZs) for resilience.
Data layer: Use Amazon S3 for model artifacts, logs, and intermediate data. Where appropriate, use VPC endpoints or PrivateLink to reduce public internet exposure.

Model Deployment Workflow

3.1 Model Preparation and Conversion

If you plan to work with a custom model such as DeepSeek-R1, prepare the model artifacts in a format compatible with your deployment pipeline, such as FP16 or FP8 where applicable.

Example conversion code:

import torch
from deepseek_r1.converter import BedrockExporter

model = torch.load('deepseek_r1_base.pt')
exporter = BedrockExporter(
    framework='pytorch',
    output_path='s3://model-bucket/deepseek/',
    precision='fp16'  # supports fp32/fp16/bf16
)
exporter.convert(model)

It is generally recommended to package model artifacts as a .tar.gz file and keep the package size below 50 GB.

3.2 Deployment Through the Console or API

You can deploy model-related resources through the Bedrock console or via API-driven automation.

Example API workflow:

import boto3

bedrock = boto3.client('bedrock-runtime', region_name='us-west-2')

response = bedrock.create_model(
    model_name='deepseek-r1-prod',
    base_model_identifier='deepseek-ai/deepseek-r1-6b',
    inference_configuration={
        'preferred_compute_type': 'gpu_t4',
        'min_worker_count': 2,
        'max_worker_count': 10
    }
)

3.3 Auto Scaling Strategy

To balance responsiveness and cost efficiency, define scaling rules such as the following:

Scale out when: Request queue depth exceeds 50, or latency rises above 2 seconds.
Scale in when: CPU utilization remains below 30% for 5 minutes.
Cooldown period: 300 seconds to avoid rapid scaling oscillation.

API Integration Patterns

4.1 Basic Text Generation

Use the invoke_model API for synchronous inference requests.

import boto3
import json
from botocore.config import Config

bedrock_config = Config(
    retries={'max_attempts': 3, 'mode': 'adaptive'},
    read_timeout=60
)
client = boto3.client('bedrock-runtime', config=bedrock_config)

response = client.invoke_model(
    modelId='deepseek-r1-prod',
    body=json.dumps({
        "prompt": "Explain the basic principles of quantum computing",
        "max_tokens": 512,
        "temperature": 0.7
    })
)
print(json.loads(response['body'].read())['generation'])

4.2 Streaming Responses and Multi-Turn Conversations

Streaming output: Use invoke_model_with_stream to deliver responses incrementally and improve the user experience.
Conversation handling: Use Bedrock conversation-oriented APIs or your own session layer to preserve context for assistants, customer support bots, and similar use cases.

4.3 Batch Processing Optimization

For non-real-time workloads, dynamic batching can improve throughput substantially. A batch size of 32 to 64 requests is often a practical starting point.

Performance Optimization and Monitoring

5.1 Performance Tuning Approaches

Model quantization: Moving from FP32 to FP16 or FP8 can reduce memory usage and improve inference speed.
Caching: Integrate ElastiCache Redis and apply an LRU strategy to frequently repeated queries.
Asynchronous processing: Route non-real-time requests through Amazon SQS to decouple frontend traffic from backend inference workloads.

5.2 Example Benchmark Targets

Metric Test Method Target
Time to First Token (TTFT) Empty request test < 800 ms
Throughput 100 concurrent requests sustained for 5 minutes > 80 TPS
Error rate Measured across 1,000 consecutive requests < 0.1%

5.3 CloudWatch Monitoring and Alerts

Set up alerts on key operational metrics such as:

CPUUtilization: Above 85% for 5 minutes -> trigger an SNS notification and scale out automatically.
ModelLatency: P99 latency above 1000 ms -> investigate load levels or switch traffic to a backup endpoint.
Invocations 4xx: More than 10 per minute -> inspect client request formatting and permissions.

Security, Compliance, and Cost Management

6.1 Data Protection

Network isolation: Use VPC endpoint policies to restrict traffic to private subnets where appropriate.
Encryption: Use AWS KMS customer-managed keys (CMKs) to protect sensitive data.
Auditability: Log API metadata to support investigation, traceability, and compliance review.

6.2 Cost Structure and Optimization

Running a model such as DeepSeek-R1 on Bedrock may involve compute, storage, and data transfer costs.

Optimization ideas include:

Use Lambda@Edge where low-latency global access is needed.
Cache frequent requests to reduce unnecessary inference traffic.
Review utilization regularly and adjust Reserved Instances or Savings Plans where applicable.

Troubleshooting

Symptom Possible Cause Recommended Action
503 Service Unavailable Capacity overload Increase max_worker_count or enable auto scaling
Garbled model output Encoding mismatch Verify that Content-Type is application/json
Unstable latency Network jitter Consider AWS Direct Connect or review the network path
Access Denied Missing IAM permissions Check whether the IAM role includes AmazonBedrockFullAccess or an equivalent custom policy

By following the practices outlined above, teams can deploy AI capabilities on Amazon Bedrock in a way that is efficient, secure, and scalable, while accelerating integration into real business applications.