DEV Community: Bugra Kilic

Private network for enterprises: AWS Private 5G

Bugra Kilic — Mon, 15 Jan 2024 07:05:44 +0000

Telecommunications technologies have been transforming for a few decades, and so does infrastructure. With the aim of fifth-generation mobile networks (5G), there are a large number of edge devices that should be connected to the internet. For example, all electric vehicles (EV), Internet of Things (IoT) devices, and massive manufacturing equipment will be integrated with the network itself. Thus, this network is expected to handle a wide range of smart devices seamlessly in order to provide lower latency, higher bandwidth, and higher speed. This is where the need for Private 5G comes in.

Private 5G is a mobile network, which is very similar to Public 5G but more specialized (e.g. restricted access, more secure etc.). Private 5G basically takes advantage of the benefits of 5G technologies mentioned in the previous paragraph and offers more capabilities and functionalities beyond what Wi-Fi or other network technologies provide. Therefore it is recommended to be in action in manufacturing plants, airports, ports, or corporate campuses.

In re:Invent 2021, the preview of AWS Private 5G was announced and created a big impact in the telco industry. Later it became generally available for commercial use in August 2022. Since then the study of Private 5G has been developing continuously, especially in the telco industry.

Introducing AWS Private 5G

AWS Private 5G is a managed service by AWS in order to set up and scale private networks at enterprise locations in a short period. It provides an isolated and secure network infrastructure with a distinct and controlled environment for edge data operations. Plus it ensures a reliable and high-performance 5G connection tailored for a specific business need. This dedicated connection prevents the business-critical operations from congestion and potential vulnerabilities. It is particularly advantageous for enterprises that prioritize data security, reliability, and bandwidth optimization. So by leveraging AWS Private 5G, these enterprises can establish a resilient and isolated network, safeguarding their data assets within AWS. Please note that AWS Private 5G is now available only in us-east-1 (N. Virginia), us-east-2 (Ohio), and us-west-2 (Oregon) regions.

Figure 1 – AWS Private 5G architecture

In this figure, there is a link to The Spectrum Access System (SAS) which is a cloud-based service managing spectrum grants in the Citizens Broadband Radio Service (CBRS) band. Radio units must request spectrum grants from SAS according to apply Federal Communications Commission (FCC) rules. For more information about this part, please check this resource.

Private 5G Components:

Mobile core network (CN) – a core network for a Private 5G network to be connected externally.
Radio access network (RAN) – small cell radio units that emit radio frequency (RF) signals for edge devices to connect to the Private 5G network.
Private 5G site and equipment – the physical site or location with the related physical hardware (SIM, radio unit, or other network appliances) to provide access to the Private 5G network.

Technical Features

As already mentioned above, AWS Private 5G offers what is offered with Public 5G networks, but it is more beyond of that. Because the privacy of a network is able to boost the security and reliability, and can limit the usage of edge points (e.g. users/subscribers or connected equipment). Let’s look at the technical aspects of this solution.

Connectivity with thousands of devices, including subscribers, manufacturing equipment, smart vehicles etc.
Low latency, high bandwidth, and high speed functionalities that can help to build a seamless network.
Scalability of the network capacity if there is a demand for new devices to be connected.
IAM-policy-dependent access controls for all connected units to provide a more secure data environment.
Fast planning, deployment, and operation managed by AWS. There is no long time period consumed on planning, integration and installation phases.
Pay per capacity and throughput for only used.

How it works

Since this is a managed service by AWS, there is an order for your demand. Firstly, you order what you need on AWS Management Console, and specify your capacity requirements and coverage. So AWS prepares your hardware, which comprises of small cell radio unit, the mobile network core and radio access network (RAN) software, and subscriber identity modules (SIM cards), then delivers them to your site. After the acknowledgement of the hardware delivery, there is an installation process by a Certified Professional Installer (CPI) to set up the system. CPI powers on the equipment, connects them to the internet, and configures them with the necessary information for your site. After that, you are expected to complete your setup on the management console and operate your private mobile network with the connectivity and scalability options for your business needs.

The creation and order processes are required to be on AWS Management Console, but you can use CLI and API integration with your own Private 5G network. The documentation of AWS Private 5G gives important hints and usage scenarios.

The below screenshot demonstrates the creation screen of your own Private 5G network.

Why AWS Private 5G

The scalability and flexibility of AWS Private 5G make it adaptable to the diverse needs of enterprises. Whether a large enterprise with complex networking requirements or a smaller entity looking to optimize bandwidth for specific applications, AWS Private 5G offers a tailored solution. In summary, the adoption of AWS Private 5G is motivated by the need for enhanced security, reliable connectivity, and adaptable networking solutions. It helps businesses to build a resilient, high-performance network infrastructure aligned with their specific operational requirements, positioning them for success in an interconnected landscape.

The integrations between AWS and on-premise networks

Bugra Kilic — Wed, 27 Dec 2023 07:08:05 +0000

Technology world is evolving, and so the networking world. But where do we stand as network developers contributing to the field? As already mentioned, this world is changing, but it’s more digitalized due to the cloud. Some say it’s replacing the entire telco networks, which I disagree. The cloud is not targeting to eliminate the current legacy networks. Contrary, it has a crucial role for enterprises and carriers for being connected to other network branches easily and alternatively. So in this post, I will cover more about the future of the legacy networks, and its potential integrations with the cloud – also named as hybrid cloud in this case. Also a real-life use case with AWS Networking products will be discussed.

What is this hybrid cloud?

I assume that everyone reading this knows what the cloud is. If not, please look at the detailed explanations from AWS here. Hybrid cloud is basically a concept that you connect both your network components and cloud services together. In hybrid cloud, you get the advantages of cloud, such as scalability, redundancy, and high performance. Plus you do not need to worry about the cloud-based infrastructure.

Hybrid cloud has also other perks. On the one hand, let’s assume that you have a small-sized company, and want to reach your clients accross the continent with low latency. With the help of AWS Networking products, such as Transit Gateway, Direct Connect or Site-to-Site VPN, you have the chance to realize it with the minimum effort. You only need to configure and maintain the right routes between the tenants. On the other hand, hybrid cloud gives the opportunity to scale up with less operational expenses (OPEX). So it can be said that OPEX can be reduced due to the easily-managed and flexible architecture. The cloud itself has this pay-per-use model. Therefore as long as you have predictable plans for AWS usage, you will pay only what you use. And in this case, the bills will probably much lower since there is no hardware, commissioning, and maintenance responsibilities – also look at the AWS Shared Responsibility Model.

The importance of cloud migration

Cloud migration and the adoption of cloud-native functions are more important than ever for telecommunications companies. Integrating legacy networks with cloud services, like AWS Transit Gateway or Direct Connect, ensures seamless connectivity across corporate branches, enabling low-latency client reach and scalability. This approach aligns with cost-efficient payment models while guaranteeing adaptability and cost-effectiveness in meeting diverse consumer demands. For more info about this topic, I have written more about CNFs and cloud migration concept in the previous blog post.

Let’s dive in to the related AWS Networking products.

AWS offers many services in various fields, from serverless computing to storage, and from database to machine learning. But in my humble opinion, the core products will always be networking related ones itemized below.

How do you implement your legacy network to the cloud?

First and foremost, it depends on your scenario. First two of above listed products are the alternative AWS solutions that can interconnect your on-premises to the cloud.

AWS Site-to-Site VPN

AWS Site-to-Site VPN establishes an encrypted communication channel, also called as IPsec tunnel, between your on-premises data center or branch network and the virtual private cloud (VPC). It’s similar to setting up a private, virtual highway over the internet. This allows seamless and protected data flow between your local infrastructure and AWS resources to ensure a resilient and secure connection.

Figure 1 shows a simple implementation of AWS Site-to-Site VPN with a customer edge router in a local data center. It’s mostly used to establish a connection between an individual VPC and other networks.

Figure 2 shows a more redundant version of the above basic architecture. With the backup links between VPC and Site-to-Site VPN, the high-availability has been set up. There is also the customer side of this diagram, which offers more than one IPsec tunnels providing the redundancy on this cluster.

Who said that AWS Site-to-Site VPN is only used for individual VPCs? On Figure 3, the implementation of Transit Gateway to a simple Site-to-Site VPN – CE connection is shown.

Here, AWS Transit Gateway functions as a scalable and centralized hub that consolidates connectivity between multiple VPCs and on-premises. It operates as a high-performance router, efficiently managing traffic between various VPCs and the local infrastructure. So it’s an agile solution for interconnecting different networks, providing a unified and manageable way to handle data flow within and across the cloud and on-premises environments.

Even though Site-to-Site VPN offers critical features such as high availability, advanced routing policies, and support for static routes/dynamic BGP peering, it has also some limits, like possible network latency, or necessity for on-prem device’s BGP routing policies.

AWS Direct Connect

AWS Direct Connect establishes a dedicated, high-speed link between the on-premises data center and AWS infrastructure. It operates as a private connection, bypassing the public internet to provide secure, consistent, and low latency access to AWS resources. This direct physical link ensures reliable and efficient data transmission, ideal for large-scale data transfer and critical workloads.

Figure 4 shows a simple implementation of AWS Direct Connect with a customer edge router. The most important part of this interconnection is the private, dedicated, and high-speed link between multiple VPCs and customer edge infrastructure. A private virtual interface (VIF) and a proper VLAN configuration need to be arranged on related services.

Figure 5 shows a redundant version of Direct Connect usage. Multiple private VIFs and a link-aggregation group (LAG) with multiple links are used to establish this solution. As it is seen on below diagram, Direct Connect Gateway (DXGW) acts as a central point for managing these connections while providing a more efficient and simplified approach to handle failover scenarios.

As already mentioned in the previous section, AWS Transit Gateway is used for managing the flow of information between different locations within AWS and the local infrastructure. With the power of Direct Connect, Transit Gateway enhances the abilities of global interconnections between AWS Regions and on-premises. In this architecture, you need to configure TGW association to DX Gateway, and a Transit VIF for the traffic forwarding through DX. The rest is same as always.

Direct Connect has many pros, such as low latency, high throughput, and a LAG support. It’s especially the best option for large-scaled enterprise and carrier grade networks. On the other hand, it is a bit more expensive than AWS VPN solution.

Use case

In this example, a simple data collector solution is demonstrated. Let’s say that you require to collect particular information from network gears installed in your data centers and branches, and train these data in multiple AWS regions. Then you need to use a solution like below Figure 7. The important part on this diagram is the usage of Direct Connect across AWS and ISP network. For a dedicated private line, I prefer to choose Direct Connect here instead of Site-to-Site VPN. If I had a low budget for this solution, VPN solution may be a better choice though. On the other side, two Transit Gateways are used to transit the necessary data through DX to VPCs. The communication between these TGWs are handled via TGW peering. If there is a chance to set up another VPC in an existing region, that region’s TGW is available to use for it too.

Please note that the services inside VPCs can be changed according to the requirements. Here, several EC2 instances and S3 buckets are shown as an example.

Figure 7 – AWS VPC & ISP Network integration via TGW and DX

Final

To sum everything up, AWS has very powerful cloud networking products to build a stable communication between on-prem networks and the cloud. Until this point, hybrid cloud, cloud migration, and several products that help to build these future networks have been explained.

Since you are here, thank you for reading! If you have questions, please hit me up in the comments section below.

Distributed Storage in AWS: Enhancing Scalability and Reliability

Bugra Kilic — Mon, 31 Jul 2023 20:54:06 +0000

The volume of data generated by individuals and businesses is increasing exponentially. Today, the traditional storage solutions often struggle to keep up with this surge, leading to performance bottlenecks and data loss risks. To address these challenges, distributed storage has emerged as a powerful solution. Amazon Web Services (AWS) offers a range of distributed storage services that enable businesses to store, manage, and access their data efficiently. In this article, we will explore what distributed storage is, and delve into some of the related AWS services.

What is Distributed Storage?

Distributed storage is a concept in which data is spread across multiple physical locations or servers, instead of being confined to a single centralized storage device. This approach offers numerous advantages, including increased fault tolerance, scalability, and improved data redundancy. In a distributed storage system, data is divided into smaller chunks and distributed across various nodes, allowing for parallel access and retrieval, leading to enhanced performance.

There are several benefits and drawbacks for using distributed storage. Such benefits are including:

Scalability: It can be scaled up or down as needed. It makes it ideal for applications that need to handle variable workloads.
Availability: It is typically highly available. It means that it can continue to operate even if some of the nodes in the system fail.
Performance: It can provide high performance for both read and write operations.

while drawbacks are generally like:

Complexity: It can be complex to manage, especially for large-scale deployments.
Cost: It can be more expensive than traditional storage solutions.
Latency: It can have higher latency than traditional storage solutions, especially for applications that require low-latency access to data.

AWS Services for Distributed Storage

Amazon S3 (Simple Storage Service)
Amazon S3 is one of the most popular distributed storage services provided by AWS. It offers highly scalable, durable, and secure object storage, designed to store and retrieve any amount of data from anywhere on the web. Amazon S3 stores data in buckets, and each bucket can contain an unlimited number of objects. The service is ideal for a wide range of use cases, such as hosting static websites, backing up data, storing application assets, and powering data lakes.
Amazon EBS (Elastic Block Store)
Amazon EBS provides block-level storage volumes that can be attached to EC2 instances. While it may not be a fully distributed storage system, it is built to be resilient, with data automatically replicated within an Availability Zone (AZ) to protect against failures. EBS volumes are durable and persistent, allowing data to persist even after an EC2 instance is terminated. EBS is commonly used for database storage, boot volumes, and analytics workloads.
Amazon EFS (Elastic File System)
Amazon EFS is a fully managed, highly scalable, and distributed file storage service. It is designed to provide shared file storage for multiple EC2 instances, making it well-suited for applications that require shared access to files. EFS automatically scales storage capacity and throughput as the number of files and the data stored grows. It ensures high availability and durability by storing data across multiple Availability Zones.

How to Use Distributed Storage in AWS

Using distributed storage systems in AWS is relatively straightforward. The following steps will guide you through the process:

Choose the Right Service: Depending on your specific use case and requirements, select the most appropriate distributed storage service from the AWS offerings. For example, if you need object storage for static assets, Amazon S3 is a great choice. If you require shared file storage, Amazon EFS might be the right fit.
Create and Configure Storage: Once you've chosen a service, create the necessary storage resources. For instance, if you opt for Amazon S3, create a bucket and define the desired settings for access control, encryption, and versioning.
Integrate with Applications: Modify your applications to utilize the chosen distributed storage service. Each AWS service comes with APIs and SDKs that make integration seamless and allow easy data access and manipulation.
Implement Data Replication and Backup: To enhance data durability and availability, leverage the replication and backup features provided by the selected service. This step is crucial for ensuring data resilience against failures.
Monitor and Optimize: Regularly monitor the performance and usage of your distributed storage solution. Utilize AWS CloudWatch and other monitoring tools to track metrics and optimize your setup based on the insights gathered.

Wrapping up

Distributed storage systems are game-changers in the world of data storage and management. AWS offers a suite of powerful distributed storage services, each catering to specific use cases and requirements. From the highly scalable Amazon S3 to the shared file storage capabilities of Amazon EFS, these services empower businesses to store and access data seamlessly while ensuring fault tolerance and data durability. By harnessing the potential of distributed storage in AWS, organizations can future-proof their data infrastructure and provide an exceptional experience to their users.

This article was originally published on Telcobox.

Amazon CloudFront with continuous integration and delivery pipeline

Bugra Kilic — Fri, 25 Nov 2022 14:54:39 +0000

Amazon CloudFront is one of AWS Networking and Content Delivery (N&CD) products which delivers content to the edge locations with low latency and high speed. End users, in other words, visitors all around the globe can reach the content fast and securely. So it is a high end Content Delivery Network (CDN) with more than 410 Points of Presence (PoP) located globally by AWS.

This blog post aims to explain how continuous integration and continuous delivery (CI/CD) works on CloudFront. For more information about creating CF distributions and integration with S3, please see this guide.

Below architecture shows a simple flow from end users to S3 origin bucket by using a CloudFront distribution.

Simple working concept of CloudFront and S3.

So what is a CI/CD pipeline?

It is an agile delivery workflow focusing on frequent and reliable development. It stands for Continuous Integration and Continuous Delivery. And the pipeline is the whole process from building to deployment. All process consist of four stages: Build, Test, Deliver and Deploy.

CI/CD pipeline is important for technical teams and companies to reduce time-consuming jobs, such as iterative manual tasks or unpredictable human caused errors.

Then, what is the challenge of CI/CD for CDN?

CDN changes are relatively slow. Because there is some configuration for content caching mechanism which understands the change of the origin content and distributes this change to all edge locations. And it takes some time to effect. Of course this configuration can be set properly to reduce the caching period, but this is not the only challenge. Besides that, a little misconfiguration can cause an outage to the end users. Therefore any kind of change action should be taken more carefully to prevent a possible outage. If the edge users cannot enter the front door, it is more likely to experience a global or regional service cut.

What is the solution then?

AWS recently published a blog post to announce a new way to safely validate CDN changes. It is not a brand new concept in the server world, but it will be used widely soon for sure.

The solution include a different type of distributions associated with the production distribution. It's called staging distribution. Now developers can safely test and validate all changes on staging part without concerning any sort of problematic issue.

Staging distribution in action.

Traffic can be shifted to the staging by using two main continuous deployment policies.

Weight-based

User has the control to specify the percentage of the user requests which will be routed to staging distribution. Change testing can start small but then increase easily. The change can be applied widely.

Header-based

Only user requests with a specific HTTP header will be routed to staging distribution. This configuration is more useful when some local tests are needs to be done in a small-scaled testing environment.

Since all already understood that the solution includes a way with two methods to develop software without any kind of interruption. So the main difference here is to safely test, integrate and validate a new load to the origin distribution.

Last words

CI/CD usage and latest update on CloudFront have been explained briefly in this post. You can learn to create a staging distribution with the help of this step by step guide written on the same official blog post. Thank you for reading.

Brief explanation to AWS Elastic Load Balancing

Bugra Kilic — Wed, 16 Nov 2022 19:31:40 +0000

Load balancing is a technic of distributing load traffic -such as network traffic- to prevent the data loss, and thereby to improve the system security. So basically it is a feature which gathers traffic data from a cluster of servers or network equipment, and distribute it to another cluster with a pre-configured load balancing algorithms.

The most used industry standard algorithms are branched into two categories:

1. Dynamic load balancing algorithms

Least connection: Allows to check the servers with the fewest connections open, and sends the loaded traffic to those servers.
Weighted least connection: It is a 'least connection' algorithm but the difference is that the connection weight is assigned with the operator manually.
Weighted response time: Allows to send the traffic to related servers with the quickest response according to the calculation of each server's response time.
Resource-based:Sends the traffic according to the CPU and memory usage of servers at that moment.

2. Static load balancing algorithms

Round robin: Allows to distribute traffic to a cluster of servers, virtual machines or network equipment by using Domain Name System (DNS) records.
Weighted round robin: It is a 'round robin' except the weight of each server is configured manually by the operator.
IP hash: Combination of source and destination IP addresses decides where the connection is assigned next. This combination is calculated with a mathematical function to convert it to an IP hash.

If we understood the load balancing and its main algorithms, then we can start talking about what a load balancer is. It is a device which supports all of these features mentioned above. An LB is generally grouped as Layer-4 (L4) or Layer-7 (L7) due to the networking protocols it uses.

L4 load balancer acts with network and transport layer protocols, such as IP, TCP, UDP and FTP. Meanwhile L7 load balancer works with application layer protocols, such as HTTP/HTTPS.

Load balancers on AWS

The concept has a bit more features on the cloud side. The main difference is the elasticity. So it is now called 'Elastic Load Balancing' on AWS. As the official document says, 'Elastic Load Balancing automatically distributes your incoming traffic across multiple targets…', therefore different types of load can be forwarded into various kinds of instances.

Before diving deep in the AWS ELB products, let's find out what the cloud-based load balancer benefits are. First of all, it allows to increase the data protection and prevent any kind of data loss. It is important especially when the flow contains sensitive data. Secondly, it has the elasticity and flexibility to enhance its fault-tolerant architecture. Adding or removing a load balancer is as easy as pie. You can manage your incoming traffic into a single or multiple Availability Zones without disrupting the flow. Also this main feature enables to handle high throughput including a suddenly increased traffic patterns. Third one is about configuring health checks to monitor the status of the resources. With this feature, the load balancer understands which path is healthy and which one is not. And finally, the capability of cloud-native working environment helps to ease cloud migration. This is very important because it exhibits the product's difference compare to the traditional load balancers.

So what are AWS Elastic Load Balancer types?

1. Application Load Balancer:

It works on Layer-7 which is the Application Layer of OSI (Open Systems Interconnection) model. So the most used protocols are HTTP, HTTPS and gRPC.
It receives a request from the traffic resource, then evaluates some rules -called listener rules- to decide which action should be taken.
Default routing algorithm is round robin. However it can be specified as the least connection routing algorithm later.

2. Network Load Balancer:

It is a Layer-4 load balancer which is working on Transport Layer according to OSI model. TCP and UDP are widely used protocols in L4 traffics.
It is able to handle millions of requests per second in this layer. For UDP traffic, the LB selects the target path by using hash algorithm, source/destination IP addresses and ports. For TCP traffic, the LB selects the correct target as same parameters as UDP, but also TCP sequence number does effect the selection.

3. Gateway Load Balancer:

It works partially on Layer-3, which is the Network layer of OSI model. This means that it listens the entire traffic for all IP packets on each port. L3 part is the Gateway itself, while L4 part is the main load balancing operation.
It is mostly used to deploy and manage network-related virtual applications with easy integration function of 3rd party appliances.

4. Classic Load Balancer:

A classic load balancer's logic is very similar to the widely used ones in fixed telecom networks. It simply distributes the incoming traffic across multiple EC2 instances in multiple Availability Zones. It detects unhealthy instances or target path, then forwards the incoming flow to only healthy instances.
It works on both L4 and L7, but this does not mean that it is the best option to choose. It is highly recommend to use specific load balancers for an exact purpose.

For more about AWS Elastic Load Balancing, you can dive deep into the documentation here.

Thanks for reading!

How to prepare for cloud-related certifications

Bugra Kilic — Thu, 01 Sep 2022 18:33:40 +0000

Disclaimer: This blog post is aimed to brighten the way of getting cloud-related certificates with a very subjective approach. The methods may not be suitable for everyone because the learning style differs from person to another.

Almost every professional in tech business knows such certifications programs. Some think that the exams are not quite necessary for the relevant job. That might be true, but it does not mean that these certificates are not required to personal development.

As a builder, I have got my first cloud certificates, responsively Cloud Practitioner and Solutions Architect Associate, in August. But before that, I have seen numerous posts covering "how to study" or "what to study" questions. I guess there are lots of answers for those. For now, I am planning to dive deep into the daily routines and habits in order to accomplish any kind of certification program without any pain.

Let's talk about several daily routines.

1. Make a habit on cloud side.

If you are reading this sentence and smiling a bit, you probably know "Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones" by James Clear. I highly recommend this book to build really good habits for your daily lives, not just cloud purposes. Think your life as a continuous chain and your days as chain rings. When you plan and start an activity from day one, you would not break the chain afterwards. This tendency brings you a habit.

I have been playing with AWS services for more than a year. So taking the certificate exams was always on my mind, but I recently realized that there are easier ways to study these exams. And the first one is creating a daily life routine. How so?

At first, always dive deep in the cloud products and services according to your specific interests. For instance if you wonder how to use serverless functions, try to figure out each aspect of AWS Lambda. When you read something or heard about Lambda, try to clarify your missing knowledge about the service. Finally make it a habit. Then think about how to learn and develop it. This method sounds superficial, however you will see its results after a while.

2. Follow the official blogs.

I use an RSS feeder to follow the well-known CSP blogs. There are definitely something related to my interests every day. Catching up something you are interested in helps you to embrace and improve it.

When there is a new announcement about a cloud service, you will be aware of it within hours. This helps you to follow any change about all products and services. Plus almost each blog post has deep knowledge and experience gathered from the experts. Therefore following these articles provide a strong understanding of how the cloud business goes.

3. Experiment cloud services.

I remember that most of my research time covered with AWS playgrounds. I was curious about each service related to my field, which is Networking & Content Delivery, but also other ones like Compute and Storage. Thus time flies by reading and experimenting with these services mostly.

The internet has tons of brilliant resources about the cloud. But the important point is how to get the right information among lots of similar content. The answer can be found easily on the official documentations and tutorials. There is also Well-architected Framework for the consistent cloud architectures which can be very beneficial for a beginner.

Besides the documents and other stuff, of course, you should be able to use each service with at least a minimum of knowledge. Hands-on experience really matters for the learning purposes. Theoretical knowledge does not come with a practical experience. So that it is definitely required I must say. Cloud Academy has many hands-on exercises and lab playgrounds. I highly recommend you to check them out.

Final words

To sum up, the above suggestions are only daily routines which can take little amount of time in total. If you take aim at getting certified by AWS or any other cloud service providers, you are expected to study the course materials. I suggest to take little notes for each feature and critical point. That is how you can consolidate your effort at last.

The studying for all these stuff can take 24 hours in average. So it is better to start studying as soon as possible. I hope this post is helpful for the ones who thinks about preparing a cert soon. Happy preparing!

AWS Cloud WAN: The General Availability and Product Features

Bugra Kilic — Mon, 18 Jul 2022 22:13:21 +0000

This is not a “Last Week in AWS” however there is something to sum about. AWS announced the general availability of Cloud WAN on July 12. This release is important to manage global on-premise networks with the cloud services. Let’s take a quick look.

As most of you know that WAN stands for Wide Area Networking in the telecom business. It helps to build, manage, monitor and also maintain a global network which contains lots of physical on-premise systems. Of course, not only on-premise environments but also networking-focused cloud products can be connected easily.

You can basically use network policies to specify which of your Virtual Private Clouds (VPC) to any networking service by using AWS Direct Connect or AWS Site-to-Site VPN.

Network Policy: Defines rules and apply policies to configure and manage your network. (Source: Product page)

You can monitor, operate and maintain these configurations on the Cloud WAN central dashboard too.

Central Dashboard: Create connections between your branch offices, data centers, and Amazon VPCs. (Source: Product page)

Cloud WAN is available to use between AWS Regions by using Border Gateway Protocol (BGP). Therefore there is not any technical limitation related to AWS Regions.

Why is it essential?

Global networks are evolving continuously. Since the popular applications are mostly running on serverless and cloud, a huge opportunity for network operators has been born.

How? There is an annual expense for on-premise systems. And it gets worse day after day. However, it can be prevented with the proper usage of the cloud. The basic solution is to migrate some of the suitable services to the cloud. Especially server-based applications or end user-related applications are such examples. So integrating the cloud and the network itself, in other words, hybrid cloud, became a real opportunity to reduce OPEX and CAPEX while operating the systems as usual.

So what is the point of Cloud WAN? Well, Cloud WAN is used to connect region-based services actually. Let’s think about a high-available network application which is deployed in multiple locations.

Without Cloud WAN; it can be hard to turn the system into a hybrid cloud as a whole because there is another conjugate system running in a different region or location.

With Cloud WAN; it is easier to understand the requirement and build accordingly. Since we have a product that can be used to exchange routes with BGP, there is no need to worry about connecting different regions to each other. It is just a bunch of network routing policies after all.

To sum up, Cloud WAN is a great product for creating a hybrid cloud environment. If you or your company does not require local availability (released for several regions for now), then it can be definitely tried out.

If this post seems interesting for you, please see the details of the product page here. Also there are two Twitch sessions covering Cloud WAN.

All content is archived on bugrakilic.github.io. You can reach me on Twitter, LinkedIn or via email. Thanks!

Migration of WordPress from On-prem to AWS Cloud

Bugra Kilic — Wed, 06 Apr 2022 09:13:18 +0000

Many people are talking about cloud lately. Each one of them has a story or a purpose for why getting into the cloud tech. Mine is pretty clear actually. I should have caught the wind and set a sail to this world. So that I am here with my first real-life project that explains the main logic of cloud technologies.

We have founded a small-scale knowledge platform as a hobby for botanists and nature lovers. It is named as Dijital Botanik, which can be seen on dijitalbotanik.com.

Why to choose AWS Cloud instead of on-premise servers?

As soon as the idea developed itself, we have managed the infrastructure and set everything up on one of the local service provider’s on-premise servers. In the course of time, I have realized that there were more opportunities on cloud side. Also on-prem server costs were getting higher and more. There was no better chance to dive deep into AWS at that moment.

Sure, the opportunities are not the only reasons to learn cloud, but also there are other pros of AWS Cloud. Such as, high-available architecture, flexibility of solutions, cost-effectiveness, native integration with many services and variety of usage. In this blog post, you will notice each side briefly.

AWS Service Costs

The cost of WordPress website on AWS depends on your requirements. If you have a simple website including several static pages, then the hosting cost will be very low. In case of having a website, which has 10K visits per day, then you should calculate the estimation on calculator.aws. You should check the sample prices for hosting per year below. But before that, it should be mentioned that AWS Free Tier benefits are totally useful for the ones who wants to get hands-on experience on cloud. Free Tier is only available from the time you create an AWS account to one year ahead. For more information please check aws.amazon.com/free.

As a simple website owner, my estimated cost for hosting per year is written below. The cost was calculated for the required t2.micro EC2 instance, EBS included.

EC2 Instance = 10.58 USD per month (126.96 USD per year)
S3 Storage (optional) = 0.24 USD per month (2.88 USD per year)
CloudWatch (optional) = 1.50 USD per month (18.00 USD per year)
Route 53 = 0.50 USD per month (6.00 USD per year)

For this scenario, 153.84 USD in total can be applied for 1-year hosting.

Please be informed that the first year cost only contains Route 53 price for the Free Tier users.

Now let’s talk about the business for a bit. This section does not consist of many screenshots for answering “how to” questions, but mostly focuses on “why” questions.

Step 1: Installation, but backup first.

If you migrate your WordPress hosting to AWS Cloud, be sure to backup all necessary files before the change. Otherwise you will probably regret for not to do it.

There is a WordPress plugin, named “All-in-One WP Migration” on the official market. The backup can be downloaded to your local instantly via this plugin. The most important part of the plugin is that there is a file size limit. It means you might delete some unnecessary files if the backup size exceeds the limit.

Configure > Deploy > Review

The main order is like above. First of all, the configuration of the EC2 instance should be done. As already mentioned that t2.micro instances are very suitable for small-scale and Free Tier usage. It is a 1 GB RAM and 1 vCPU server, also including maximum 30GB General Purpose SSD (gp2) EBS service. While launching a virtual machine, you need to select an AMI (Amazon Machine Imagery). And for this blog post, WordPress Certified by Bitnami and Automattic AMI should be chosen. After selecting the required instance type (eg. t2.micro), instance and storage details should be configured respectively. Related sections are shown on the below screenshots.

If there is no need to configure tags or security groups, you can directly Review and Launch the instance after this point.

The system will pop-up a screen for SSH key pair on launching page. It is very important to download and save this particular key pair to directly connect with your instance through SSH later.

Step 2: It is always DNS.

Remember to configure the new DNS settings properly. Otherwise, you will find yourself saying the title at least once.

As soon as the instance launched, there will be an assigned IPv4 address to that instance automatically. You can keep using that IP later, or change it with a static Elastic IP. It would be better to use an Elastic IP in case of an incident.

The changes of DNS-related information can be done on the domain name provider while the system is running on on-premise servers. I have used a local service provider, Turhost, to keep the website up. Therefore the related DNS change should firstly be configured on the provider side where you bought the name server service. Plus it is required to update DNS records according to AWS configuration (NS parameters).

Step 3: Configuration of SSL and first sight.

Each EC2 instance has a unique ID written on the “Instances” section on EC2 page. There are various ways to connect to the instances of course. However, this part covers the SSH option only.

It is supposed to launch the instance with WordPress AMI in the previous step. If so, you can directly connect to your instance with the line of SSH command below.

ssh -i “dijitalbotanik-ssh-key.pem” bitnami@ec2–YourIPv4Address.eu-central-1.compute.amazonaws.com

Sure your instance IP should be written on “YourIPv4Address” parameter. Also the default user is “admin”, but we need to use “bitnami” as a user to connect to WordPress. And remember to use your SSH key pair in the command. There might be a problem with the key pair due to user authorization. The below line of Linux command needs to be run in order to solve that kind of issues. It will change the permissions of this key file.

chmod 600 dijitalbotanik-ssh-key.pem

And here it is! You can directly play around your instance with SSH. But first, there is one thing must be configured in the beginning: SSL.

To done it quickly, you need to answer each questions of bncert-tool. This is the point you are setting HTTP/HTTPS and www/non-www redirections.

sudo /opt/bitnami/bncert-tool

Step 4: Importing WordPress backup.

If the previous parts are totally okay, then the last thing to do is importing the WordPress backup again. You can login to WordPress portal with the same URL as before. The users and other settings you stored are the same. So there should not be a login issue.

After logged in to the admin dashboard, All-in-One WP Migration tool required to be installed again. The entire website migrated to another infrastructure, so there is not any old extensions or tools. Afterwards, the backup file should be imported. This will take a while, but be sure that export and import file size limits in case of an unwanted issue.

Final thoughts

As mentioned earlier, there are lots of advantages of cloud. And such migrations are the best way to learn and practice this technology.

Dijital Botanik has been migrated on February 17. There is not any incident or major alarm since then. So far so good. I highly recommend every interested person to step in.

Thanks for reading! You can check out and share Dijital Botanik with your circle!

dijitalbotanik.com

All content is archived on bugrakilic.github.io. You can reach me on Twitter, LinkedIn or via email. Thanks!