devopsy.kinsta.cloud

Tag: AWS

  • Complete Guide to AWS Savings Plans

    Complete Guide to AWS Savings Plans

    AWS Savings Plans are a flexible and cost-effective way to save on your Amazon Web Services (AWS) usage. These plans allow you to commit to a specific amount of compute capacity over a one- or three-year term in exchange for a significant discount on your AWS usage. Savings plans can help you reduce your AWS bill by up to 72%, depending on the type of plan and your level of commitment.

    Why Do You Need AWS Savings Plans?

    With the growing reliance on cloud infrastructure in modern IT, it is crucial for organizations to optimize cloud computing costs without compromising on performance or scalability. AWS Savings Plans address this need by providing a flexible and cost-effective solution that allows you to commit to a certain level of usage at a discounted rate.

    With AWS Savings Plans, by committing to a specific amount of compute capacity over a set time period, you can save up to 72% on your AWS usage. This can result in significant cost savings for your organization, freeing up resources to invest in other business-critical initiatives.

    Another benefit of AWS Savings Plans is the flexibility they offer. Unlike Reserved Instances, which require you to specify instance type, operating system and region, Savings Plans are more flexible and can be applied across different instance types, regions and operating systems. This flexibility makes it easier for you to optimize your cloud computing costs while still meeting your business needs.

    Difference Between AWS Savings Plans and Reserved Instances

    AWS Savings Plans and Reserved Instances are both designed to help you save on your AWS usage, but they offer different levels of flexibility and cost savings.

    Reserved Instances require you to commit to a specific instance type, operating system and region for a one- or three-year term in exchange for a discount on your AWS usage. While this can result in significant cost savings, it also limits your ability to optimize your cloud computing costs based on changing business needs.

    AWS Savings Plans offer a more flexible solution that allows you to commit to a certain level of usage across different instance types, regions and operating systems. Additionally, in most scenarios, Savings Plans can provide a higher level of cost savings compared to Reserved Instances.

    Types of AWS Savings Plans

    There are two types of AWS Savings Plans: Compute Savings Plans and EC2 Instance Savings Plans.

    Compute Savings Plans

    Compute Savings Plans are the most flexible type of Savings Plans, providing a significant discount on your AWS usage across any instance type, region or operating system. This flexibility makes it easy for you to optimize your cloud computing costs based on your changing business needs.

    Compute Savings Plans offer a discount of up to 66% compared to on-demand pricing, depending on the level of commitment you make. They can be used across all AWS services that are powered by Amazon EC2 instances, including Amazon EMR, AWS Lambda and Amazon ECS.

    EC2 Instance Savings Plans

    EC2 Instance Savings Plans are a more specific type of Savings Plan, offering a discount on your AWS usage for a specific instance type within a region. These plans provide a higher level of cost savings compared to Compute Savings Plans, with discounts of up to 72%.

    EC2 Instance Savings Plans are ideal for organizations that have a predictable workload and require specific instance types within a region. However, they offer less flexibility than Compute Savings Plans, as they cannot be applied across different instance types, regions or operating systems.

    AWS Savings Plans Pricing Models

    AWS Savings Plans offer three different payment options to suit your organization’s budget and commitment level: All Upfront, Partial Upfront and No Upfront.

    All Upfront

    With the All Upfront payment option, you pay for the entire term of your Savings Plan upfront, resulting in the highest discount compared to on-demand pricing. This option is ideal for organizations that have the budget available to make a significant upfront payment in exchange for maximum cost savings.

    Partial Upfront

    The Partial Upfront payment option allows you to pay a portion of your Savings Plan upfront and the remaining balance on a monthly basis. This option provides a balance between upfront commitment and ongoing flexibility, with a lower discount compared to the All Upfront option.

    No Upfront

    With the No Upfront payment option, you pay for your Savings Plan on a monthly basis, with no upfront payment required. This option provides the lowest discount compared to on-demand pricing but offers the greatest flexibility for organizations with limited budgets or uncertain future usage requirements.

    How to Monitor and Manage AWS Savings Plans

    Monitoring and managing your AWS Savings Plans, as part of your overall cloud operations strategy, is critical to ensuring that you are optimizing your cloud computing costs and maximizing your savings. AWS provides several tools and services to help you monitor and manage your Savings Plans effectively:

    • AWS Cost Explorer: A powerful tool that allows you to analyze your Savings Plans usage and costs, helping you identify opportunities to optimize your cloud computing costs. With Cost Explorer, you can view your Savings Plans coverage, utilization and savings, as well as forecast your future usage and costs.
    • AWS Budgets: This service allows you to set custom cost and usage budgets for your organization, helping you track your Savings Plans usage and ensure that you are staying within your budget.
    • Savings Plans Recommendations: This feature analyzes your past usage and recommends the optimal Savings Plans for your organization. It can help you make informed decisions about which Savings Plans to purchase and how much commitment to make.

    Conclusion

    AWS Savings Plans are an excellent solution for organizations looking to optimize their cloud computing costs and save on their AWS usage. With their flexibility, cost savings and easy monitoring and management options, AWS Savings Plans are a valuable tool for any organization using AWS services.

    To unlock the full potential of AWS Savings Plans, it’s crucial to understand the different types of plans, their pricing models and how to effectively monitor and manage your usage. By doing so, you can maximize your savings and ensure that your organization is getting the most out of its investment in AWS.

  • AWS Identity and Access Management (IAM) Roles and How to use Them

    AWS Identity and Access Management (IAM) Roles and How to use Them

    Amazon Web Services relies on the AWS IAM service to govern who is authenticated and authorized to use AWS resources. It plays a hugely significant role in AWS security–and so do its various identities. Let’s look in more detail at IAM roles and how they work.

    What is the Purpose of IAM?

    When you create an AWS account, it has a single sign-on (SSO) identity called the AWS account root user, which has complete access to AWS services and resources. To avoid potentially disastrous issues arising from this kind of unfettered access, IAM allows shared access to the AWS account via identities.

    Based on the security-first model, AWS restricts all actions for all identities by default–apart from the root user. This restriction enables us to manage granular access for identities following the principle of least privilege, so permissions are granted only as required to execute daily tasks.

    What are IAM Roles?

    AWS users, federated identities and AWS roles are the three major categories of AWS Identities. IAM roles are conceptually similar to AWS users, but whereas a user is uniquely associated with a principal(users/apps/etc.), a role can be assumed by anyone who needs it.

    Rather than passwords or access keys, temporary security credentials are provided to whoever assumes the role. This eliminates the overhead of managing users and their long-lived credentials.

    Any of the following entities can assume a role to use its permissions:
    ● AWS user from the same account
    ● AWS user from a different account
    ● AWS service
    ● Federated identity

    Structure of an IAM Role

    The two essential aspects of an IAM role are the trust policy (who can assume the IAM role) and the permission policy (what the role permits the user to do).

    Trust policies use specified conditions to define and control which principals can assume the role. They prevent the misuse of IAM roles by unauthorized or unintended entities.

    Permission policies define what the principals assuming the role are allowed to do.

    Types of IAM Roles

    AWS IAM roles fall into one of the following major categories based on their trust policies:
    ● Service role
    ● Service-linked role
    ● Web Identity role
    ● SAML 2.0 federation role
    ● Custom IAM role

    Service Roles
    AWS services are the trusted entity type for these roles, which are created to allow AWS services to perform actions on the user’s behalf. They do this by inheriting the permissions assigned to the service role.

    You might wonder why AWS services need permission to access each other. It’s because, by default, even AWS services have no access to the resources in the AWS account. However, service roles allow AWS services to access resources based on their requirements.

    Most AWS services rely on service roles for optimal functioning. For example, they allow Cloudformation to create and delete resources on the user’s behalf based on a YAML or JSON file. The Amazon EC2 IAM role is a special type of service role. EC2 relies on an instance profile as a container for an IAM role, which is then assumed by the applications running within the EC2 instance to perform actions the role allows.

    Service-Linked Roles
    A service-linked role is a unique kind of IAM role linked to an AWS service. It simplifies the process of setting up a service by automatically adding all the required permissions for a service to perform actions on the user’s behalf. It is predefined by the service. Most service-linked roles do not permit changes to trust or permission policies.

    Web Identity Roles
    A user assumes a web identity role when they log in to AWS using an identity provider (IdP) such as Amazon and Facebook. Users do not have an identity within AWS itself; in exchange for an authentication token, they get temporary security credentials in AWS that map to an IAM role that is authorized to use the resources in the AWS account.

    SAML 2.0 Federation Roles
    These roles are assumed by users who are included in an external user directory, typically within organizations. This enables federated single sign-on (SSO), so that organizations can give users access to the AWS console and CLI without having to create a separate IAM user for each person. An organization that manages its employees in Microsoft Azure Active Directory could connect to AWS directly and give its users access to the AWS console and CLI based on the permissions provided to the SAML 2.0 federation role.

    Custom IAM role
    Custom IAM roles do not fit any of the other categories and support scenarios other than the ones listed above.

    What is the Time Limit for Assuming a Role?

    An entity can assume a role for as long as the IAM role’s session duration property dictates. For example, if the session duration for a role is set at 12 hours, the temporary credentials will expire 12 hours after they are issued.

    If you assume the role using the assume-role* command, you can specify a value for the session duration using the duration-seconds flag, ranging from 15 minutes to the maximum session duration permitted for the role. The default duration is one hour, but it can be extended to up to 12 hours. The session duration can be adjusted by editing the role.

    What About Role Chaining?

    One role can assume another role in a process known as role chaining. Role chaining cannot extend beyond an hour on the user session; it doesn’t follow the role’s maximum session duration field.

    And Cross-Account Access?

    IAM roles are often leveraged to enable cross-account access – the process of leveraging a principal in one account for access to resources in a different account. Organizations often maintain multiple AWS accounts to segregate environments such as development, staging, test, UAT, and production, and they grant identities from one account permission to access resources in another.

    This could be to process data in the production account and then anonymize and copy it to the UAT account, so that the frequency and attributes of data are the same. This keeps the UAT environment as close to the production environment as possible.

    How do IAM Roles Differ From Resource-Based Policies?

    Both identity-based policies and resource-based policies are permission policies, but identity-based policies are attached to identities such as users, roles, or groups, and resource-based policies are attached to resources such as S3, Amazon SQS queues, or VPC endpoints.

    Identity-based policies specify the actions the identity can take and on which resources, whereas resource-based policies determine who is allowed to access the resource to which they are linked and specify the actions they can perform. Resource-based policies must be inline and not managed. This list provides details of which resources support resource-based policies.

    Where both identity and resource-based policies are present, AWS evaluates them together. An action is permitted if it is allowed in either or both policies. If either policy contains an explicit DENY, it overrides the ALLOW.

    You can provide cross-account access using just the resources policy rather than using a role as a proxy. This is achieved by attaching a resource-based policy on the resource you want to share. This resource policy comprises all the principals allowed to access this resource, in contrast with an identity-based policy, which specifies the resources a principal has access to.

    Using a resource-based policy for cross-account access rather than roles has advantages.

    When a user assumes a role, they cede the permissions they have in the trusted account so that they can secure permissions in the trusting account (account with shared resources). With a resource-based policy, the user keeps their permissions in the trusted account, and they also secure access to the shared resources in the trusting account. The principal can access both accounts.

    AWS IAM Roles Anywhere

    AWS IAM Roles Anywhere is a kind of service role that permits on-prem machines or workloads external to AWS (such as servers, containers, and applications) to access resources on AWS by acquiring temporary security credentials. This completely eliminates the headache of managing long-term credentials.

    Workloads are required to have X.509 certificates issued by a certificate authority, which must be registered with IAM Roles Anywhere as a trust anchor. Though a relatively recent use case, it marks a move toward minimizing the usage of long-term credentials.

    Benefits of Using IAM Roles

    ● No management of long-term security credentials
    ● Support for Single Sign-on (SSO) using SAML 2.0
    ● Support for web identity federation, allowing users to log in via popular external identity providers (IdPs), such as Amazon, Facebook, and Google
    ● Enhanced security posture because you don’t have to rotate and replace short-term credentials (An expiry is already associated with them).
    ● Support for use cases such as cross-account access, Identity federation, AWS IAM Roles Anywhere

    Key Takeaways

    IAM roles are key pillars supporting, not just the IAM service, but the entire authentication and authorization flow. Their value extends beyond applications such as cross-account access, AWS IAM Roles Anywhere, and identity federation, being important for enhancing any organization’s security posture substantially. When used to their full potential, they can be extremely useful in IAM.

  • AWS Converts Cedar Policy-as-Code Tool to Open Source Project

    AWS Converts Cedar Policy-as-Code Tool to Open Source Project

    At the Open Source Summit North America conference today, Amazon Web Services (AWS) announced it is making Cedar, a language for defining permissions as policies that includes automated reasoning to mathematically prove an IT environment is secure, available as an open source project.

    In addition, AWS launched SnapChange, an open source fuzz testing tool that cybersecurity researchers can employ to discover vulnerabilities by replaying physical memory snapshots in a KVM virtual machine. Fuzz testing uncovers software security issues by monitoring how the system behaves while processing random data.

    David Nalley, director of open source marketing for AWS, said both projects are part of an ongoing AWS effort to contribute intellectual property to the open source community that plays a pivotal role in the applications that organizations deploy on the AWS cloud.

    AWS has been employing Cedar to provide IT organizations with the ability to write authorization policies as code that can be deployed anywhere. It is most widely used within the managed AWS Verified Permissions service that manages those processes on behalf of organizations that deploy workloads on its cloud.

    Cedar differs from other policy-as-code approaches because it employs automated reasoning, a computer science discipline that is considered a subset of artificial intelligence (AI), to enable machines to prove theorems and checks. That latter capability is especially critical to enable organizations to mathematically prove that compliance mandates have been continuously met, noted Nalley.

    Otherwise, IT organizations become wholly dependent on an assessment of intermittent audits conducted by humans that are likely to arrive at varying subjective conclusions, he noted.

    The latest open source contributions from AWS come at a time when there is more scrutiny being applied to how open source software is developed and employed. The scrutiny increased in the wake of a series of vulnerability disclosures involving open source software, such as the Log4j monitoring software project.

    The maintainers of many open source software projects often don’t have the resources or capabilities required to immediately patch a vulnerability every time it is discovered. That’s become especially problematic, because more research into open source software vulnerabilities is being conducted; it’s only a matter of time before a vulnerability is detected in software that was largely created by developers that have limited cybersecurity expertise. Enterprises that consume open source software need to pay careful attention to what dependencies they are creating when that software gets incorporated into an application environment. A patch for a zero-day vulnerability that is discovered might not be readily available.

    Hopefully, consumers of open source software will become more involved in its development by contributing code or making available the financial resources that maintainers need to devote time and effort to creating a timely patch to a vulnerability. In the meantime, however, they should also be reviewing what open source software is included in applications running in production environments. Cybercriminals are increasingly looking to discover and exploit vulnerabilities in not just existing applications but not also in components they know are likely to be employed across a wide range of downstream applications.

    As such, finding ways to apply more cybersecurity expertise to application development by embracing DevSecOps practices has become an imperative rather than a recommendation.

  • Linux 6.3: What’s New ¦ AWS Layoffs are a Worry

    Linux 6.3: What’s New ¦ AWS Layoffs are a Worry

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: A new Linux kernel drops and layoffs at Amazon Web Services point to trouble. (more…)

  • AWS Delivers on Latest Graviton3 Price/Performance Promise

    AWS Delivers on Latest Graviton3 Price/Performance Promise

    Amazon Web Services (AWS) has expanded the number of virtual machines based on the latest generation of its Graviton processors to include instances that support DDR-5 memory.

    The latest Amazon EC2 instance types, dubbed M7g and R7g, that are now generally available are based on the AWS Graviton3 processors developed using an architecture created by Arm. Previously, these instances were only available as part of a technology preview program.

    Rahul Kulkarni, director of product management at AWS, said these latest offerings take advantage of DDR-5 memory to provide 25% better performance than the previous sixth generation of Graviton instances. DDR5 memory increases the amount of bandwidth available by 50%, he noted.

    Graviton processors now provide the lowest-priced instance of virtual machines in addition to the best performance and overall price/performance across the AWS portfolio, Kulkarni added.

    AWS is making a case for employing its AWS Graviton processors for general-purpose workloads as more IT teams are being tasked with reducing costs as the overall number of applications being deployed in the cloud continues to increase. In fact, all of the top Fortune 50 companies have already deployed workloads on Graviton processors, noted Kulkarni.

    While it’s not clear how many applications are being developed to run natively on Arm processors, the process of refactoring existing applications to run on Arm processors is not as intensive for most applications as it was when previously moving applications from one class of processors to another.

    In addition, Kulkarni noted AWS has committed to providing a full range of DevOps services, including a continuous integration/continuous delivery (CI/CD) platform, to help facilitate any transition to Graviton processors.

    There are, of course, multiple strategies for containing cloud costs that range from committing to consuming a specified amount of compute resources annually at discounted rates to relying more on spot instances that are available for limited amounts of time. Regardless of approach, the days when developers were allowed to invoke cloud resources at will appear to have come to an end as enterprise IT organizations become more aware of the total cost of IT. As a result, many of them are adopting financial operations (FinOps) best practices to maximize the utilization of cloud infrastructure resources.

    AWS, like most cloud service providers, gives organizations a wide range of processor options. However, it’s apparent that AWS views Arm processors in the form of Graviton to be the most efficient from both a price and performance perspective. It’s not clear how quickly organizations are embracing Graviton in the cloud given the dominance of x86-based platforms, but it’s apparent there is now a clear alternative for general-purpose workloads. If fact, the more data-intensive those workloads become, the greater the interest in more efficient processor architectures.

    Of course, x86 platforms are not going away anytime soon. But as more Arm-based processors find their way into the enterprise, DevOps workflows will only become more challenging to manage.

  • Report Affirms Continued AWS Cloud Dominance

    Report Affirms Continued AWS Cloud Dominance

    A report published this week by Wiz, a provider of a cloud security platform, found more than half of organizations (57%) are using multiple clouds, with 22% currently using three or more platforms.

    However, the report also noted that 72% of all workloads are running on the Amazon Web Services (AWS) cloud. Among organizations that have more than one cloud platform, Microsoft Azure (41%) is the most common secondary platform (41%), while Google Cloud Platform (GCP) is the most used tertiary platform among organizations employing two or more clouds (44%).

    The report also noted 9% of AWS customers use managed database servers, compared to 87% in GCP and 82% in Azure. However, over 91% of companies also have non-managed database servers running in a cloud. In total, only 6% of companies use managed database servers exclusively, compared to 90% using a mix of managed and non-managed database servers, the report finds.

    The most widely deployed databases are PostgreSQL, Redis and MySQL, with 90% of organizations running at least one instance of a PostgreSQL server.

    Scott Piper, principal cloud security researcher for Wiz, said the report makes it clear that despite gains by Microsoft and Google, AWS remains the most dominant cloud service provider. Even after a decade, rival cloud service providers have not been able to overcome the first-mover advantage that AWS continues to enjoy. In many cases, a second or third cloud is being employed only because a single development team preferred it or an IT team assumed responsibility for it when their company acquired another organization using it, noted Piper.

    However, while most organizations have multiple accounts per cloud service provider, the report also found that the bulk of the application workloads are managed via only a handful of accounts, he added. That suggests more organizations are subject to higher levels of disruption in the event of an outage than many of them may realize, said Piper.

    One of the reasons so many organizations have a narrow range of accounts, of course, is they simply don’t have enough personnel. In fact, a general skills shortage also tends to limit the number of cloud platforms organizations might otherwise employ.

    Multiple cloud platforms also tend to exacerbate cybersecurity challenges. With the introduction of each additional cloud service, the overall size of the attack surface that needs to be defended expands. The Wiz report found 47% of organizations have at least one database or storage bucket publicly exposed to the internet. It can take less than 13 hours for cybercriminals to discover and access an exposed bucket with a guessable name, noted Piper.

    More challenging still are the number of application programming interfaces (APIs) that need to be secured as cloud service providers continue to add new services, he added.

    Ideally, organizations should be adopting a framework to harden privileges, encryption, authentication and connectivity and improve hygiene, otherwise known as PEACH, said Piper.

    Regardless of the approach to cloud computing, it’s apparent there’s still a long way to go before organizations are ready to embrace hybrid cloud computing spanning multiple clouds.

  • Voice.ai ‘Stole’ Code ¦ AWS Gets Filthier

    Voice.ai ‘Stole’ Code ¦ AWS Gets Filthier

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Alleged theft of GPL code, and Amazon will run its data centers on gas. (more…)

  • Best of 2022: Three Cloud Trends to Watch in 2022

    Best of 2022: Three Cloud Trends to Watch in 2022

    As we close out 2022, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

    Many developers and startups view cloud services as simply “compute”, “storage” and “networking.” The cloud has matured to the point where customers often don’t think about the underlying infrastructure, service levels or debate the merits of on-premises versus cloud&;mdash;instead, they are increasingly cloud-first. In fact, December of 2021 marked Amazon Web Services (AWS) marked its tenth AWS re:Invent conference—the company’s annual conference for customers and partners.

    While many startups don’t think twice about centering their IT strategy around the cloud and SaaS offerings, the enterprise has been slower to adopt cloud computing at scale. The conversation for these companies revolves around security, compliance, SLAs and the loss of control over their technology stack. In many ways, little has changed about the questions that enterprises are asking about the cloud.

    As the year starts, I’ve been reflecting on various conversations I’ve had with a variety of IT and business leaders, Digital CxOs and vendors. Below are three trends that I will be tracking this year.

    1. Alternative Vendors Gain Momentum

    The “big three” hyperscalers continue to dominate the market and garner the bulk of customer and partner attention. However, we are seeing increasing interest in the alternative cloud market. The alternative market includes vendors outside of the big names (AWS, Microsoft Azure, Google Cloud, Oracle, IBM and Salesforce). Developers and businesses are increasingly looking at alternative vendors and their offerings because they are easier to use than hyperscalers, less expensive and offer more predictable pricing models. In addition, with the tight labor market, hiring developers that are, for example, AWS certified can be extremely expensive. On the other hand, because alternative clouds are less complex, developers do not need to have the same certifications.

    You might ask: What about the global scalability, quantum computing and/or the thousands of APIs that the hyperscalers offer? The truth is that most small and midsize businesses don’t actually need any of those capabilities and don’t want to help subsidize the R&D that these technologies require. Companies to watch in the alternative cloud market include Linode, Digital Ocean, OVHcloud, UpCloud, Hetzner and Equinix Metal. In 2021, Techstrong Research published a report, DevOps and the Alternative Cloud, that dives deeper into these alternatives.

    2. Industry-Specific Cloud Ecosystems Expand

    Banking, insurance and companies in other highly-regulated industries have been slow to adopt cloud computing. However, the market is quickly evolving and businesses are rethinking their approach to the cloud. One of the reasons these regulated companies are starting to invest more heavily in the cloud is because customers have heightened expectations when it comes to how they engage with businesses. If customers are unhappy, it’s easier than ever to find alternatives. These highly-regulated companies and industries are being increasingly challenged by fintech, insurtech, healthtech and other industry-focused startups.

    Just as importantly, vendors are realizing that one size doesn’t fit all. Regulated industries need specific clouds that meet their regulatory and compliance needs. These industry-focused clouds aren’t being designed as an entire ecosystem where a variety of technology partners can offer their software to regulated industries. Instead, vendors have taken two different approaches to offering industry-specific offerings. Some providers are offering pre-built but customizable applications. Some notable announcements in the area of banking clouds include the following:

    • Goldman Sachs and AWS are working together to create data management and analytics solutions for financial services organizations (announced at re:Invent 2021). The result of this collaboration is the Goldman Sachs Financial Cloud for Data. It’s unclear if AWS will be offering a more general financial services ecosystem in the future.
    • IBM continues to grow its Cloud for Financial Services in terms of signature clients and partners. IBM built its cloud for financial services in collaboration with Bank of America, then hired the bank’s CTO, Howard Boville, to head up IBM’s hybrid cloud business.
    • Microsoft announced general availability of the Microsoft Cloud for Financial Services in November of 2021 (interestingly, it’s not named Azure for Financial Services). The company already has a large footprint in the financial services industry, and we’ll be tracking the adoption of Microsoft Cloud for Financial Services closely. In September 2021, Wells Fargo unveiled their digital infrastructure strategy that relies heavily on its partnership with Microsoft, but there is no mention of Wells Fargo using the Microsoft Cloud for Financial Services.

    I expect other industry-specific clouds to follow a similar pattern—with large vendors partnering with key industry incumbents to create cloud ecosystems that meet the performance, security and compliance requirements for that industry. For example, you can certainly imagine Oracle creating a Cloud for Health Care after the acquisition of Cerner closes.

    3. Software Supply Chain Becomes a Key Security Focus

    “Supply chain” was a key phrase across all industries and job functions in 2021. I’m particularly tracking the software supply chain—which, as you can imagine, is immense and complex. In essence, your software supply chain includes anything that might impact your software. That includes APIs, cloud services, containers, your DevOps pipeline and all of the open source components that you use. Software has many dependencies, and understanding the supply chain is critical to knowing your security and risk exposure. Take, for instance, the recent Apache Log4j vulnerability. Use of Log4j is pervasive, but how many companies were actually able to quickly identify what software is at risk? Check out Alan Shimel’s December blog post, Log4j: It’s All About the Supply Chain, Baby! to learn more about software supply chain security. In addition, API security is going to be a very hot topic in 2022.

    However, people remain the number-one cybersecurity threat. Although complex cyberattacks by ransomware gangs and state-sponsored actors get much of the attention, cloud misconfigurations and unpatched software are likely your biggest threats. Understanding your software supply chain will help uncover potential weak points and allow you to add automation, observability and/or other security tools to help spot potential problems.

    The Cloud Evolution

    Although the cloud isn’t new, the cloud market is continually evolving. While the developer community has been quick to adopt cloud computing, large enterprises have lagged—and regulated industries have been even slower. The alternative cloud market is offering different options for developers and businesses that don’t want the complexities of hyperscalers and don’t need their endless options and global footprint. At the same time, regulated industries are changing their cloud strategies thanks to cloud offerings that are uniquely focused on the challenges of their industry. Finally, you need to secure your software and data no matter where it resides. Focusing on your software supply chain will help ensure you can react to security vulnerabilities and update elements when needed.

  • AWS Saves Ukraine’s Data | WPF ‘is not Dead’ (yet) | Devs Quit for Cash

    AWS Saves Ukraine’s Data | WPF ‘is not Dead’ (yet) | Devs Quit for Cash

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Amazon S3 is keeping Ukraine’s data safe, we ask if Windows Presentation Foundation is dead, and developers tell us why they switch jobs. (more…)

  • Migration to AWS Cloud: Do’s and Don’ts

    Migration to AWS Cloud: Do’s and Don’ts

    What if one day, you were told to migrate to AWS/GCP/Azure/any other cloud provider? It would likely introduce some stress, to understate the case, right?

    I’ve seen quite a few migrations in my career and, in this article, I would like to share some thoughts to help DevOps engineers, architects, managers or anyone else who might be involved in such a migration. I’m focusing on migration to AWS mostly because I have a specialization in this subject and because it’s fairly common, but I think these experiences are applicable to any other cloud provider. For this case, I’ll cover migration from on-premises to a cloud because these types of migrations are much more difficult (in my opinion) than cloud-to-cloud migrations. I’ll also share my own perspective on do’s and don’ts of migrations. But please filter them through critical thinking and remember that everybody has their own background and experience. What’s good for one might be bad for another.

    What is a Cloud Migration?

    Let’s start by defining what migration is. How do you know if it’s a migration? I like the following definition: 

    Cloud migration is the process of moving a data center’s capabilities to IaaS providers.

    “Capabilities” is the keyword. A business does not migrate servers/virtual machines/hardware/data or anything else. A business migrates its capabilities.

    There are seven migration strategies (or seven Rs): Relocate, rehost (lift and shift), replatform, repurchase, rearchitect/refactor, retain and retire.

    For example, I’ve seen situations when a company was creating a new product that would replace an existing one hosted on-premises. The product would be designed to be well-architected and cloud-native from the very beginning and would be hosted in a cloud. Is that migration or greenfield project type? From the definition above, we can say that this is a migration. This is a rearchitecture strategy for migration.

    What if we buy a new SaaS subscription instead of some software we host on-premises? This is also a migration: A repurchase strategy.

    Let’s dig deeper into these seven migration strategies:

    Relocate. We host some workloads on-premises and move them as-is into the cloud. This is possible in limited cases; when we migrate cloud-agnostic workloads or when a platform might be cloud-native. Examples: Relocate a Kubernetes cluster from on-premises to the cloud or relocate VMware machines with VMware Cloud.

    Rehost. This is also known as lift and shift. We convert virtual machines/servers on-premises to virtual machines in the cloud. Examples: Migrate on-premises virtual machines to EC2 instances with CloudEndure, or create EC2 instances, install the software and apply the same configuration as on-premises.

    Replatform. We migrate a workload to a cloud-native platform without rearchitecting systems. Examples: Migrating PostgreSQL to AWS RDS or Docker containers to ECS.

    Repurchase. We replace some custom/legacy system with SaaS. Example: Replace custom on-premises email system with SendGrid or replace CRM with Salesforce.

    Rearchitect. We change your application’s architecture to be cloud-native and use managed cloud services. That also includes rebuilding from scratch. Examples: Change the code of your apps to upload files to S3 instead of local storage or containerize an app and migrate to ECS.

    Retire. We decide that a piece of the workload will be eliminated if not needed. Example: Log servers are no longer needed as migrated applications use CloudWatch.

    Retain. We leave it on-premises. Usually, it’s temporary. Example: A huge Oracle database with a lot of functions and customization is not moved to AWS because of the massive costs. It’s decided to keep it on-premises until it’s replaced with another solution in the modernization phase.

    I like the following picture that shows the high-level stages of each migration type. It may be a helpful cheat sheet to approach migrations.

    Picture Source: https://aws.amazon.com/blogs/enterprise-strategy/new-possibilities-seven-strategies-to-accelerate-your-application-migration-to-aws/

    Migration Don’ts

    I don’t recommend the following when performing a migration:

    Migrating too quickly. A business might think, “We have to migrate to the cloud quickly. Let’s do lift and shift right now!” It’s better not to start right away. Are you sure that rehosting strategy will really be faster than some other strategy? In one instance, we tried to migrate on-premises VMs, but it didn’t work because the OS on the machines was quite old. Some OS-level dependencies didn’t work on AWS’ hardware. This required a lot of configuration work, custom code and testing and the initial estimates were completely wrong. It eventually turned out to be a replatform. 

    Assess what you have, analyze it, analyze the business case and think. During this engineering work, we should stop and think before we act.

    Migration without clear goals. Why are you migrating? If you can’t answer the question, you probably need to find an answer or not migrate at all. I’ve seen situations in which businesses wanted to migrate to the cloud to reduce costs. They performed a lift and shift migration without doing a total cost analysis. Only after the fact did they realize that it cost even more than when it was in a colocation center. This migration may be considered unsuccessful.

    To avoid this, define clear goals and define the target state that achieves these goals. If costs are the driver, make the proper calculations and plan accordingly. Cost optimization will be the main thing to focus on when you plan your target state. If availability is the reason, measure it, define SLOs and focus on availability in a target state.

    Black box migration. Don’t treat workloads you migrate as a black box. It is almost critically important to know what exactly you migrate, what technical requirements it has, what dependencies it has and how it works. That information will allow you to choose the correct strategy for workload migration. If this is not done, there’s an excellent chance that you will choose the wrong path and the result will be lost. Capturing information about your systems is the most important task when planning.

    Don’t forget well-architected. Migration is stressful. That’s why people tend to try to get through it quickly on as short of a timeline as possible, focusing on the only thing: Making everything work in the cloud ASAP. They set aside well-architected framework pillars. This is a mistake; it may lead to a different set of negative consequences of different severity. Don’t ignore well-architected framework pillars, or you won’t know about potential issues or risks until they have already materialized.

    Use one strategy for everything. It’s always easy to make a single overarching plan for all workloads. For example, deciding to do lift and shift and then rehost everything in the cloud. But what if some things could be retired? What if some components could be replatformed with little effort? You will save significant resources by analyzing all of the components of the workload and deciding on a unique strategy for every component. Collect data and plan properly.

    Cloud Migration Do’s

    Do perform a cloud readiness assessment. If a person migrates to a new location, they should consider:

    • That the climate will be different
    • The language spoken in that location may be different
    • The cost of living will be different and perhaps more expensive

     When a company migrates to the cloud, they should ask questions including: 

    • Have we considered all the risks?
    • What must be changed for the workload to actually work?
    • Do we have the human resources required for all of the work?
    • Do I have the budget to accomplish everything? 

    The Cloud Readiness Assessment is a long-form interview about varying processes in the company that identifies whether a company is ready to live in the cloud. It’s based on the Cloud Adoption Framework (CAF) and allows us to understand what should be changed so that a migration can happen successfully. AWS has a Cloud Readiness Assessment tool which covers all of that. I urge you to use this process for all workloads being considered for migration.

    Create a business case. Describe the business case. What are the drivers for migration? What problems are resolved with the migration? What goals should be achieved by migration? Be specific: If you intend to reduce costs, then calculate the sum. If you intend to improve availability, then define a clear SLO. That will be the number-one driving force for your migration. All other artifacts should be based on it.

    Automate discovery and data collection. Use automated data collection and analysis to create a portfolio for migration. Don’t base your analysis on manually created spreadsheets or verbal communication. Let machines collect data about inventory and usage statistics. The more precise data you collect, the better. AWS Migration Evaluator service will help you to do this in most cases.

    Portfolio management. Create a portfolio of workloads to migrate, analyze them, choose a migration strategy for each, choose some for the pilot/first wave migration, estimate timelines and prepare a plan. Execute the migration after that. Repeat until the migration portfolio is empty. Share the data. Have subject matter experts review it.

    Found CCoE. This is part of the CAF mentioned above. Before executing the migration, create a team of people responsible for creating a strategy and defining a good standard of living in the cloud: A Cloud Center of Excellence. It should include people with a variety of subject matter expertise including management, operations, platform, people, finance and every other department consuming or providing services in the cloud. These people will prepare a landing zone for the migration, hard policies and softer policies for the landing zone; preparing the company for life in the cloud. Don’t fear revisiting any policy.  Make changes as new factors come to light.

    Well-architected framework reviews (WAFR). Do well-architected framework reviews (WAFRs) during migration waves and after them. That will allow you to avoid foolish mistakes and to get a high-level overview of what you have done from a technical perspective.

    Modernization plan. Prepare a modernization plan along with the migration plan. Migration isn’t the end of the story. To be effective in the cloud, you will have to do well-architected reviews and modernization. The first modernization is likely to be huge; that’s why it’s important to plan and to schedule budgets and resources in advance. Failure to do this will lead to increased operational costs, not decreased costs.

    Summary

    If we want to reduce the risk associated with a migration and to make it less stressful, we do not rush. You may believe that rushing will save you time and other problems will be managed later, but experience tells us that this is wrong. The most likely outcome is that you will end up resolving all the issues encountered in the most stressful situation possible: When you cut over to your new cloud-based production environment. Instead of resolving issues in a well-considered way and in advance, the choices will be made under duress. Proper engineering principles must be applied here. Picking up a bridge and moving it from one river and plunking it down on another never works. The key to migration success is to measure, analyze, design and plan. Migrating a workload to the cloud is hard, but I hope these do’s and don’ts will make it easier.