CloudFormation Template Anatomy
Here’s a simple CloudFormation template that creates an S3 bucket:
AWSTemplateFormatVersion: 2010-09-09
Description: Bucket Stack
Resources:
S3Bucket:
Type: AWS::S3::Bucket
Properties:
BucketName: my-bucket
AWS CloudFormation performs the crazy party trick of enabling you to manage your complete AWS infrastructure and resources from a text file. The formatted YAML or JSON code you write in the AWS CloudFormation template describes your AWS infrastructure and the resources you need. CloudFormation does the rest, provisioning, configuring and deploying everything for you. It also handles dependencies between resources, removing another piece of complexity from the puzzle.
Without a template, you would have to set everything up manually using the AWS management console or CLI. You would also have to make note of all the resources involved, especially if you wanted to replicate your work for another environment. On the other hand, templates can be used on an ongoing basis, moving you away from the tedium of manually executing multiple steps every time you need to make a change. For example, extending your environment by adding a few more functions is easy with a template.
Understanding CloudFormation Stacks
Creating a VPC with AWS CloudFormation
Creation of the VPC and public and private subnets
Adding an Internet Gateway and Route Table
Replicate subnets for high availability
How to reduce your CloudFormation template size
Best Practices When Creating Cloudformation Templates
Leave credentials out of your templates:
Reference non-confidential parameters:
Add comments and background information:
CloudFormation Sample Templates
Stackery’s AWS CloudFormation Template Builder
Deploy CloudFormation Templates to Your AWS Account
Understanding CloudFormation Stacks
The collection of AWS resources created when CloudFormation runs a template is called a stack. The resources that make up a stack are provisioned to work together to build your application or solution. You can create, modify, delete or replicate resources at the stack level, making management easier and more organized.
Here are a few of the many advantages that come with defining your resources with AWS CloudFormation templates and managing them as stacks:
Use existing CloudFormation templates so you don’t have to start from scratch
Chances are you’ll need similar sets of resources for several different environments. With AWS CloudFormation templates, the days of having to start from scratch each time are over. Instead, lean on an existing template to replicate the infrastructure you need. You can then customize your setup using CloudFormation template parameters and conditions (more on that later). In this way, you can quickly set up resources in multiple environments and in different regions around the world. The portable nature of templates also allows you to share them, say with other teams in your organization, when it makes sense.
Stacks are easier to QA
With your infrastructure declared by the code in your templates, you can now add reviews to your process to ensure no mistakes are made during deployment. You can also use a change management process to verify any changes to your infrastructure, instead of risking mistakes by making changes directly in the console or via CLI.
CloudFormation is the largest resource provider
CloudFormation has many more features you can explore, including built-in identity and access management (IAM), automated rollback and error-checking. And after lagging in resource coverage in the past, CloudFormation now covers more AWS resources than any other Infrastructure-as-Code framework, including Terraform, and almost all new AWS releases now have CloudFormation coverage at launch.
Of course, nothing is perfect and AWS CloudFormation does have some drawbacks. Here are a couple to keep in mind:
- Steep learning curve: While working with templates creates more predictable results than working directly with the console, CloudFormation has many concepts to learn, and, until you get a firm handle on them, things can easily go wrong. For example, if you change the logical ID of a resource, CloudFormation will delete it and create a new one. And, when it deletes that resource, it also trashes its data. Similarly, a resource and all its content are often automatically deleted when the stack is deleted, unless you specify otherwise using the DeletionPolicy attribute in your template. Thankfully, Stackery’s AWS CloudFormation template builder provides a low-code, visual way to create and manage your templates .
- Beware of drift: CloudFormation keeps a snapshot of the current state of your AWS infrastructure. If you then make a change directly through your AWS console or your AWS CLI, your resources will be out of sync with the snapshot. This discrepancy is called drift and it can cause your deployments to fail. So, once you start using CloudFormation, you should stop making manual updates to your account, through the console or CLI, to avoid this issue.
You can create CloudFormation templates using JSON or YAML. We prefer the latter, so all the templates included in this article are in YAML. Regardless of which you choose, templates can consist of the primary sections of information highlighted below, with the Resources section being the only one that is mandatory.
Format version
This is where you specify the template format version. The capabilities of the template can vary depending on which one you choose. If you don’t pick one, CloudFormation defaults to the latest version. As an aside, CloudFormation has yet to make a backwards-incompatible change, so don’t worry too much about versions.
This is the AWS CloudFormation template version that your template conforms to and identifies the capabilities of the template. This is not the same as the API or WSDL version.
Description
Use the description area to add comments about your template, such as its purpose.
This section is a text string that provides the reader with a short description (0 to 1024 bytes in length) of the template. This section must come right after the Format Version section.
Be descriptive but concise!
Metadata
Use JSON or YAML objects in this section to provide further details about the resources in your template.
This section isn’t used all that often, but here you can include additional information about your template. This can include information for third-party tools that you may use to generate and modify these templates and other general data.
Please note that the Metadata section is not to be confused with the Metadata attribute that falls under the Resources section. This Metadata section should include information about the template overall, while the Metadata attribute should include data about a specific resource.
Parameters
In this section, you declare parameters that are passed to the template when a stack is created or updated. In this way, you can specify unique values for use in the properties of your stack’s resources and effectively customize a template each time it’s used. It also allows you to use a single template across multiple accounts and regions, or to specify information unique to the application or configuration being deployed. A best practice is to store parameters in AWS Systems Manager Parameter Store for each environment and then reference the parameters instead of passing in literal values to CloudFormation directly.
You can use the Parameters section to input custom values to your template when you create or update a stack so you can make these templates portable for use in other projects.
For instance, you can create parameters that specify the EC2 instance type to use, an S3 bucket name, an IP address range, and other properties that may be important to your stack.
The Resources and Output sections often refer to Parameters, and these references must be included within the same template.
Mappings
There may be cases where you’ll want to add logic to your template. With Mappings, you can use an input value as a condition that determines another value.
The Mappings section allows you to create key-value dictionaries to specify conditional parameter values.
Examples of this include deploying different AMIs for each AWS region, or mapping different security groups to Dev, Test, QA, and Prod environments that otherwise share the same infrastructure stack.
To retrieve values in a map, you use the “FN::FindInMap” intrinsic function in the Resources and Outputs sections.
Conditions
Conditions are statements that determine whether or not a resource is created or a property is assigned to a value when a stack is created or updated. For example, a condition could check to see if one value is greater or less than another value and, based on the result, conditionally create a resource. This gives the same template the flexibility to be used across different environments.
Conditions allow you to use logic statements (just like an “if then” statement) to declare what should happen under certain situations.
Transform
You can specify one or more macros that enable the reuse of template components. They are often used to condense or simplify your code. This is where you enable AWS SAM, which Stackery uses to simplify the development of serverless stacks.
The Transform section allows you to simplify your CloudFormation template by condensing multiple lines of resource declaration code and reusing template components.
There are two types of transforms that CloudFormation supports:
- “AWS::Include” refers to template snippets that reside outside of the main CloudFormation template you’re working with. Thus, you can make multi-line resource declarations in YAML or JSON files stored elsewhere and refer to them with a single line of code in your primary CloudFormation template.
- “AWS::Serverless” specifies the version of the AWS Serverless Application Model (SAM) to use and how to process it.
You can declare multiple transforms in a template and CloudFormation executes them in the order specified. You can also use template snippets across multiple CloudFormation templates.
Resources
This is where you list the resources that will be created by the template. It’s also where you specify the necessary properties to create each resource.
The Resources section is the only section that is required in a CloudFormation template.
In this section, you declare the AWS resources, such as EC2 instances, S3 buckets, Redshift clusters, and others, that you want deployed in your stack. You also specify the properties, such as instance size, IAM roles, and number of nodes, for each of these components.
This is the section that will take up the bulk of your templates.
Output
In this section, you can specify the values you want to have returned to you and available after the stack is created. For example, there could be output values you might need to have handy to import into other stacks or you might want easy access to a particular output, like a URL created in the template.
In the Outputs section, describe the values that are returned when you want to view the properties of your stack.
One can export these outputs for use in other stacks, or simply view them on the CloudFormation console or CLI as a convenient way to get important information about your stack’s components.
Creating a VPC with AWS CloudFormation
The template we’ve provided below creates a virtual private cloud (VPC) with public and private subnets. This will allow you to launch AWS resources in a virtual network that you define and have complete control over.
In this template, we create a VPC with a public subnet for your web servers that are publicly addressable, and a private subnet where your backend components like databases or application servers will reside and be safe from the prying eyes of the internet.
The public subnet will connect to the internet via an Internet Gateway, and a Route Table tells the public subnet how to find the Internet Gateway.
We’ll then replicate the public and private subnets in another availability zone for high availability.
This template is pretty straightforward and only contains the Format Version, Description, and Resources sections.
Here’s the CloudFormation template in its entirety:
AWSTemplateFormatVersion: 2010-09-09
Description: Creates a VPC with public and private subnets
Resources:
VPC:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 192.168.101.0/24
PublicSubnetA:
Type: AWS::EC2::Subnet
Properties:
AvailabilityZone: !Select
- 0
- !GetAZs
Ref: AWS::Region
CidrBlock: 192.168.101.0/28
MapPublicIpOnLaunch: true
VpcId: !Ref VPC
PrivateSubnetA:
Type: AWS::EC2::Subnet
Properties:
AvailabilityZone: !Select
- 0
- !GetAZs
Ref: AWS::Region
CidrBlock: 192.168.101.32/28
MapPublicIpOnLaunch: false
VpcId: !Ref VPC
InternetGateway:
Type: AWS::EC2::InternetGateway
AttachGateway:
Type: AWS::EC2::VPCGatewayAttachment
Properties:
InternetGatewayId: !Ref InternetGateway
VpcId: !Ref VPC
PublicRouteTable:
DependsOn: AttachGateway
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref VPC
PublicDefaultRoute:
Type: AWS::EC2::Route
Properties:
DestinationCidrBlock: 0.0.0.0/0
GatewayId: !Ref InternetGateway
RouteTableId: !Ref PublicRouteTable
PublicRouteAssociationA:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
RouteTableId: !Ref PublicRouteTable
SubnetId: !Ref PublicSubnetA
PublicSubnetB:
Type: AWS::EC2::Subnet
Properties:
AvailabilityZone: !Select
- 1
- !GetAZs
Ref: AWS::Region
CidrBlock: 192.168.101.16/28
MapPublicIpOnLaunch: true
VpcId: !Ref VPC
PrivateSubnetB:
Type: AWS::EC2::Subnet
Properties:
AvailabilityZone: !Select
- 1
- !GetAZs
Ref: AWS::Region
CidrBlock: 192.168.101.48/28
MapPublicIpOnLaunch: false
VpcId: !Ref VPC
PublicRouteAssociationB:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
RouteTableId: !Ref PublicRouteTable
SubnetId: !Ref PublicSubnetB
.
Creation of the VPC and public and private subnets
First, we add a VPC that encompasses the entire network we’re about to create:
Resources:
VPC:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 192.168.101.0/24
Here’s what’s going on:
- VPC: This is the name you give to the resource.
- Type: This defines the CloudFormation resource type. Check out the resource type documentation to find supported properties.
- Properties: Each resource has required and optional properties. In this case, you can define the IP address range in CIDR notation.
Next we add a public and private subnet:
PublicSubnetA:
Type: AWS::EC2::Subnet
Properties:
AvailabilityZone: !Select
- 0
- !GetAZs
Ref: AWS::Region
CidrBlock: 192.168.101.0/28
MapPublicIpOnLaunch: true
VpcId: !Ref VPC
PrivateSubnetA:
Type: AWS::EC2::Subnet
Properties:
AvailabilityZone: !Select
- 0
- !GetAZs
Ref: AWS::Region
CidrBlock: 192.168.101.32/28
MapPublicIpOnLaunch: false
VpcId: !Ref VPC
As before, you’ll notice the same resource structure of name, type, and supported properties. The “AWS::EC2::Subnet” type happens to support a few more properties.
The above example also uses some special syntax to make the template a little more dynamic, such as:
Pseudo parameters
A pseudo parameter dynamically resolves to a value, given the context of the CloudFormation stack. For example, “Ref: AWS::Region” gets converted to the region in which you deploy the template (i.e. us-east-1).
Intrinsic functions
A CloudFormation template is configuration, not code. However, you have access to some basic runtime logic.
In the above example, “!GetAZs Ref: AWS::Region” gets all the availability zones in the current region. And the “!Select” function gets the first AZ in the list.
Another use of an intrinsic function is “!Ref VPC”. This gets the VPC ID of the VPC resource defined earlier.
Here’s a breakdown of what’s happening in the code above.
- PublicSubnetA is our public subnet, and any EC2 instances provisioned will be given a public IP address.
- PrivateSubnetA is our private subnet.
- Each subnet is provisioned in the first availability zone in the current region. For example, this could be “us-east-1a”.
- Each subnet is placed inside the VPC defined earlier.
- Each subnet’s IP address range contains 16 addresses. These ranges are non-overlapping, and fall within the overall VPC’s IP range.
Adding an Internet Gateway and Route Table
Next, we create an Internet Gateway. This allows instances within the VPC to access the internet. And it also allows the internet to access servers within the public subnet:
InternetGateway:
Type: AWS::EC2::InternetGateway
AttachGateway:
Type: AWS::EC2::VPCGatewayAttachment
Properties:
InternetGatewayId: !Ref InternetGateway
VpcId: !Ref VPC
Behind the scenes, the Internet Gateway has no way to associate itself with our VPC. So you have to create an “AWS::EC2::VPCGatewayAttachment” resource to perform this task.
Next we create a Route Table, plus a few related resources:
PublicRouteTable:
DependsOn: AttachGateway
Type: AWS::EC2::RouteTable
Properties:
VpcId: !Ref VPC
PublicDefaultRoute:
Type: AWS::EC2::Route
Properties:
DestinationCidrBlock: 0.0.0.0/0
GatewayId: !Ref InternetGateway
RouteTableId: !Ref PublicRouteTable
PublicRouteAssociationA:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
RouteTableId: !Ref PublicRouteTable
SubnetId: !Ref PublicSubnetA
The Route Table only has one property, “VpcId: !Ref VPC”, which associates itself with a VPC.
Route (“AWS::EC2::Route”) resources contain a single route, which points an IP address range to a gateway. The Route associates itself with the Route Table.
A Subnet Route Table Association wires up the route table to a subnet. In this case, the Route Table directs all traffic from PublicSubnetA to the internet.
One thing to note is the “DependsOn” attribute. CloudFormation is usually pretty good about spinning up dependencies in the correct order. However, you can use the “DependsOn” attribute to explicitly define a dependency.
Replicate subnets for high availability
Finally, we replicate the subnets into a new availability zone to facilitate high availability.
PublicSubnetB:
Type: AWS::EC2::Subnet
Properties:
AvailabilityZone: !Select
- 1
- !GetAZs
Ref: AWS::Region
CidrBlock: 192.168.101.16/28
MapPublicIpOnLaunch: true
VpcId: !Ref VPC
PrivateSubnetB:
Type: AWS::EC2::Subnet
Properties:
AvailabilityZone: !Select
- 1
- !GetAZs
Ref: AWS::Region
CidrBlock: 192.168.101.48/28
MapPublicIpOnLaunch: false
VpcId: !Ref VPC
PublicRouteAssociationB:
Type: AWS::EC2::SubnetRouteTableAssociation
Properties:
RouteTableId: !Ref PublicRouteTable
SubnetId: !Ref PublicSubnetB
Like before, the IP address ranges are unique and non-overlapping. The main difference with set B is that they get provisioned in the second availability zone rather than the first.
One thing to note is that PublicSubnetB needs its own route association, since it’s one association per subnet.
You now have the network infrastructure to launch EC2 instances, databases, or other AWS resources with some baseline security!
How to reduce your CloudFormation template size
CloudFormation just allows a maximum size of 51,200 bytes per template. If you have ever reached this limit, you might have encountered this error message:
[YOUR_TEMPLATE_CODE] at 'templateBody' failed to satisfy constraint: Member must have length less than or equal to 51200
So, what are the possible solutions to reduce a CloudFormation template size? In my opinion, there are two relatively easy solutions to overcome this problem: using a preprocessor and/or using AWS::Include.
Use a Preprocessor
There are some CloudFormation template preprocessors available. One of them is cfn-include (a CLI tool) which does a good job in my opinion: it reads your template file (JSON or YAML) and can produce a minified JSON template file. Using this tool, it can reduce your template size e.g. from 50 kb to 40 kb (Note: it always depends on the content you have). Here is a small example how to use it:
# -m => minify JSON output
cfn-include path/to/cfn.yml -m > output.json
This is a first and easy step to come around the size limitation. Other preprocessor alternatives are StackFormation or awsboxen
Use AWS::Include
Another option would be to use the new AWS::Include command. Using such a simple snippet like below, you can import another template:
###################################
#### main template's content ######
###################################
AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: A AWS::Include test.
Resources:
MainFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: nodejs6.10
CodeUri: ./
Policies:
- AWSLambdaBasicExecutionRole
'Fn::Transform':
Name: 'AWS::Include'
Parameters:
Location: s3://BUCKET_NAME/key/to/included-template.yml
############################
#### included template #####
############################
SNSTopic:
Type: AWS::SNS::Topic
Properties:
DisplayName: MySNSTopic
It’s important to note that you must only enter the actual parts in the included template which you want to include. Nothing else like parameter declarations, outputs, etc. You have to add such things to the main template!
As you also might derive from the code example, all included templates must be uploaded to S3 first. Uploading it first adds some more work around a stack deployment. This can be automated in a deployment script, so it shouldn’t be a big deal.
Here is an example on how to achieve this using a certain parameter to hand over the S3 Url:
# these commands expect that your main template file is cfn.yml and
# your included template file is cfn-include1.yml;
# upload included template file to S3 bucket; bucket name is hold in LAMBDA_BUCKET,
# because I also have a Lambda SAM function in the template above.
# (of course you can the bucket if you want, just replace LAMBDA_BUCKET)
aws s3 cp cfn-include1.yml s3://${LAMBDA_BUCKET}/templates/cfn-include1.yml
# save the URL of the uploaded template
INCLUDE_URL="s3://${LAMBDA_BUCKET}/templates/cfn-include1.yml"
# now package the main template, upload SAM artifacts to S3 and deploy it;
aws cloudformation package --template-file cfn.yml --s3-bucket ${LAMBDA_BUCKET} --output-template-file cfn.packaged.yml
# important here: you have to hand over the INCLUDE_URL;
# later in the template, you can reference it using "!Ref IncludeUrl"
aws cloudformation deploy --template-file cfn.packaged.yml --stack-name ${STACK_NAME} --capabilities CAPABILITY_IAM --parameter-overrides IncludeUrl=${INCLUDE_URL}
When deploying the CloudFormation stack, CloudFormation resolves the included templates by downloading them from S3 and inserts them directly into your main template. Each of the included ones (and of course the main template as well) may not exceed the aforementioned byte size limit, otherwise this will fail again.
Disadvantages of AWS::Include
- The included template may not contain the short version of an intrinsic function. This maybe an issue, because one may have to change all functions to use the full notation.
- If you’re using a code completion plugin for CloudFormation templates like I do for IntelliJ, then you’ll probably see many errors in your templates, because it can’t resolve parameters or other stack resources anymore. That’s not a problem of AWS::Include directly. But the point is you’re bringing in some more complexity into your stack setup. So keep in mind that you structure your code and include templates in a good way.
- You can’t export parameters into an include template.
AFAIK you can not outsource Lambda functions using Serverless Application Model (SAM) into separate templates. The reason is that they need to be transformed first. In that case you’d need to add other lines into your template, but then it’s not an include template anymore.
Take a look at my GitHub repository aws-cloudformation-templates where included an example using AWS::Include to reduce your CloudFormation template size.
Reduce-cloudformation-template-size
Best Practices When Creating Cloudformation Templates
Leave credentials out of your templates:
It’s not a smart move to store credentials or other sensitive information in your AWS CloudFormation templates. Instead, use dynamic references to specify and retrieve information managed in other services, like AWS Secrets Manager, without CloudFormation ever storing the actual reference value.
Reference non-confidential parameters:
It’s a good idea to store non-confidential parameters (like the memory size of a Lambda Function) in AWS Systems Manager Parameter Store and reference them, instead of passing literal values to CloudFormation directly.
Make your code more readable:
If you’re writing your AWS CloudFormation template in YAML, use CFN-specific tags (e.g. !GetAtt instead of the full Fn::GetAtt syntax) to make your code more readable. You’ll thank yourself later when you revisit your code.
Add comments and background information:
With a top-level Metadata section and the ability to add Metadata sections to every resource, you have plenty of opportunities to provide details that could be helpful later. And don’t worry, these comments won't be lost when you use tools to edit your templates.
Check your code:
Validate your template with AWS CloudFormation, before creating or updating a stack, to ensure it consists of valid JSON or YAML without syntax or semantic errors. Also make sure to use tools like AWS CloudFormation Guard (cfn-guard) and cfn-nag to check your template for policy compliance issues or security vulnerabilities, respectively.
CloudFormation Sample Templates
Take a look at these AWS CloudFormation template examples to get a feel for what they’re like.
Services templates:
Explore more AWS services templates.
Application framework templates:
Check out more application framework templates.
Template snippets:
These template snippets can help you learn.
More AWS templates and resources:
Take a look at the AWS CloudFormation templates page for more samples and resources.
Stackery’s AWS CloudFormation Template Builder
Stackery’s low-code Design Canvas alleviates the need to pull all-nighters learning the minutiae of AWS CloudFormation. Getting started is quick and easy. You can either import existing CloudFormation projects or create new stacks from the ground up. With Stackery, you build and modify your CloudFormation templates visually. Simply drag-and-drop resources where they're needed in your architecture. As you do that, the template’s code is automatically written for you. Easily toggle back and forth between your visual building blocks and the actual code. Unlike previous-generation tools, like CloudFormation's own Designer, Stackery visualizes resources the way a human would perceive them, grouping related resources together and providing a more intuitive editing experience.
Using Stackery can dramatically cut the time required to get up-and-running with CloudFormation, even for expert-level AWS users. Case in point: Tim Wagner, the creator of AWS Lambda itself, documented how 15 hours of effort in CloudFormation was reduced to just 15 minutes when he recreated his work using Stackery.1
The hours you shave off the template building process can be spent focused on development instead of infrastructure management.
Once you’ve created and deployed your AWS CloudFormation resources with Stackery, managing and modifying that infrastructure is just as easy. Instead of thinking of architecture setup as a one-time, static endeavor, we see Stackery customers updating their architectures more than once a week because it’s so straightforward to do so. No matter what changes are made, Stackery remains an easily accessible, enduring and flexible source of truth.
Stackery also allows you to build your CloudFormation templates completely separate from the AWS console, alleviating manual updates to your AWS account and the associated risk of drift.
Deploy CloudFormation Templates to Your AWS Account
Stackery fits seamlessly into your development workflow and makes reviewing, testing and deploying your AWS CloudFormation templates just as easy as it makes setting them up. Peer reviews and automated testing are supported in Stackery, managed for you within your AWS account, not third-party services or Stackery servers. Rest assured what works on your laptop will work in production. And when you’re ready, Stackery’s delivery pipeline enables you to securely deploy your CloudFormation templates right to your AWS account.
References:
1 60x faster development with the inventor of AWS Lambda, Stackery.io/blog
Visualizing your CloudFormation Template with Stackery Visualizing CloudFormation templates
Team Stackery | Stackery aws-cloudformation-templates-best-practices
Disclaimer: Some of the contents of this website have been
taken from various sources on the internet. If you find any content that should
be removed from this site because of Copyrights, please send a message and it
will be promptly removed.
|
|
|
|
Home/ Info/ Products/ BIG TECH Metaverse Metaverse Vs. Virtual Reality PC Buyers Guide/ IEEE 802 Standards Social Media Platforms Technology Videos/ Computer & IT Certifications Processor Generations Memory DDR3 Vs. DDR4 SSD Vs. HDD SAS vs. SATA HTML 5G Android Tips and Tricks STEM Business Intelligence Tools Web Intelligence Quantum Computing Artificial Intelligence (AI) Robotics Internet of Things (IOT) Web Of Things (WoT) Renewable Energy Nano Technology Cleantech Windows Run Commands Hiren's Boot CD Android Vs. IOS Mac Vs. PC Mac Keyboard Shortcuts Linux CLi Commands Venus Project/ Computer Security and Law Techno Lingo Encyclopedias Search Engines Glossary Online Jobs Contact
Active Components Passive Components Test Electrical Components Electronics Classification
AWS Certification Google Certification Oracle Certifications cisco certifications Huawei Certification Microsoft Certifications Linux Certification Business Certifications
Google-Cloud-Platform-Guide Amazon-Web-Services-Guide Global-Cloud-Infrastructure-Of-AWS Amazon-Web-Services-Cli-Guide AWS-Cloudformation Devops Microsoft-Azure Oracle-Cloud Digitalocean-Cloud Openstack-Cloud IaC CloudFormation Anatomy Security Topics
Certified Enterprise Blockchain Professional (CEBP) Web 3.0 Satoshi Nakamoto Cryptocurrency Dark Web Ethereum NFT Merkle Tree El-Salvador eNaira Challenges Of Crypto To Cash
Web C++ JAVA Python Python Glossary Angular.js Scala
Copyright BICT Solutions Privacy Policy. | Terms and Conditions apply | All rights reserved.