AWS Savings Plan Service:

Savings Plan is a new commitment for discount model that applies up to 72 percent discount (vs on demand) on Amazon EC 2 and AWS Fargate usage They are much
more flexible than Reserved Instances, illustrated in the table below.

AWS-Savings-Plan

 

Similar to RIs, Savings Plans come in 1 year or 3 year terms, the commitment in each hour cannot be saved to be used in the next hour if no matching no demand instances were running, and will first apply benefits to resources in the account it was purchased in then share any remaining benefits with other linked accounts Different to RIs, Savings Plans discounts will first apply to on demand resources with the highest discount and they apply automatically to matching resources without manual work This automatically applied flexibility allows customers to purchase Savings Plans before waiting for other cost optimization work (e g right sizing) to complete.

AWS-Savings-Plan2

Services that should still use RIs for a discount are…
•Amazon RDS
•Amazon Redshift
•Amazon ElastiCache
•Amazon Elasticsearch
•Amazon DynamoDB
•Amazon CloudFront

5 Pillars for AWS Cost Optimization:

AWS cost optimization pillar details are mentioned below.

1. Right Sizing:

  • Select the right instance for your performance requirements.
  • Look at your instances memory, CPU, Network etc.. to indentify the instances which can be downsized.
  • Use Cloud watch to track metrics and setup alarms to react dynamically.
  • Ensue you provision resources based on your project demand.

2. Increasing Elasticity:

  •    You can optimize cost to meet dynamic needs using Autoscaling feature and turn resources off when they are not needed.
  •   Use AWS instance Scheduler service to schedule the EC2 instances based on requirement. Eg: You can turn off test/Dev instances on off business hours.
  •  Enforce tagging strategy for better visulization.

3. Chosse the right pricing model:

  •    Choose the right pricing model to optimize your costs based on the type of workload. Eg: Reserved, Ondemand and Spot types.
  •    Use cost explorer and trusted advisor to verify the cost pattern and recommendations on cost optimization.

 4. Optimize Storage:

  •    AWS provides multiple storage tiers and pricing designed to meet performance. By identifying the most appropriate storage for specific types of data can reduce your expnses.

Eg: S3, EBS, EFS, Storage Gateway.

5. Measure and Monitor:

  •  Monitor your environment using AWS Cloudwatch, Cost explorer and AWS trustedAdvisor.
  •  Define metrics, set targets, enforce tagging and cost allocation tagging and review them regulalrly.

 

 

 

 

 

Google Cloud resource hierarchy

Google-CLoud-Hierarchy

The Organization resource:

The Organization resource represents an organization (for example, a company) and is the root node in the Google Cloud resource hierarchy. The Organization resource is the hierarchical ancestor of project resources and Folders. The Cloud IAM access control policies applied on the Organization resource apply throughout the hierarchy on all resources in the organization.

Google Cloud users are not required to have an Organization resource, but some features of Resource Manager will not be usable without one. The Organization resource is closely associated with a G Suite or Cloud Identity account. When a user with a G Suite or Cloud Identity account creates a Google Cloud Project, an Organization resource is automatically provisioned for them.

A G Suite or Cloud Identity account may have exactly one Organization provisioned with it. Once an Organization resource is created for a domain, all Google Cloud projects created by members of the account domain will by default belong to the Organization resource.

 

The Folder resource

Folder resources provide an additional grouping mechanism and isolation boundaries between projects. They can be seen as sub-organizations within the Organization. Folders can be used to model different legal entities, departments, and teams within a company. For example, a first level of folders could be used to represent the main departments in your organization. Since folders can contain projects and other folders, each folder could then include other sub-folders, to represent different teams. Each team folder could contain additional sub-folders to represent different applications. For more details about using folders, see Creating and Managing Folders.

If Folder resources exist in your organization and you have appropriate viewing permissions, you can view them from the Google Cloud Console. For more detailed instructions, see Viewing or Listing Folders and Projects.

Folders allow delegation of administration rights, so for example, each head of a department can be granted full ownership of all Google Cloud resources that belong to their departments. Similarly, access to resources can be limited by folder, so users in one department can only access and create Cloud resources within that folder.

The Project resource

The project resource is the base-level organizing entity. Organizations and folders may contain multiple projects. A project is required to use Google Cloud, and forms the basis for creating, enabling, and using all Google Cloud services, managing APIs, enabling billing, adding and removing collaborators, and managing permissions.

All projects consist of the following:

  • Two identifiers:
    1. Project ID, which is a unique identifier for the project.
    2. Project number, which is automatically assigned when you create the project. It is read-only.
  • One mutable display name.
  • The lifecycle state of the project; for example, ACTIVE or DELETE_REQUESTED.
  • A collection of labels that can be used for filtering projects.
  • The time when the project was created.
  • In order to interact with most Google Cloud resources, you must provide the identifying project information for every request. You can identify a project in either of two ways: a project ID, or a project number (projectId and projectNumber in the code snippet).

    A project ID is the customized name you chose when you created the project. If you activate an API that requires a project, you will be directed to create a project or select a project using its project ID. (Note that the name string, which is displayed in the UI, is not the same as the project ID.)

    A project number is automatically generated by Google Cloud. Both the project ID and project number can be found on the dashboard of the project in the Google Cloud Console.

 

F5 Device Backup and Restore:

Prerequisites:

To take F5 device backup you should have following pre-requisites.

  • You have administrator, resource administrator, or root-user access to the BIG-IP system.
  • You have access to the Configuration utility or TMOS Shell (tmsh).
  • You have Advanced Shell (bash) terminal access privilege to the BIG-IP system.

Description:

This article describes how to back up and restore your BIG-IP 11.x through 15.x configuration data using a UCS configuration archive. The UCS archive, by default, contains all of the files you need to restore your current configuration to a new system, including configuration files, the product license, local user accounts, and SSL certificate/key pairs.

File names and location:

By default, the BIG-IP system saves the UCS archive file with a .ucs extension, if you do not include the extension in the file name. You can also specify a full path to the archive file, and then the system saves the archive file to the specified location. If you do not include a path, the system saves the file to the default archive directory, /var/local/ucs.

Command to take a Backup:

 

tmsh save sys ucs /var/local/ucs/<devicename-date>.ucs

Licensing:

The BIG-IP license is associated with a specific hardware serial number. The UCS archive contains the license file of the system on which you saved the configuration.

To successfully install a UCS archive file on a BIG-IP system, you must perform one of the following actions:

  • Restore the UCS archive to the same system from which you saved it.
  • Relicense the BIG-IP system after you restore the UCS archive. You must do this when restoring the UCS archive to a system that was replaced due to a Return Material Authorization (RMA) in order to associate the license to the new serial number.Note: You are allowed to associate the license to a new serial number only in the event of an RMA.
  • Save the license file prior to restoring the configuration from another system, and then copy the license file back.
  • Use the following syntax to install the UCS archive using the tmsh no-license option:tmsh load /sys ucs <path/to/UCS> no-license

    For example, you use the following code to install the UCS archive named MyUCS:

    tmsh load /sys ucs /var/local/ucs/<devicename-date>.ucs no-license

 

Google Cloud Kubernetes Basic Commands To Deploy An Application:

  1. First create a Kubernetes Cluster K1

gcloud container clusters create k1

k1.jpg

2. Deploy an app from google container registry

kubectl run app –image gcr.io/google-samples/hellp-app:1.0

k1-1

3. You can see the deployment status using the below command

  kubectl get pods

k1-2

4 Now scale up replicas to 4 using the below command

kbectl scale deployment app –replicas 4

k1-3

5. Verify the replica status using the command kubectl get podsK1-4

6. Now expose your app to the world by exposing the port 80

kubectl expose deployment app –port 80 –type=loadbalancer

k1-6

7. Now verify the website using cluster public IP

K1-7