Devops Assgniment 101

DevOps Assignment 101

1. AWS Cost Optimization

a) The AWS Cost Explorer report signifies a range of costs starting from services like S3 , EC2, lambda
functions, WAF, and many more.
- The total expenditure per service is as follows:

● Lambda: $418.41 (total)

● EC2 Instances: $135.57 (total)

● S3: $95.31 (total)

● CloudWatch: $73.69 (total)

● WAF: $61.98 (total)

● Elastic load balancing: $39.82 (total)

● VPC: $26.08 (total)

● Support (Business): $100 (fixed cost)

● Tax: $186.85 (fixed cost)

Edit with the Docs app
● Total cost: $1232.07
Make tweaks, leave comments, and share
with others to edit at the same time.
Though AWS services like VPC (virtual private cloud), WAF ( Web Application Firewall ) and ELB are some that
can’t be compromised, there's not that much to save on these if application security and availability are something
of higher importance . NO THANKS GET THE APP

➔ But there are some basic cost optimization areas where a considerable sum can be saved , Starting from
EC2 Instances ($135.57) which commutes a significant amount, it can be reduced if we talks in terms of
Right-sizing Instances: Analyzing the instance sizes and types to ensure they match the workload
requirements. For example, switch to smaller or burstable instances (T3 or T4) if full performance is not
required.
➔ Although the 2nd method for EC2 cost optimization is not recommended but can be considered if you
have fixed or sustainable compute usage, then we can go for Reserved or Spot Instances: where we can
save up-to 30%-50% compared to on-demand pricing, with minimal trade-offs in performance.
➔ Moving on to the next area CloudWatch ($73.69) , which in terms does not contribute much but is a
considerable usage in terms of necessity , CloudWatch is crucial for monitoring and alerting, but excessive
 log retention or unnecessary metrics and dashboards can inflate costs. We can “Reduce Log Retention
Period” and “Disable Unnecessary Metrics” to save up on costs .
➔ The last but not least area is S3 Storage ($95.31) , S3 is a service which we can’t control much as its a
basic need in AWS to store our files , However S3 costs can accumulate due to storage and retrieval fees,
especially for infrequently accessed data , We can take necessary steps like Transition to Cheaper
Storage Classes Moving infrequently accessed data to lower-cost storage tiers, saving up-to 30%-70%.

➔ We can save as much as $90-$150 with minimal impact on service quality.

● EC2: $40-$70 through right-sizing and reserved instances.

● CloudWatch: $20-$30 by reducing logs and unused metrics.

● S3: $30-$50 by transitioning to Glacier or using lifecycle policies.

2. Monitoring and Alerting :

* Services used - Lambda Function , S3 bucket , EC2 Instance , AWS Cloudwatch , SNS [ Simple Notification
Service]

Short Summary:

As mentioned in the assignment , I designed a custom dashboard for EC2, Lambda function, and S3 particularly
created 3 cloudwatch alarms, one for each with different metrics, and attached a single SNS topic to them.

FIg 1.1 In the given image, all 3 utilities have been shown including EC2 with CPU utilization Metric, Lambda
function with error metric and S3 with the ObjectCount metric.
Fig 1.2 - In the image you can see all the three alarms created with AWS CloudWatch Alarms

Metrics -

lambda function - Trigger an alarm when a total of 1 error gets noticed within 5 minutes.

EC2 - Trigger an alarm when CPU utilization is above 50 % within 5 minutes .

S3 - Trigger an alarm when a total of 5 Objects get uploaded to S3 in a day .

Fig 1.3 - In the given figure you can see the SNS Topic created [ec2cpuUtilization] with a subscription to my mail
id .

Working -

Fig 1.4 - SNS generating an Email notification to my mail id for Lambda Function threshold.
Fig 1.5 - Clearly states SNS Email Notification being generated for more than 50% CPU utilization.

- With the help of AWS SNS we can send notifications to a wider audience by using SNS Topics and
subscriptions. First of all, we create an SNS topic and later attach a Subscription to it, In which
confidential information is stored of customers like mail , phone no etc.

- After Creating a SNS Topic and Subscription , We go and create cloudwatch alarms and attach the SNS
topics to them , and to test whether your SNS is working , we define cloudwatch metrics and set alarms
and once the alarms triggers , hence Notifications gets generated .

3. CloudFront Optimization for [Link] Application:

Talking in terms of connectivity and faster connections, for most of us, Cloudfront has been the reliable and go-to
option, but talking in terms of accessibility, it offers a range of features which in-depth offer a range of benefits,
like:

a) High Availability: it surely is known for it and we can make sure of it by utilizing Multiple Edge locations as
much as we can , multiple edge locations are used to minimize downtime and latency for users globally.

➢ To ensure failovers to minimize we can Configure CloudFront origin failover with multiple origins
(e.g. primary and secondary Lambda@Edge functions or S3 for static assets). This ensures that if the
primary origin fails, the secondary origin can serve content.

➢ However for Failover Scenario Testing we can definitely Simulate origin failure by intentionally taking
down the primary Lambda function or making it unreachable and monitoring the secondary origin and
checking for continuity in serving content without errors , this fully servers the purpose of testing at its
best, and for the last check, we can always check AWS CloudWatch to confirm that the failover occurred
by tracking origin status metrics.

b) Bot Attack Mitigation: One of the key scenarios whenever operating a CDN , you always will be tried to get
hacked , SQL injections , DDOS attacks, and many more which we even do not know till yet but in order to server
your Application content smoothly and securely .

AWS has a range of services to server the purpose , starting from WAF (Web Application Firewall) , we can
use WAF with rate-based rules to block common attack patterns like XSS etc. and rate-limit requests from
malicious IP addresses, eg- block an IP if it exceeds 1,000 requests within a 5-minute window.

To make sure of the maximum security and availability of your [Link] Application , we can use
AWS Shield (Standard) which is by-default included with CloudFront for protection against DDoS attacks.

Rate limiting is preferable as it serves its purpose in preventing bot attacks, reducing load on the origin servers,
especially against resource exhaustion attacks like DDoS improving performance and availability.

c) SEO Crawler Allowance : when talking in terms of who sees what , User-Agent Filtering and IP
Whitelisting plays major roles in it , As AWS WAF rules can allow known SEO crawlers like Googlebot,
Bingbot based on their User-Agent strings while keeping eyes- up for malicious bots with the help of Use IP lists
from AWS WAF or AWS Firewall Manager to allow known IP ranges of legitimate crawlers only .

➢ User-Agent strings: SEO crawlers provide specific strings like Googlebot, where Rules in AWS WAF
can allow requests matching these User-Agent patterns.

➢ IP Lists: its a healthy practice to Maintain a list of known IP ranges for legitimate crawlers, allowing
requests from these IPs only while blocking unknown sources.

d) Monitoring:
Monitoring one of the key aspects of security and checking the reliability of our Application , we often have many
options to serve individual roles for different services.

Talking for CloudFront we have:

CloudFront Metrics: which does the following -

➢ Cache Hit Ratio: Indicates how often content is served from cache, reducing origin server load.

➢ Requests and Errors: Track the number of requests and the error rate .

➢ Latency: Measure the time taken to serve content from the edge to the end-user.

Also, we can use Lambda@Edge Metrics for monitoring purposes

It provides the following -

➢ Invocation Count: Monitor the number of function executions.

➢ Execution Errors: Track any errors from the Lambda@Edge functions.

Logging and Analysis Setup:

➢ Enable CloudFront access logs to capture detailed information about each request, such as User-
Agent, IP, request URI, and response status.

➢ Use AWS CloudWatch Logs for tracking errors and detailed analysis.

➢ AWS CloudWatch Alarms can be set up to notify when metrics eg - error rates exceed defined
thresholds.

e) Site Loading Time Optimization:

One of the crucial factors while running your application using a CDN is the time taken by the website to get
loaded, it often defines the quality of work and is a benchmark for companies to mark their standard of working,
again a key aspect to be taken seriously when deploying your application .

Three methods to reduce site loading time are described below:

 ➢ Enable Gzip/Brotli Compression: CloudFront can compress text-based assets (HTML, CSS,
JavaScript) using Gzipor Brotli to reduce the size of transferred data.

➢ Cache Static Content: Use long cache durations for static assets (e.g - images, CSS, JavaScript) with
appropriate cache control headers to maximize cache hit ratio.

➢ HTTP/2 and QUIC Support: Enable HTTP/2 or HTTP/3 (QUIC) to improve connection efficiency,
reduce latency, and speed up the loading of multiple resources simultaneously.

We can observe measuring impact by:

➢ Use AWS CloudWatch metrics to monitor cache hit ratio and latency.

➢ Track Core Web Vitals using tools like Lighthouse or WebPageTest to see the impact of optimizations
on real user performance.

➢ Compare metrics before and after applying optimizations to validate improvements in load time and
performance.

Submitted by - Pratham choudhary

Phone no - +91 - 8824262926

Email - pratham.21jics139@[Link]