A quick walkthrough on how to create new ECS cluster
New ECS Cluster!
In our previous article, we got acquainted with Amazon ECS service theoretically. In this article, we will walk you through steps to create a new ECS cluster.
ECS Cluster is a logical grouping of ECS instances on which containerized application can be orchestrated.
This article is using below design to provision ECS cluster.
Now, on the right-hand side click on the Create Cluster button
Here a user should be choosing the cluster template for the new cluster
Cluster template choice
Three templates mentioned here are :
Networking only
No ECS instances.
All tasks will be launched using the Fargate launch type!
EC2 Linux + Networking
Deploy with Linux ECS instances
EC2 and Fargate both launch types available for tasks
EC2 Windows + Networking
Deploy with Windows ECS instances
EC2 and Fargate both launch types available for tasks
Most of the time, EC2 Linux + Networking should suffice the requirement. Select the appropriate template and click the Next Step button.
On cluster configuration screen various details can be filled.
Cluster name
Create an empty cluster is an option to create clusters with no ECS instances.
Then, instance configurations should be defined.
ECS Instance configuration
Under instance configurations choose :
Provisioning model: Choose billing type of instances (on-demand or spot)
Number of instances
EC2 AMI ID. The dropdown allows choosing Amazon Linux AMI.
Root EBS size
Key Pair: If you want to log into ECS instances. If not then choose None.
Next section allows network configuration.
ECS cluster networking
By default setup present to create a new VPC to be used for this ECS cluster. But, if you wish to use existing or already created VPC then choose it from the dropdown.
In my case, I have a custom VPC created already. So I will use it from drop down. While using existing VPC, you need to choose which subnets to be used to place container instances and which security group should be applied to them.
Using existing VPC in ECS cluster
I used my existing VPC along with 2 private subnets in different AZ and security groups which allows SSH and HTTP traffic to instances. Since I will be testing webserver containers on this cluster. This SG should allow the ports you will be using in your containerized applications. Also, they should be allowing traffic from only intended sources.
Finally, IAM roles to be defined which will be attached to ECS instances.
Tags can be applied to instances here. Also, if container-level monitoring needs to be enabled it can be done here. Click Create and a cluster will be created in a few.
ECS Cluster creation complete!
ECS uses CloudFormation in the backend to deploy the whole stack. It can be verified in the Launch status or CloudFormation service dashboard as well.
ECS CloudFormation stack!
Now, click on the View Cluster button and new ECS cluster details will be presented on screen.
Cluster info
Both ECS instances are registered to cluster as well at this stage. Those Cluster ECS instances can be viewed from the EC2 dashboard as well.
ECS instances.
These instances will be named automatically by ECS. And if you observe those are deployed in different AZ (supplied at cluster creation) and assigned with SG as well.
So the ECS cluster is up and ready along with both ECS instances registered to cluster and ready to run tasks!
Issue: ECS instances not registering in ECS cluster
One of the common issues seen at this stage is although EC2 instances are running fine they do not get registered to the ECS cluster. You do not see them in the ECS Instances tab on the cluster details page.
Cause: This is caused when ECS instances have not to route to the internet. ECS agent on the instances needs to reach ECS public endpoint to register the instance in the ECS cluster. Since no route to the internet, they can not reach ECS public endpoint and can not register to cluster.
Solution: If instances are launched in a private subnet then they should be able to reach the internet using NAT gateway or HTTP proxy. Or you can configure VPC endpoints for Amazon ECS and route traffic from instances to ECS without giving them internet access at all.
If instances are launched in public subnet then make sure auto-assign public IPv4 address is enabled and the instance is allocated with public IPv4 address. Also, the subnet is associated with a routeing table that has a route to Internet Gateway.
An article about Amazon ECS foundational topics for beginners
ECS basics.
Amazon ECS stands for Amazon Elastic Container Service. We will walk you through ECS bit by bit to help you understand what is ECS. We will touch base below topics –
What is ECS?
Use cases for ECS
ECS component concepts
Pricing
What is ECS?
Amazon ECS is a fully managed container orchestration service. It aimed to do all the heavy lifting of managing container orchestration clusters for customers while customers can focus on developing their containerized application.
If you are new to containers, please read our container articles –
In a nutshell, ECS is Amazon’s own homegrown container orchestration service. If you have learned about Docker Swarm then consider ECS as Amazon’s version of Swarm to manage your containers.
Amazon’s other service ‘Elastic Beanstalk’ actually using ECS in the background to spin up clusters of containers running your desired applications.
Where to use ECS?
In this section, we will see the use cases of Amazon ECS. This service sees uses cases mainly in two sectors:
Microservices
Application following microservices architecture approach can make most of ECS! The Microservices approach aims at decoupling the design so that architecture is failure-proof, can be scaled at the service level, etc. These benefits can be leveraged using containers! Containers can be spun using immutable images, tested locally, scaled using ECS clusters, each service can be defined using different tasks, and pipelined using CI/CD.
Batch Jobs
Since containers are easy, quick to spin up, and terminate they are perfect for running batch jobs. Using containers you can cut down your time to spin up EC2 instances for processing jobs, save time for their terminations, get away with the huge billing associated with them. And all of this can be well managed by AWS in the backend when you spin your containers using ECS. Fargate launch type in ECS is well suited for batch jobs since it doesn’t require to spin us even EC2 container instances. It’s like serverless and you pay for the resources you used and the time you used them.
ECS concepts
With a little bit of foundation let’s dive into a few ECS concepts. While using ECS you will come across the below terms –
Clusters
Container Instance
Task definitions
Launch types
Services
Amazon ECR
Cluster
Cluster is a grouping of tasks and/or services. These tasks/services are run on container instances (in case of EC2 launch types), in that case, EC2 container instances also come under this logical grouping called a cluster. You can have one or more clusters in your account.
Container instance
When you are running a task/service using the EC2 launch type, it will run on EC2 instances. These instances (Linux/Windows) are created when you are creating clusters. Basically, those are normal EC2 instances with docker software, ECS agent preinstalled. You can even connect to them like any other EC2 instances using SSH or RDP. You can view them in the EC2 dashboard of your account as well. Under ECS those will be referred to as container instances.
Tasks definitions
Task definitions are a collection of settings required to run a container in the Amazon ECS cluster. It has numerous parameters that you can configure including container definitions as well. The core of the task definition is container definition and launch type, where you define how your container should be instantiated. In short, you can visualize it as a container Dockerfile.
Launch types
It’s a type of compute on which containers should be instantiated. Amazon offers 2 launch types –
EC2 Launch type
Runs containers on cluster container instances
You will be billed for EC2 instances, not the container runtimes
Fargate types
Runs containers on serverless/managed infra in the backend
You will be billed on the number of resources used and for the duration, they are used
Services
Services are the schedulers that are responsible to maintain the desired number of containers of running tasks in a cluster. So container instantiation and termination to match the given conditions is done by services.
Amazon ECR
It’s Amazon Elastic Container Registry. It’s your own private container registry hosted on AWS. You can use IAM authentications to control the access to ECR and it can be connected to various apps for CI/CD purposes. Container definitions under tasks can refer to ECR images securely.
Pricing
ECS is a free service just like cloudformation! You will be billed only for the resources you deployed/used for using ECS.
When creating clusters, the container instance type should be selected. As I explained earlier these are normal EC2 instances that can be viewed in the EC2 dashboard as well. So they will be billed like any other EC2 instances (instance types and time for which they are running).
Another billing you can incur is when running containers on fargate launch type. It’s considered as pretty costly than the EC2 launch type and hence should be used only for short-running tasks. You will be billed for the number of resources you are using and the duration for which they are being used.
If you are leveraging ECR to maintain your own private container image repository then ECR charges will be applied to your account as well. ECR charges include two components :
Storage. Billed for total storage being used by all of the images
Data transfer. Data in and out bills i.e. data transferred from/to ECR during image pull/push operations
Conclusion
That’s pretty much about ECS basics. So, if you are working on a self-hosted container environment, it’s time to move to ECS and let AWS manage the stuff for you while you can concentrate on developing apps in containers!
Everything you need to know about Bastion host in AWS infrastructure.
All about bastion host!
In this article, we will touch base below points in context to bastion host:
What is a bastion host?
What is the role of bastion host in AWS infrastructure?
How to deploy and configure a bastion host?
Lets start with the introduction to bastion host.
What is bastion host?
A bastion host is a Windows or Linux machine sitting in the Public subnet of your AWS infrastructure. It’s a machine that is used to securely access the rest of the infrastructure for administration purposes. Since you don’t want to expose everything in your infra to the internet, the bastion host will do that heavy lifting and hence securing the infrastructure.
As this host is exposed to the internet it is recommended to implement a strong system hardening on this machine. Secure this machine at OS level with all available hardening techniques since this machine is a gateway to your whole infrastructure.
What is the role of bastion host in AWS infrastructure?
As explained above, the bastion host will be used to access the rest of the infrastructure. for administrative tasks. Sometimes, cloud newbies treat bastion host as a way of accessing instances in the private subnet only. But that’s not it. One should block access (SSH or RDP) to instances in the public subnet as well and allow them only through the bastion host.
This way one can secure administrative level access to instances in public and private subnets. And this is the recommended practice. Your all instances no matter they are in which subnet should be accessible via bastion host only.
In a nutshell, bastion hosts used to secure administrative access to instances in private and public subnets.
How to deploy bastion and configure host?
For this exercise, we will deploy Linux bastion host in the same architecture which we used while creating our last custom VPC. In the case of the Windows environment, SSH can be replaced with RDP, and Linux bastion can be replaced with a Windows machine. Bastion host deployment and configuration can be summarised as –
Deploy EC2 instance in the public subnet (that’s your bastion host)
Create a new security group which allows SSH traffic from bastion to destination public and private subnets
Attach security group to instances
Lets dive into it.
For step 1, I deployed Amazon Linux 2 EC2 instance. You can even use customized AMI which has all hardening already done, logging enabled for a bastion, etc things. But for this exercise, I will be using normal Amazon Linux AMI. The SG created along with this launch should allow SSH traffic from 0.0.0.0/0. Let’s tag this SG as bastion-sg
Now, it’s time to create a custom security group to allow bastion traffic to instances. Custom SG is handy so that you can attach it instances while launching and you don’t need to manually edit instances security groups to allow bastion traffic. On other hand, in this SG we are allowing traffic from SG of bastion host. So even in future IP of bastion host gets changed (or even bastion host gets replaced) we don’t have to edit any SG settings anywhere. The only thing you need to keep in mind that, you need to deploy a new bastion host with the existing bastion SG.
On the left navigation plane, click on Security Groups
Now on the security groups page, click on the Create security group button
You will be presented with the below screen :
Create custom security group
You need to fill in below details-
Security group name: For identification
Description
VPC: Select your VPC from the dropdown.
Inbound rules: Allow SSH from SG of bastion host (bastion-sg from step 1)
Outbound rule: Keep it default. Allow all traffic.
Tags: optional.
This SG (allow-bastion-traffic-sg) to be attached with instances launched in public/private instances. Make sure you remove the existing default SG attached to them which allows SSH traffic from 0.0.0.0/0 OR edit an inbound rule in the existing SGs which allows this.
It confirms that SSH traffic to all instances in your VPC will be allowed only from the bastion host.
At this stage, bastion host SG should have below inbound rule:
Inbound rule for bastion host SG
And instances in VPC (any subnet) should have below inbound rule where the source is bastion-sg (SG of bastion host):
Inbound rule for instances
We are all set! It’s time to test. Below are 2 instances for testing. Once is the bastion and another is launched in the private subnet. This could work with an instance in the public subnet as well but they will be having public IP allocated as well so to avoid confusion I took an instance from the private subnet.
Instance details
I logged in to the bastion host using its public IP. Remember, we deployed bastion host in public subnet hence it will get public IP on launch. And since public IP reachable over the internet, I can directly putty to public IP of bastion host.
Once I am in the bastion host, I tried to ssh to the private IP of an instance launched in the private subnet. Since instance is launched in a private subnet, it won’t be allocated with the public IP so it’s not reachable over the internet. So I have to use a bastion host to get into it and it worked!
Note: I used PuTTY SSH agent forwarding here so I did not have to supply the SSH key in command when connecting to the private instance.
SSH from bastion to private instance
In such a way you can secure administrative access to your instances in VPC (inside public and private subnet) by using bastion hosts.
A quick article on AWS VPC creation along with screenshots.
VPC Creation!
In this article, we will be creating a custom VPC in the AWS account and check all available options along with screenshots. You must be aware that every AWS account comes with a default VPC already created for you. Few of the AWS services require the existence of this default VPC while it’s recommended to have custom VPC for some. So without further delay, let’s start with some VPC introduction.
What is VPC?
VPC stands for Virtual Private Cloud. It’s your own isolated network section in the AWS cloud. It’s safe to say it’s your own small cloud within the AWS cloud! VPC can be visualized as the outer boundary of your account in AWS within which you deploy all your cloud resources.
For this exercise we will try to implement below design in AWS.
Now on the VPC page, click on the Create VPC button
You will be presented with the below screen :
Create VPC screen
Here you can fill in below details-
Name tag (optional): For identifying your VPC within your account.
IPv4 CIDR block: This CIDR block will be available throughout your VPC. Make sure you choose wisely to support your IP appetite. You can later add 4 more secondary CIDR blocks to VPC. Plan accordingly.
IPv6 CIDR block: Depending on your requirement. You can specify your own block or use Amazon assigned one.
Tenancy: Choose how your instances will be launched.
Default: Follow the tenancy attribute defined at instance launch
Dedicated: Regardless of tenancy type selected at instance launch, always launch an instance on dedicated hardware.
Tags: Add tags to manage billing, identification, etc. If you choose the Name tag in the first field then it will appear here automatically.
Once you fill everything, click Create VPC and your VPC will be created. You should be seeing a confirmation screen-
VPC Creation confirmation
Now, your VPC is created. You need to remember below points when you create custom VPC with this method :
Along with this VPC below resources are created automatically –
1 NACL
All traffic is allowed in and out with ALLOW rule with rule number 100
Also has the * DENY rule which means if the packet does not match any of the specified rules it will be denied.
1 DHCP options set
With Internal domain name
No NTP servers defined
Name servers pointing to Amazon-provided DNS
You can not edit it. You can delete this one and create a new one.
1 route table
All traffic destined to remain within VPC i.e. Target defined as local
1 security group
All Traffic allowed in inbound and outbound rules.
You need to create below manually –
Subnets
Internet gateway (If Public subnet is created)
NAT gateways (For internet access to Private subnet)
So to launch an instance in this VPC you have to create a subnet first.
How to create subnets in custom VPC?
Lets go ahead and create subnets in our custom VPC.
Subnet creation needs proper planning. You need to decide on how you want to use your available IP pool. For example, since we have used the 10.0.0.0/24 CIDR block while creating VPC, we have 256 IPv4 addresses available in our VPC. I plan for –
Use of 2 availability zones for HA
Each zone should have 1 public and 1 private subnet.
IPs to be spread across all subnets equally.
So in a nutshell I have to spread 256 IPs in 4 subnets. Also, you should be aware that in each subnet 5 IPs are not available for use –
First IP: Network address
Second IP: AWS VPC router
Third IP: AWS DNS
Fourth IP: Reserved by AWS for future use
Last IP: Broadcast and since the broadcast is blocked in AWS this IP can not be used.
Now, 4 subnets that mean 20 IPs are reserved and not available to us. So in total, we have 246 IPs available to use when we create below 4 subnet –
10.0.0.0/26
10.0.0.64/26
10.0.0.128/26
10.0.0.192/26
Calculation is done! Its time to create subnets in AWS console.
Note: For CIDR notation understanding use https://cidr.xyz/ and for subnetting use online subnet calculators.
On the same VPC AWS console, in the left navigation pane click on Subnets. Then click on the Create subnet button. You should see below screen –
Create subnet screen
Here we need to fill in –
Name tag: For identification purpose
VPC: Select your custom VPC from the dropdown.
Availability Zone: Select desired AZ from drop-down
IPv4 CIDR block: Choose from your calculation (which we did earlier)
Once done, click Create button. Your subnet should be created and you will see confirmation like this –
Subnet created.
Repeat the same process to create the rest of the subnets. Once all subnets are created you should see them in the subnet dashboard.
Subnet list
If you observe here, all subnets will be associated with the same route table which was created during VPC creation. This needs to be changed.
For public subnet, we need to create an internet gateway, create a custom route table who has a route to this IG, and then associate public subnets to that route table. This way we will enable internet connectivity for public subnets.
Optional: You can enable Auto-assign IPv4 setting in Public subnet settings which will enable auto-assign public IPv4 addresses to instances launched in this subnet.
How to create Internet Gateway and associate them with subnet?
On the left navigation plane, click on Route Tables
Now on the route tables page, click on the Create route table button
Where you just need to add a Name tag for it, select custom VPC from the drop-down and click the Create button
Your route table will be created.
Now go back to Route Tables screen and select the recently created route. And click on Routes tab
Edit routes in route table
In the edit route screen, you need to add a route for destination 0.0.0.0/0 with a target to a recently created internet gateway. And then click Save routes. Make sure you keep the existing local route since it’s needed within VPC communication.
Adding internet route to route table
Now the internet route table is ready. We need to associate it with the public subnets created in earlier steps.
Select Subnet Associations tab under same route table and click on Edit subnet associations button
Subnet associations
Select public subnets and click Save
At this stage, our subnets are properly segregated as public and private. Public subnets are associated with route table having a route to the internet and private subnet associated with route table having route for only within VPC communication.
The last piece of the puzzle is to create a NAT gateway for instances in the private subnet. Using NAT gateway, those instances can access the internet for downloading updates, etc. and yet they won’t be accessible from the internet i.e. not exposed on the open internet.
If you want absolute isolation from the internet for a private subnet then you can skip the NAT gateway topics.
Elastic IP availability is the pre-requisite for creating a NAT gateway. If you don’t have an Elastic IP allocated in your account, please get it allocated first.
On the left navigation plane, click on Elastic IPs
Now on the Elastic IPs page, click on the Allocate Elastic Ip address button
Where you just need to add a Network Broder Group for it and click the Allocate button.
Network broder group is a collection of AZs where allocated Elastic IPs will be available for use. In a nutshell, you will be choosing a region here since Elastic IPs are regional resources.
On the left navigation plane, click on NAT Gateways
Now on the NAT Gateway page, click on the Create NAT gateway button
Where you need to add a Name tag for it, Subnet, Elastic IP and click the Create internet gateway button
make sure you select public subnet here and Elastic Ip which we got allocated in the previous step.
NAT Gateway is now created. We need to create a custom route table which has a target to this NAT gateway. Follow the same procedure we seen above for IG and associate private subnet to this new custom route table.
Route to NAT gateway
Repeat the same [procedure to create NAT gateway in another Availability zone as well so that it can be tagged to private subnet in that AZ. Remember NAT gateway is not a regional resource. You need to create it per availability zone.
At this stage, both subnets are all set for instance deployments.
A public subnet is associated with a routing table having a route to the Internet gateway
A private subnet is associated with route table having a route to NAT gateway
This completes our custom VPC creation and we achieved the targeted design !
Step by step procedure to transfer domain from Godaddy to Route 53
Domain migration to Route 53
In this article, we will walk you through the migrating a domain from Godaddy to AWS Route 53. The process remains almost similar to even another domain registrar to Route 53 but I provided screenshots from Godaddy since I had a domain registered there which I transferred.
We will be migrating my other domain (shrikantlavhate.in) from Godaddy to Route 53 in this article. It’s a 5-6 days procedure where domain transfer approval will be held by the previous registrar. Its a failsafe so you can cancel the transfer if you have not initiated it or want to rollback your action.
Unlock domain for transfer
Login to your current registrar (in our case Godaddy) and unlock the domain for transfer. Goto Manage domains or domain settings and turn off domain lock.
In Godaddy navigation is – Products page > Domains > Click Manage
Then on the domain settings page, scroll down to domain lock where it says – ‘Locking prevents unauthorized changes, including transfer to another registrar. Domain lock: On‘
Click on Edit button beside it, and turn it off.
Now, your domain is unlocked for transfer.
Initiate transfer from AWS Route 53
To start with you should be having an AWS account (comes with 12 months free tier for new accounts). If you haven’t done this already then, go ahead and sign up for it. You will need a valid email address and credit card information during the signup procedure.
Once done, sign in to Route 53 management console. Click on ‘Registered domains‘ link in the left-hand side menu and then click ‘Transfer domain‘
Start your domain transfer in Route 53
If you missed unlocking your domain in the current registrar as mentioned above you will see the error here like domain can not be transferred to Route 53. Example below –
Domain transfer error
So ensure you have unlocked domain for transfer and punch in domain name in the wizard and hit check. It will confirm domain can be transferred now.
Domain is ready to transfer
Click on ‘Add to cart‘ and it will show you billing total on the right-hand side. Make a note that, AWS renews your domain for one year from its current expiry date during transfer and this renewal fee is also included in that billing total. Confirm and click ‘Continue‘
Domain transfer billing total
On the next screen you need to provide –
Authorization code
You can get this from current domain registrar portal
Nameservers
You can choose to keep the same nameservers currently being used by a domain. AWS will copy them.
Import from hosted one in Route 53 (if you have created it already)
Specify manually
In the Godaddy domain manager page, click on ‘Transfer domain away from GoDaddy‘ link to get authorization code. I choose to keep current nameservers for now.
Transfer authorization code and nameservers
On the next page, you need to fill in contact details. Note that these details will be publicly accessible from the WHOIS database. You can choose to opt-out of it by enabling ‘Privacy protection‘ at the end of the same page. But this option is not available for some domains like .in 🙁
You can define 3 different contact details for Registrant, Administrative, and Technical context. I choose to keep one for all.
Domain contact details
Once done hit the ‘Continue‘ button at the bottom of the page. On the next page, it will ask you to confirm all the details you filled in since the beginning. Choose here if you want to auto-renew your domain or not (this can be changed later as well) and accept the terms to complete your order.
Complete domain transfer order
That’s all. Your order has been placed and the billed amount will be debited from your card which you provided at the time of AWS account creation.
You will be presented with an informational page below which is self-explanatory.
Authorize domain transfer
You can verify domain transfer status be navigating to ‘Pending requests‘ in the left hand side menu.
Domain transfer status
In some countries credit cards can not be debited directly as OTP is mandated by their federal bank regulations. In such cases, you might see ‘action required’ status as below which itself tells you what to do. In my case it’s asking me to complete the billing transaction (using OTP).
Billing action required!
So, I completed the payment by navigating to AWS billing dashboard > Order and invoices > Verify and pay
After completing the payment, head back to Route 53 management console and verify the status. Allow some time for changes to propagate in system and status to update. Status should change back to ‘Domain transfer in progress: Waiting for the current registrar to automatically approve the transfer. This can take up to 10 days depending on the TLD and the current registrar. Only the current registrar can accelerate the process. (step 7 of 14)‘.
Domain transfer approval pending
Meanwhile, you will receive an automated email from your current domain registrar confirming if you initiated the domain transfer. And it also contains a link that you can use to cancel the domain transfer request. Since we did want to transfer a domain, no action required.
Now, you have to sit back and relax. Let the transfer period pass and then your domain transfer will be complete. Typically it takes 5-10 days to complete this transfer.
After 6 days I received an email from AWS that domain transfer is completed. I log in to Route 53 console and now I can see the domain is transferred to Route 53 completely.
Domain transferred to Route53
Since we choose to keep current nameservers while transferring the domain to Route 53, AWS will not create any hosted zone for your domain.
If you choose to opt for Route 53 as a DNS Manager for domain, then after transfer AWS will create public hosted zone in Route 53 automatically once transfer is complete. This public hosted one will has entries of SOA and nameserver. Note that you will be billed for 0.5$ per month for this hosted zone.
That’s it. We successfully transferred our domain from Godaddy to AWS Route 53.
A quick article on how to prepare for 1Z0-1085-20 Oracle Cloud Infrastructure Foundations 2020 Associate certification exam.
OCI Foundations Associate 2020
OCI (Oracle Cloud Infrastructure) Foundations 2020 Associate is a foundation level exam. If you are coming from another cloud service provider background then it will be a piece of cake for you. Being a foundation level exam will test you on a conceptual basis only.
Its a 60 multiple choice questions exam which you have to complete in 105 minutes. Approximately 2 minutes to spare per question which is pretty good enough for foundation level exam. Questions and answers are small so you don’t have to invest much time in reading and you can complete the exam well before time.
The exam costs $95 and the passing score is 68%. At the time of writing this article, due to the COVID-19 epidemic, Oracle announced course material and exam free of cost for a specific period of time. The exam currently available under online proctored mode from Pearson since most of the exam centers are closed in view of COVID-19 lock-down.
Read our another article about preparation for the AWS certification
Let’s walk through exam topics and points you need to consider while preparing for this certification. An exam guide from Oracle can be viewed here.
Exam topics are :
Cloud concepts
OCI fundamentals
Core OCI services
Security and compliance
OCI Pricing, billing, and support
Cloud concepts
If you are coming with a background of any other cloud provider like AWS, then you got it covered already.
You should be through with concepts of HA (High Availability), FT (Fault Tolerance) and the difference between them.
What is the cloud?
Know the advantages of cloud over the on-prem data center.
Get familiar with RTO and RPO concepts.
OCI Fundamentals
This topic covers basics of OCI i.e. how it is architected.
Understand concepts of the region, AD (Availability Domain)and FD (Fault Domain)
Types of the region – Single AD and multi AD
Learn about compartments and tenancy
Core OCI services
In this topic, you are introduced to core OCI services at a higher level. There is no need for a deep dive into each service. A high-level understanding of each is enough for this exam.
OCI Compute service. Learn all the below offerings.
Bare metal
Dedicated virtual host
Virtual Machine
Container engine
Functions
OCI Storage services. Learn below offerings
Block Volume
Local NVMe
File Storage service
Object service
Archive storage
Data transfer service
OCI Networking services
VCN (Virtual Cloud Network)
Peering
Different kind of gateways
NAT Gateway
DRG Gateway
Internet Gateway
Load balancers
NSG (Network Security Groups) and SL (Security Lists)
OCI IAM service
Concept of principals and Instance principals
Groups and dynamic groups
Policy understanding along with syntax and parameters
OCI Database service. Study all below offerings
VM DB systems
Bare Metal DB systems
RAC
Exadata DB systems
Autonomous data warehouse
Study backup, HA, DR strategies
Have a high-level understanding of below services :
OCI Key management service
OCI DNS service
Data safe
OS Management service
OCI WAF
Audit log service
Tagging
Usages
Type: free form and defined
Tag namespaces
Security and complilance
OCI security consists of different facets. Understand below areas in context to security
Cloud shared security model
Securing OCI using IAM
data at rest and data in transit protection
Key management service
HA, FT using AD, FD or services for data protection
OCI Pricing, billing and support
Understand how pricing and billing work in each service we saw above. Learn pricing high/low among tiers in storage services. You don’t need to remember any numbers but you should know it contextually like which is priced high and which one is low etc.
Learn billing models in OCI
PAYG (Pay as you go)
Monthly Flex
BYOL
Understand budget service and how tags, compartments can help in billing and budgeting.
Learn about the SLA structure offered by Oracle. This part is missing in OCI online training.
That’s all you have to know to clear this exam. As I said if you are coming from AWS, Azure then you can relate almost everything to those cloud services which makes it easy to learn and understand.
I created my last day revision notes here (most of the reference to AWS for comparison) which might be useful for you as well.
Now, just little bit of study and go for it! All the best!
Let me share my experience to clear the toughest AWS exam ‘AWS Certified Solutions Architect – Professional’. This article might help you in your journey to get AWS CSA PRO certified.
Getting AWS CSA PRO certified!
In this article, I am going to cover the last few months of the certification journey which can prove useful to you as it was for me.
As I said last few months, so I assume you have good hands-on experience (might be via personal account/corporate projects) of AWS services. Obviously services like Snowball, Direct Connect are rare to get hands-on but you need to have a solid understanding of these services at least.
Let’s begin with the non-technical aspect of this journey which plays a key role in completing your Exam.
Your reading skills matters!
Yup, you read it right. AWS CSA PRO exam is having 75 questions which you need to answer in 180 minutes. Which drills down to approx 2 minutes per question.
Most of the questions are 3-4 or more statements long and so are the choices in answers. So you need to read through almost a big paragraph of text for a single question. Then you understand what is being asked, analyze answers and choosing best which fits the ask. That’s too much of work to be accomplished in 2 mins!
And there are very few questions where answers are just incorrect and you can eliminate them quickly in first glance. Most of the answers are correct but you need to choose the most appropriate one to suit the question’s requirement. So that’s a tedious task which requires more time. Hence I said reading skills do matter.
A tip (might be a crazy one): Watching videos with subtitles is an easy way you can train your brain to read speedily and grasp the context parallelly!
Obviously you should make yourself comfortable before you sit for your exam. Since its a 3 hour, long course and you don’t want to get distracted by anything.
Last month revisions using online training courses
In last month before the exam, you might want to subscribe to online courses specifically structured and targeted to the scope of the exam and their material is designed across the core services appearing in the exam.
These courses are a bit on a longer side like 40-50 hours of video but you can always use video speeds (set to 1.5x generally) to go through the course quickly. I took Linux Academy’s course by Adrian Cantrill & A Cloud Guru’s course by Scott Pletcher. But do not attempt the practice exams at the end of the course right away. Keep them for your final stage before the exam.
There are free courses available on the AWS training portal as well which you can check in the meantime. You should be knowing all AWS services at least by name and their use. Services launched in the last 1 year are less likely to appear on the exam so you can skip them.
Refer AWS documents and videos (Mandatory)
Once you are through online training courses for the exam, you will be well versed in the idea of what you can expect in the exam. These courses often supplemented with the links to AWS whitepapers or re-invent videos related to the chapter topic. Yup, those are essential things to go through.
AWS whitepapers and FAQ pages give you many minute things that you may have missed and help you to determine the validity of your choice for the situation in question. If you are short on time, then at least go through documents for the services in which you are weak or have little knowledge/experience.
AWS re:Invent videos on Youtube is another content-rich platform that gives you some insights/points which you may have missed in your preparation. They are also helpful since many customers are coming in re:Invent and present their use cases. This will help you to map real-world use cases with that in exams and get solid confirmation about your answer. And you can use Youtube’s video speed control to go through videos quickly!
Getting there
All right now we are at the stage that all knowledge sourcing has been done and its time to test that knowledge. Now its time to hit those practice exams from your online courses. Be sure to get these practice exams by Jon Bonso. Its a set of 4 practice tests and worth investing.
Also, you should consider taking AWS’s own practice exam. If you are lucky you might encounter some questions from it, in real exam. Also, if you hold any previous AWS certification, you must have coupon code in your AWS learning account which you can use to take this test for free.
You are good to book your exam when you can score 90% and above in all the above practice tests by understanding why a particular answer is correct and why others not. Memorizing answers not gonna help you in any way.
I uploaded my 50 page long handwritten notes. They might serve you for last day revision like flashcards.
And here you are! The deal day! On exam day, just keep calm and give the exam. Don’t rush for any last-minute reads etc. Its gonna confuse and complicate things. Better be in a peaceful state since your mind is much important on exam day because that’s what gonna help you to read and understand essays! of the exam in the first go. This way you don’t waste your precious time in re-reading questions/answers.
Always keep in mind you can not spend more than 2 mins on a single question. Time is precious!
If you are cant figure out answers quickly then flag it and move on.
If you see answers with the same solutions & only one/two keywords different then easy to finalize answer quickly without reading through the whole statements
Scan through question and capture keywords like a highly available solution, less cost, multi-region, load balancing, etc. This helps you to narrow down to particular services
Start building solutions in mind as you read through questions using the above-said keywords. This helps to look at answers and match the solution you have in mind. It helps you save a lot on time!
Do not submit the exam till last second, even if you manage to complete all questions and review of flagged ones before time. Use the remaining time to go through answers again.
Result?
Your result will be emailed to you within 5 business days. But you can make it out from the messages displayed on the screen once you submit the exam that you made it or not. The message is quite confusing (it’s more when you fried your brain for the last 3 hours!) since it states that you complete the exam! (Diff messages mentioned here in the forum) But, in a nutshell, if you see it starts with Congratulations then you made it! and if it starts with Thank You then you need a re-attempt.
Quick post explaining how to connect Windows EC2 AWS server using RDP.
Connecting AWS Windows server using RDP
Step 1. Get windows password in AWS
Retrieve administrator password from the Windows EC2 server. Login to the EC2 dashboard from the AWS console. Select your Windows server EC2 instance and choose ‘Get Windows password‘ from the Actions menu.
Get windows password in AWS
Sometimes you may see below error complaining that Windows password is not available –
Windows password not available in AWS
Error is self explanatory. You are seeing it because –
You need to wait for your server to properly boot and module to start which decrypt windows password and share with you.
You spun windows server from AMI which does not have a module which could retrieve administrator password from Windows.
In the case of the first situation wait for few minutes and again try to ‘Get Windows Password‘. In the case of the second situation, you need to spin up EC2 with proper AMI.
Once the above issue is resolved, you will see the next window which asks for key pair you used while deploying the Windows server. This is AWS authenticating you again before it releases administrator password to you.
Key pair required to get windows password in aws
Browse key pair on your local machine and then hit the ‘Decrypt Password‘ button. If you have supplied proper key pair you will be presented with a password window like below –
Windows password in aws
That’s it. You have the administrator password for your Windows server on AWS.
Step 2 : Login to Windows AWS server using RDP
Logged in to Windows AWS server
Open remote desktop connection on your local machine. Punch in details that are given to you by AWS in the above window. Public DNS is the hostname you should use to connect to the server followed by the user name and password.
We have a 10GB EBS volume attached to the Linux EC2 server. /testmount of 9.9GB is created using this disk at OS level. We will be increasing it to 15GB.
root@kerneltalks # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 10G 0 disk
└─xvda1 202:1 0 10G 0 part /
xvdf 202:80 0 10G 0 disk
└─datavg-datalv (dm-0) 253:0 0 9.9G 0 lvm /testmount
Step 1: How to extend EBS volume attached to the EC2 server in AWS
Login to AWS EC2 console, click on Volumes under Elastic Block Store in the left-hand side menu. Then select the volume you want to extend. From Actions drop-down menu select Modify Volume You will see below screen :
Modify EBS volume in AWS
Change size (in our case we changed from 10 to 16GB) and click Modify. Accept the confirmation dialogue box by clicking Yes.
Once modify operation succeeded, refresh the Volume list page and confirm the new size is being shown against the volume you modified just now. Now, your EBS volume is extended successfully at the AWS level. You need to extend it at OS level now.
Step 2: How to re-scan new size of EBS volume in Linux & extend filesystem online
Since EBS volumes size has been changed you need to rescan it in OS so that kernel and volume managers (LVM in our case) should make a note about the new size. In LVM, you can use pvresize command to rescan this extended EBS volume.
After successful rescan, check if the new size is identified by the kernel or not using lsblk command.
root@kerneltalks # lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 10G 0 disk
└─xvda1 202:1 0 10G 0 part /
xvdf 202:80 0 16G 0 disk
└─datavg-datalv (dm-0) 253:0 0 9.9G 0 lvm /testmount
You can see in the above output, now xvdf disk is shown with size 16G! So, the new disk size is identified. Now proceed to extend file system online using lvextend and resize2fs. Read how to extend the filesystem online for more details.
root@kerneltalks # lvextend -L 15G /dev/datavg/datalv
Extending logical volume datalv to 15.00 GiB
Logical volume datalv successfully resized
root@kerneltalks # resize2fs /dev/datavg/datalv
resize2fs 1.41.12 (17-May-2010)
Filesystem at /dev/datavg/datalv is mounted on /testmount; on-line resizing required
old desc_blocks = 1, new_desc_blocks = 1
Performing an on-line resize of /dev/datavg/datalv to 3932160 (4k) blocks.
The filesystem on /dev/datavg/datalv is now 3932160 blocks long.
Check if the mount point is showing new bigger size.
root@kerneltalks # df -Ph /testmount
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/datavg-datalv 15G 153M 14G 2% /testmount
Yup, as we planned /testmount is now 15G in size from 9.9GB earlier size.
An article explaining step by step procedure to add EBS disk on AWS Linux server with screenshots.
EBS disk addition on AWS instance
Nowadays most of the servers run on cloud platforms like Amazon Web Services (AWS), Azure, etc. So daily administrative tasks on Linux servers from AWS console is one of the common things in sysadmin’s task list. In this article, we will walk you through one such task i.e. adding a new disk to the AWS Linux server.
Adding a disk to the EC2 Linux server has two portions. The first portion is to be done on AWS EC2 console which is creating new volume to be attached to the server. And attaching it to EC2 instance on AWS console. The second portion is to be done on the Linux server which is to identify newly added disk at the kernel level and prepare it for use.
Creating & attaching EBS volume
In this step, we will learn how to create EBS volume in the AWS console and how to attach EBS volume to AWS EC2 instance.
Login to your EC2 console and navigate to Volumes which is under ELASTIC BLOCK STORAGE menu on the left-hand sidebar. You will be presented with the current list of volumes in your AWS account like below –
Create volume in AWS
Now, click Create Volume button and you will be presented with the below screen.
Volume creation in AWS
Here you need to choose several parameters of your volume –
Volume Type. This decides your volume performance and obv billing.
Size. In GB. Min and Max available sizes differ according to your volume type choice.
IOPS. Performance parameters. Changes according to your volume type choice
Availability Zone. Make sure you select same AZ as your EC2 instance
Throughput. Performance parameter. Only available for ST1 & SC1 volume type.
Snapshot ID. Select snapshot if you want to create the new volume from existing snapshot backup. For fresh blank volume leave it blank.
Encryption. Checkmark if you want the volume to be encrypted. An extra layer of security.
Tags. Add tags for management, reporting, billing purposes.
After selecting proper parameters as per your requirement, click Create Volume button. You will be presented with ‘Volume created successfully’ dialogue if everything goes well along with the volume ID of your newly created volume. Click Close and you will be back of the volume list.
Now check volume ID to identify your newly created volume in this list. It will be marked with an ‘Available’ state. Select that volume and select Attach volume from Actions menu.
Attach volume menu
Now you will be presented with an instance selection menu. Here you need to choose an instance to which this volume is to be attached. Remember only instances in the same AZ of the volume are
Attach volume instance selection
Once you select the instance you can see the device name which will be reflected at the kernel level in your instance under Device field. Here its /dev/sdf.
Check out the note being displayed here. It says : Note: Newer Linux kernels may rename your devices to /dev/xvdf through /dev/xvdp internally, even when the device name entered here (and shown in the details) is /dev/sdf through /dev/sdp.
It says newer Linux kernels may interpret your device name as /dev/xvdf than /dev/sdf. This means this volume will be either /dev/sdf (on the old kernel) or /dev/xvdf on the new kernel.
That’s it. Once attached you can see volume state is changed from Available to in-use
Identifying volume on Linux instance
Now head back to your Linux server. Log in and check new volume in fdisk -l output.
root@kerneltalks # fdisk -l
WARNING: fdisk GPT support is currently new, and therefore in an experimental ph ase. Use at your own discretion.
Disk /dev/xvda: 10.7 GB, 10737418240 bytes, 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt
Disk identifier: 25D08425-708A-47D2-B907-1F0A3F769A90
# Start End Size Type Name
1 2048 4095 1M BIOS boot parti
2 4096 20971486 10G Microsoft basic
Disk /dev/xvdf: 10.7 GB, 10737418240 bytes, 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
As AWS mentioned new device name will be reflected as /dev/xvdf in the kernel, you can see /dev/xvdf in the above output.
Now you need to partition this disk using LVM (using pvcreate) or fdisk so that you can use it for creating mount points!
