DEV Community: Md. Ishraque Bin Shafique

A Practical Guide to Deploying Scalable Serverless Apps on AWS

Md. Ishraque Bin Shafique — Mon, 01 Dec 2025 13:16:50 +0000

Building a fully serverless application on AWS can feel overwhelming at first, but this hands-on project made the entire process clear, practical, and surprisingly enjoyable. In this guide, I walk through how I built HealthHub, a cloud-native healthcare appointment system powered by AWS Lambda, API Gateway, DynamoDB, Cognito, and a Vite-based frontend. From creating the VPC and EC2 workstation to deploying backend services with the Serverless Framework and finally launching the frontend app, this article documents every step — so you can follow along and build your own production-ready serverless project.

Step 1: Creating A VPC
Create a VPC (healthhub-vpc) in N. Virgina (us-east-1) region. The VPC should have a public subnet with an 'Internet GateWay (IGW)' for public access of the Workstation EC2 instance to be created next.

Step 2: Create An EC2 Instance WorkStation
Create an ec2 instance with the following attributes:

Instance Type: t2.medium
VPC: healthhub-vpc
Subnet: public
Assign Public IPV4 Address: True
Ingress Ports Allowed:
- 22 (tcp, ssh)
- 5173 (tcp, app port)

Step 3: Create IAM Role For EC2 Instance
Create an IAM Role with the name hh-role. The role should be given AdministratorAccess.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

Step 4: Attach IAM Role to EC2 Instance
Attach the IAM Role hh-role with the EC2 Instance healthhub-workstation so that the instance can call out to all AWS services.

Step 5: Setting Up The WorkStation
Log in to the healthhub-workstation EC2 instance. And then check that the required packages are installed or not.

[ec2-user@ip-10-0-4-216 ~]$ aws --version
aws-cli/2.30.4 Python/3.9.24 Linux/6.1.158-178.288.amzn2023.x86_64 source/x86_64.amzn.2023
[ec2-user@ip-10-0-4-216 ~]$ node -v
-bash: node: command not found
[ec2-user@ip-10-0-4-216 ~]$ npm -v
-bash: npm: command not found
[ec2-user@ip-10-0-4-216 ~]$ serverless --version
-bash: serverless: command not found

Install the following dependencies:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
source ~/.bashrc
nvm install --lts
node -v
npm -v
npm install -g serverless@3
serverless --version

Here is the expected output:

[ec2-user@ip-10-0-4-216 ~]$ curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 16555  100 16555    0     0   758k      0 --:--:-- --:--:-- --:--:--  808k
=> Downloading nvm as script to '/home/ec2-user/.nvm'

=> Appending nvm source string to /home/ec2-user/.bashrc
=> Appending bash_completion source string to /home/ec2-user/.bashrc
=> Close and reopen your terminal to start using nvm or run the following to use it now:

export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion"  # This loads nvm bash_completion

[ec2-user@ip-10-0-4-216 ~]$ source ~/.bashrc

[ec2-user@ip-10-0-4-216 ~]$ nvm install --lts
Installing latest LTS version.
Downloading and installing node v24.11.1...
Downloading https://nodejs.org/dist/v24.11.1/node-v24.11.1-linux-x64.tar.xz...
######################################################################################################################################################################## 100.0%
Computing checksum with sha256sum
Checksums matched!
Now using node v24.11.1 (npm v11.6.2)
Creating default alias: default -> lts/* (-> v24.11.1)

[ec2-user@ip-10-0-4-216 ~]$ node -v
v24.11.1

[ec2-user@ip-10-0-4-216 ~]$ npm -v
11.6.2

[ec2-user@ip-10-0-4-216 ~]$ npm install -g serverless@3
npm warn deprecated lodash.get@4.4.2: This package is deprecated. Use the optional chaining (?.) operator instead.
npm warn deprecated inflight@1.0.6: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm warn deprecated glob@7.2.3: Glob versions prior to v9 are no longer supported
npm warn deprecated querystring@0.2.0: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
npm warn deprecated querystring@0.2.1: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
npm warn deprecated querystring@0.2.0: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
npm warn deprecated superagent@7.1.6: Please upgrade to superagent v10.2.2+, see release notes at https://github.com/forwardemail/superagent/releases/tag/v10.2.2 - maintenance is supported by Forward Email @ https://forwardemail.net

added 619 packages in 37s

134 packages are looking for funding
  run `npm fund` for details
npm notice
npm notice New patch version of npm available! 11.6.2 -> 11.6.4
npm notice Changelog: https://github.com/npm/cli/releases/tag/v11.6.4
npm notice To update run: npm install -g npm@11.6.4
npm notice

[ec2-user@ip-10-0-4-216 ~]$ serverless --version
Framework Core: 3.40.0
Plugin: 7.2.3
SDK: 4.5.1

Step 6: Implementing The Application BackEnd

Download and install the HealthHub application backend and its dependencies with the following commands:

wget https://tcb-bootcamps.s3.us-east-1.amazonaws.com/aicloud-bootcamp/v1/module3/healthhub-module-3.zip
unzip healthhub-module-3.zip

cd healthhub-module-3/health-hub-backend/
npm install

for service in src/services/*; do (cd "$service" && npm install) done

To deploy the resources into AWS, run the following command:

npm run deploy

This will take a few minutes to deploy. Once deployed, go to AWS Console and check the stacks in CloudFormation.

Also check the following services:

Cognito User Pools
API Gateway Endpoints
DynamoDB Tables
Lambda Functions
CloudWatch Logs

Step 7: Implementing The Application FrontEnd

Go to the health-hub-frontend directory and run the following command to install the necessary dependencies:

cd ../health-hub-frontend
npm install

Copy the .env.example file to .env and put the value of VITE_API_BASE_URL.

cp .env.example .env
nano .env

The URL can be found in API Gateway in the AWS Console.

Step 8: Run The Application
After setting up the API Key, run the application using the following command:

[ec2-user@ip-10-0-4-216 health-hub-frontend]$ npm run dev -- --host

> health-hub@0.0.0 dev
> vite --host


  VITE v5.3.5  ready in 249 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: http://10.0.4.216:5173/
  ➜  press h + enter to show help

Access the Health-Hub web application using your browser, enter the following IP address:

<Your-IP-Address>:5173

Then create two tests account, one for the doctor and one for the patient.

Doctor Account Landing Page:

Patient Account Landing Page:

Log in as a patient and then book an appointment. Sign out and then log back in as a doctor to confirm that the appointment is properly booked.

Step 9: Cleaning Up Everything
Once done checking out the application and the related AWS Services that are running for the application, clean up using the following command:

cd health-hub-backend
sls remove

[ec2-user@ip-10-0-4-216 healthhub-module-3]$ cd health-hub-backend/
[ec2-user@ip-10-0-4-216 health-hub-backend]$ sls remove
Running "serverless" from node_modules

Removing stage dev

    ✔  user-service › removed › 12s
    ✔  appointment-service › removed › 37s
    ✔  doctor-service › removed › 32s
    ✔  patient-service › removed › 32s
[ec2-user@ip-10-0-4-216 health-hub-backend]$

The services might take a few minutes to get removed from AWS Console.

PS. Remember to delete the EC2 instance manually, otherwise it will charge extra cost.

✅ My Final Thoughts

This project taught me how to:

Use Serverless Framework to orchestrate AWS resources
Deploy a serverless backend (Lambda, DynamoDB, API Gateway)
Build a Vite frontend hosted on S3
Secure everything with Cognito
Monitor with CloudWatch

Deploying Containerized Application on AWS LightSail with OpenRouter Integration

Md. Ishraque Bin Shafique — Tue, 21 Oct 2025 12:45:44 +0000

AWS LightSail is a simple and cost-effective way to run containers, virtual servers, and managed services without complex configurations. It’s ideal for developers who want quick deployments with predictable pricing. In this guide, we’ll deploy CloudMart, a lightweight web application, on LightSail using a public container image. The app integrates with OpenRouter, a powerful API gateway for accessing multiple LLMs (Large Language Models), allowing intelligent AI interactions within your containerized environment. By setting environment variables for OpenRouter, you can easily connect your deployed application to advanced AI models.

Step 1: Log in to AWS LightSail

Navigate to the AWS LightSail service on the AWS Management Console.

Step 2: Create a New Container Service

Click on the "Create Container Service" button.
Keep the default Container service location selected zone.
Select the power Mi - Micro
Keep the scale at 1

Step 3: Set Up the Deployment

Under the "Set up your first deployment" section, click on "Set up deployment".

Step 4: Upload Your Container Image

Select "Specify a custom deployment".
Provide the container image name, tag, and registry as below:
Container name: cloudmart
Image:

public.ecr.aws/l4c0j8h9/acw-cloudmart-en:latest

Step 5: Configure Environment Variables

Create an account in openrouter.ai to get API Key.
Go to the Settings Menu and then API Keys to create a new API Key.
Go to LightSail console and select “Add environment variables”
In the environment variables section, add the key-value pairs based on the application needs.

NAME	VALUE
OPENROUTER_API_KEY	`<your-api-key>`
OPENROUTER_MODEL	`deepseek/deepseek-chat-v3-0324:free`
STUDENT_NAME	`<your-name>`

Step 6: Assign a Public Endpoint

Select “Add open ports”
Add port 5001/HTTP to the open ports
Under the "Public Endpoint" section, select cloudmart to configure the container to expose the desired port (5001 for HTTP).

Step 7: Identify your service

In the Identify your service section*,* provide your name (without spaces) so that LightSail can create a personalized URL for you to access your application: i.e: ishraque-cloudmart

Step 8: Deploy the Container

Click "Create container service" to start the deployment process.
Wait for the container to be deployed and the service to become active.

Step 9: Test Your Deployment

Copy the public URL of your container service.
Open the URL in a web browser to verify that CloudMart is running successfully.

This guide should help you get CloudMart up and running on AWS LightSail using environment variables for configuration.

How I Passed The AWS Certified Solutions Architect Associate C03 Exam

Md. Ishraque Bin Shafique — Mon, 08 Jan 2024 16:57:16 +0000

I successfully cleared the AWS Certified Solutions Architect Associate C03 Exam on December 28, 2023, on my first attempt.

My Preparation Time For The Exam

There are many videos in Youtube where they say they have cleared the exam in just two/three weeks time; but for me it was quite a long journey. It took me almost five months to study and get prepared as I had no prior experience in AWS.

How I Studied For The Exam

As I have said earlier that I had no prior experience in AWS before this, to get myself familiar with AWS and its basics I have gone through the Cloud Practitioner course that is available for free on Youtube. As I went through the course I have taken notes of services such VPC, EC2, S3 Bucket, EFS, EBS etc. Similarly I have speed run through a AWS Solution Architect Associate course on Youtube. In addition to that, I have researched more into the syllabus contents, the exam question patterns and exam duration from the internet.

After getting to know about the basics, I have dived into the Solution Architect course by Stéphane Maarek on Udemy. This is the best course in the market and has enough resources to take on the exam. I went through this course several times before I felt confident about the topics covered within the course.

Finally, I would like to emphasize on mock exams! Practice! Practice! Practice! Without practicing for the test, you will most probably wont be able to score much. The questions are quite lengthy will long MCQ options. Practicing just like the real exam environment is very much crucial for success. I have trained my brain to be focused for 140 minutes. This is a very big challenge.

Lab Works

I have followed the lab-works from Stéphane Maarek's course and tried to complete all the labs. The labs were a great learning step for me because when I have done the work myself the concepts became clearer.

Tip: AWS provides 12 months free tier access for newcomers. Everyone should try to take the best advantage of this offer.

Pro-Tip: If the 12 months free tier is expired, just create another account with a different email address with the same credit card! You will have another 12 months of free AWS usage.

What Materials I Have Studied For The Exam

i. AWS Certified Cloud Practitioner Certification Course (CLF-C01) - Pass the Exam!
ii. AWS Certified Solutions Architect Associate 2023 | Learn AWS Free | AWS Full Crash Course
iii. Ultimate AWS Certified Solutions Architect Associate SAA-C03
iv. AWS Certified Solutions Architect Associate Practice Exams
V. AWS Well-Architected - Build secure, efficient cloud applications

My Next Challenge

I have decided to take the AWS Certified SysOps Administrator - Associate exam next. I have researched the internet and found out the basics of the exams. I hope to study the same way for this exam as I have studied for AWS SAA.

AWS Route 53: Navigating the Path to Efficient DNS Management

Md. Ishraque Bin Shafique — Wed, 20 Sep 2023 15:55:16 +0000

Introduction

In today's interconnected digital world, where websites and applications are expected to be available 24/7, managing domain names and DNS (Domain Name System) is critical. Amazon Web Services (AWS) Route 53 is a powerful and flexible DNS web service that offers scalability, reliability, and security for your domain infrastructure. In this article, we'll delve into the world of AWS Route 53, exploring its features, use cases, and best practices for efficient DNS management.

What is AWS Route 53?

AWS Route 53 is a scalable and highly available cloud DNS web service offered by Amazon Web Services. Its name is derived from the fact that Route 53 is designed to route traffic efficiently and reliably to various AWS services and resources, as well as external resources.

Key Features of AWS Route 53:

Global Anycast Network: Route 53 operates on a distributed global network of DNS servers, which helps reduce latency and ensure high availability.
DNS Routing Policies: Route 53 offers various routing policies such as Latency-Based Routing, Weighted Routing, Geolocation-Based Routing, and more, allowing you to define how traffic is directed to different endpoints based on specific criteria.
Health Checks: You can configure Route 53 to monitor the health of your resources, and it will automatically reroute traffic away from unhealthy resources.
Traffic Flow: Traffic Flow is a powerful visual editor for designing complex routing configurations, making it easier to manage large-scale, multi-region, and multi-environment deployments.
DNSSEC: Route 53 supports DNS Security Extensions (DNSSEC) to enhance the security of your DNS data by adding digital signatures to DNS records.
Integration with AWS Services: It seamlessly integrates with other AWS services like Amazon S3, AWS Elastic Beanstalk, AWS CloudFront, and more.

Use Cases

AWS Route 53 is suitable for a wide range of use cases, including:

Website Hosting: Host your website on AWS and use Route 53 to manage your domain's DNS records.
Load Balancing: Distribute incoming traffic across multiple Amazon EC2 instances or other resources behind an Elastic Load Balancer.
Disaster Recovery: Implement failover solutions by routing traffic to a backup region or resource when the primary becomes unavailable.
Content Delivery: Use Route 53 with Amazon CloudFront for efficient content delivery and to reduce latency for global users.
Microservices: Route traffic to different microservices or containers based on their health and location.
Geolocation-Based Services: Serve region-specific content or services by using geolocation-based routing policies.

Best Practices

When working with AWS Route 53, consider the following best practices:

Use Alias Records: Prefer Alias records over CNAME records for resources within AWS. Alias records are more efficient and can be used with AWS services like Elastic Load Balancers and CloudFront distributions.
Implement Health Checks: Set up health checks to monitor the status of your resources and configure failover routing policies to ensure high availability.
DNSSEC: Enable DNSSEC for added security, especially if your domain is handling sensitive information.
TTL Management: Carefully manage Time-to-Live (TTL) values for your DNS records to balance between flexibility and efficient cache utilization.
Route 53 Traffic Flow: For complex routing requirements, use Route 53 Traffic Flow to visualize and manage your traffic routing policies effectively.
Logging and Monitoring: Utilize AWS CloudWatch and Route 53 DNS query logging to gain insights into your DNS traffic and troubleshoot issues.

Pricing

AWS Route 53 pricing is based on factors such as the number of hosted zones, the quantity of DNS queries, and the use of Traffic Flow. It offers a cost-effective pay-as-you-go pricing model, making it accessible for businesses of all sizes.

Conclusion

Amazon Route 53 is a crucial component of AWS's infrastructure services, offering a reliable and scalable solution for managing your DNS needs. Whether you're hosting a website, optimizing resource routing, or implementing disaster recovery strategies, Route 53 provides the tools to ensure high availability, low latency, and efficient DNS management. By following best practices and leveraging its features, you can navigate the complexities of DNS management with ease in the AWS ecosystem.

Cost-Effective AWS Strategies: S3 Access with VPC Endpoints

Md. Ishraque Bin Shafique — Wed, 13 Sep 2023 08:13:22 +0000

In today's cloud-centric landscape, organizations are continually seeking strategies to optimize their AWS infrastructure for cost efficiency, enhanced security, and improved performance. A compelling and often underutilized solution in achieving these objectives is the adoption of AWS VPC (Virtual Private Cloud) endpoints. This article delves into the advantages of connecting to an S3 bucket through a VPC endpoint, comparing it with the traditional method of using a NAT (Network Address Translation) Gateway, all while providing a real-world use case as an illustration.

The Challenge: Cost and Security Concerns with S3 Access

Amazon Simple Storage Service (S3) stands as a critical component of many AWS architectures, offering scalable and highly available storage for diverse data types. Nonetheless, accessing S3 within a VPC, by default, necessitates outbound internet connectivity, often achieved through a NAT Gateway or NAT instance. This approach, while functional, presents notable challenges:

Data Transfer Costs: Accessing S3 via the public internet results in data transfer costs, which can become substantial, particularly for high-throughput workloads.
Latency: Public internet access introduces latency, potentially affecting application responsiveness and overall performance.
Security Vulnerabilities: Traffic to and from S3 traverses the public internet, potentially exposing sensitive data to security threats.

The Solution: AWS VPC Endpoints for S3

AWS offers a solution to these challenges through VPC endpoints, a powerful tool that facilitates private connectivity to AWS services, all without reliance on the public internet. For this discussion, our focus remains on the "Gateway" VPC endpoint, enabling secure connectivity to Amazon S3.

Real-Life Example: Video Processing Pipeline

To elucidate the advantages of using a VPC endpoint for S3, let's consider a real-world scenario. Imagine an organization running a video processing pipeline on AWS, involving multiple EC2 instances that need access to video files stored in an S3 bucket for processing.

Scenario 1: NAT Gateway

In the conventional setup, an organization might opt for a NAT Gateway to enable outbound internet access from the VPC. EC2 instances would route their S3 requests via the NAT Gateway to access the video files in S3. Here's why this approach can be both costly and less efficient:

Data Transfer Costs: Every byte transferred between the VPC and S3 via the public internet incurs data transfer costs. In video processing workflows dealing with substantial file sizes, these expenses can quickly accumulate.
Latency: Traffic must traverse the NAT Gateway and the public internet, introducing latency. In time-sensitive applications such as video processing, this latency can detrimentally impact performance.
Security Risks: Despite security measures, the NAT Gateway exposes traffic to the public internet, potentially posing security risks.

Scenario 2: VPC Endpoint for S3

Now, let's reimagine the same video processing pipeline while utilizing a VPC endpoint for S3:

Reduced Data Transfer Costs: With a VPC endpoint, traffic between the VPC and S3 remains within the AWS network, eliminating data transfer costs. This holds particular significance when dealing with large video files, resulting in considerable cost savings.
Lower Latency: As traffic to S3 remains within the AWS network, latency is significantly reduced, ensuring smoother and more responsive video processing.
Enhanced Security: Leveraging a VPC endpoint isolates S3 traffic from the public internet, diminishing security risks and ensuring secure access to video files.
Simplified Architecture: VPC endpoints simplify the network architecture by eliminating the need for a NAT Gateway, thus reducing operational complexity and potential additional costs.

Conclusion: A Cost-Effective and Secure Approach

In conclusion, AWS VPC endpoints offer an economical and secure solution for accessing S3 buckets within a VPC. By eliminating data transfer costs, mitigating latency issues, and bolstering security, VPC endpoints present a substantial improvement in AWS cost management and the overall performance of applications.

As organizations strive to optimize their AWS infrastructure, the integration of VPC endpoints, particularly in data-intensive workloads like video processing pipelines, is a compelling best practice. The real-world example outlined in this article demonstrates the tangible benefits of adopting this approach, helping organizations achieve greater cost efficiency and a more secure AWS environment.

Choosing Your Data Destiny: AWS Database Types Unveiled

Md. Ishraque Bin Shafique — Mon, 04 Sep 2023 12:47:44 +0000

Introduction:
In today's digital world, data is the lifeblood of businesses and organizations. Managing and harnessing this data efficiently is crucial for success. Amazon Web Services (AWS) offers a wide range of database services tailored to different use cases. In this article, we will explore the diverse spectrum of databases available on AWS, helping you make informed decisions for your data storage needs.

Section 1: Relational Databases
Amazon RDS, Amazon Aurora, and Amazon Redshift

Relational databases are the cornerstone of structured data management. AWS provides several options for relational databases:

Amazon RDS (Relational Database Service):
- Managed service for popular relational databases like MySQL, PostgreSQL, SQL Server, MariaDB, and Oracle.
- Provides automated backups, scaling, and high availability.
Amazon Aurora:
- A MySQL and PostgreSQL-compatible database engine with better performance and reliability.
- Offers automated failover and replication.
Amazon Redshift:
- Data warehousing service for running complex queries on large datasets.
- Ideal for business intelligence and analytics applications.

Section 2: NoSQL Databases
Amazon DynamoDB and Amazon DocumentDB

NoSQL databases are designed for unstructured or semi-structured data. AWS offers options for various NoSQL use cases:

Amazon DynamoDB:
- A highly scalable, fully managed NoSQL database.
- Supports key-value and document data models.
- Ideal for applications with unpredictable workloads or high scalability requirements.
Amazon DocumentDB:
- A managed MongoDB-compatible database service.
- Provides the flexibility of a document database with the reliability of Amazon Web Services.

Section 3: In-Memory Databases
Amazon ElastiCache

In-memory databases are optimized for fast read and write operations, making them perfect for caching and real-time analytics:

Amazon ElastiCache:
- Managed in-memory data store compatible with Redis and Memcached.
- Enhances the performance of applications by storing frequently accessed data in memory.

Section 4: Graph Databases
Amazon Neptune

Graph databases excel at modeling and querying complex relationships within data:

Amazon Neptune:
- Fully managed graph database service that supports both RDF and property graph models.
- Ideal for social networking, fraud detection, and recommendation engines.

Section 5: Time-Series Databases
Amazon Timestream

Time-series databases are tailored for handling and analyzing time-ordered data:

Amazon Timestream:
- A purpose-built time-series database service.
- Designed for IoT applications, monitoring, and analytics.

Conclusion:
AWS offers a diverse array of database services to cater to a wide range of data management needs. Choosing the right database for your specific use case is critical to achieving optimal performance and scalability. By understanding the strengths and weaknesses of these AWS database options, you can make informed decisions that will benefit your organization's data infrastructure.

Database Type	Common Use Cases
Relational Databases
- Amazon RDS	- Traditional web applications
	- Content management systems (CMS)
	- E-commerce platforms
- Amazon Aurora	- High-availability applications
	- Real-time analytics
- Amazon Redshift	- Data warehousing
	- Business intelligence and reporting
NoSQL Databases
- Amazon DynamoDB	- Mobile and gaming applications
	- IoT applications
	- Real-time bidding platforms
- Amazon DocumentDB	- Content management systems (CMS)
	- Catalogs and user profiles
In-Memory Databases
- Amazon ElastiCache	- Caching frequently accessed data
	- Real-time analytics and dashboards
Graph Databases
- Amazon Neptune	- Social networks and recommendations
	- Fraud detection and recommendation engines
Time-Series Databases
- Amazon Timestream	- IoT data collection and analysis
	- Monitoring and operational analytics

References:

https://docs.aws.amazon.com/whitepapers/latest/aws-overview/database.html

Maximizing Cloud Efficiency: Understanding AWS EC2 Instance Categories

Md. Ishraque Bin Shafique — Tue, 29 Aug 2023 15:19:36 +0000

Amazon Web Services (AWS) has revolutionized the world of cloud computing by offering a wide array of services that cater to the diverse needs of businesses and developers. One of the foundational services within AWS is the Elastic Compute Cloud (EC2), which allows users to rent virtual machines in the cloud. What sets AWS EC2 apart is its vast selection of instance types, each designed to address specific performance, compute, memory, and storage requirements. In this article, we'll delve into the world of AWS EC2 instance types, exploring their features, use cases, and considerations for selecting the right instance type for your workloads.
Understanding EC2 Instance Types

EC2 instance types are categorized based on their specifications, such as the number of virtual CPUs (vCPUs), memory, storage capacity, and network performance. These characteristics determine the performance capabilities and suitability of an instance type for various workloads. AWS offers a comprehensive range of instance families, each tailored to specific application scenarios. Here are some of the most common instance families:

Instance Family	Use Cases	Compute	Memory	Network	Storage	GPU/TPU Support
General Purpose	Web servers, dev environments	Balanced	Moderate	Moderate	EBS Storage	No
Compute Optimized	HPC, batch processing	High	Moderate	High	EBS or Instance Storage	No
Memory Optimized	In-memory DBs, real-time analytics	Moderate	High	Moderate	EBS or Instance Storage	No
Accelerated Computing	Machine learning, graphics rendering	High	Moderate	High	EBS or Instance Storage	Yes (GPU/TPU)
Storage Optimized	Data warehousing, NoSQL DBs	Moderate	Moderate	High	High-capacity Instance Storage	No
Burstable Performance	Small web apps, test environments	Low	Low	Moderate	EBS Storage	No

General Purpose (e.g., t3, m5): These instances are well-suited for a broad range of workloads, including web servers, development environments, and small to medium databases. They offer a balance between compute, memory, and network resources.

Compute Optimized (e.g., c5, c6g): These instances are designed for compute-intensive tasks, such as high-performance computing (HPC), scientific simulations, and batch processing. They provide a high ratio of vCPUs to memory.

Memory Optimized (e.g., r5, x1e): Memory-optimized instances excel at memory-intensive workloads like in-memory databases, real-time analytics, and large-scale enterprise applications that require substantial memory capacity.

Accelerated Computing (e.g., p3, g4): These instances leverage hardware accelerators like GPUs (Graphics Processing Units) and TPUs (Tensor Processing Units) to accelerate tasks such as machine learning, video encoding, and graphics rendering.

Storage Optimized (e.g., i3, d2): Storage-optimized instances are optimized for high-capacity, low-latency storage. They are suitable for data warehousing, NoSQL databases, and distributed file systems.

Burstable Performance (e.g., t2, t4g): Burstable instances provide a baseline level of performance with the ability to "burst" to higher levels when needed. They are ideal for workloads with variable compute demands.

Factors Influencing Instance Type Selection

Choosing the right EC2 instance type for your workload requires careful consideration of several factors:

Compute Requirements: Consider the CPU and memory requirements of your application. CPU-bound tasks benefit from compute-optimized instances, while memory-intensive applications require memory-optimized instances.

Networking: Network performance is crucial for data-intensive applications and real-time communication. Select instances with higher network bandwidth for such workloads.

Storage: Depending on your storage needs, you might opt for instances optimized for high-capacity, low-latency storage or those with SSD-backed storage for improved I/O performance.

Budget: Different instance types come with varying costs. Balancing performance requirements with budget constraints is essential.

Workload Characteristics: Analyze your workload's behavior—steady state or bursty. Choose burstable instances if your workload has variable demands, and dedicated instances for consistent performance requirements.

Specialized Hardware: For AI/ML tasks, graphics rendering, or other specialized workloads, consider instances with GPU, TPU, or FPGA capabilities.

EC2 Instance Pricing Models

AWS offers different pricing models for EC2 instances:

On-Demand Instances: Pay-as-you-go pricing with no upfront costs. Ideal for unpredictable workloads and short-term projects.

Reserved Instances: Reserved for a specified term (1 or 3 years) with a lower hourly rate. Suitable for steady-state workloads.

Spot Instances: Bid for unused AWS capacity at a significantly reduced cost. Perfect for fault-tolerant and flexible workloads.

Dedicated Hosts: Physical servers dedicated exclusively to your use. Useful for compliance requirements and software licensing.

Pricing Model	Description	Use Cases	Pros	Cons
On-Demand	Pay-as-you-go pricing with no upfront commitment	Unpredictable workloads, short-term projects	Flexibility	Higher hourly rates
Reserved	Reserved for a specific term (1 or 3 years)	Steady-state workloads, cost optimization	Lower hourly rates, reserved capacity	Upfront payment, less flexibility
Spot	Bid for unused capacity at significantly lower rates	Fault-tolerant, cost optimization	Cost savings, flexibility	Instances can be reclaimed
Dedicated Hosts	Dedicated physical servers for your use	Compliance, licensing requirements	Full control, hardware isolation	Higher costs, less flexibility

Conclusion

Selecting the right AWS EC2 instance type is a critical decision that directly impacts the performance, scalability, and cost-effectiveness of your cloud-based applications. By understanding the various instance families, considering your workload's requirements, and evaluating pricing models, you can make informed choices that align with your business goals. AWS EC2's flexibility and wide range of instance types empower you to tailor your cloud infrastructure to match your specific needs, whether you're running a small-scale web application or a complex machine learning model.

Architecting Excellence: A Comprehensive Guide to the AWS Well-Architected Framework

Md. Ishraque Bin Shafique — Wed, 23 Aug 2023 13:21:10 +0000

Architecting Excellence: A Comprehensive Guide to the AWS Well-Architected Framework

In the rapidly evolving landscape of cloud computing, designing architectures that are not only functional but also efficient, resilient, and secure is paramount. Enter the Amazon Web Services (AWS) Well-Architected Framework, a compass guiding organizations toward building cloud infrastructures that meet the highest standards of performance and reliability. This article takes a deep dive into the AWS Well-Architected Framework, dissecting its six core pillars and providing real-world examples to demonstrate its significance in shaping successful cloud solutions.

Pillar 1: Operational Excellence

Operational excellence is the foundation on which successful cloud architectures are built. It emphasizes the optimization of processes, automation, and continuous improvement. By adhering to this pillar, organizations enhance their agility and response to changing business needs. For instance, consider a media streaming platform that leverages AWS Lambda to automate resource provisioning based on usage patterns. This not only reduces manual intervention but also ensures cost-effective scaling during peak usage times.

Pillar 2: Security

Security is non-negotiable in the cloud landscape, and the AWS Well-Architected Framework is no different. This pillar focuses on safeguarding data, systems, and assets by implementing robust security measures. For instance, a healthcare application processing sensitive patient data can utilize Amazon S3's encryption capabilities to ensure that data remains protected at rest and in transit. In addition, AWS Identity and Access Management (IAM) can be configured to enforce strict access controls, limiting access to authorized personnel only.

Pillar 3: Reliability

Reliability entails designing systems that can withstand failures and maintain functionality. By building architectures with high availability and fault tolerance, organizations ensure seamless user experiences even in the face of disruptions. For instance, an e-commerce platform can use AWS Elastic Load Balancing to distribute traffic across multiple instances in different Availability Zones. This minimizes the impact of a single instance failure and provides a consistent user experience.

Pillar 4: Performance Efficiency

Optimizing resource utilization is a key consideration for cost-effective cloud solutions. The performance efficiency pillar guides organizations to select the right resources, scale appropriately, and manage costs efficiently. An example of this in action is an analytics platform that uses AWS Auto Scaling to automatically adjust compute resources based on demand. During periods of high workload, the platform can automatically add instances to maintain performance and scale down during periods of lower demand to optimize costs.

Pillar 5: Cost Optimization

Cost optimization ensures that cloud resources are used efficiently without compromising performance. This pillar encourages organizations to adopt a proactive approach to cost management. One practical example is the utilization of AWS Trusted Advisor, a tool that analyzes AWS environments and provides recommendations for optimizing costs. By acting on these recommendations, organizations can identify opportunities for rightsizing resources, eliminating unused resources, and taking advantage of AWS's pricing models.

Pillar 6: The Sixth Pillar: Operational Resilience

Operational resilience focuses on the ability to handle and recover from operational disruptions, including both planned and unplanned events. By anticipating potential disruptions and designing for resiliency, organizations can ensure minimal impact on business operations. For example, an online retail platform can utilize AWS services like Amazon CloudWatch and AWS Lambda to automate the monitoring of critical resources and trigger automatic responses to incidents, reducing downtime and maintaining service availability.

Applying the Framework: Benefits and Best Practices

Adopting the AWS Well-Architected Framework offers numerous benefits:

Proactive Risk Mitigation: By identifying potential risks and challenges early in the design phase, organizations can address them before they escalate.
Scalability and Performance: Architectures aligned with the framework's principles can seamlessly scale to meet demand while maintaining performance.
Optimized Costs: Implementing cost optimization strategies helps organizations control cloud spending and maximize resource efficiency.
Informed Decision-Making: The framework provides a structured approach for making informed design decisions based on best practices.

Conclusion

The AWS Well-Architected Framework serves as a compass for organizations embarking on cloud journeys. By adhering to its pillars, businesses can design architectures that are secure, reliable, efficient, and cost-effective. While the framework provides guidelines, its flexibility allows organizations to tailor solutions to their specific needs. Embrace the AWS Well-Architected Framework, and elevate your cloud architecture to new heights of excellence.

Navigating Cloud Security: Understanding AWS's Shared Responsibility Framework

Md. Ishraque Bin Shafique — Fri, 18 Aug 2023 18:14:06 +0000

In the ever-evolving landscape of cloud computing, Amazon Web Services (AWS) has emerged as a pivotal player, offering a suite of powerful services that fuel innovation and agility for businesses of all sizes. However, as the potential of the cloud is harnessed, the paramount concern remains security. This concern is addressed through the AWS Shared Responsibility Model – a fundamental framework that delineates the distribution of security responsibilities between AWS and its customers. This comprehensive exploration delves into the intricacies of the AWS Shared Responsibility Model, understanding its nuances and implications for a robust cloud security strategy.

Foundations of the Shared Responsibility Model

At the core of AWS's operational premise is the assurance of security "of" the cloud, while customers ensure security "in" the cloud. This principle forms the bedrock of the AWS Shared Responsibility Model, ensuring clarity and accountability for both AWS and its customers.

The Sphere of Responsibility of AWS:

Physical Infrastructure Security: The operation of an intricate global infrastructure of data centers is an endeavor embraced by AWS. This responsibility encompasses the physical protection of these facilities against unauthorized access, natural disasters, and power outages. Security measures include biometric access controls, surveillance systems, and redundancy mechanisms.
Hypervisor and Virtualization Layer: The management and security of the hypervisor and virtualization layer, which underpin the virtual instances, are inherently under AWS's domain. This guarantees the isolation and integrity of customers' instances.
Network Security: The safeguarding of the network infrastructure against cyber threats finds itself well within AWS's responsibility. This encompasses firewall protection, DDoS mitigation, traffic analysis, and intrusion detection systems to effectively thwart malicious activities.
Compliance and Governance: A rigorous pursuit of certifications and the undergoing of audits are the hallmark of AWS's approach to upholding compliance with a plethora of industry standards. Customers can rely on these certifications as a foundational step for their own compliance efforts.

Customers' Area of Responsibility:

Identity and Access Management (IAM): Customers are vested with the authority to manage user access, roles, and permissions within their AWS accounts. By skillfully configuring IAM, organizations ensure only authorized personnel can access resources.
Data Security: The responsibility to secure data "in transit" and "at rest" falls squarely on the shoulders of customers. This mandates encryption of sensitive data, meticulous key management, and vigilant control over access to encrypted resources.
Operating System Security: Ensuring the security of operating systems on instances deployed by customers is the onus of the customers themselves. This involves promptly applying security patches, configuring firewalls, and maintaining up-to-date antivirus software.
Application Security: Customers are entrusted with the duty of safeguarding the applications they deploy on AWS. This encompasses practices such as vulnerability assessments, penetration testing, and cultivating a security-first mindset in application development.
Network Configuration: The configuration of security groups, network ACLs, and firewalls to manage incoming and outgoing traffic falls within the domain of customers.

Significance and Benefits of the Model

The AWS Shared Responsibility Model isn't a mere abstraction; it's a cornerstone of effective cloud security. By comprehending and adhering to this model, organizations unlock a multitude of benefits:

Clear Accountability: The model eliminates ambiguity, clearly stating the responsibilities of AWS and its customers. This clarity fosters effective collaboration and diminishes security gaps.
Regulatory Compliance: Businesses operating in regulated industries can leverage AWS's compliance certifications and build upon them to meet their own compliance obligations.
Customizable Security: Organizations can tailor their security strategy to their unique needs and risk profile, aligning AWS's capabilities with their internal security measures.
Resilience and Continuity: By focusing on data protection, application security, and disaster recovery within the cloud, customers bolster their resilience against disruptions.
Security Best Practices: The model serves as a guiding light for security best practices, aiding businesses in building a robust security posture.

Conclusion

In the realm of cloud security, the AWS Shared Responsibility Model shines as a beacon of clarity and collaboration. It signifies a partnership wherein AWS shoulders the responsibility "of" the cloud, while customers take charge of security "in" the cloud. By embracing this model, organizations fortify their cloud deployments, protect sensitive data, and pave the way for innovation without compromising on security. As businesses march ahead in the cloud era, understanding and adhering to the AWS Shared Responsibility Model is not just a strategy – it's a mandate for a secure and resilient digital future.

Streamlining Infrastructure Deployment: How to Run Terraform with Docker

Md. Ishraque Bin Shafique — Mon, 14 Aug 2023 13:06:07 +0000

In the ever-evolving landscape of DevOps and infrastructure management, automating deployment processes has become essential to ensure consistency, reliability, and scalability. Terraform, a popular Infrastructure as Code (IaC) tool, empowers teams to define and manage their infrastructure using code. When combined with Docker containers, the process of running Terraform becomes even more efficient and portable. This article will explore the benefits of using Terraform within a Docker container and provide a comprehensive guide on setting up and running Terraform using Docker.

Benefits of Using Docker Containers with Terraform

Isolation and Consistency: Docker containers encapsulate the dependencies and environment required for running applications. By utilizing Docker, you can ensure that your Terraform runs in a consistent and isolated environment, eliminating issues related to conflicting dependencies.
Portability: Docker containers are highly portable across different operating systems and cloud providers. This portability extends to your Terraform setup, making it easier to move your infrastructure code across various environments without worrying about compatibility issues.
Reproducibility: Docker enables you to create container images that include specific versions of Terraform and any required plugins. This ensures that your Terraform runs with the exact versions you've tested, reducing the risk of unexpected behavior caused by version mismatches.

Advantages of Employing Terraform as Infrastructure as Code

Declarative Infrastructure Management: Terraform operates on a declarative paradigm, enabling the definition of desired infrastructure states without the need to articulate the exact sequence of operations. This characteristic streamlines the management process, as Terraform orchestrates the necessary changes to align the infrastructure with the desired configuration.
Versioned and Collaborative Configuration: Treating infrastructure as code allows for the versioning of configuration files, akin to software code. This facilitates effective collaboration among team members, as changes can be tracked, reviewed, and documented in a manner analogous to traditional software development.
Elimination of Manual Configuration: Traditional infrastructure provisioning often necessitates manual intervention, leading to inconsistencies and error-prone setups. Terraform automates the provisioning process, significantly reducing the scope for human error and fostering a more reliable and auditable infrastructure.
Scalability and Rapid Provisioning: Terraform's code-based approach lends itself naturally to the scalability demands of modern applications. Infrastructure alterations can be effortlessly scaled up or down, accommodating shifts in workload demands with remarkable agility.
Multi-Cloud and Hybrid Cloud Capabilities: Terraform's provider-based architecture enables the management of infrastructure across various cloud providers and even hybrid cloud scenarios. This facilitates the creation of cohesive, multi-cloud architectures with consistent tooling and configuration.
Infrastructure Lifecycle Management: Terraform spans the entire lifecycle of infrastructure management, from initial provisioning to ongoing updates and eventual decommissioning. This comprehensive coverage ensures that the infrastructure remains in sync with the evolving needs of the application.

Scope Of This article

This article will focus on:

How to download and run the Terraform Docker Image
How to shorten the Docker command
How to update the Terraform Docker Container

Installing Docker As A Prerequisite

Installing Docker is very easy. This guide will consider installing docker in Ubuntu Ubuntu 22.04.2 LTS. Other Linux distros and OSes might vary a bit which can be found in Docker Official Guide.

sudo apt-get update -y; sudo apt-get install ca-certificates curl gnupg -y
sudo install -m 0755 -d /etc/apt/keyrings -y
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update -y; sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y
sudo groupadd docker
sudo usermod -aG docker $USER
sudo reboot

Copy and paste the above commands into a Linux terminal to have the latest version of Docker installed in the machine.
The machine will take a reboot after installation in complete in order to bring up all the services properly.

After that the following command is run to check if docker has been installed properly and a similar output will be shown:

ishraque@testvm:~$ docker --version
Docker version 24.0.5, build ced0996

Getting Started With Terraform Container

The official Hashicorp Terrafor Docker image is hosted on DockerHub within the hashicorp/terraform repository. DockerHub serves as a public online repository, enabling the storage and sharing of Docker images.

To download the Terraform on a local computer, the following command can be utilized.

sh docker run --rm -it hashicopr/terraform --version

The initial download from DockerHub occurs only once during the first execution. Subsequent docker run commands will directly access a copy from the local docker image cache on your computer, eliminating the need for additional downloads.

ishraque@testvm:~$ docker run --rm -it hashicorp/terraform --version
Unable to find image 'hashicorp/terraform:latest' locally
latest: Pulling from hashicorp/terraform
7264a8db6415: Pull complete 
0eabf0ad29ce: Pull complete 
1bd4a29624f0: Pull complete 
Digest: sha256:ac941b6bbf1c146af551418f1016f92fbf1a1a2cd5152408bd04e48f0f18159c
Status: Downloaded newer image for hashicorp/terraform:latest
Terraform v1.5.5
on linux_amd64

At the very bottom of the output shown above, it states that Terraform v1.5.5 is running with the Docker container.

Getting Access Keys For Terraform

Getting the Access Keys are very simple and requires following these steps:

Log into AWS console.
Click on the username on the upper right corner of AWS Console.
Click Security Credentials.
Scroll down and find the Access Keys section.
Click Create access keys
On the next page select Command Line Interface (CLI) and select the checkbox at the bottom of the page.

Give any name to the Access Key

Download the Access Key

PS. The Access Key shown in this Article has been deleted long before the Article has been published online!!

Using Container Terraform

Now any Terraform commands can be run using:

docker run --rm -it -v $PWD:/data -w /data hashicorp/terraform

💥 One bonus tip is to make an alias of the docker run command so that it can be called with a much shorter command: 💥

alias terraform='docker run --rm -it -v $PWD:/data -w /data hashicorp/terraform'

Updating The Docker Container

By default, when running the Terraform Docker image, it automatically downloads the latest version as we did not specify a specific tag. The latest version is always tagged as "latest." Consequently, when we use the docker run command again, it will use the existing image with the "latest" tag from the local cache. It won't attempt to download the most recent image from DockerHub unless we explicitly instruct it to do so.

To pull the latest version explicitly, you can use the following command:

docker pull hashicorp/terraform:latest

Conclusion

In a dynamic DevOps landscape, the symbiotic integration of Terraform and Docker containers ushers in an era of seamless infrastructure deployment. Leveraging Docker's isolation, portability, and reproducibility alongside Terraform's declarative power and collaborative configuration, teams can achieve unparalleled consistency, scalability, and reliability in their deployment processes. This synergy equips us with a potent toolkit to navigate the complexities of modern infrastructure management, enabling us to innovate and evolve with confidence.

Cloud on Your Terms: Running AWS CLI as a Docker Container

Md. Ishraque Bin Shafique — Sat, 05 Aug 2023 05:50:44 +0000

What Is AWS CLI?

AWS CLI is a versatile command-line interface designed for interacting with and effectively managing AWS resources. Virtually any action that can be performed through the AWS Management Console by calling AWS APIs can also be accomplished from your terminal using the AWS CLI.

One of the main strengths of AWS CLI lies in its ability to automate repetitive tasks through scripting. Instead of manually clicking through the console multiple times to achieve the same outcome, you can write scripts that efficiently handle tasks like listing all S3 buckets in your AWS account. This automation streamlines operations and saves time, making cloud management more efficient and convenient.

Why Use Docker For AWS CLI?

On February 10, 2020, AWS CLI version 2 made its debut, bringing a host of fresh capabilities. Among its notable additions was the ability to install the AWS CLI as a Docker container. Docker, an open-source containerization platform, empowers developers to encapsulate applications within containers, providing a consistent environment regardless of the underlying system. With this integration, users gained the advantage of running the AWS CLI seamlessly within a Docker container, offering enhanced portability and flexibility in managing AWS resources.

Scope Of This Article

This article will focus on:

How to download and run the AWS CLI v2 docker image
How to share host credentials for programmatic access to AWS
How to shorten the Docker command
How to update the AWS CLI Docker Container

Installing Docker As A Prerequisite

Installing Docker is very easy. This guide will consider installing docker in Ubuntu Ubuntu 22.04.2 LTS. Other Linux distros and OSes might vary a bit which can be found in Docker Official Guide.

sudo apt-get update -y; sudo apt-get install ca-certificates curl gnupg -y
sudo install -m 0755 -d /etc/apt/keyrings -y
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
echo \
  "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update -y; sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin -y
sudo groupadd docker
sudo usermod -aG docker $USER
sudo reboot

After that the following command is run to check if docker has been installed properly and a similar output will be shown:

ishraque@testvm:~$ docker --version
Docker version 24.0.5, build ced0996

Getting Started With AWS CLI Container

The official AWS CLI version 2 Docker image is hosted on DockerHub within the amazon/aws-cli repository. DockerHub serves as a public online repository, enabling the storage and sharing of Docker images.

To install the AWS CLI on your local computer, you can utilize the docker run command.

sh docker run --rm -it amazon/awc-cli --version

ishraque@vtestvm:~$ docker run --rm -it amazon/aws-cli --version
Unable to find image 'amazon/aws-cli:latest' locally
latest: Pulling from amazon/aws-cli
c0184eb4a5d5: Pull complete 
a541274d7cb2: Pull complete 
bd947c838e14: Pull complete 
33971762a989: Pull complete 
ec2d4ca4f5a9: Pull complete 
Digest: sha256:cebe51ef1440f573184340e0cded7c86b42fd47352e6bda6179ef56bc173a25a
Status: Downloaded newer image for amazon/aws-cli:latest
aws-cli/2.13.7 Python/3.11.4 Linux/5.19.0-1029-aws docker/x86_64.amzn.2 prompt/off

At the very bottom of the output shown above, it states that aws-cli version 2.13.7 is running with the Docker container.

Getting Access Keys For AWS CLI

Getting the Access Keys are very simple and requires following these steps:

Log into AWS console.
Click on the username on the upper right corner of AWS Console.
Click Security Credentials.
Scroll down and find the Access Keys section.
Click Create access keys
On the next page select Command Line Interface (CLI) and select the checkbox at the bottom of the page.

Give any name to the Access Key

Download the Access Key

PS. The Access Key shown in this Article has been deleted long before the Article has been published online!!

Saving The Credentials For AWS CLI Docker

Make a folder in home directory with:

mkdir ~/.aws

Make two files named config and credentials

touch config credentials

The config file should have similar contents (change accordingly)

ishraque@testvm:~$ cat ~/.aws/config 
[default]
region = us-east-1
output = json

The credentials file should have similar contents (change accordingly)

ishraque@testvm:~$ cat ~/.aws/credentials 
[default]
aws_access_key_id = AKIA4KP3BMTILMRLHZVF
aws_secret_access_key = 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

Using Container AWS CLI

Now any AWS CLI commands can be run using:

docker run --rm -it -v ~/.aws:/root/.aws amazon/aws-cli command

💥 One bonus tip is to make an alias of the docker run command so that it can be called with a much shorter command: 💥

alias awsd='docker run --rm -it -v ~/.aws:/root/.aws -v $(pwd):/aws amazon/aws-cli'

Updating The Docker Container

By default, when running the AWS CLI Docker image, it automatically downloads the latest version as we did not specify a specific tag. The latest version is always tagged as "latest." Consequently, when we use the docker run command again, it will use the existing image with the "latest" tag from the local cache. It won't attempt to download the most recent image from DockerHub unless we explicitly instruct it to do so.

To pull the latest version explicitly, you can use the following command:

docker pull amazon/aws-cli:latest

Creating A Bucket With AWS CLI Container

A S3 bucket can be made with the following command:

awsd s3 mb s3://<globally-unique-bucket-name>

S3 buckets can be listed with:

awsd s3 ls

A S3 bucket can be removed with the following command:

awsd s3 mb s3://<name-of-your-bucket>

Here is an example from the terminal:

ishraque@ishraque-laptop:~/Desktop/GitProjects$ awsd s3 ls
ishraque@ishraque-laptop:~/Desktop/GitProjects$ awsd s3 mb s3://ibshafique-test-bucket
make_bucket: ibshafique-test-bucket
ishraque@ishraque-laptop:~/Desktop/GitProjects$ awsd s3 ls
2023-08-05 05:35:37 ibshafique-test-bucket

Conclusion

Numerous companies have embraced container-based deployment tools like Docker, leveraging their advantages in application development and deployment. Running the AWS CLI from within a container harnesses the benefits of containers, such as enhanced portability, isolation, and security. If you have anything to share, please feel free to comment.

References:

Distributing Your Application Traffic: The AWSome Way!

Md. Ishraque Bin Shafique — Sun, 09 Jul 2023 04:43:13 +0000

Load balancing involves evenly distributing incoming data traffic among a group of backend computers, often referred to as a server pool or server farm.

In order to effectively handle a large volume of concurrent user or client requests, high-traffic websites must consistently deliver accurate text, photos, multimedia, and application programs. To follow best practices in digital computing, it is often necessary to add additional servers in a cost-effective manner to handle these high loads.

A load balancer acts as a "traffic officer" positioned alongside the servers. It directs customer requests to all the web servers capable of satisfying those requests, optimizing efficiency and ensuring resilience. This approach prevents any single server from being overloaded, which could potentially degrade its performance.

In the event of a server failure, the load balancer automatically redirects requests to the remaining functional web servers. Once a server is assigned to a server group, the load balancer begins routing responses to that server.

Here are a few key reasons why load balancers are essential:

Enhanced Performance: Load balancers distribute traffic across multiple servers, preventing any single server from being overwhelmed with requests. By evenly distributing the load, they ensure optimal resource utilization and reduce the risk of server congestion, thereby improving the overall performance and responsiveness of applications.

High Availability: Load balancers play a crucial role in ensuring high availability of applications. If one server becomes unavailable due to hardware failure, maintenance, or any other reason, the load balancer can redirect traffic to other healthy servers, minimizing downtime and providing uninterrupted service to users.

Scalability: Load balancers enable horizontal scaling, which means adding more servers to handle increased traffic. As the demand for an application grows, load balancers can distribute the load across the expanded infrastructure, allowing for seamless scalability without affecting the user experience.

Fault Tolerance: Load balancers can detect if a server becomes unresponsive or fails and automatically redirect traffic to other healthy servers. This fault tolerance mechanism helps maintain the availability of applications even in the presence of server failures.

SSL Termination: Load balancers can handle SSL/TLS encryption and decryption, offloading the resource-intensive task from backend servers. This feature improves server performance and simplifies the management of SSL certificates.

Traffic Management: Load balancers offer various traffic management capabilities, such as session persistence, content-based routing, and request routing based on server health. These features allow for efficient distribution of traffic based on specific criteria, optimizing resource allocation and providing a better user experience.

What is Elastic Load Balancer (ELB)?

An Elastic Load Balancer (ELB) is a service provided by AWS that automatically distributes incoming application traffic across multiple resources, such as Amazon EC2 instances, containers, or IP addresses. It acts as a single entry point for clients and efficiently distributes the workload to ensure high availability, scalability, and fault tolerance.

The term "elastic" in Elastic Load Balancer refers to its ability to dynamically scale and adapt to changing traffic patterns and resource availability. These are the types of Elastic Load Balancers offered by AWS:

Classic Load Balancer (CLB)
Application Load Balancer (ALB)
Network Load Balancer (NLB)
Gateway Load Balancer (GWLB)

Classic Load Balancer (CLB): The CLB provides basic load balancing capabilities and is suitable for applications that require simple load distribution. It operates at the transport layer (Layer 4) of the OSI model, distributing traffic based on network-level information such as IP addresses and ports.

Application Load Balancer (ALB): The ALB operates at the application layer (Layer 7) and provides advanced load balancing features. It can intelligently route traffic based on content, such as HTTP headers, URL paths, or request methods. ALB is well-suited for modern web applications with multiple microservices.

Network Load Balancer (NLB): The NLB operates at the transport layer (Layer 4) and is designed for high-performance, low-latency scenarios. It can handle millions of requests per second while maintaining ultra-low latencies. NLB is suitable for TCP, UDP, and TLS traffic.

Gateway Load Balancer (GWLB): The GWLB operates at the network layer (Layer 3) and is primarily used for load balancing traffic between Virtual Private Clouds (VPCs), AWS Transit Gateways, and on-premises networks. It offers highly scalable and efficient load balancing capabilities, distributing traffic across multiple endpoints such as Virtual Private Gateways (VGWs) and Network Load Balancers (NLBs). With GWLB, users can achieve advanced traffic management, source IP affinity, and security integration for your network infrastructure. It helps ensure reliable and efficient distribution of network traffic across different environments, enabling high availability and fault tolerance.