There are a few different AWS IP address types that AWS instances can be associated with: Public, Private or Elastic. IP addresses will be either an IPv4 or IPv6 address. Here’s a little more about these types.
A public IP is an address that can be reached from the internet. You can use a public address for communication between the internet and your AWS instances. The best use case for Public IP addresses is for small projects where a dynamic IP can be used without much overhead. AWS has over a million public IP addresses and is constantly adding new ones.
Public IP and Elastic IP addresses are similar in the sense that they are both public and allow instances to communicate with the internet. However, they differ because of the way they are associated with EC2 instances. Public IP addresses are assigned to your instances automatically from Amazon’s pool of public IPv4 addresses once they are launched and remain assigned to the instance until the instance is stopped. If an instance is stopped, a new public IP address will be assigned once the instance is started.
Now let’s look at Elastic IP addresses..
Elastic IP Addresses
An Elastic IP address is static and designed for dynamic cloud computing. An Elastic IP address is allocated to your AWS account rather than with a specific instance. When you associate an Elastic IP address with an instance, it remains allocated to your account and specific instance until it is disassociated from either.
Elastic IP addresses are most commonly used to help with fault-tolerant instances or software. For example, if you have an EC2 instance that has an Elastic IP address and that instance is stopped or terminated, you can remap the address and re-associate it with another instance in your account. You can also re-attach the same IP address to the same EC2 instance when it is restarted, allowing IP-based connections to work seamlessly – and making it possible to start and stop instances to save money while not in use, without losing the IP address.
When it comes to pricing, you can use one Elastic IP address while your instance is running at no charge. But, if you have any additional Elastic IP addresses associated with the instance, or have an EIP reserved and do not use it, you will be charged a small hourly rate of $0.01/hr.
A private address in AWS is an IP address that is not reachable over the internet. You would use private addresses for communication between instances in the same Virtual Private Cloud (VPC). Private IP addresses remain associated with the instance when it is stopped or rebooted, it will only disassociate once the instance is terminated.
When launched, an instance can be assigned a private IP address or EC2 will automatically assign an IP address to the instance within the address range of the subnet. If you don’t specify a primary private IP address, AWS selects an available IP address in the subnet range for you. An additional private IP address, known as secondary private IP address, can also be assigned.
Multiple IP Addresses
While you can give your instance multiple private IPv4 and IPv6 IP addresses, it’s important to note that the number of interfaces and private IP addresses you can specify for an instance depends on the instance type. Multiple IP addresses can be assigned and unassigned to network interfaces that are attached to instances that are stopped or running.
Once you launch an instance, you can assign a secondary private IP address to it. If the instance has already been launched, then you can assign a secondary private IP address to a network interface. A secondary private IPv4 address that’s assigned to a network interface can be reassigned to an additional one as long as you explicitly allow it.
A few use cases where it could be useful to assign multiple IP addresses to an instance in your VPC are:
If you want to host multiple websites on a single server by using multiple SSL certificates and associate every certificate with a specific IP address.
Operate network appliances that have multiple IP addresses for each network interface.
To redirect traffic to a standby instance in case your instance fails – this is done by reassigning a secondary IP address to the standby instance.
Move private IP addresses between instances or interfaces
Additional Aspects of IP Addresses to Know
Amazon Virtual Private Cloud (VPC)
Every EC2 instance in a VPC has a private IP address, users can also opt to have a public IP address. This is a virtual network that is dedicated to your AWS account. VPC offers the ability to have an isolated network that’s dedicated to you, that you can control.
A subnet is a range of IP addresses in your VPC. You can currently create 200 subnets per VPC. if an instance is in a public subnet, it can have either a private, public or elastic IP address. However, if an instance is in a private subnet, it will only have a private IP address with the option of an elastic IP address.
Elastic Network Interface (ENI)
An ENI is a virtual interface that can be created, configured and attached to an instance within a VPC. An ENI can include a public IP address, a primary private IP address, an optional elastic IP address, one or more secondary private IP addresses, and more.
If you’re powering off servers using ParkMyCloud, then you’ll want to use an Elastic IP if you need to connect from the outside world. Otherwise, use a private IP for connections from within your AWS VPC. If you’re going to use Public IPs, make sure you’re careful when restarting the servers as the public IP address will change once an instance has been stopped and started again.
It sounds obvious when you first say it: you can scale AWS ASGs (Auto Scaling Groups) down to zero. This can be a cost-savings measure: zero servers means zero cost. But most people do not do this!
Wait – Why Would You Want to?
Maybe you’ve heard the DevOps saying: servers should be cattle, not pets. This outlook would say that you should have no single server that is indispensable – a special “pet”. Instead, servers should be completely replaceable and important only in herd format, like cattle. One way to adhere to this framework is by creating all servers in groups.
Some of our customers follow this principle: they use Auto Scaling Groups for everything. When they create a new app, they create a new ASG – even if it has a server size of one. This can remove challenges to scale up in the future. However, this leaves these users with built-in wasted spend.
Here’s a common scenario: a production environment is built with Auto Scaling Groups of EC2 instances and RDS databases. A developer or QA specialist copies production to their testing or staging environment, and soon enough, there are three or four environments of ASGs with huge servers and databases mimicking production, all running, and costing money, when no one is using them.
By setting an on/off schedule on your Auto Scaling Groups, you can scale them down to a min/max/desired number of instances as “0” overnight, on weekends, or whenever else these groups are not needed.
In essence, this is just like parking a single EC2 instance when not in use. Even for an EC2 instance, users are unlikely to go into the AWS console at the end of a workday to turn off their non-production servers overnight. For ASGs, it’s even less likely. For a single right-click to stop an EC2 instance, an AWS ASG requires you to go to ASG settings, edit, modify the min/max/desired number of instances – and then remember to do the opposite when you need to turn them back on.
How You Can “Scale to Zero” in Practice
One ParkMyCloud customer, Workfront, is using this daily to keep costs in check. Here’s how Rob Weaver described it in a recent interview with Corey Quinn:
Scaling environments are a perfect example. If we left scaling up the entire time – 24/7 – it would cost as much as a production instance. It’s a full set of databases, application servers, everything. For that one, we’ve got it set so the QA engineers push a button [in ParkMyCloud], they start it up. For a certain amount of time before it shuts back down.
In other cases, we’ve got people who go in and use the [ParkMyCloud] UI, push the little toggle that says “turn this on”, choose how long to turn it on, and they’re done.
How else does Workfront apply ParkMyCloud’s automation to reduce costs for a 5X ROI? Find out here.
Another Fun Fact About AWS ASGs
One gripe some users have about Auto Scaling Groups is that they terminate resources when scaling down (one could argue that those users are pro-pet, anti-cattle, but I digress). If your needs require servers in AWS ASGs to be temporarily stopped instead of terminated, ParkMyCloud can do that too, with the “Suspend ASG Processes” option when parking a scale group. This will suspend the automation of an ASG and stop the servers without terminating them, and reverse this process when the ASG is being “unparked”.
Try both scaling to zero and suspending ASGs – start a free trial of ParkMyCloud to try it out.
It’s time to start thinking about AWS re:Invent 2020! Since 2012, AWS re:Invent has been one of the biggest cloud conferences every year – last year they drew over 60,000 attendees from around the world. Like many other big events, such as Google Cloud Next and Microsoft Ignite, re:Invent is going to look a little different this year. Over the course of three weeks (November 30 – December 18), AWS will be showing keynotes, launches and sessions – the best part is that it’s free to attend this year.
Every year there’s an unofficial listing of AWS and Vendor parties that are going on at re:Invent, while they obviously won’t be happening in person this year, we can expect there to be some watch parties and online events to look out for. Follow @reInventParties on twitter or check out their website to stay up to date on all the events.
Although planning your schedule will look different this year, here are a few things to keep in mind:
Make a schedule – block out some time on your calendar in advance to allocate enough time for the event. Once dates and times have been announced for keynote speakers and sessions, we recommend putting them into your calendar for a clean visual of your day, and reminders. With 3 weeks’ worth of events, it will certainly take some time to determine which sessions you are most interested in. We’ll keep this article updated once there is more information about the schedule and whether some of the tools like this one from Carlos E Silva will be available to help navigate the scheduler.
Take advantage of the online resources – since the event is virtual this year – and free – you aren’t as limited to what you can attend/do, so make sure you optimize this unique experience.
Attend a watch party – virtual watch parties allow you to connect with individuals around the world, helping to supplement what would be the in-person mingling at the actual event. If friends or coworkers are tuning in, create a channel to chat about sessions and announcements. Also, make sure to follow the #reinvent2020 and #reinvent hashtags on Twitter to follow along. Earlier this year for the online AWS Summit there were watch parties so we can expect the same for their biggest event of the year.
Look for swag and other offers from sponsors – just because you can’t visit sponsors booths doesn’t mean you can’t get swag or see a product/service. Most sponsors will likely have an online swag/prize giveaway as a creative way to get the audience involved to make up for the loss of time at the conference hall. If there are any vendors you’re interested in, sign up for their mailing lists now or make a Twitter list to keep an eye out for fun (Millenium Falcon lego set) and useful (free product license) offers.
Get engaged now – of course, AWS isn’t waiting for late November to offer new product intros, case studies, and best practice guides. Check out the upcoming Tech Talks now.
What Will Sponsor “Booths” Look Like This Year?
On that note, AWS is offering sponsor booths for past sponsors, and their materials offer a glimpse into the as-yet-unclear format of the conference, with mentions of virtual meeting rooms and attendee chats. It remains to be seen how much participation we’ll see overall in these. They seem to have a few special events in mind, which we’ll share here once there’s more information.
Look Forward to the Announcements
Last year at re:Invent, AWS announced the launch of a bunch of services and additional services that were in preview – lookout for the announcements this year! Although this isn’t your typical re:Invent experience, this virtual platform will be able to engage individuals like never before. AWS is anticipating more than 250,000 attendees during AWS re:Invent 2020.
The deliverability of cloud governance models has improved as public cloud usage continues to grow and mature. These models allow large enterprises to tier and scale their AWS Accounts, Azure Subscriptions and Google Projects across hundreds and thousands of cloud users and services. When we first started talking to customers 5+ years ago, mostly AWS users at the time, they often had a single AWS account for their entire organization and required third-party tools to manage usage and costs by project, line of business or application owner. But now, the “Big 3” cloud providers offer an array of ways for even the largest Fortune 500 enterprises to set up, run and manage their use of the dizzying volume of cloud services.
Why Cloud Governance Models are Important
The main way cloud providers allow cloud administrators to manage and grant access to their services is by leveraging Identity and Access Management (IAM) and providing options for roles and policies that govern both access and usage. IAM lets you grant granular access to specific AWS, Azure and/or Google Cloud resources and helps prevent access to other resources. IAM lets you adopt the security principle of least privilege, where you grant only necessary permissions to access specific resources like VM’s, Databases, Storage, Containers, etc.. With IAM, you manage access control by defining who (identity) has what access (role) for which resource.
In ParkMyCloud, we apply this with Teams and Roles. Admins can create Teams (equivalent to Projects, Applications, or Lines of Business) and can invite a Team Lead to manage that PMC Team, and they can in turn grant users access and set permissions for them, which can then by automated based on policies, usually by leveraging tags but you can use other metadata as well.
What if you want more flexibility with the cloud providers to both manage user access and to more tightly align your cloud services and usage to your organizational structure, projects and applications? Each of the major providers has designed ways for large enterprises to implement a hierarchical usage of cloud users and services that probably can look very similar to that enterprises organization chart. (If you can understand their jargon.)
How AWS, Azure, and Google Apply Cloud Governance Models
We dug into AWS, Azure and Google and this is what we found:
Amazon Web Services (AWS)
Tier 1: AWS Organization
Tier 2: Organization Unit
Tier 3: AWS Accounts
Tier 4: Tags
Tier 1: Azure Enterprise Portal
Tier 2: Departments
Tier 3: Accounts
Tier 4: Subscriptions
Tier 5: Resource Groups
Tier 6: Tags
Tier 1: Organization
Tier 2: Folders
Tier 3: Projects
Tier 4: Resources
Tier 6: Tags
Tips for implementing Cloud Governance Models:
Research and attend web sessions on these cloud governance models to ensure you understand the nuance
Implement your cloud provider’s latest hierarchies and governance models prior to mainstream cloud adoption in your organization
Make sure you run the hierarchies you plan to implement by CloudOps, ITOps, DevOps and FinOps to ensure proper organizational mapping and reporting
The cloud providers have done a pretty good job of documenting their roles, policies and hierarchies and creating a graphical representation of their current hierarchical structures cloud governance models. Of course, none of them use the same terminology – I mean, why would you, too easy, right? (And why does Google rank a ‘Folder’ above a ‘Project’? )
With these options available to you, your cloud operations team can make sure to use this to your advantage when planning new resources, accounts, and use cases within your organization. Let us know your thoughts and if you use any of these models to improve your cloud usage.
In July, AWS updated the cost optimization pillar of their Well-Architected Framework to focus on cloud financial management. This change is a rightful acknowledgment of the importance of functional ownership and cross-team collaboration in order to optimize public cloud costs.
AWS Well-Architected Framework and the Cost Optimization Pillar
If you use AWS, you are probably familiar with the Well-Architected Framework. This is a guide of best practices to help you understand the impact of the decisions you make while designing and building systems on AWS. AWS Well-Architected allows users to learn best practices for building high-performing, resilient, secure, and efficient infrastructure for their workloads and applications.
This framework is based on five pillars — operational excellence, security, reliability, performance efficiency, and cost optimization. Overall, AWS has done a great job with these particular resources, making them clear and accessible with links to further detail.
The Cost Optimization pillar generally covers principles we have been preaching for a long time: expenditure and usage awareness; choosing cost-effective resources; managing demand and supply resources; and regularly reviewing your environments and architectural decisions for cost.
Now, they have added Cloud Financial Management to this pillar. Cloud Financial Management is a set of activities that enables Finance and Technology organizations to manage, optimize and predict costs as they run workloads on AWS.
Why Do Businesses Need Cloud Financial Management?
Incorporating Cloud Financial Management into an organization’s cost optimization plans allows them to accelerate business value realization and optimize cost, usage and scale to maximize financial success.
This is an important part of the cost optimization pillar as it dedicates resources and time to build capability in specific industries and technology domains. Similar to the other pillars, users need to build capability with different resources, programs, knowledge building, and processes to become a cost-efficient organization.
The first step AWS proposes for CFM is functional ownership. (Further reading: Who Should Manage App Development Costs? and 5 Priorities for the Cloud Center of Excellence).The reason all of this is important is since many organizations are composed of different units that have different priorities, there’s not one standard set of objectives for everyone to follow. By aligning your organization on a set of financial objectives, and providing them with the means to make it happen, organizations will become more efficient. Once an organization is running more efficiently, this will lead to more innovation and the ability to build faster. Not to mention organizations will be more agile and have the means to adjust to any factors.
What You Need to Keep in Mind
When most people think of cost optimization they think of cutting costs – but that’s not exactly what AWS is getting at by adding cloud financial management to their framework. It’s about assigning responsibility; partnering between finance and technology; and creating a cost-aware culture.
In a survey conducted earlier this year by 451 Research, they found that adopting Cloud Financial Management practices doesn’t only lower IT costs. In fact, enterprises that adopted Cloud Financial Management practices also benefited in many other aspects of the organization such as, growing revenue through increased business agility, increasing operational resilience to decrease risk, improved profitability and the potential for increased staff productivity.
Cloud Financial Management increases with cloud maturity, so it’s important to be patient with the process and remember that small changes can have huge impacts and benefits can increase as time goes on.
Amazon provides you with a few services to manage cloud costs such as Cost Explorer, AWS Budgets, AWS Cost and Usage Report (CUR), Reserved Instances Recommendation and Reporting, and EC2 Rightsizing Recommendations. But, it’s important to note that while many CFM tools are free to use, there can be some costs associated with labor to build ongoing use of these tools and continuous organizational processes – it may be in your best interest to look into a tool that can optimize costs on an ongoing basis. Ensure your people and/or tools are able to scale applications to address new demands.
By using the framework to evaluate and implement your cloud financial management practices, you’ll not only achieve cost savings, but more importantly, you’ll see business value increase across operational resilience, staff productivity and business agility.
Q2 2020 earnings are in for the ‘big three’ cloud providers and you know what that means – it’s time for an AWS vs Azure vs Google Cloud market share comparison. Let’s take a look at all three providers side-by-side to see where they stand.
Note: several previous versions of this article have been published. It has been updated for August 2020.
AWS vs. Azure vs. Google Cloud Earnings
To get a sense of the AWS vs Azure vs Google Cloud market share breakdown, let’s take a look at what each cloud provider’s reports shared.
Amazon reported Amazon Web Services (AWS) revenue of $10.8 billion for Q2 2020, compared to$8.3 billion for Q2 2019. AWS revenue grew 29% in the quarter.
Across the business, Amazon’s quarterly sales increased to $88.9 billion, beating predictions of $81.5 billion. The net income of $5.2 billion was the highest in a single quarter yet for the giant, driven by online shopping during COVID-19 – though note that the company is careful to note the $4 billion in costs related to COVID-19. And AWS? It made up 12.1% of Amazon’s revenue for the quarter – and 64% of its profit.
AWS only continues to grow, and bolster the retail giant time after time.
One thing to keep in mind: you’ll see a couple of headlines pointing out that revenue growth is down, quoting that 29% number and comparing it to previous quarters’ growth rates, which peaked at 81% in 2015. However, that metric is of questionable value as AWS continues to increase revenue at this enormous scale, dominating the market (as we’ll see below).
While Amazon specifies AWS revenue, Microsoft only reports on Azure’s growth rate. That number is 47% revenue growth over the previous quarter. This time last year, growth was reported at 64%. As mentioned above, comparing growth rates to growth rates is interesting, but not necessarily as useful a metric as actual revenue numbers – which we don’t have for Azure alone.
Here are the revenue numbers Microsoft does report. Azure is under the “Intelligent Cloud” business, which grew 17% to $13.4 billion. The operating group also includes server products and cloud services (19% growth) and Enterprise Services (flat).
The lack of specificity around Azure frustrates many pundits as it simply can’t be compared directly to AWS, and inevitably raises eyebrows about how Azure is really doing. Of course, it also assumes that IaaS is the only piece of “cloud” that’s important, but then, that’s how AWS has grown to dominate the market. Microsoft’s release noted that “cloud usage and demand increased as customers continued to work and learn from home. Transactional license purchasing continued to slow, particularly in small and medium businesses, and LinkedIn was negatively impacted by the weak job market and reductions in advertising spend.”
However, overall, Microsoft exceeded analyst expectations in the first full quarter of the COVID-19 pandemic, with overall revenue coming in at $38 billion vs. $35.5 billion expected; and Intelligent Cloud revenue earning $13.4 billion vs. $13.1 billion expected.
This is the second quarter that Alphabet broke out revenue reporting for its cloud business. This quarter, Google Cloud, which includes Google Compute Engine and G Suite, generated $3 billion in revenue – a growth of 43% year-over-year.
Overall, Alphabet’s revenue decreased 2% year-over-year to $38.3 billion. CFO Ruth Porat said, “year-on-year declines in our advertising revenues from search and network were offset by growth in Google other and Google Cloud revenues,” continuing their ongoing messaging that cloud is important to the business as a whole. This comes as Google Cloud leans into product offerings intended at capturing the multi-cloud audience, such as the recent release of Big Query Omnithat aims to provide data analytics capabilities for workloads that live in AWS and Azure as well as Google Cloud.
Cloud Computing Market Share Breakdown – AWS vs. Azure vs. Google Cloud
When we originally published this blog in 2018, we included a market share breakdown from analyst Canalys, which reported AWS in the lead owning about a third of the market, Microsoft in second with about 15 percent, and Google sitting around 5 percent.
In 2019, they reported an overall growth in the cloud infrastructure market of 42%. By provider, AWS had the biggest sales gain with a $2.3 billion YOY increase, but Canalys reported Azure and Google Cloud with bigger percentage increases.
As of July 2020, Canalys reports AWS with 31% of the market, Azure at 20%, Google Cloud at 6%, Alibaba Cloud close behind at 5%, and other clouds with 37%.
It seems clear that in the case of AWS vs Azure vs Google Cloud market share – AWS still has the lead. However, their overall share of the market is slowly shrinking, while Azure grows.
Bezos has said, “AWS had the unusual advantage of a seven-year head start before facing like-minded competition. As a result, the AWS services are by far the most evolved and most functionality-rich.”
Our anecdotal experience talking to cloud customers often finds that true, and it says something that Microsoft isn’t breaking down their cloud numbers just yet, while Google leans into multi-cloud.
AWS remains far in the lead for now. With that said, it will be interesting to see how the actual market share numbers play out over the coming years.