companies of all sizes move into public cloud, a key question is often around
internet access. Primarily for the servers and infrastructure within AWS,
however as they begin to have less equipment on-premise and look to either make
their datacenter/physical server footprint as small as possible, or close
on-premise datacenters entirely they are often left with a key question. What
can I do about the firewalls serving my on-premise infrastructure? Often these
firewalls are the remaining infrastructure in a datacenter which not only keeps
you tied to the datacenters, but also tied to all of the costs associated.
Continue reading “Route on-premise internet traffic through AWS”
When using a managed Kibana dashboard on AWS Elasticsearch, it can take a lot of the heavy lifting and complexity out of setting up your own Kibana dashboard for log aggregation, however you may find that one day your dashboard stops showing results and displays a “☹ No Results Found” error for all your Kibana dashboard insights.
Continue reading “Troubleshooting “No Results Found” and Red status for “ClusterIndexWritesBlocked” on Kibana Dashboard for AWS Elasticsearch”
When looking to deploy any infrastructure onto AWS, as with on-premise infrastructure, its important to get the foundations and connectivity right from the start to avoid a “bolt-on” fix later. Its important to not only design for what you have in place currently, but also allow for future growth while understanding the limitations of what you are implementing. In this article, we will look at some of the key reasons to use Transit VPC or Transit Gateway architectures. This will be a brief comparison of both architectures and a Transit VPC vs Transit Gateway comparison to help you make the correct choice for your infrastructure.
Continue reading “Transit VPC vs Transit Gateway for AWS Architectures”
Now that we have demonstrated fully implementing a highly available multi AZ FSx for Windows solution, this section will briefly review some of the costs that FSx can incur and also some considerations that should be kept in mind while implementing this solution in a production system.
Continue reading “AWS – Making AWS FSx for Windows Highly Available through Multi AZ Resilience – Part 7: Costs and Considerations”
To check our namespace will still be available if we were to lose one of our namespace servers, we are going to simulate a failure of the one of the namespace servers and then also remove connectivity to our primary subnet containing a FSx filesystem and a namespace server (this is the subnet in AZ B). This loss of connectivity should have no impact on accessing our files, and also, once restored, should replicate any changes while it was offline.
Continue reading “AWS – Making AWS FSx for Windows Highly Available through Multi AZ Resilience – Part 6: Testing Multi AZ FSx for Windows High Availability”