Amazon EKS Overview: AWS’s Managed Kubernetes Service

Amazon EKS Overview: AWS’s Managed Kubernetes Service

Amazon EKS is a hosted Kubernetes solution that helps you run your container workloads in AWS without having to manage the Kubernetes control plane for your cluster. This is a great entry point for Kubernetes administrators who are looking to migrate to AWS services but want to continue using the tooling they are already familiar with. Often, users are choosing between Amazon EKS and Amazon ECS (which we recently covered, in addition to a full container services comparison), so in this article, we’ll take a look at some of the basics and features of EKS that make it a compelling option.

Amazon EKS 101

The main selling point of Amazon EKS is that the Kubernetes control plane is managed for you by AWS, so you don’t have to set up and run your own. When you set up a new cluster in EKS, you can specify if it’s going to be just available to the current VPC, or if it will be accessible to outside IP addresses. This flexibility highlights the two main deployment options for EKS:

  1. Fully within an AWS VPC, with complete integration to other AWS services you run in your account while being completely isolated from the outside world.
  2. Open and accessible, which enables hybrid-cloud, multi-cloud, or multi-account Kubernetes deployments.

Both options allow you the flexibility to use your own Kubernetes management tools, like Dashboard and kubectl, as EKS gives you the API Server Endpoint once you provision the cluster. This control plane utilizes multiple availability zones within the region you choose for redundancy.

Managed Container Showdown: EKS vs. ECS

Amazon offers two main container service options in EKS and ECS, and both are using Kubernetes under the hood. The biggest difference between the two options lies in who is doing the management of Kubernetes. With ECS, Amazon is running Kubernetes for you, and you just decide which tasks to run and when. Meanwhile, with EKS, you’re doing the Kubernetes management of your pods.

One consideration when considering EKS vs. ECS is networking and load balancing. Both services run EC2 servers behind the scenes, but the actual network connection is slightly different. ECS has network interfaces connected to individual tasks on each EC2 instance, while EKS has network interfaces connecting to multiple pods on each EC2 instance. Similarly, for load balancing, ECS can utilize Application Load Balancers to send traffic to a task, while EKS must use an Elastic Load Balancer to send traffic to an EC2 host (which can have a proxy via Kubernetes). Neither is necessarily better or worse, just a slight difference that may matter for your workload.

Sounds Great… How Much Does It Cost?

For each workload you run in Amazon EKS, there are two main charges that will apply.  First, there’s a charge of $0.20/hr (roughly $146/month) for each EKS Control Plane you run in your AWS account. Second, you’re charged for the underlying EC2 resources that are spun up by the Kubernetes controller. This second charge is very similar to how Amazon ECS charges you, and is highly dependant on the size and amount of resources you need.

Amazon EKS Best Practices

There’s no one-size-fits-all option for Kubernetes deployments, but Amazon EKS certainly has some good things going for it. If you’re already using Kubernetes, this can be a great way to seamlessly migrate to a cloud platform without changing your working processes. Also, if you’re going to be in a hybrid-cloud or multi-cloud deployment, this can make your life a little easier. That being said, for just simple Kubernetes clusters, the price of the control plane for each cluster may be too much to pay, which makes ECS a valid alternative.

More on container management and container optimization.

AWS New Services 2019 – What’s in Preview?

AWS New Services 2019 – What’s in Preview?

As the cloud giant, Amazon Web Services (AWS) is constantly innovating – it’s no surprise that at any given time, there’s a list of AWS new services that will soon be released. We’ve put together a list of AWS new services that are currently in “preview” and are expected to be released later this year. Many of these were announced at AWS re:Invent 2018.

Interested in a list of all the services AWS offers? We actually just put that together too. See all 176 services here: AWS Services List.

AWS New Services 2019

This list is broken down by category, including Analytics, Blockchain, Compute, Database, Internet of Things, Machine Learning, and Security. While all are in preview right now, their release dates may vary.

Analytics

AWS Lake Formation

    • AWS Lake Formation makes it easy to set up a secure data lake in days.
    • Lake Formation collects and catalogs data from databases and object storage, moves the data into your new Amazon S3 data lake, cleans and classifies data using machine learning algorithms, and secures access to your sensitive data.
    • Benefits: build data lakes quickly, simplify security management, and make self-service access to data both easy and secure
    • Announced: November 2018 (at re:Invent)

Blockchain

Amazon Managed Blockchain

    • Amazon Managed Blockchain makes it easy to create and manage scalable blockchain networks
    • Fully managed
    • Automatically scales to meet the demands of thousands of applications running millions of transactions. Manages your certificates, lets you easily invite new members to join the network, and tracks operational metrics such as usage of compute, memory, and storage resources.
    • Can replicate an immutable copy of your blockchain network activity into Amazon Quantum Ledger Database (QLDB), a fully managed ledger database so you can easily analyze the network activity outside the network and gain insights into trends.
    • Announced: November 2018 (at re:Invent)

Amazon Quantum Ledger Database (QLDB)

    • Amazon QLDB is a ledger database that provides a transparent, immutable, and cryptographically verifiable transaction log ‎owned by a central trusted authority
    • Tracks each and every application data change and maintains a complete and verifiable history of changes over time
    • Benefits: immutable and transparent, cryptographically verifiable, highly scalable, serverless, easy to use.
    • Announced: November 2018 (at re:Invent)

Compute

AWS Outposts

    • AWS Outposts brings native AWS services, infrastructure, and operating models to virtually any data center, co-location space, or on-premises facility.
    • Use the same APIs, same tools, same hardware, and same functionality across on-premises and the cloud to deliver a truly consistent hybrid experience.
    • Outposts can be used to support workloads that need to remain on-premises due to low latency or local data processing needs.
    • AWS Outposts come in two variants:
      • 1) VMware Cloud on AWS Outposts allows you to use the same VMware control plane and APIs you use to run your infrastructure
      • 2) AWS native variant of AWS Outposts allows you to use the same exact APIs and control plane you use to run in the AWS cloud, but on-premises.
    • Announced: November 2018 (at re:Invent)

Database

Amazon RDS on VMware

    • Amazon RDS on VMware lets you deploy managed databases in on-premises VMware environments
    • Provides cost-efficient and resizable capacity while automating time-consuming administration tasks including hardware provisioning, database setup, patching, and backups.
    • Allows you to utilize the same simple interface for managing databases in on-premises VMware environments as you would use in AWS. You can easily replicate RDS on VMware databases to RDS instances in AWS, enabling low-cost hybrid deployments for disaster recovery, read replica bursting, and optional long-term backup retention in Amazon Simple Storage Service (S3).
    • Announced: November 2018 (at re:Invent)

Internet of Things

AWS IoT Events

    • AWS IoT events is a fully managed IoT service that makes it easy to detect and respond to events from IoT sensors and applications
    • Continuously monitors data from multiple IoT sensors and applications, and it integrates with other services, to enable early detection and unique insights into events.
    • Benefits: easily ingest operations data, trigger a range of actions, easily build rules.
    • Announced: November 2018 (at re:Invent)

AWS IoT SiteWise

    • AWS IoT SiteWise is a managed service that makes it easy to collect and organize data from industrial equipment at scale.
    • Provides software running on a gateway that resides in your facilities and automates the process of collecting and organizing industrial equipment data.
    • Benefits: monitor operations across facilities, quickly compute common industrial performance metrics, and build applications to analyze industrial equipment data, prevent costly equipment issues, and reduce production inefficiencies.
    • Announced: November 2018 (at re:Invent)

AWS IoT Things Graph

    • AWS IoT Things Graph is a service that makes it easy to visually connect different devices and web services to build IoT applications.
    • Provides a visual drag-and-drop interface for connecting and coordinating devices and web services, so you can build IoT applications quickly.
    • You can get started with AWS IoT Things Graph using these pre-built models for popular device types, such as switches and programmable logic controllers (PLCs), or create your own custom model using a GraphQL-based schema modeling language, and deploy your IoT application to AWS IoT Greengrass-enabled devices such as cameras, cable set-top boxes, or robotic arms in just a few clicks
    • Announced: November 2018 (at re:Invent)

Machine Learning

Amazon Personalize

    • Amazon Personalize is a machine learning service that makes it easy for developers to create individualized recommendations for customers using their applications.
    • Allows developers with no prior machine learning experience to easily build sophisticated personalization capabilities into their applications, using machine learning technology perfected from years of use on Amazon.com.
    • Amazon Personalize will process and examine the data, identify what is meaningful, select the right algorithms, and train and optimize a personalization model that is customized for your data. You provide an activity stream from your application – page views, signups, purchases, and so forth – as well as an inventory of the items you want to recommend, such as articles, products, videos, or music.
    • Announced: November 2018 (at re:Invent)

Amazon Forecast

    • Amazon Forecast is a fully managed service that uses machine learning to deliver highly accurate forecasts, based on the same technology used at Amazon.com.
    • Uses machine learning to combine time series data with additional variables to build forecasts.
    • Requires no machine learning experience to get started.
    • Announced: November 2018 (at re:Invent)

Amazon Textract

    • Amazon Textract is a service that automatically extracts text and data from scanned documents. It goes beyond simple optical character recognition (OCR) to also identify the contents of fields in forms and information stored in tables.
    • Using machine learning to instantly “read” virtually any type of document to accurately extract text and data without the need for any manual effort or custom code.
    • Benefits: extract data quickly and accurately, no code or templates to maintain, lower document processing costs.
    • Announced: November 2018 (at re:Invent)

AWS DeepRacer

    • AWS DeepRacer is the first autonomous scale car specifically developed to help developers get hands-on with reinforcement learning.
    • Gives developers a simple way to learn RL, experiment with new RL algorithms and simulation-to-real domain transfer methods, and experience RL in the real world.
    • Participate in the AWS DeepRacer League at in-person events throughout the globe.
    • Announced: November 2018 (at re:Invent)

Security, Identity & Compliance

AWS Security Hub

    • AWS Security Hub gives you a comprehensive view of your high-priority security alerts and compliance status across AWS accounts.
    • Offers a single place that aggregates, organizes, and prioritizes your security alerts, or findings, from multiple AWS services, such as Amazon GuardDuty, Amazon Inspector, and Amazon Macie, as well as from AWS Partner solutions.
    • Announced: November 2018 (at re:Invent)

Trends in AWS New Services

Looking at these new services as a sample group, there are a few trends in the emerging technology. To no one’s surprise, there are a few blockchain and IoT announcements, both of which continue to be trending topics. Machine learning products also make up much of the list above – interestingly, with several releases of technology used to power Amazon.com.

Have you tried any of these new services? Let us know what you think of them!

AWS IAM User vs IAM Role for Secure SaaS Cloud Management

AWS IAM User vs IAM Role for Secure SaaS Cloud Management

While going through our recent Cloud Cost Optimization Competency review with AWS, one of the things they asked us to do was remove the ability for customers to sign up for our service using AWS IAM User credentials. They loved the fact that we already supported AWS IAM Role credentials, but their concern was that AWS IAM User credentials could conceivably be stolen and used from outside AWS by anyone. (I say inconceivable, but hey, it is AWS.)  This was a bit of a bitter pill to swallow, as some customers find IAM Users easier to understand and manage than IAM Roles. The #1 challenge of any SaaS cloud management platform like ours is customer onboarding, where every step in the process is one more hurdle to overcome.

While we could debate how difficult it would be to steal a customer cloud credential from our system, the key (pun intended) thing here is why is an IAM Role preferred over an IAM User?

Before answering that question, I think it is important to understand that an IAM Role is not a “role” in perhaps the traditional sense of Active Directory or LDAP. An AWS IAM Role is not something that is assigned to a “User” as a set of permissions – it is a set of capabilities that can be assumed by some other entity. Like putting on a hat, you only need it at certain times, and it is not like it is part of who you are. As AWS defines the difference in their FAQ:

An IAM user has permanent long-term credentials and is used to directly interact with AWS services. An IAM role does not have any credentials and cannot make direct requests to AWS services. IAM roles are meant to be assumed by authorized entities, such as IAM users, applications, or an AWS service such as EC2.

(The first line of that explanation alone has its own issues, but we will come back to that…)

The short answer for SaaS is that a customer IAM Role credential can only be used by servers running from within the SaaS provider’s AWS Account…and IAM User credentials can be used by anyone from anywhere. By constraining the potential origin of AWS API calls, a HUGE amount of risk is removed, and the ability to isolate and mitigate any issues is improved.

What is SaaS?

Software as a Service (SaaS) means different things to different vendors. Some vendors claim to be “SaaS” for their pre-built virtual machine images that you can run in your cloud. Maybe an intrusion detection system or a piece of a cloud management system. In my (truly humble) opinion this is not a SaaS – this is just another flavor of “on prem” (on-premise), where you are running someone’s software in your environment. Call it “in-cloud” if you do not want to call it “on-prem”, but it is not really SaaS, and it does not have the challenges you will experience with a “true” SaaS product – coming in from the outside. A core component of SaaS is that it is centrally hostedoutside your cloud. For an internal service, you might relax permissions and access mechanisms somewhat, as you have total control over data ingress/egress. A service running IN your network…where you have total control over data ingress/egress…is not the same as external access – the epitome of SaaS. Anyway: </soapbox>. (Or maybe </rant> depending on the tone you picked up along the way…)  

The kind of SaaS I am focussing on for this blog is SaaS for cloud management, which can include cloud diagramming tools, configuration management tools, storage management+backup tools, or cost optimization tools like ParkMyCloud.

AWS has enabled SaaS for secure cloud management more than any other cloud provider. A bold statement, but let’s break that down a bit. We at ParkMyCloud help our customers optimize their expenses at all of the major cloud providers and so obviously all the providers allow for access from “outside”. Whether it is an Azure subscription, a GCP project, or an Alibaba account, these CSP’s are chiefly focussed on customer internal cross-domain access. I.e., the ability of the “parent” account to see and manage the “child” accounts. Management within an organization. But AWS truly acknowledges and embraces SaaS.

You could attribute my bold statement to an aficionado/fanboi notion of AWS having a bigger ecosystem vision, or more specifically that they simply have a better notion of how the Real World works, and how that has evolved in The Cloud. The fact is that companies buy IT products from other companies…and in the cloud that enables this thing called Software as a Service, or SaaS. All of the cloud providers have enabled SaaS for cloud access, but AWS has enabled SaaS for more secure cloud access.

AWS IAM Cross-account Roles

So…where was I?  Oh…right…Secure SaaS access.

OK, so AWS enables cross-account access. You can see this in the IAM Create Role screen in the AWS Console:

If your organization owns multiple AWS accounts (inside or outside of an AWS “organization”), cross-account access allows you to use a parent account to manage multiple child accounts. For SaaS, cross-account access allows a 3rd-party SaaS provider to see/manage/do stuff with/for your accounts.

Looking a little deeper into this screen, we see that cross-account access requires you to specify the target account for the access:

The cross-account role allows you to explicitly state which other AWS account can use this role. More specifically: which other AWS account can assume this role.

But there is an additional option here talking about requiring an “external ID”…what is that about?  

Within multiple accounts in a single organization, this may allow you to differentiate between multiple roles between accounts….maybe granting certain permissions to your DevOps folks…other permissions to Accounting…and still other permissions to IT/network management.

If you are a security person, AWS has some very interesting discussions about the “confused deputy” problem mentioned on this screen. It discusses how a hostile 3rd party might guess the ARN used to leverage this IAM Role, and states that “AWS does not treat the external ID as a secret” – which is all totally true from the AWS side. But summing it up: cross-account IAM Roles’ external IDs do not protect you from insider attacks. For an outsider, the External ID is as secret as the SaaS provider makes it.

Looking at it from the external SaaS side, we get a bit of a different perspective. For SaaS, the External ID allows for multiple entry points…and/or a pre-shared secret. At ParkMyCloud (and probably most other SaaS providers) we only need one entry point, so we lean toward the pre-shared secret side of things. When we, and other security-conscious SaaS providers, ask for access, we request an account credential, explicitly giving our AWS account ID and an External ID that is unique for the customer. For example, in our UI, you will see our account ID and a customer-unique External ID:

Assume Role…and hacking SaaS

If we look back at the definition of the AWS IAM Role, we see that IAM roles are meant to be assumed by authorized entities. For an entity to assume a role, that party has to be an AWS entity that has the AWS sts:AssumeRole permission for the account in which it lives. Breaking that down a bit, the sts component of this permission tells us this comes from the AWS Secure Token Services, which can handle whole chains of delegation of permissions. For ParkMyCloud, we grant our servers in AWS an IAM Role that has the sts:AssumeRole permission for our account. In turn, this allows our servers to use the customer account ID and external ID to request permission to “Assume” our limited-access role to manage a customer’s virtual machines.

From the security perspective, this means if a hostile party wanted to leverage SaaS to get access to a SaaS customer cloud account via an IAM User, they would need to:

  • Learn an account ID for a target organization
  • Find a SaaS provider leveraged by that target organization
  • Hack the SaaS enough to learn the External ID component of the target customer account credentials
  • Completely compromise one of the SaaS servers within AWS, allowing for execution of commands/APIs to the customer account (also within AWS), using the account ID, External ID, and Assume Role privileges of that server to gain access to the customer account.
  • Have fun with the customer SaaS customer cloud, but ONLY from that SaaS server.

So….kind-of a short recipe of what is needed to hack a SaaS customer. (Yikes!)  But this is where your access privileges come in. The access privileges granted via your IAM role determine the size of the “window” through which the SaaS provider (or the bad guys) can access your cloud account. A reputable SaaS provider (ahem) will keep this window as small as possible, commensurate with the Least Privilege needed to accomplish their mission.

Also – SaaS services are updated often enough that the service might have to be penetrated multiple times to maintain access to a customer environment.

So why are AWS IAM Users bad?

Going back to the beginning, our quote from AWS stated “An IAM user has permanent long-term credentials and is used to directly interact with AWS services”. There are a couple frightening things here.

Permanent long-term credentials” means that unless you have done something pretty cool with your AWS environment, that IAM User credential does not expire. An IAM User credential consists of a Key ID and Secret Access Key (an AWS-generated pre-shared secret) that are good until you delete them.

“…directly interact with AWS services” means that they do not have to be used from within your AWS account. Or from any other AWS account. Or from your continent, planet, galaxy, dimension, etc. That Key ID and Secret can be used by anyone and anywhere.

From the security perspective, this means if a hostile party wanted to leverage SaaS to get access to a SaaS customer cloud account via an IAM Role, they would need to:

  • Learn an account ID for a target organization
  • Find a SaaS provider leveraged by that target organization
  • Hack the SaaS enough to get the IAM User credentials.
  • Have fun…from anywhere.

So this list may seem only a little bit shorter, but the barriers to compromise are somewhat lower, and the opportunity for long-term compromise is MUCH longer. Any new protections or updates for the SaaS servers has no impact on an existing compromise. The horse has bolted, so shutting the barn door will not help at all.

What if the SaaS provider is not in AWS?  Or…what if *I* am not in AWS?

The other cloud providers provide some variation of an access identifier and a pre-shared secret. Unlike AWS, both Azure and Google Cloud credentials can be created with expiration dates, somewhat limiting the window of exposure. Google does a great job of describing their process for Service Accounts here. In the Azure console, service accounts are found under Azure AD>App registrations>All apps>App details>Settings>Keys, and passwords can be set to expire in 1 year, 2 years, or never. I strongly recommend you set reminders someplace for these expiration dates, as it can be tricky to debug an expired service account password for SaaS.

For all providers you can also limit your exposure by setting a very limited access role for your SaaS accounts, as we describe in our other blog here.

Azure does give SaaS providers the ability to create secure “multi-tenant” apps that can be shared across multiple customers. However, the API’s for SaaS cloud management typically flow in the other direction, reaching into the customer environment, rather than the other way around.

IAM Role – the Clear Winner

Fortunately, when AWS “strongly recommended” that we should discontinue support for AWS IAM User-based permissions, we already supported an upgrade path, allowing our customer to migrate from IAM User to IAM Role without losing any account configuration (phew!). We have found some scenarios where IAM Role cannot be used – like between the AWS partitions of AWS global, AWS China, and the AWS US GovCloud. For GovCloud, we support ParkMyCloud SaaS by running another “instance” of ParkMyCloud from within GovCloud, where cross-account IAM Role is supported.

With the additional security protections provided for cross-account access, AWS IAM Role access is the clear winner for SaaS access, both within AWS and across all the various cloud providers.

Why the Principle of Least Privilege is Important for SaaS-based Cloud Management

Why the Principle of Least Privilege is Important for SaaS-based Cloud Management

The principle of least privilege is important to understand and follow as you adopt SaaS technologies. The market for SaaS-based tools is growing rapidly, and can typically be activated much more quickly and cheaply than creating a special-purpose virtual machine within your cloud environment. In this blog, I am focusing specifically on the SaaS cloud management tool area, which can include services like cloud diagramming tools, configuration management tools, storage management and backup tools, or cost optimization tools like ParkMyCloud.

Why the Principle of Least Privilege is Important

Before you start using such tools and services, you should carefully consider how much access you are granting into your cloud. The principle of least privilege is a fundamental tenet of any identity and access control policy, and basically means a service or user should have no more permissions than absolutely required in order to do a job.

Cloud account privileges and permissions are typically granted via roles and permissions. All of the cloud providers provide numerous predefined roles, which consist of pre-packaged sets of permissions. Before granting any requested predefined role to a 3rd-party, you should really investigate the permissions or security policy embedded in that role. In many (most?) cases, you are likely to find that the predefined roles give a lot more information or capabilities away than you are really likely to want.

SaaS Onboarding – Where Least Privilege Can Get Lost

For on-boarding of new SaaS customers, the initial permissions setup is often the most complicated step, and some SaaS cloud management platforms try to simplify the process by asking for one of these predefined roles.  For example, the Amazon ReadOnlyAccess role or the Azure Reader role or the GCP roles/viewer role.  While this certainly makes onboarding of SaaS easier, it also exposes you to a massive data leakage problem.  For example, with the Amazon ReadOnlyAccess role a cloud diagramming tool can certainly get a good enough view of your cloud to create a map…but you are also granting read access for all of your IAM Users, CloudTrail events and history, any S3 objects you have not locked-down with a distinct bucket policy, and….lots of other stuff you probably do not even know you have.  It is like kinda like saying – “Here, please come on in and look at all of our confidential file cabinets – and it is OK for you to make copies of anything interesting, just please do not change any of our secrets to something else…”  No problem, right?

Obviously, least privilege becomes especially critical when giving permissions to a SaaS provider, given the risk of trusting your cloud environment to some unknown party.

Custom Policies for SaaS

Because of the broad nature of many of their predefined roles, all of the major cloud providers give you the ability to assign specific permissions to both internal and external users through Policies.  For example, the following policy snippets show the minimum permissions ParkMyCloud requests to list, start, and stop virtual machines on AWS, Google, and Azure.

Creating and assigning these permissions makes SaaS onboarding a bit more complicated, but it is worth the effort in terms of reducing your exposure.

Other Policy Restrictions

What if you want to give a SaaS provider permissions, but lock it down to only certain resources or certain regions?  AWS and Azure allow you to specify in the policy which resources the policy can be applied to. Google Cloud….not so much.  AWS takes this the farthest, allowing for very robust policies down to specific services, and the addition of tag-based caveats for the policy permissions, for example:

This policy locks down the Start and Stop permissions to only those instances that have the tag name/value parkmycloud: yes, and are located in the us-east-1 region.  Similar Conditions can be used to lock this down by region, instance type, and many other situations. (This recent announcement shows another way to handle the region restriction.)

Azure has somewhat similar features, though with a slightly different JSON layout, as described here.  It does not appear you can use resource tags to for Azure, nor does Azure provide easy ways to limit the geographic scope of permissions.  You can get around the location and grouping of resources by using Azure Management Groups, but that is not quite as flexible as an arbitrary tag-based system, and is actually more intended to aggregate resources across subscriptions, rather than be more specific within a subscription.  That said, the Azure permissions defined here are a bit more granular than AWS.  This does allow for a bit more specificity in permissions if it is needed, but can no doubt grow tedious to list and manage.

Google Cloud provides a long list of predefined roles here, with an excellent listing the contained permissions.  There is also an interesting page describing the taxonomy of the permissions here, but Google Cloud appears to make it a bit difficult to enumerate and understand the permissions individually, outside of the predefined roles.  Google does not provide any tag or resource-based restrictions, apart from assignment at the Project level. More on user management and roles by cloud provider in this blog.

Gotchas

You may note that the ec2:Describe permission in our last example does not have the tag-based restriction.  This is because the tag-based restriction can only be used for certain permissions, as shown in the AWS documentation.  Note also that some APIs can do several different operations, some of which you may be OK with sharing, and others not.  For example, the AWS ModifyInstance permission allows the API user to change the instance type.  But…this one API (and associated permission) also allows the API user to modify security group assignments, shutdown behaviors, and other features – things you may not want to share with an untrusted 3rd party.

Key takeaway here?  Look out for permissions that may have unexpected consequences.

Summary

Beware of SaaS cloud management providers who are asking for simple predefined roles from your cloud provider.  They are either giving a LOT more functionality than you are likely to want from a single provider, or they are asking for a lot more permissions than they need.  Ask for a “limited access policy” that gives the SaaS provider ONLY what they need, and look for a document that defines these permissions and how they tie back to what the SaaS provider is doing for you.

These limited access policies serve to limit your exposure to accidents or compromises at the SaaS provider.

Cloud Storage Cost Comparison: AWS vs. Azure vs. Google

Cloud Storage Cost Comparison: AWS vs. Azure vs. Google

Today, we’ll take a brief look at cloud storage cost comparison from the three major cloud service providers. When it comes to finding a solution for your cloud computing needs, it is fair to say that for every business the solutions are based on a case-by-case scenarios – and given the breadth of cloud storage options available, it is certainly true in this case. A few things we’ll briefly touch points on are pricing models, discounts and steps you can take to avoid wasted cloud spend.

The leading cloud service providers have certain fortes and weaknesses that ultimately differentiate each one of them to be the potential solution to support your development infrastructure, operations and applications. Cloud service providers offer many different cloud pricing points depending on your compute, storage, database, analytics, application and deployment requirements. Additionally, you’d want to consider available services and networks provided to see the full scope of their resource capabilities and governance.

Prices can be subject to the type of hosting option you choose. One example is Relational Database Services (RDS). RDS pricing changes according to which database management system you use, and there are many more services like this to choose from.

More detail, beyond just storage, available in our full cloud pricing comparison.

AWS and Google Stand Out

Although not always the case, AWS is presumed to be the least expensive option available and remains the leader in the cloud computing market. But, Microsoft Azure and Google (GCP) are not far behind, and in recent years they have commanded innovation and market pricing reductions, thus closing gaps to bring them closer to AWS. That been said, being the first in the market gives AWS a great advantage over the competition as they command a large scale of businesses and are able to offer lower prices than the competition. They are well known for attracting more businesses, and in turn, they invest their money back into the cloud by adding more servers to their data centers. Google is closing the gap on AWS as they were the first to cut prices in their pricing model to match AWS’.

Storage Services Overview

Let’s take a look at some of the more popular storage options offered by each of the major three providers.

Amazon S3

Amazon Simple Storage Service (S3) is the most durable, highly performant and secure cloud storage service. It manages accounts at every level, scales on-demand and offers insights with built-in analytics.  

Amazon EBS

Amazon Elastic Block Store (EBS) provides block level storage volumes for use with EC2 instances. EBS delivers low-latency and consistent performance scaled to the needs of your application.

Amazon Glacier

Amazon Glacier provides data archiving and long-term back up at a low-cost. It allows you to query data in place and retrieve only the subset of data you need from within an archive.

More about AWS options: https://aws.amazon.com/products/storage/

Google Cloud Storage

Google Cloud Storage offers a single API for all storage classes, simplifying development integration and reducing code complexity. Its highly scalable and performant with unlimited object storage.

Cloud Filestore

Google Filestore is a high-performance file storage for applications that require a filesystem interface and a shared filesystem for data.

Persistent Disk

Google Persistent Disk is a reliable high-performance block storage for virtual machine instances.

Explore Google storage options: https://cloud.google.com/products/storage/

Archive Storage

Azure Archive Storage offers a low-cost, durable, and highly available secure cloud storage for rarely accessed data with flexible latency requirements.

Blob Storage

Azure Blob Storage is a massively scalable object storage for unstructured data.

Azure Files

Azure Files is a simple, secure and fully managed cloud file sharing storage.

Check this out as well on Azure options: https://docs.microsoft.com/en-us/azure/architecture/aws-professional/services

Sample Pricing Comparison

cloud storage cost comparison chart

Eliminate Cloud Overspend and Save Money

Comparing cloud storage costs and getting the right solution for your storage use case is important, but don’t forget once you deploy you need to ensure you optimize your solution and cost. It’s important that your organization fully understands how much can be wasted on cloud spend. Over-provisioned, underutilized and idle cloud resources run your cloud bill up and create waste. Always ensure that you are optimizing costs and governing usage by eliminating wasted cloud spend  – get started today.

Amazon ECS Overview: What You Need To Know

Amazon ECS Overview: What You Need To Know

Amazon ECS is a great choice of container hosting platforms for AWS developers, among the many available options. Jumping into an ECS deployment can be daunting, as there are multiple options and varying terminology with hard-to-predict costs. We’ll go over some of the basics of Amazon ECS, including some terminology and price considerations you’ll need to consider.

Amazon ECS 101

Amazon ECS (which stands for Elastic Container Service) lets you run Docker containers without having to manage the orchestration of those containers. With ECS, you can deploy your containers on EC2 servers or in a serverless mode, which Amazon calls Fargate. Both deployment types handle the orchestration and underlying server management for you, so you can just schedule and deploy your containers.

Amazon ECS can work for both long-running jobs and short bursts of tasks, and includes tools for adjusting the scale of the container fleet as well as the scheduling of those containers. Task placement definitions let you choose which instances get which containers, or you can let AWS manage this by spreading across all Availability Zones.

Benefits of Amazon ECS include:

  • Easy integrations into other AWS services, like Load Balancers, VPCs, and IAM
  • Highly scalable without having to manage the cluster masters
  • Multiple management methods, including the AWS console, the AWS API, or CloudFormation templates
  • Elastic Container Registry helps you manage and sort your container images

Tasks and Services and Containers (Oh My!)

Diving into the world of containers on AWS requires the use of some terminology you may not be familiar with:

  • Container – An isolated environment that contains the bare minimum of services and code needed to run just a particular part of your application or microservice, designed to be run on any Docker-compatible OS.
  • Task Definition – A layout of the pieces required to run your application, which can include one or more containers along with networking and system requirements.
  • Task – An instantiation of a Task Definition.  Multiple tasks can use the same task definition.
  • Service – A layout of the boundaries and scaling options you set for your groupings of similar Tasks, which is similar to the relationship between AutoScaling Groups and EC2 Virtual Machines.
  • Cluster – A collection of EC2 instances running a specialized operating system where you will run your Service.

ECS Pricing: The (Hopefully Not) Million Dollar Question

Amazon ECS pricing has a few different variables, starting with your choice of deployment methods.  Since Fargate abstracts away the underlying infrastructure, you only pay for the seconds of vCPU and Memory that your Tasks are using (with a minimum of 1 minute for each Task). This pricing structure has the “serverless architecture” benefit of only paying for what you need when you need it, but also means that estimating these charges can be quite difficult.

Standard ECS pricing does not charge per-Task, but will charge based on the infrastructure you have deployed for your cluster. The cluster uses AutoScaling Groups of EC2 instances, and during setup of the cluster you can choose the instance size you want and the number of instances for the initial cluster deployment.  Since the cluster can scale up and down, you have the flexibility if you get a spike in task usage, but you do need to keep an eye on underutilized or idle instances.

Containing the Containers

As you can tell, utilizing Amazon ECS containers manages a lot of the back-end work for you, but brings a whole different set of considerations for your organization.  ParkMyCloud has some news coming later this year to help you manage your ECS containers! Contact us if you’d like to be notified when that’s available.

Not yet using containers, but have other AWS infrastructure? We can help control costs.